"Operation not supported by backend" when backing up to smb server

This was my mistake.

SMB is considered a local folder (file). Setting it up that way works fine.
The credentials are asked for during backup (in 34.x one had to enter Username / Domain)

Sorry again, ignore #2.

The backup to a remote SMB server does not work

OK, I'm not entirely sure why you hit this situation, but I can see in the code why you might end up with that error. So I've committed a fix to avoid ending up there, and added code to print the error to the console, so next time this happens we can have more of a clue.

https://git.launchpad.net/deja-dup/commit/?h=36&id=9954525d56b2b604114cbc7fbf15d99983edfacb

today the update of deja-dup came in (35.6-0ubuntu1 -> 36.0-0ubuntu1)

There is no directory /var/cache/samba which the application searches for.

creating it, does not help ->
Backup failed
Operation not supported by backend

$ deja-dup

(org.gnome.DejaDup:5945): Gtk-WARNING **: Allocating size to AssistantBackup 0x55b7940d0d70 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

** (org.gnome.DejaDup:5945): WARNING **: BackendRemote.vala:83: Could not find enclosing mount

** (org.gnome.DejaDup:5945): WARNING **: BackendRemote.vala:83: Could not find enclosing mount

starting deja-dup with sudo rights ->
Backup failed
volume doesn’t implement mount

on the console deja-dup complains that it cannot find /var/cache/smb:
$ sudo deja-dup

** (org.gnome.DejaDup:5846): CRITICAL **: string_contains: assertion 'self != NULL' failed

(org.gnome.DejaDup:5846): Gtk-WARNING **: Allocating size to AssistantBackup 0x5609b7db2070 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
gpg: WARNING: unsafe ownership on homedir '/home/wolf/.gnupg'

** (org.gnome.DejaDup:5846): WARNING **: BackendRemote.vala:83: Containing mount for file /var/cache/smb:/s4 not found

mounting the backup volume ->
Backup failed
volume doesn’t implement mount

$ sudo deja-dup

** (org.gnome.DejaDup:5987): CRITICAL **: string_contains: assertion 'self != NULL' failed

(org.gnome.DejaDup:5987): Gtk-WARNING **: Allocating size to AssistantBackup 0x55f188b7f450 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
gpg: WARNING: unsafe ownership on homedir '/home/wolf/.gnupg'

** (org.gnome.DejaDup:5987): WARNING **: BackendRemote.vala:83: Containing mount for file /var/cache/smb:/s4 not found

creating /var/cache/smb ->
Backup failed
volume doesn’t implement mount

$ sudo mkdir smb
wolf@mbpr13b:/var/cache$ sudo deja-dup

** (org.gnome.DejaDup:6045): CRITICAL **: string_contains: assertion 'self != NULL' failed

(org.gnome.DejaDup:6045): Gtk-WARNING **: Allocating size to AssistantBackup 0x558b0333f3a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
gpg: WARNING: unsafe ownership on homedir '/home/wolf/.gnupg'

** (org.gnome.DejaDup:6045): WARNING **: BackendRemote.vala:83: Containing mount for file /var/cache/smb:/s4 not found

Even giving o+w does not help

This can be tested on a plain 17.10 installation

Thanks for the update, Wolf!

The first error you reported is the real one [1]: "Operation not supported by backend." Samba has a history of being a bit flaky over gvfs. I'll try to reproduce here and see if I know why this is happening for ya.

[1] Don't bother running deja-dup with sudo, it's not surprising that it doesn't work. Root doesn't have the same access to the user's DBus session that the user does. So a lot of stuff (including all gvfs file operations) fails.

Does this work if you open your samba server in Nautilus ("Files")? Deja-dup just uses the same gvfs operations nautilus does. If it works there, it should work in deja-dup.

Sorry, don't get the question:

I tried to mount the samba share and run deja-dup then. This led to the error.

I can however access the files on this share from Nautilus without any issues (i can create a file, copy and delete it)

I have set up that the password is not required on reconnect so it can't even be that authentication does not work.

However, the backup volume is about 2000 files per full backup (~ 60GB). In 17.10 Nautilus is pretty slow to load the file list (~3s). Can this be caused by a timeout?

Does that answer your question.

upgraded to deja-dup 36.1. -> Backup failed
Operation not supported by backend

syslog:
Sep 15 12:27:23 mbpr13b deja-dup[1983]: BackendRemote.vala:83: The specified loc
ation is not mounted
Sep 15 12:27:23 mbpr13b gvfsd[1375]: mkdir failed on directory /var/cache/samba: Permission denied
Sep 15 12:27:25 mbpr13b gvfsd[1375]: message repeated 9 times: [ mkdir failed on directory /var/cache/samba: Permission denied]
Sep 15 12:27:25 mbpr13b deja-dup[1983]: BackendRemote.vala:83: Could not find enclosing mount
Sep 15 12:27:25 mbpr13b dbus-daemon[1335]: Activating via systemd: service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service'
Sep 15 12:27:25 mbpr13b systemd[1321]: Starting Virtual filesystem metadata service...
Sep 15 12:27:25 mbpr13b dbus-daemon[1335]: Successfully activated service 'org.gtk.vfs.Metadata'

Hrm. Is it possible to share your /etc/samba/smb.conf?

(On the server of course)

[global]
        workgroup = RSB
        netbios name = s4
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:
* %n\n *password\supdated\ssuccessfully* .
        obey pam restrictions = Yes
        unix password sync = Yes
        invalid users = root
        preferred master = yes
        os level = 20
        idmap config * : backend = tdb
        log file = /var/log/samba/log.%m
        passwd program = /usr/bin/passwd %u
        server string = %h server (Samba, Ubuntu)

...

[nethome]
        comment = Network home share
        writable = yes
        path = /home/%u
        force directory mode = 0700
        force group = users
        force create mode = 0700
        create mode = 0700
        directory mode = 0700
; valid users = %u

Connecting from Nautilus works fine but slow

Can't reproduce yet... Still thinking about this one.

I tried to monitor via jouralctl -f

first attempts suggest that the application can't create a directory /var/cache/samba

I added write access to /var/cache for world.

Then I got this

Sep 23 14:05:35 mbpr13b dbus-daemon[2751]: Activating service name='org.gnome.DejaDup'
Sep 23 14:05:35 mbpr13b dbus-daemon[2751]: Successfully activated service 'org.gnome.DejaDup'
Sep 23 14:05:37 mbpr13b PackageKit[1129]: resolve transaction /511_eccbbeed from uid 1000 finished with success after 394ms
Sep 23 14:05:37 mbpr13b deja-dup[4000]: BackendRemote.vala:83: Could not find enclosing mount
Sep 23 14:05:37 mbpr13b deja-dup[4000]: BackendRemote.vala:83: Could not find enclosing mount

Mounting the directory manually

Sep 23 14:08:18 mbpr13b dbus-daemon[2751]: Activating service name='org.gnome.Nautilus'
Sep 23 14:08:18 mbpr13b dbus-daemon[2751]: Successfully activated service 'org.gnome.Nautilus'
Sep 23 14:08:18 mbpr13b org.gnome.Nautilus[2751]: sys:1: PyGIWarning: Nautilus was imported without specifying a version first. Use gi.require_version('Nautilus', '3.0') before import to ensure that the right version gets loaded.
Sep 23 14:08:18 mbpr13b dbus[891]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Sep 23 14:08:18 mbpr13b systemd[1]: Starting Hostname Service...
Sep 23 14:08:18 mbpr13b nautilus[4157]: Called "net usershare info" but it failed: Failed to execute child process “net” (No such file or directory)
Sep 23 14:08:18 mbpr13b dbus[891]: [system] Successfully activated service 'org.freedesktop.hostname1'
Sep 23 14:08:18 mbpr13b systemd[1]: Started Hostname Service.
Sep 23 14:08:20 mbpr13b gvfsd[2791]: mkdir failed on directory /var/cache/samba: Permission denied
Sep 23 14:08:20 mbpr13b gvfsd[2791]: mkdir failed on directory /var/cache/samba: Permission denied
Sep 23 14:08:20 mbpr13b gvfsd[2791]: mkdir failed on directory /var/cache/samba: Permission denied
Sep 23 14:08:20 mbpr13b gvfsd[2791]: mkdir failed on directory /var/cache/samba: Permission denied

The mount works though.

Sep 23 14:10:56 mbpr13b dbus-daemon[2751]: Activating service name='org.gnome.DejaDup'
Sep 23 14:10:56 mbpr13b dbus-daemon[2751]: Successfully activated service 'org.gnome.DejaDup'
Sep 23 14:11:00 mbpr13b PackageKit[1129]: resolve transaction /512_dedcceee from uid 1000 finished with success after 422ms
Sep 23 14:11:00 mbpr13b deja-dup[4216]: BackendRemote.vala:83: Could not find enclosing mount
Sep 23 14:11:00 mbpr13b deja-dup[4216]: BackendRemote.vala:83: Could not find enclosing mount

Same issue.

Sep 23 14:15:08 mbpr13b org.gnome.Nautilus[2751]: **
Sep 23 14:15:08 mbpr13b org.gnome.Nautilus[2751]: ERROR:../src/nautilus-bookmark.c:387:nautilus_bookmark_connect_file: assertion failed: (!nautilus_file_is_gone (bookmark->file))
Sep 23 14:15:11 mbpr13b dbus-daemon[2751]: Activating service name='org.gnome.Nautilus'
Sep 23 14:15:11 mbpr13b dbus-daemon[2751]: Successfully activated service 'org.gnome.Nautilus'
Sep 23 14:15:11 mbpr13b gsd-media-keys[2953]: Couldn't lock screen: Timeout was reached
Sep 23 14:15:11 mbpr13b org.gnome.Nautilus[2751]: sys:1: PyGIWarning: Nautilus was imported without specif...

Just as a hint:
maybe you want to remove the new code for storage location and replace it with the old working one.

Today update to deja-dup:amd64 (36.2-0ubuntu1) was offered.

Issue with gvfs still exists.

I am questioning whether I set up the backup path incorrectly:

server: "smb://server/"
path: "/absolute/path/to/backup"

is this correct?

(I tried every possible combination though)

That seems fine. (Question: does it work any better if you use relative path?)

I haven’t been able to reproduce, but I agree there’s a problem. Smb is the flakiest gvfs backend, it tends to be temperamental.

I have no issues connecting to the share from Nautilus.
The code in 34.4 worked flawless and reliably
In 34.4. the protocol was set using a dropdown and the server entered alone (see screenshots)
In 36.2 one has to enter the protocol and server but the path in a different location (see screenshots).

I have tried a simple Python script to connect to my server and it works fine (so I don't think it is an issue with Gnome but rather an issue in the new selection box).

Today the gnome gvfs package came in updated. The issue still persists.

If you want I can have a look at the source code and see if I can be of assistance.

Currently after every upgrade I revert to 34.4 as the last working solution.

There is no difference whether I prepend a / in front of nethome.
I always get "Operation not allowed"

Uups,

I just saw that deja-dup is written in Vala. I fear, I will not be of much help there.

So I've mentioned I can't reproduce. To be more verbose, when I use your smb.conf[1] in comment #12 on my up-to-date Ubuntu 16.04 machine, I can't even navigate to the share in nautilus. I get "Failed to mount Windows share: Invalid argument" when trying to log into the "nethome" share on the server machine after providing my server user's name/password. :(

Maybe my config is still incomplete?

[1] I have to add "server role = standalone server" to make the config work

I installed smbclient (which is not installed by default) and tested the connection. Worked fine.

Then I applied the connection string to deja-dup.

Selected drop-down Network Server
Server address: smb://10.1.0.4/nethome
Folder: /backup/mbpr13b

The difference to previous tests: Entering the smb service (//server/servicename) works, entering just the server (smb://server) does not.

I will attach a screenshot that demonstrates the issue (compared to previous screenshots).

Maybe you want to exchange "Server Address" with "Service path" and in the help modal add
"smb://gnome.org/backup_dir" as the current description and help is definitely missleading.

Status changed to 'Confirmed' because the bug affects multiple users.

Wolf Rogner's remarks solves my SMB backupping problem, but I restate his solution because it took me some time to understand it. The working settings are:

Storage Location: Network Server
Server Address: smb://$SERVER/$SHARE (e.g. smb://homeserver/mybackups)
Folder: (empty, I backup to the share and not to a directory within the share).

So "Server Address" could maybe renamed as Remote URI, explaining that the share name is part of the URI.

C.

:-) agree

Thanks for debugging this one for me! I've added code in master to rename Server Address to Network Location, updated the sample smb URI in the tooltip, and to add an explicit error message for smb: "Samba network locations must include both a hostname and a share name."

This bug was fixed in the package deja-dup - 37.1-0ubuntu1

---------------
deja-dup (37.1-0ubuntu1) bionic; urgency=medium

  * New upstream release
    - Fixes crash when restoring missing files (LP: #1729935)
    - Updates smb error to be clearer (LP: #1715582)

 -- Michael Terry <email address hidden> Tue, 02 Jan 2018 17:12:49 -0500

Is it possible to add this to Ubuntu 17.10? Current version 36.2 is totally unusable, and I don't want to jump into 18.04 yet.

That will take work that Ubuntu developers might not have the time to do. The process is here for anyone who does have time and wants to get this into 17.10, it's thorough because updates into existing releases is risky...it might be that the fix from 37 needs to be backported to 36...
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Just upgraded to 17.10; can't use DejaDup to backup to network NAS drive. Got this error. Is there a workaround, or do I have to wait for the new 18.04 release?

Nevermind; bloody NAS drive was stuck in a loop - hard reset fixed it.

I can connect with nautilus and browse drive. BUT, when I try and start DejaDup, I get this error:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1380, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1127, in ProcessCommandLine
    globals.backend = backend.get_backend(args[0])
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in get_backend_object
    return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/giobackend.py", line 97, in __init__
    self.remote_file.make_directory_with_parents(None)
 Error: g-io-error-quark: Operation not supported by backend (15)

Okay, even weirder.

If I connect to the root of the share, it works, but not to the subdirectory. HMMMMMMmmmmmmm......

Did you try all the settings that I described in this thread?

1. I had to create a /var/cache/samba directory (which you might probably have already).
2. The settings dialog has changed.

Storage location
  Storage location: Network Server
  Server Address: smb://server/share_name
  Folder: /complete/path/to/backup/directory

I had to play around for a while myself to figure this out. Setting the / was essential (as the path is concatenated as python strings).

On the backend, you must have write permission (the whole path, not just the destination directory).

I hope this helps.

(yep, have the SAMBA directory)

Wait a second!!!

Okay, got it working - thanks for the tip about the EXACT PATH to the share.

Mine was: "sftp://10.34.229.164/shares/System76-Lemur7" and, of course I was leaving out the /shares/ part

Solution was:

Storage location: Network Server
  Server Address: smb://10.34.229/
  Folder: /shares/System76-Lemur7

https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1734499 is apparently a duplicate of this and I still get that on 18.04 (with the backup that, iirc, I made on 17.10).