Locking the vault doesn't unmount the directory about vaults HOT 10 CLOSED

I can't really reproduce this. What error is shown? Can you try running it in terminal with flatpak run io.github.mpobaschnig.Vaults and see if there's some error/output when this is happening and post it?

from vaults.

I'm having the same issue on a system with:

• Application: 0.3.0 (and tested with a downgrade to 0.2.1, both Flatpaks)
• gocryptfs: 2.3
• Distribution: Fedora 36 with Gnome 42.4

Running the application from terminal gave no errors or additional output and the GUI shows that the vault should be locked again. Meanwhile in Nautilus (GNOME Files) I can continue to browse the decrypted folder. Under running processes the gocryptfs command still shows as running and the folder is mounted. However, I can unmount it manually with fusermount -u /path/to/decrypted/folder.

I tested it on another system with Fedora 37 and Gnome 43 and there it's unmounting like it should. I also noticed that in Nautilus the decrypted folder is showing in the sidebar and I can unmount it there too with a button click. From what I recall, that was the case in Fedora 36 too some time ago but it isn't now. Maybe it's a regression in a system package independent of Vaults?

from vaults.

My issue is the same as @LordTwix is having. Terminal doesn't give errors, and neither does GUI. I'm still on Fedora 36 and Gnome 42, as Fedora 37 has not yet released stable, but I add my comments when I get the update.

from vaults.

I tested a bit further and it seems like Vaults does have the aforementioned issue when in Vault Settings the Mount Directory is set to be inside a hidden folder.

For example:

• /home/user/mnt/vault1 works like intended and allows me to unmount the directory
• /home/user/.mnt/vault1 however gives me the problems that I mentioned earlier

from vaults.

Thanks, I can reproduce this now. I'll look into it as soon as I have time.

from vaults.

I can confirm that my issue also happens only with hidden mount directories.

from vaults.

Alright, I looked into it briefly. Vaults is relying on gio's VolumeMonitor to monitor "user interesting devices and volumes on the computer". As soon as the mounted path contains a hidden folder, it's no longer 'user interesting', according to the library developers, and thus disappears from the list of mounted folders. This also happens for Nautilus' sidebar, where no entry appears for hidden mounted volumes. Consequently, Vaults can't detect if the folder is already mounted or not and doesn't correctly unmount it as it guesses to be unmounted, since there is no entry.

I looked into gio's source code and as far as I can see, there are no changes regarding VolumeMonitor for a long time. I'm curious if anybody could point to some easily-reproducible working combination of Vaults not closing correctly and mount entry appearing within Nautilus, if that exists at all, so I can look into it further.

The workaround for now, obviously, is not using hidden folders.

Out of interest, what is your exact use case for having the mounted folder within a hidden folder?

from vaults.

Thank you very much for the detailed explanation. In my case it was more a coincidence. I've started using PikaBackup and their mounted folder for recovery was automatically put inside /home/user/.mnt, so I thought that I could put all my other 'mounted' folders inside there too to tidy the home folder a bit up again. Before that, I had the mounted Vaults inside a non-hidden folder, that's how I stumbled upon this limitation. At first I didn't realize that the problems were connected to me changing the mount directory.

from vaults.

Thanks for explaining your use case. I tried out PikaBackup and skimmed through the source code and it suffers from the same behavior. It also relies on VolumeMonitor, however, instead of relying on the events, they manually track the mounted/unmounted behavior for these hidden folders. I can add this functionality for hidden folders, i.e., if the path is in some hidden directory, we rely on our own tracking of mounted/unmounted instead of VolumeMonitor events. This replicates the behavior of PikaBackup and should fix this issue. I'll implement it for the next release :)

from vaults.

Oh, it seems this is a bit more complicated. PikaBackup unmounts the folder automatically when closed, so tracking the mount state while running the application makes sense. However, gocryptfs/cryfs mounts are likely to stay mounted even when Vaults is closed. When closing and starting the Vaults again, there's no way to check the state of the mounts, and relying on some state file is probably error-prone.

from vaults.