SMB Error: "Backup Failed. Success"

[SB]

I just made today some changes to which directories should be backed up. Deja Dup seemed to be accepting the changes and started the back up. The process failed with a weird notification window which I don't know what to make of. Title says "Backup failed" and then it says "Success" in the window itself. See attached screenshot. Kinda funny, don't you think?! :-)
I don't know where I can find log files to see if there is any extra information that can be usefull

[Kieran Hogg (xerosis)]

Confirming as I saw this. For the record, I don't think the backup did complete successfully.

[Michael Terry (mterry)]

Setting high, because Kieran reports the backup was not successful.

[Michael Terry (mterry)]

SB, interesting error indeed! :) To get log information and help me fix this, please upload the following:

The file /tmp/deja-dup.log after running the following line and replicating the problem (you may want to scrub the log of any incriminating file names or details):
    DEJA_DUP_DEBUG=1 deja-dup | tail -n 200 > /tmp/deja-dup.log

[SB (sonny-benshimon)]

Michael, I can't seem to be able to reproduce this error message.

Ever since this bug though, Deja Dup NEVER completes a backup in my case. I keep getting an error window with title "Backup Failure" and "Invalid Argument" in the window panel. I think that I don't have enough disk space left on my backup partition (I am backing up to a HD connected by USB to my wireless router and I don't have an easy access to see the amount of free space).
Does Deja sup fail gracefully in case there is no more space on the backup destination?

[Michael Terry (mterry)]

It should fail gracefully in the sense that it gives you a sensible error message about it.

How are you connecting to the remote storage? WebDAV? SMB?

Your "Invalid Argument" message reminds me of bug 545486. Which, to summarize, is about duplicity's failure to retry list() operations on the backend, which is apparently necessary for some connection methods like WebDAV.

If you could, please try the instructions in comment 15 there (https://bugs.launchpad.net/deja-dup/+bug/545486/comments/15) and let me know how that goes.

[Launchpad Janitor (janitor)]

[Expired for Déjà Dup because there has been no activity for 60 days.]

[Michael Rodríguez-Torrent (mrtorrent)]

Hi folks, just wanted to add that I just experienced this issue about a day and a half into a full backup. It seems a bit nonsensical, surely Deja Dup shouldn't be giving a "success" message in a failure dialogue?

[Michael Rodríguez-Torrent (mrtorrent)]

Subsequent backups have succeeded and I've been unable to reproduce this issue, unfortunately.

[Michael Terry (mterry)]

Lowering to medium importance, since it isn't very reproducable.

[ttnyny (ttnyny)]

I have the same problem. I am backing up to a USB drive attached to a Netgear wireless router.

In configuring Deja Dup, after struggling with the "Storage" (i.e., file location) settings for a while, I selected custom location and added the following URI:

  smb://router-drive/usb_storage/Notebook_Backup

Where "router-drive" is the name of the USB drive attached to my router, "usb_storage" seems to be a necessary part of the path to the USB drive (not sure why ... ), and "Notebook_Backup" is the folder I created on the USB drive for this purpose.

Deja Dup seems to find the USB drive and folder and begin the back-up process, but at a certain point stops and flashes the "Backup Failed ... Success" message. The routine did create about 250 Duplicity .gpg files (26.2 MB each) in /Notebook_Storage, but I have no way of telling if the back up is complete. The USB drive is not even 10% full.

I am running Ubutu 11.10, and this is my first involvement with Duplicity or Deja Dup. In case it's not painfully obvious from the above, I'm a Linux beginner with 10 years of experience .....

[Todd Little (little-x)]

I've had this problem for several months, i.e., the Backup failed.. success message. What steps should I take to help debug this problem as I'm fairly certain I haven't had any good backups in months?

[Todd Little (little-x)]

Here's a log from my system that returns the Failed/Success message:

DUPLICITY: INFO 2 54999298190
DUPLICITY: . Processed volume 1145

DUPLICITY: DEBUG 1
DUPLICITY: . Registering (mktemp) temporary file /tmp/duplicity-T5XHyy-tempdir/mktemp-wg1ZQH-147

DUPLICITY: INFO 11
DUPLICITY: . AsyncScheduler: running task synchronously (asynchronicity disabled)

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://tlittle@media/backups/duplicity-full.20120421T000419Z.vol1146.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed: Error: Connection timed out

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 309, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Connection timed out
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://tlittle@media/backups/duplicity-full.20120421T000419Z.vol1146.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 2 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 309, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Success
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://tlittle@media/backups/duplicity-full.20120421T000419Z.vol1146.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 3 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 309, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Success
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://tlittle@media/backups/duplicity-full.20120421T000419Z.vol1146.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 4 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 309, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target....

[Michael Terry (mterry)]

Ah, thanks Todd. That's what I was going to ask for. So it seems like we are getting that directly from gvfs when it tries to write to a Windows share.

Is everybody that gets this using SMB?

[Bryce Bias (biasbryce)]

Yes, I can confirm that. Using the same type of setup he is (Netgear router, same path structure) and I'm using 12.04. It creates the several duplicity files, all 26.2 mb.

[jan-teichmann (teichmann-jan)]

I have the same problem on Fedora 17 with
deja-dub-20.2
duplicity-0.6.18

DUPLICITY: DEBUG 1
DUPLICITY: . Selecting /home/jan/Documents/CITY/reading/xan-22-3-321.pdf

DUPLICITY: DEBUG 1
DUPLICITY: . Comparing ('home', 'jan', 'Documents', 'CITY', 'reading', 'xan-22-3-321.pdf') and None

DUPLICITY: DEBUG 1
DUPLICITY: . Getting delta of (('home', 'jan', 'Documents', 'CITY', 'reading', 'xan-22-3-321.pdf') /home/jan/Documents/CITY/reading/xan-22-3-321.pdf reg) and None

DUPLICITY: INFO 4 'home/jan/Documents/CITY/reading/xan-22-3-321.pdf'
DUPLICITY: . A home/jan/Documents/CITY/reading/xan-22-3-321.pdf

DUPLICITY: INFO 11
DUPLICITY: . AsyncScheduler: running task synchronously (asynchronicity disabled)

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://ENTERPRISE;XXXXXXXXXX@samba1/homes/backup/duplicity-full.20121112T172651Z.vol23.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 311, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Success
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://ENTERPRISE;XXXXXXX@samba1/homes/backup/duplicity-full.20121112T172651Z.vol23.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 2 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 311, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Success
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://ENTERPRISE;XXXXXXX@samba1/homes/backup/duplicity-full.20121112T172651Z.vol23.difftar.gz

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 3 failed: Error: Success

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backend.py", line 311, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 119, in copy_file
DUPLICITY: . target.get_parse_name())
DUPLICITY: . File "/usr/lib64/python2.7/site-packages/duplicity/backends/giobackend.py", line 95, in handle_error
DUPLICITY: . raise e
DUPLICITY: . Error: Success
DUPLICITY: .

DUPLICITY: INFO 1
DUPLICITY: . Writing smb://ENTERPRISE;XXXXXXX@samba1/homes/backup/duplicity-full.20121112T172651Z.vol23.difftar.gz

DUPLICITY: WARNING 1
DUPLICIT...

[Bob Kerns (rwk)]

A possible clue...and workaround.

I had the same symptoms. I looked on the smb: share (on a Windows 7 system, stored on a Drobo). I found that the last archive written was zero-length, likely due to an error on the first attempt. Thereafter, it repeatedly died at the same point, with the weird "success" error and/or the illegal argument error.

In order to delete the file, I had to first forcibly close it; even exiting Duplicity / deja-dup didn't close the file as far as Windows was concerned. I had to use 'net file' and 'net file <id> /close' to close it.

My backup is now happily proceeding again.

I'm running Ubuntu 12.10 from the install DVD. 1GB ethernet between this system and the Windows system. USB 2.0 to the Drobo 2nd gen.

[Ronald Poulin (rrpoulin)]

Another possible clue... and workaround ?

I have the exact same problem on Mint 14/Samba on Amahi server. I took the advice offered from Bob Kerns. When the problem occurs, and I cancel the backup, I cannot un-mount the share because it is kept open by a process on my laptop that I cannot find in the process list. After several attempts, I figured out that if I log out and log back in, I can delete the 0 byte archive on the server. This probably means it is a user process that does not terminate correctly (me thinks Duplicity).

After running a full backup several times, I figure out that deja-dup failed nearly on the same archive each time. I was not using password encryption so, I started from a clean slate, ran a full backup with password encryption turned on and still got failures but not as many, and in different archives.

I think - mind you that I am not an expert - that there is a data pattern that trips the receiving samba process into a failure that Duplicity cannot handle but I'm only guessing here.

[Ronald Poulin (rrpoulin)]

One more clue:

After a couple more tries I reloaded my system but this time, instead of using a cinnamon session, I used a gnome classic interface. Guess what, it went like grease on a door knob! Not a single glitch. I also found how to reproduce the error: Make the back up fail: Usually, this is a hang where there is one archive at 0 bytes left in the destination. Once that happens do not logout to reset the session. Restart the backup and it will eventually give you a success message with a backup fail session. It appears that this condition occurs when the ghost process isn't stopped by the logout/login reset.

So, my burning question: Would this be a GTK issue or something related to the new version of Cinnamon?

[Michele Costantino Soccio (michelinux)]

@Michael Terry
I can reproduce the problem any time I want (ie I'm desperately trying to do a backup).
I am using an SMB sharing on a box (something my internet provider gave me). I'd like to understand and help you understand what's going on, but I cannot find any log. Where could I look for it?
No duplicity processes are running once it fails.
My system is Ubuntu 12.10

[John Sage (jsage-c)]

Ubuntu 12.10, Linux tweedle 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 i686 i686 GNU/Linux

 smbd --version Version 3.6.6

After reading down these posts, I think your real problem is with SMB. After a Ubuntu upgrade last spring I've had random, persistent and transient SMB errors that get logged but that do not seem to have any serious effect. NOTE that I haven't been paying a lot of attention to this because the SMB problem seems to immediately resolve itself (the SMB process re-spawns?) and life goes on.

This *may* be the most recent of those, can't recall the exact date and time:

[2013/02/16 16:07:51.038682, 0] lib/fault.c:47(fault_report)
  ===============================================================
[2013/02/16 16:07:51.051266, 0] lib/fault.c:48(fault_report)
  INTERNAL ERROR: Signal 11 in pid 21916 (3.6.6)
  Please read the Trouble-Shooting section of the Samba3-HOWTO
[2013/02/16 16:07:51.051391, 0] lib/fault.c:50(fault_report)

  From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2013/02/16 16:07:51.051494, 0] lib/fault.c:51(fault_report)
  ===============================================================
[2013/02/16 16:07:51.051569, 0] lib/util.c:1117(smb_panic)
  PANIC (pid 21916): internal error
[2013/02/16 16:07:51.220998, 0] lib/util.c:1221(log_stack_trace)
  BACKTRACE: 22 stack frames:

OK.

I too have suddenly begun seeing the Duplicity errors yesterday and today.

I too have a Duplicity archive file as a zero-length file on my backup device (Netgear NAS which works perfectly in all other regards).

I too cannot directly delete that zero-length file "Device or resource busy".

I too cannot *usually* unmount the Netgear NAS backup share in Nautilus -- but today I can, and when I do a 'ps ax grep 'dup'' I do NOT see the following Python script running now that the backup has failed:

32178 ? DNsl 7:43 /usr/bin/python /usr/bin/duplicity --include=/home/jsage/.cache/deja-dup/metadata --include=/home/html/www.finchhaven.com --exclude=/home/jsage/Downloads --exclude=/home/jsage/.local/share/Trash --exclude=/home/jsage/.xsession-errors --exclude=/home/jsage/.thumbnails --exclude=/home/jsage/.gvfs --exclude=/home/jsage/.adobe/Flash_Player/AssetCache --exclude=/home/jsage/.cache/deja-dup --exclude=/home/jsage/.cache --include=/home/jsage --exclude=/sys --exclude=/proc --exclude=/tmp --exclude=** --gio --volsize=25 / smb://finchnet-nas.local/backup/Tweedle --no-encryption --verbosity=9 --gpg-options=--no-use-agent --archive-dir=/home/jsage/.cache/deja-dup --log-fd=19

In the past I have not been able to unmount the Netgear backup share because some (unknown at that time) Python script had it "busy".

[John Sage (jsage-c)]

Now running a manual backup; can see 28 26.2 MB *vol287* to *vol314* files on my Netgear NAS which were uploaded roughly 3 to 6 per minute; it's been sitting on a zero-length *vol315* for about 20 minutes, and the "Uploading" status bar hasn't moved.

[John Sage (jsage-c)]

OK. Essentially an hour later, gave up and clicked "Resume later".

Last file written was the zero-length *vol315* at 9:21 am.

At ~/.cache/deja-dup/8-blah-blah-blah-e/ duplicity-full-signatures.20130109T045118Z.sigtar.part and duplicity-full.20130109T045118Z.manifest.part were the last files written at 9:21 am.

Never any entry at /var/log/samba/log.smbd -- I was tailing it...

Never any entry seen at ~/.gvfs/

*vol315* cannot be deleted: "Device or resource busy"

ps ax |grep 'dup'
2637 ? Sl 0:02 /usr/lib/i386-linux-gnu/deja-dup/deja-dup-monitor

kill -hup 2637 and *vol315* still cannot be deleted.

ps ax |grep 'dup' now shows nothing.

The Netgear NAS is unmountable because it's tied-up with a very low-PID process; that process always seems to have exited or re-spawned because a ps -xxx never shows anything.

And ... I gotta get back to work.

[Thierry Bonifas (stebs)]

If this bug is indeed provoked by hard to reproduce/fix smb/gvfs/network errors (was on lan btw), wouldn't it be the obvious way to fix it by checking for a 0 byte file after 5 failed attempts, delete it and try another 5 times?

[Pablo180 (paultait22)]

Same problem, same Failure and Success message. Using Ubuntu 12.10 and to a back up using Samba. It had been working fine for weeks, but I made a change to the folders to ignore, and now I have this error. Tried to run back up twice, same error both times.

[John Sage (jsage-c)]

I've now got definitive, anecdotal proof that the zero-length file (and resulting backup failure) is Ubuntu/smbd/Linux kernel related.

All day I've been trying to use Nautilus to move thousands of 13-14MB files off my Linux/Ubuntu file server and onto my Netgear NAS for archiving.

Every attempt fails after some random number of files are moved when a zero-length file is written on the NAS, and something -- Nautilus, smbd, the Linux kernel, who knows -- looses its mind and the file move comes to a halt. I have to close out Nautilus and start all over, maybe move several hundred files, and *bang* it dies again. Lather, rinse, repeat.

Why do I know it's one or several of Nautilus/Ubuntu/smbd/Linux kernel related?

I've gone onto one of my Win & boxes, <ctrl-a> selected 2,516 13-14MB files on my Linux/Ubuntu file server, <ctrl-x> cut them, and have <ctrl-v> pasted them into the Netgear NAS. I've moved over 1,900 files so far, at 10.0 MB/sec, with no problem whatsoever.

So there's a problem specific to Ubuntu -> NAS, big-time, but Win 7 -> Ubuntu -> NAS works like a charm.

Figure that one out...

[Thomas Bechtold (toabctl)]

I can confirm the problem with smb backend. Here's my log output:

$ DEJA_DUP_DEBUG=1 deja-dup --backup
DUPLICITY: INFO 1
DUPLICITY: . Using archive dir: /home/tom/.cache/deja-dup/c29ce7486bdf2672249a6257f783d051

DUPLICITY: INFO 1
DUPLICITY: . Using backup name: c29ce7486bdf2672249a6257f783d051

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.ftpsbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.rsyncbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.u1backend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.webdavbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.cloudfilesbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.ftpbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.tahoebackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.hsibackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.gdocsbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.imapbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.sshbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.botobackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Import of duplicity.backends.localbackend Succeeded

DUPLICITY: INFO 1
DUPLICITY: . Main action: collection-status

DUPLICITY: INFO 1
DUPLICITY: . ================================================================================

DUPLICITY: INFO 1
DUPLICITY: . duplicity 0.6.20 (October 28, 2012)

DUPLICITY: INFO 1
DUPLICITY: . Args: /usr/bin/duplicity collection-status --include=/home/tom/Software --include=/home/tom/Music --include=/home/tom/env --include=/home/tom/Pictures --include=/home/tom/Documents --exclude=/home/tom/.cache/thumbnails --exclude=/home/tom/Downloads --exclude=/home/tom/.local/share/Trash --exclude=/sys --exclude=/proc --exclude=/tmp --exclude=/home/tom/.xsession-errors --exclude=/home/tom/.thumbnails --exclude=/home/tom/.gvfs --exclude=/home/tom/.adobe/Flash_Player/AssetCache --exclude=/home/tom/.cache/deja-dup --exclude=/home/tom/.cache --exclude=** --gio smb://fritz.box/mass-storagedevice-01/tom --no-encryption --verbosity=9 --gpg-options=--no-use-agent --archive-dir=/home/tom/.cache/deja-dup --log-fd=17

DUPLICITY: INFO 1
DUPLICITY: . Linux avocado 3.8-trunk-amd64 #1 SMP Debian 3.8.5-1~experimental.1 x86_64

DUPLICITY: INFO 1
DUPLICITY: . /usr/bin/python 2.7.4 (default, Apr 10 2013, 23:24:08)
DUPLICITY: . [GCC 4.7.2]

DUPLICITY: INFO 1
DUPLICITY: . ================================================================================

DUPLICITY: NOTICE 1
DUPLICITY: . Local and Remote metadata are synchronized, no sync needed.

DUPLICITY: WARNING 1
DUPLICITY: . Attempt 1 failed: Error: Invalid argument

DUPLICITY: DEBUG 1
DUPLICITY: . Backtrace of previous error: Traceback (innermost last):
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 316, in iterate
DUPLICITY: . return fn(*args, **kwargs)
DUPLICITY: . File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", l...

[Felix Griewald (tiiunder)]

I have the same problem. Is there any fix now? I'm using Ubuntu 12.04. I already tried to delete the 0-length file, but it didn't help. I still get the problem.

[Felix Griewald (tiiunder)]

Here is my log file of this error

[Michael Terry (mterry)]

Does this still affect people? The oldest duplicate is from 2013. The samba GVFS backend is a moving target, it might have fixed this in the meantime.

[Launchpad Janitor (janitor)]

[Expired for Déjà Dup because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for deja-dup (Ubuntu) because there has been no activity for 60 days.]