Description of problem: With a "local" filesystem as the backup target, each run of deja-dup leaves a dangling mount: $ grep -n bak1 /proc/mounts 23:/dev/vdb1 /mnt/bak1 ext4 rw,seclabel,nosuid,nodev,noexec,relatime 0 0 29:/dev/vdb1 /mnt/bak1 ext4 rw,seclabel,nosuid,nodev,noexec,relatime 0 0 30:/dev/vdb1 /mnt/bak1 ext4 rw,seclabel,nosuid,nodev,noexec,relatime 0 0 31:/dev/vdb1 /mnt/bak1 ext4 rw,seclabel,nosuid,nodev,noexec,relatime 0 0 $ lsblk -o NAME,FSTYPE,LABEL,OWNER,GROUP,MOUNTPOINTS /dev/vdb1 NAME FSTYPE LABEL OWNER GROUP MOUNTPOINTS vdb1 ext4 fedora_bak1 root disk /mnt/bak1 /mnt/bak1 /mnt/bak1 /mnt/bak1 /etc/fstab uses the "users" option, so a non-root user can unmount the filesystem: $ grep '^LABEL=fedora_bak1' /etc/fstab LABEL=fedora_bak1 /mnt/bak1 ext4 nofail,users 0 0 Version-Release number of selected component (if applicable): deja-dup-45.2-4.fc40.x86_64 duplicity-2.2.3-2.fc40.x86_64 glibc-2.39-8.fc40.x86_64 kernel 6.8.9-300.fc40.x86_64 How reproducible: Always. An alternative test case starts with an unmounted filesystem: LABEL=fedora_bak1 /mnt/bak1 ext4 noauto,users 0 0
Configuration: Mountpoint: /mnt/bak1 Backup directory: /mnt/bak1/bak-duplicity/ The user has rwx permissions on that path. Mount automatically: $ grep '^LABEL=fedora_bak1' /etc/fstab LABEL=fedora_bak1 /mnt/bak1 ext4 nofail,users 0 0 $ grep -n bak1 /proc/mounts 28:/dev/vdb1 /mnt/bak1 ext4 rw,seclabel,nosuid,nodev,noexec,relatime 0 0 Test procedure: Open a terminal window and run: $ watch -n 0.1 grep -n bak1 /proc/mounts Run deja-dup in backup mode. NB: Testing is much faster in a virtual machine with a minimal number of files in the home directory. Use a second terminal window to reverse extra mounts after a test run: $ umount -v /mnt/bak1 umount: /mnt/bak1 (/dev/vdb1) unmounted
As a workaround, use dconf-editor to configure deja-dup to unmount /mnt/bak1: Dconf path: /org/gnome/deja-dup/custom-tool-teardown Command: /usr/bin/umount /mnt/bak1 NB: The backups themselves do not seem to be affected. Restores are possible.
For the record: $ ls -ldnZ /mnt/bak1/bak-duplicity/ drwxr-xr-x. 2 1000 1000 unconfined_u:object_r:mnt_t:s0 20480 May 18 23:25 /mnt/bak1/bak-duplicity/ $ dconf dump /org/gnome/deja-dup/ [/] backend='local' delete-after=0 last-backup='2024-05-19T06:25:02.152952Z' last-restore='2024-05-18T18:08:52.528120Z' last-run='2024-05-19T06:24:59.376145Z' nag-check='2024-05-18T18:35:33.847300Z' periodic-period=7 tool='duplicity' window-height=441 window-width=1060 [local] folder='/mnt/bak1/bak-duplicity/'
Upstream maintainer here - thanks for the report! I’m looking into it. For sure, we should pass the mount command that prevents duplicate mounts. That’s an easy oversight to correct. We have code in there that should perform the unmount (if we ended up mounting it in the first place) — maybe that’s not working or obscured by the multiple mounts… Will investigate.
OK - I just landed a commit that should fix this. https://gitlab.gnome.org/World/deja-dup/-/commit/577b6756a23e3e177cb8c6ddb5aef24b4b4ce94b In addition to this fix, which will prevent double-mounting the mount point, to actually see unmounts happen, you'll need to use the 'user' flag instead of 'users' -- with 'users', unmounting still requires superuser privileges (since mounts aren't in theory owned by one user). Thank you for flagging that this wasn't working!
Thanks, Mike! I will revert to using "user" instead of "users" in /etc/fstab. The latter was only being used for debugging.
I rebuilt the Fedora deja-dup package with your patch applied and confirm that it works as expected in both cases. Initially mounted in /etc/fstab: LABEL=fedora_bak1 /mnt/bak1 ext4 nofail,user 0 0 There are no double-mounts, and, after the backup, fedora_bak1 (/dev/vdb1) remains mounted. Initially unmounted in /etc/fstab: LABEL=fedora_bak1 /mnt/bak1 ext4 noauto,user 0 0 There are no double-mounts, and, after the backup, fedora_bak1 (/dev/vdb1) is unmounted.
(In reply to Steve from comment #7) ... > Initially mounted in /etc/fstab: > LABEL=fedora_bak1 /mnt/bak1 ext4 nofail,user 0 0 ... The "user" option isn't needed in that case, since the backup device is already mounted: LABEL=fedora_bak1 /mnt/bak1 ext4 nofail 0 0 The "nofail" option prevents a boot failure if the backup device is missing. With "nofail", if the backup device is missing, deja-dup displays this message: "Error creating directory /mnt/bak1/bak-duplicity: Permission denied" However, if deja-dup is run from the command-line, a more informative message is displayed: "umount: /mnt/bak1: not mounted."
(In reply to Michael Terry from comment #5) > OK - I just landed a commit that should fix this. > > https://gitlab.gnome.org/World/deja-dup/-/commit/ > 577b6756a23e3e177cb8c6ddb5aef24b4b4ce94b > > In addition to this fix, which will prevent double-mounting the mount point, > to actually see unmounts happen, you'll need to use the 'user' flag instead > of 'users' -- with 'users', unmounting still requires superuser privileges > (since mounts aren't in theory owned by one user). > > Thank you for flagging that this wasn't working! Thank you! I'll get an updated RPM out today.
FEDORA-2024-576b69b874 (deja-dup-45.2-5.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-576b69b874
FEDORA-2024-2acfdd327b (deja-dup-45.2-5.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-2acfdd327b
(In reply to Fedora Update System from comment #10) > FEDORA-2024-576b69b874 (deja-dup-45.2-5.fc40) has been submitted as an update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-576b69b874 The changelog shows 45.3-1. Is that intentional? https://koji.fedoraproject.org/koji/buildinfo?buildID=2454113
It is not. I'll fix it in rawhide git.
45.3-5 or 45.2-5? https://src.fedoraproject.org/rpms/deja-dup/c/63714cce38ecfa94f3b73da048971ecddf498fbb?branch=rawhide
Sigh. I fixed the fix. :)
Thanks! https://src.fedoraproject.org/rpms/deja-dup/c/1e804aeb2946a7299ff2b962bf6ceb2e7afc1adc?branch=rawhide
FEDORA-2024-576b69b874 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-576b69b874` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-576b69b874 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-2acfdd327b has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2acfdd327b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2acfdd327b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-576b69b874 (deja-dup-45.2-5.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-2acfdd327b (deja-dup-45.2-5.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.