SMB Mount to backup directory prevents mounting parent directories of share

[Dan Sorak]

May also apply to the "duplicity" package and is related to network "mount"s:

To reproduce:
* Set up a writeable SMB share: smb://1.2.3.4/backup
* Create a subdir: smb://1.2.3.4/backup/UbuntuBackup
* Using "deja-dup" -> "Storage location" set:
    Storage location: Network Server
    Network Location: smb://1.2.3.4/backup/UbuntuBackup
    Folder: MyMachineBackup
* REBOOT THE MACHINE (or clear any cached mounts to "smb://1.2.3.4/backup")
* Select "deja-dup" -> "Overview" -> "Back Up Now..."
* Allow the backup to start, but not finish
* Go to Nautilus (file browser) -> "+ Other Locations"
  - At the bottom set "Connect to server" to: smb://1.2.3.4/backup

Result:
* The parent SMB directory "smb://1.2.3.4/backup" is inaccessible because the "UbuntuBackup" subdir is currently mounted
* Can happen at semi-random times if the backup is on a schedule
* This is especially a problem when backing up remotely over a VPN which can take a long time
* Prevents access to all parent folders of the backup folder
* Nautilus will hang, unable to mount the "backup" parent directory
* Also a problem if the "smb://1.2.3.4/backup" folder is bookmarked in nautilus
* This problem is persistent throughout backup process and for a period of time afterwards until the mount to "UbuntuBackup" times out or the backup process exits

Possible solutions:
* Add a configuration option to deja-dup/duplicity to specify the "Share root" and mount that first before accessing the configured "Network Location"
* Have deja-dup or duplicity attempt to mount the parent directory/directories first by starting at the root of the SMB share and walking down the directory tree until a successful mount is made. In the above example, start by attempting to mount "smb://1.2.3.4/backup" first and then "smb://1.2.3.4/backup/UbuntuBackup" (in the case of deeper folder structures, try each one successively)

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: deja-dup 40.7-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
Uname: Linux 5.13.0-30-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Tue Mar 1 08:51:47 2022
ExecutablePath: /usr/bin/deja-dup
InstallationDate: Installed on 2021-09-13 (168 days ago)
InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
ProcEnviron:
 XDG_RUNTIME_DIR=<set>
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
SourcePackage: deja-dup
UpgradeStatus: No upgrade log present (probably fresh install)

[Dan Sorak (dsorak)]

Maybe not a "bug" per se, but definitely an unwanted side-effect of the network backup process.

[Vej (vej)]

Hello Dan,

thank you for reporting this bug. I am triaging this as "Medium" for Ubuntu because it has "a moderate impact on a core application" but "Low" for Déjà Dup (upstream) as it does not affect any interaction in the application itself.

Some comments on the proposed solutions:

Déjà Dup is unlikely to implement a new "Share root" because that goes against the policy of providing a tool for (new) standard users and keeping the interface as simple as possible.

The second solution is much better in this regard as it hides the workaround from the user.

Leaving Déjà Dup as "New" for now as I will have to check who does the mount in the end.

[Michael Terry (mterry)]

Deja Dup could maybe be smarter in the specific case of SMB mounts and only try to mount the root folder...

If you switch your settings from:

    Network Location: smb://1.2.3.4/backup/UbuntuBackup
    Folder: MyMachineBackup

to:

    Network Location: smb://1.2.3.4/backup
    Folder: UbuntuBackup/MyMachineBackup

do things work like you expect?