Using onedrive backend fails with TypeError
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Duplicity |
New
|
Undecided
|
Unassigned | ||
Bug Description
I'm using duply to call duplicity on a Debian Jessie system. It uploads a few hundred MB each day to onedrive and was working for months without any issues. The last successful backup was on Jan 26th and since this date (almost) all commands always fail with the same error message:
Traceback (most recent call last):
File "/usr/bin/
if "Forced assertion for testing" in str(e):
TypeError: __str__ returned non-string (type Error)
Yes, it fails MOST of the time, not always. Today the following command executed successfully about 2-3 times in 50 tries. So I think it's quite unlikely it's a local problem or an issue in the duplicity onedrive backend. Also a colleague has exactly the same issue since about the same date.
/usr/bin/duplicity collection-status --name duply_owncloud --encrypt-key B44F3F99 --sign-key B44F3F99 --verbosity 9 --gpg-options --compress-
I modified line 1580 to print out a full backtrace and this is the complete output:
# /usr/bin/duplicity collection-status --name duply_owncloud --encrypt-key B44F3F99 --sign-key B44F3F99 --verbosity 9 --gpg-options --compress-
Using archive dir: /root/.
Using backup name: duply_owncloud
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Using temporary directory /tmp/duplicity-
Traceback (most recent call last):
File "/usr/bin/
with_
File "/usr/bin/
fn()
File "/usr/bin/
action = commandline.
File "/usr/lib/
globals.backend = backend.
File "/usr/lib/
obj = get_backend_
File "/usr/lib/
return factory(pu)
File "/usr/lib/
self.
File "/usr/lib/
user_
File "/usr/lib/
return self.request('GET', url, **kwargs)
File "/usr/lib/
headers=
File "/usr/lib/
resp = self.send(prep, **send_kwargs)
File "/usr/lib/
r = adapter.
File "/usr/lib/
raise SSLError(e, request=request)
SSLError: <unprintable SSLError object>
I've no experience in Python but for me this looks like an issue with SSL. Most likely provoked by the server side.
And this is the output on a successful run (some minutes later)
# /usr/bin/duplicity collection-status --name duply_owncloud --encrypt-key B44F3F99 --sign-key B44F3F99 --verbosity 9 --gpg-options --compress-
Using archive dir: /root/.
Using backup name: duply_owncloud
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
Import of duplicity.
OneDrive id for the configured directory "backups/ownCloud" is "folder.
Main action: collection-status
=======
duplicity 0.7.03 (May 11, 2015)
Args: /usr/bin/duplicity collection-status --name duply_owncloud --encrypt-key B44F3F99 --sign-key B44F3F99 --verbosity 9 --gpg-options --compress-
Linux srvt01 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-3~bpo8+2 (2015-12-14) x86_64
/usr/bin/python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2]
=======
Local and Remote metadata are synchronized, no sync needed.
797 files exist on backend
163 files exist in cache
Extracting backup chains from list of files: [u'duplicity-
-- LOTS OF LINES REMOVED --
Found primary backup chain with matching signature chain:
-------
Chain start time: Mon Jan 4 00:30:05 2016
Chain end time: Tue Jan 26 00:30:06 2016
Number of contained backup sets: 21
Total number of contained volumes: 103
Type of backup set: Time: Num volumes:
-------
No orphaned or incomplete backup sets found.
Releasing lockfile <lockfile.
Using temporary directory /tmp/duplicity-
Duplicity is absolutely perfect to backup to storage you don't trust (as onedrive). But it looks like the access to onedrive is so unreliable since a few weeks it's unusable. I've tried accessing onedrive using the web browser and this works perfect all the time and I still have about 800GB of free space on my onedrive account. Anyone else experiencing the same problems? Any ideas how to solve this?
My environment:
- duplicity 0.7.03
- duply v1.9.1
- Python 2.7.9
- Debian Jessie 64bit
| ThomasL. (tht) wrote | #1 |
| ThomasL. (tht) wrote | #2 |
I've sniffed all the network traffic and this is what I get:
* TCP Connection is open
* Server sends his certificate
* Client responds with "Alert (Level: Fatal, Description: Unknown CA)"
* Client aborts the connection
So why do I get a certificate issue most of the time but not always? This smells like a server side issue. But then again, all my duplicity commandlines do have --ssl-no-