[SOLVED] cryptsetup device cannot be closed: still in use

[freifunk_connewitz]

Hi,

I am just adding this here in case someone has the same problem, and it took me a while to find the solution.

I am doing regular backups on encrypted USB devices. To make it handy for everyday use on all of my computers I've added an entry for the USB device to /etc/fstab so that I just have to click the device icon in dolphin file manager in order to decrypt and mount it (without the need to sudo).

For a while now I've had the problem randomly that I could not remove the device: upon clicking to unmount it the device properly unmounts but dolphin throws a warning that the device could not be removed because it still would be in use. Even trying to 'cryptsetup luksClose' manually as root brought the same error.

It seems that firejail is the culprit which somehow locks all dmcrypt-devices:
https://gitlab.com/cryptsetup/cryptsetup/-/issues/797
https://github.com/netblue30/firejail/issues/5640

And indeed, as soon as I close all firejail'd applications (in my case: browser and telegram) the device could easily be removed.

[Hu]

Based on the comments in the GitHub issue, I think the problem is not specifically firejail locking dm-crypt, but rather that firejail creates an unshared mount namespace, and so any mounts that exist when firejail starts remain mounted in that namespace for the duration of the jail, even when unmounted in the main namespace. The crypt device cannot be closed until the filesystem in it is unmounted in all namespaces, including the jail namespace. This would be consistent with the claim in the issue that a long-running emerge causes the problem too, since emerge also uses mount namespaces (at least in some circumstance).

One workaround for this would be to create an unshared mount namespace for the mounting of the encrypted filesystem, so that most processes (including firejail) cannot see it, and thus cannot pin it.

It is possible, though I have not tested this, that mounting the crypted filesystem under a tree that is marked as shared would also work, since that should cause the unmount to propagate into the child mount namespaces (unless they disabled propagation).

[freifunk_connewitz]

Thanks for the explanations. It seems that I finally have to wrap my head around this new namespace stuff .