Can't unmount

[Tom-H-L]

trafficstars

Description

1. I cannot unmount a mounted archive.
2. I press the Archive > Selected Archive > Unmount button, but nothing happens, neither the archive unmounts (I can still access it on the filesystem), nor does the button change status to "Mount", it still says "Unmount".
3. Every time I click on the button the same 5 lines of log are recorded to the log file (see below).
4. The path of the archive includes space and rounded brackets "()", filesystem ext4: "/home/username/Documents/Temp (deleteme)/tempmount", maybe this is relevant.

Reproduction

• [X] I tried to reproduce the issue.
• [X] I was able to reproduce the issue.

OS

Ubuntu 22.04.1 LTS Desktop

Version of Vorta

0.8.3

What did you install Vorta with?

Distribution package

Version of Borg

1.2.0

Logs

2022-11-02 20:29:58,970 - vorta.keyring.abc - DEBUG - Only available on macOS
2022-11-02 20:29:58,976 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-02 20:29:58,978 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
2022-11-02 20:29:58,980 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-02 20:29:58,983 - root - DEBUG - Found 1 passwords matching repo URL.

[m3nu]

Both Borg and Vorta versions are rather old. Does it happen with newer versions too?

[real-yfprojects]

I could imagine that the following lines are the cause of this behaviour:

https://github.com/borgbase/vorta/blob/055338af2cce1df74ee8d4750f131f86e5c6c7e8/src/vorta/keyring/secretstorage.py#L59-L64

Is it possible that your keyring is locked and couldn't be unlocked when vorta requested the password?

[real-yfprojects]

I had another look at the code. Maybe it is a different issue but one is for sure: The logs you provided are incomplete.

[Tom-H-L]

Is it possible that your keyring is locked and couldn't be unlocked when vorta requested the password?

The keyring is currently unlocked. I double checked twice:

1. I locked the keyring and then pressed "Unmount" in Vorta: The keyring unlocking dialogue pops up and I unlock it. Nevertheless Vorta still does not unmount
2. I locked the keyring and unlocked it manually. Then went to Vorta and pressed "unmount". No remedy, either.

[Tom-H-L]

I had another look at the code. Maybe it is a different issue but one is for sure: The logs you provided are incomplete.

The logs are everything that is shown as soon as I press the "Unmount" button. Which other parts of the log file do you find interesting so I can fetch the relevant parts?

[Tom-H-L]

Can it be related to the password in the keyring itself, concerning length, special characters, etc.?

[real-yfprojects]

The logs are everything that is shown as soon as I press the "Unmount" button. Which other parts of the log file do you find interesting so I can fetch the relevant parts?

Following the logs you posted, either the GUI must have shown a status message next to the Cancel button: Please unlock your system password manager or disable it under Misc or Mount point not active. OR the logs show Add job for site <n>.

[Tom-H-L]

Mount point not active. OR the logs show Add job for site <n>.

Yes, the GUI says "Mount point not active"!

I just did the following:

1. I clicked on "Refresh". The log output after pressing the button is as follows, and there a "Add job for site 2" is found.

2022-11-03 05:34:04,639 - vorta.keyring.abc - DEBUG - Only available on macOS
2022-11-03 05:34:04,640 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-03 05:34:04,641 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
2022-11-03 05:34:04,643 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-03 05:34:04,645 - root - DEBUG - Found 1 passwords matching repo URL.
2022-11-03 05:34:04,677 - vorta.borg.jobs_manager - DEBUG - Add job for site 2
2022-11-03 05:34:04,677 - vorta.borg.jobs_manager - DEBUG - Start job on site: 2
2022-11-03 05:34:04,700 - vorta.borg.borg_job - INFO - Running command /usr/bin/borg list --info --log-json --json /home/user/Documents/10 Backups/Borg
2022-11-03 05:34:05,284 - vorta.borg.jobs_manager - DEBUG - Finish job for site: 2
2022-11-03 05:34:05,285 - vorta.borg.jobs_manager - DEBUG - No more jobs for site: 2

Right after under the Archive Button it says now "Refreshed archives".

2. Now I clicked that button menu and selected "Unmount". Below the button the "Refreshed archives" changed to "Mount point not active" again and the log file got this:

2022-11-03 05:42:51,765 - vorta.keyring.abc - DEBUG - Only available on macOS
2022-11-03 05:42:51,767 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-03 05:42:51,768 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
2022-11-03 05:42:51,769 - asyncio - DEBUG - Using selector: EpollSelector
2022-11-03 05:42:51,771 - root - DEBUG - Found 1 passwords matching repo URL.

[real-yfprojects]

When trying to unmount, what does the following command output? Be sure to replace the path by the actual path of the mountpoint.

python3 -c "import psutil; print([p for p in psutil.disk_partitions(all=True) if p.mountpoint == '/home/username/Documents/Temp (deleteme)/tempmount' or 'borg' in p.device or 'fuse' in p.fstype])"

[Tom-H-L]

When trying to unmount, what does the following command output? Be sure to replace the path by the actual path of the mountpoint.

python3 -c "import psutil; print([p for p in psutil.disk_partitions(all=True) if p.mountpoint == '/home/username/Documents/Temp (deleteme)/tempmount' or 'borg' in p.device or 'fuse' in p.fstype])"

After reboot I could reproduce the problem. Without having done anything else before, after reboot I did the following:

1. Mounted the last Archive file:

 2022-11-03 15:01:54,144 - vorta.scheduler - DEBUG - Scheduler for profile 1 is disabled.
 2022-11-03 15:01:54,146 - vorta.scheduler - INFO - Setting timer for profile 2
 2022-11-03 15:01:54,147 - vorta.scheduler - DEBUG - Scheduling next run for 2022-11-03 16:00:00
+2022-11-03 15:15:07,146 - vorta.keyring.abc - DEBUG - Only available on macOS
+2022-11-03 15:15:07,300 - asyncio - DEBUG - Using selector: EpollSelector
+2022-11-03 15:15:07,302 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
+2022-11-03 15:15:07,304 - asyncio - DEBUG - Using selector: EpollSelector
+2022-11-03 15:15:07,306 - root - DEBUG - Found 1 passwords matching repo URL.
+2022-11-03 15:15:14,126 - vorta.borg.jobs_manager - DEBUG - Add job for site 2
+2022-11-03 15:15:14,129 - vorta.borg.jobs_manager - DEBUG - Start job on site: 2
+2022-11-03 15:15:14,136 - vorta.borg.borg_job - INFO - Running command /usr/bin/borg --log-json mount /home/XXXX/XXXX/XXXX Backups/Borg::XXXX-2022-11-02-185959 /home/XXXX/XXXX/Temp (deleteme)/tempmount
+2022-11-03 15:15:19,108 - vorta.borg.jobs_manager - DEBUG - Finish job for site: 2
+2022-11-03 15:15:19,112 - vorta.borg.jobs_manager - DEBUG - No more jobs for site: 2

Below the button it says "Mounted successfully". I then tried to dismount it right again. Result: Below the button it says "Mount point not active", the volume remains mounted and the log added:

+2022-11-03 15:31:18,746 - vorta.keyring.abc - DEBUG - Only available on macOS
+2022-11-03 15:31:18,748 - asyncio - DEBUG - Using selector: EpollSelector
+2022-11-03 15:31:18,749 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
+2022-11-03 15:31:18,751 - asyncio - DEBUG - Using selector: EpollSelector
+2022-11-03 15:31:18,752 - root - DEBUG - Found 1 passwords matching repo URL.

I then ran the python3 command as per your instruction. The output is as follows, with the path, user id, group id being obfuscated by me with "XXXX": [sdiskpart(device='fusectl', mountpoint='/sys/fs/fuse/connections', fstype='fusectl', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='gvfsd-fuse', mountpoint='/run/user/XXXX/gvfs', fstype='fuse.gvfsd-fuse', opts='rw,nosuid,nodev,relatime,user_id=XXXX,group_id=XXXX', maxfile=1024, maxpath=4096), sdiskpart(device='portal', mountpoint='/run/user/XXXX/doc', fstype='fuse.portal', opts='rw,nosuid,nodev,relatime,user_id=XXXX,group_id=XXXX', maxfile=None, maxpath=4096), sdiskpart(device='borgfs', mountpoint='/home/XXXX/XXXX/Temp (deleteme)/tempmount', fstype='fuse', opts='ro,nosuid,nodev,relatime,user_id=XXXX,group_id=XXXX,default_permissions', maxfile=255, maxpath=4096)]

[real-yfprojects]

sdiskpart(device='borgfs', mountpoint='/home/XXXX/XXXX/Temp (deleteme)/tempmount', fstype='fuse', opts='ro,nosuid,nodev,relatime,user_id=XXXX,group_id=XXXX,default_permissions', maxfile=255, maxpath=4096)

This is the mountpoint in question and it is correctly found as an active mount. Does the GUI show the correct mount path next to the archive name you mounted?

[Tom-H-L]

This is the mountpoint in question and it is correctly found as an active mount.

Yes, the mountpoint gets mounted correctly. Here is what the GNU/Linux tool "mount" reports, which lists all active mounts: borgfs on /home/XXXX/XXXX/Temp/tempmount type fuse (ro,nosuid,nodev,relatime,user_id=XXXX,group_id=XXXX,default_permissions)

Does the GUI show the correct mount path next to the archive name you mounted?

Yes it does show the mountpoint correctly in the GUI. Everything works fine with that mount, I can access it, I can extract files from it, etc. Only: I cannot unmount it anymore, I have to reboot to get rid of the mount (I might be able to unmount it via the terminal, but as a Vorta and borg noob I am reluctant to fiddle around with the borgfs/fuse volume without concrete instructions since the archive contains real production data and I don't want to mess it up)

I rebooted and tried out the following:

• Renamed the path in a way that it does not contain any spaces or brackets or anything else "fancy" anymore
• Mounted the archive and tried to unmount it again right away without even accessing the path in the filesystem (not to have any filesystem locks due to open files, etc.)

No cure.

[real-yfprojects]

but as a Vorta and borg noob I am reluctant to fiddle around with the borgfs/fuse volume without concrete instructions since the archive contains real production data and I don't want to mess it up

borg umount <path> or unmount <path> should do the job. Those two commands are completely safe.

Yes it does show the mountpoint correctly in the GUI.

Double clicking on the path in the GUI opens the correct folder?

I created a debug version of vorta for this issue. You can install it with the following commands. This won't touch borg, affect your repositories or your configuration of vorta.

sudo apt install python3-pip python3-dev build-essentials git && \
pip3 install "vorta @ https://github.com/real-yfprojects/vorta/archive/refs/heads/debug%231461.zip"

After that try reproducing the issue and have a look into the logs for a line starting with Selected archive.

[Tom-H-L]

borg unmount <path> or unmount <path> should do the job. Those two commands are completely safe.

I tried borg umount <path> (beware for GNU/Linux readers: umount, not unmount) and the volume unmounted successfully, thanks for that information! What else happened:

• Nothing got logged in Vorta for this unmount
• The Mount point still gets displayed in the Archives tab as if the volume would still be mounted. Double clicking also opens in the correct directory, but empty as nothing is actually mounted into this mountpoint
• Selecting "unmount" in Vorta, the info below the button changed to "No active Borg mounts found"
• Clicking "Refresh" removed the mount point path in the Archives menu
• With clicking "mount" I could mount it again
• With clicking "unmount" again nothing happens, the bug is 100% reproducable

Double clicking on the path in the GUI opens the correct folder?

Yes!

I created a debug version of vorta for this issue. You can install it with the following commands. This won't touch borg, affect your repositories or your configuration of vorta.

sudo apt install python3-pip python3-dev build-essentials git && \
pip3 install "git+https://github.com/real-yfprojects/vorta@f64c045#egg=vorta"

After that try reproducing the issue and have a look into the logs for a line starting with Selected archive.

That sounds great, but unfortunately due to policy reasons I am not able to use anything else on this production machine than stuff coming from the official Debian repositories that Ubuntu uses (only from "main" and "universe"). So I am afraid and sorry that I cannot do that on this machine right now. Please tell me if going this route would be of great significance for finding this bug; in that case I could set up a testing VM with identical setup to try to reproduce the bug there and use the tool you created on it, but this would not be earlier than in a few days. Is there anything else that I could try out and report right now on this machine with the tools I got?

[real-yfprojects]

Is there anything else that I could try out and report right now on this machine with the tools I got?

I don't know of anything. To me this is the definition of an impossible bug.

[Tom-H-L]

Updated to 0.8.7, no cure

[quazar-omega]

I've been experiencing the same up to the current Vorta 0.8.12 (Flatpak), I'm not sure what the conditions that recreate the issue are.
There may be a loose connection to putting the system into sleep mode, waking it and trying to unmount, in my case, but I can't confirm yet

---

Update: it seems the things aren't related, even trying to unmount immediately after mounting doesn't work

[real-yfprojects]

Thank you @quazar-omega for reporting. Can you run the debug version from https://github.com/borgbase/vorta/issues/1461#issuecomment-1302409318, reproduce the issue and post the logs here?

[quazar-omega]

Sure! I'll try that soon

[quazar-omega]

Sorry if my soon isn't being very soon (∩´ᴖ`∩)
Can I ask you if these instructions still apply? I'm using Fedora Kinoite so I'm guessing I could try to run that in a Debian Distrobox container?

[real-yfprojects]

Can I ask you if these instructions still apply?

They do still apply for Debian/Ubuntu. For Fedora the following should work:

sudo dnf install python3-pip git 
python -m pip install --user "vorta @ https://github.com/real-yfprojects/vorta/archive/refs/heads/debug%231461.zip"

[quazar-omega]

Ok, I've run it in a Debian 12 container

My process

1. Installed the dependencies, added pipx to install vorta cleanly later (and corrected build-essentials typo):

sudo apt install python3-pip python3-dev build-essential git pipx

2. Installed the vorta test build:

pipx install "vorta @ https://github.com/real-yfprojects/vorta/archive/refs/heads/debug%231461.zip"
pipx ensurepath

3. Running it like that I realized I was missing all the application dependencies so I installed the Debian package for vorta:

sudo apt install vorta

4. Renamed and ran:

mv .local/bin/vorta .local/bin/vorta-testing
vorta-testing

Mounting doesn't seem to work, it outputs this:

2023-09-10 17:44:30,468 - vorta.borg.borg_job - INFO - Running command /usr/bin/borg --log-json mount /run/media/amusing-dove/Backup/backup-fedora-workstation::ddd174-f5765038 /home/amusing-dove/.local/share/box-homes/Box-Debian/mnt
2023-09-10 17:44:34,033 - vorta.borg.borg_job - WARNING - fuse: failed to exec fusermount3: No such file or directory
2023-09-10 17:44:34,193 - vorta.borg.jobs_manager - DEBUG - Finish job for site: 1
2023-09-10 17:44:34,195 - vorta.borg.jobs_manager - DEBUG - No more jobs for site: 1

Maybe I'll try to install on my host OS

[real-yfprojects]

Maybe I'll try to install on my host OS

That will probably save time.

Mounting doesn't seem to work, it outputs this:

Most likely the libfuse package is missing.

[quazar-omega]

Alright, I've got something, I managed to run it now by installing in the same way on my host.

It (luckily) behaves the same as my original installation so this is my output when I click on "Unmount"

Selected archive: ddd174-f5765038
Mountpoint: /home/amusing-dove/.mnt/old-backup
Mountpoints: {'ddd174-f5765038': '/home/amusing-dove/.mnt/old-backup'}
2023-09-11 15:08:07,723 - vorta.keyring.abc - DEBUG - Only available on macOS
2023-09-11 15:08:07,725 - vorta.borg.borg_job - DEBUG - Using VortaKWallet5Keyring keyring to store passwords.
Partitions [sdiskpart(device='proc', mountpoint='/proc', fstype='proc', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='sysfs', mountpoint='/sys', fstype='sysfs', opts='rw,seclabel,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='devtmpfs', mountpoint='/dev', fstype='devtmpfs', opts='rw,seclabel,nosuid,size=4096k,nr_inodes=2006778,mode=755,inode64', maxfile=255, maxpath=4096), sdiskpart(device='securityfs', mountpoint='/sys/kernel/security', fstype='securityfs', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='tmpfs', mountpoint='/dev/shm', fstype='tmpfs', opts='rw,seclabel,nosuid,nodev,inode64', maxfile=255, maxpath=4096), sdiskpart(device='devpts', mountpoint='/dev/pts', fstype='devpts', opts='rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000', maxfile=255, maxpath=4096), sdiskpart(device='tmpfs', mountpoint='/run', fstype='tmpfs', opts='rw,seclabel,nosuid,nodev,size=3229212k,nr_inodes=819200,mode=755,inode64', maxfile=255, maxpath=4096), sdiskpart(device='cgroup2', mountpoint='/sys/fs/cgroup', fstype='cgroup2', opts='rw,seclabel,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot', maxfile=255, maxpath=4096), sdiskpart(device='pstore', mountpoint='/sys/fs/pstore', fstype='pstore', opts='rw,seclabel,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='efivarfs', mountpoint='/sys/firmware/efi/efivars', fstype='efivarfs', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='bpf', mountpoint='/sys/fs/bpf', fstype='bpf', opts='rw,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-vconsole-setup.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='configfs', mountpoint='/sys/kernel/config', fstype='configfs', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/sysroot', fstype='btrfs', opts='ro,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=258,subvol=/root', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/', fstype='btrfs', opts='rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=258,subvol=/root', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/etc', fstype='btrfs', opts='rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=258,subvol=/root', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/usr', fstype='btrfs', opts='ro,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=258,subvol=/root', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/sysroot/ostree/deploy/fedora/var', fstype='btrfs', opts='rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=258,subvol=/root', maxfile=255, maxpath=4096), sdiskpart(device='selinuxfs', mountpoint='/sys/fs/selinux', fstype='selinuxfs', opts='rw,nosuid,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='systemd-1', mountpoint='/proc/sys/fs/binfmt_misc', fstype='autofs', opts='rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=23710', maxfile=255, maxpath=4096), sdiskpart(device='binder', mountpoint='/dev/binderfs', fstype='binder', opts='rw,relatime,max=1048576', maxfile=255, maxpath=4096), sdiskpart(device='hugetlbfs', mountpoint='/dev/hugepages', fstype='hugetlbfs', opts='rw,seclabel,relatime,pagesize=2M', maxfile=255, maxpath=4096), sdiskpart(device='mqueue', mountpoint='/dev/mqueue', fstype='mqueue', opts='rw,seclabel,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='debugfs', mountpoint='/sys/kernel/debug', fstype='debugfs', opts='rw,seclabel,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='tracefs', mountpoint='/sys/kernel/tracing', fstype='tracefs', opts='rw,seclabel,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='fusectl', mountpoint='/sys/fs/fuse/connections', fstype='fusectl', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-sysctl.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-sysusers.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-tmpfiles-setup-dev.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/var', fstype='btrfs', opts='rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/var', maxfile=255, maxpath=4096), sdiskpart(device='/dev/nvme1n1p2', mountpoint='/boot', fstype='ext4', opts='rw,seclabel,relatime', maxfile=255, maxpath=4096), sdiskpart(device='tmpfs', mountpoint='/tmp', fstype='tmpfs', opts='rw,seclabel,nosuid,nodev,size=8073032k,nr_inodes=1048576,inode64', maxfile=255, maxpath=4096), sdiskpart(device='/dev/mapper/luks-353e522f-c0f3-4167-99fc-90d576a734e8', mountpoint='/var/home', fstype='btrfs', opts='rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/home', maxfile=255, maxpath=4096), sdiskpart(device='/dev/nvme1n1p1', mountpoint='/boot/efi', fstype='vfat', opts='rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro', maxfile=1530, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-tmpfiles-setup.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='binfmt_misc', mountpoint='/proc/sys/fs/binfmt_misc', fstype='binfmt_misc', opts='rw,nosuid,nodev,noexec,relatime', maxfile=255, maxpath=4096), sdiskpart(device='ramfs', mountpoint='/run/credentials/systemd-resolved.service', fstype='ramfs', opts='ro,seclabel,nosuid,nodev,noexec,relatime,mode=700', maxfile=255, maxpath=4096), sdiskpart(device='sunrpc', mountpoint='/var/lib/nfs/rpc_pipefs', fstype='rpc_pipefs', opts='rw,relatime', maxfile=255, maxpath=4096), sdiskpart(device='tmpfs', mountpoint='/run/user/1000', fstype='tmpfs', opts='rw,seclabel,nosuid,nodev,relatime,size=1614604k,nr_inodes=403651,mode=700,uid=1000,gid=1000,inode64', maxfile=255, maxpath=4096), sdiskpart(device='portal', mountpoint='/run/user/1000/doc', fstype='fuse.portal', opts='rw,nosuid,nodev,relatime,user_id=1000,group_id=1000', maxfile=None, maxpath=4096), sdiskpart(device='/dev/mapper/luks-6ad1bc21-b2c4-42ee-b830-cc56fbb7d3c7', mountpoint='/run/media/amusing-dove/Backup', fstype='ext4', opts='rw,seclabel,nosuid,nodev,relatime,errors=remount-ro', maxfile=255, maxpath=4096), sdiskpart(device='borgfs', mountpoint='/var/home/amusing-dove/.mnt/old-backup', fstype='fuse', opts='ro,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions', maxfile=255, maxpath=4096)]
Umount params {'ok': True, 'password': 'expand anyplace ladies swizzle dill amuck', 'ssh_key': None, 'repo_id': 1, 'repo_url': '/run/media/amusing-dove/Backup/backup-fedora-workstation', 'extra_borg_arguments': '', 'profile_name': 'Default', 'profile_id': 1, 'active_mount_points': ['/var/home/amusing-dove/.mnt/old-backup'], 'cmd': ['borg', 'umount', '--log-json']}

(Realized I just leaked my password like a dumbass... well, whatever)

[real-yfprojects]

(Realized I just leaked my password like a dumbass... well, whatever)

Sorry about that. While they are unsafe now, I can still completely redact them from github if you want.

I will look into you results later when I have more time. Thank you for running the debug build.

[quazar-omega]

It's fine, there's no need, it's all local anyway. I can just change it or make a new repo, once it's on the internet it's already compromised after all :)

About the message, just by giving it a mindless skim it doesn't look like there's any specific error reported, is that actually the important part? It is what was output when I clicked the button each time I tried, so I'm wondering if there's more info to give, I'll stay available to help troubleshoot

[real-yfprojects]

About the message, just by giving it a mindless skim it doesn't look like there's any specific error reported, is that actually the important part?

No, it is printing out extra information (that's also why you're passwords appeared there, usually they aren't logged). Hopefully this information will allow me to get closer to the root problem of this issue. However I can't garantee anything.

[quazar-omega]

Got it, thanks for looking into this!

[real-yfprojects]

Ok, I got closer to the problem (at least in your case @quazar-omega). While you seem to have mounted the archive into /home/amusing-dove/.mnt/old-backup, psutil.disk_partitions(all=True) will return the mountpoint /var/home/amusing-dove/.mnt/old-backup. This explains Vorta's behaviour. However I don't know where the /var comes from.

Can you reproduce the bug and check the output of

cat /proc/mounts

which should list all mounts. This will allow determining whether there is an issue with diskutils. If that also outputs /var/home/..., can you check that the archive isn't mounted in /home/amusing-dove/... but only in /var/home/...?

[quazar-omega]

Looked through the output, I see at the end

borgfs /var/home/amusing-dove/.mnt/old-backup fuse ro,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions 0 0

I assume that's what I'm looking for? It is listed with /var, which I can further confirm with the fact that /home is a symbolic link to /var/home:

/ $ ls -l
total 48
lrwxrwxrwx.   4 root root    7 May  1 19:02 bin -> usr/bin
drwxr-xr-x.   7 root root 4096 Sep 10 18:04 boot
drwxr-xr-x.  21 root root 4640 Sep 16 13:22 dev
drwxr-xr-x.   1 root root 4506 Sep 11 12:46 etc
lrwxrwxrwx.   4 root root    8 May  1 19:02 home -> var/home
lrwxrwxrwx.   7 root root    7 May  1 19:02 lib -> usr/lib
lrwxrwxrwx.   7 root root    9 May  1 19:02 lib64 -> usr/lib64
lrwxrwxrwx.   4 root root    9 May  1 19:02 media -> run/media
lrwxrwxrwx.   4 root root    7 May  1 19:02 mnt -> var/mnt
lrwxrwxrwx.   4 root root    7 May  1 19:02 opt -> var/opt
lrwxrwxrwx.   4 root root   14 May  1 19:02 ostree -> sysroot/ostree
dr-xr-xr-x. 466 root root    0 Sep 16  2023 proc
lrwxrwxrwx.   4 root root   12 May  1 19:02 root -> var/roothome
drwxr-xr-x.  51 root root 1300 Sep 16 13:20 run
lrwxrwxrwx.   4 root root    8 May  1 19:02 sbin -> usr/sbin
lrwxrwxrwx.   4 root root    7 May  1 19:02 srv -> var/srv
dr-xr-xr-x.  13 root root    0 Sep 16 13:18 sys
drwxr-xr-x.   1 root root   74 May  1 19:02 sysroot
drwxrwxrwt.  19 root root  460 Sep 16 13:23 tmp
drwxr-xr-x.   1 root root  106 Jan  1  1970 usr
drwxr-xr-x.   1 root root  222 Sep 11 12:46 var

So the archive is mounted on "both", i.e. just the actual path prepended by /var