You are not logged in.
Pages: 1
Hi,
I'm a long-time Debian user (17 years...), finally switching to Arch. I'm using the occasion (setting up a new system) to encrypt some of my partitions with dm-crypt/luks. One of those partitions serves for backups. I want to decrypt+mount when backing up stuff and umount+crypt when that's done.
I have the following in /etc/crypttab:
backup UUID=xxxxxxxx /path/to/key luks,noauto
and in /etc/fstab:
/dev/mapper/backup /media/backup ext4 defaults,noauto,x-systemd.automount 0 2
When booting the system, I find /media/backup unmounted, cryptsetup status backup gives "inactive" and systemctl status media-backup.automount says "active (waiting)".
ls /media/backup takes a couple of seconds (normal) and gives the expected output. Hurray! However, this is only step 1.
When I go "umount /media/backup", cryptsetup status backup shows the decryption is still active (not sure what the correct lingo here is). If I complete the transaction with cryptsetup close backup, all diagnostics return to the status immediately after boot. A somewhat smaller hurray.
The problem is that after this first iteration, a new "ls /media/backup" doesn't do the autmount anymore: cannot access /media/backup: no such device.
An easy workaround would be to remove the crypttab/fstab lines, write 2 2-line bash scripts to do the mounting and the unmounting and forget the entire thing. But I do want to ask the community: What am I doing wrong; is there a more elegant fix to my problem?
I understand that from a security point of view this is somewhat academic: the decryption key is stored on another encrypted partition, but if someone gets access to my running system, they would gain access to my backup partition, whether it is decrypted at that point in time or not. if someone would gain access to a not-running system or only take the disk, the encryption is enforced.
However, I still find the question worth asking, even if it is mostly academical and even if I already have an easy workaround (that would have taken me less time then to type up this post).
Offline
Welcome to the arch linux forums spuddie. Note sure if it will help have you tried the TimeoutIdleSec option https://www.freedesktop.org/software/sy … mount.html
Offline
Hi, thx for the suggestion, but that didn't help. I'll just go with the workaround; still interested in a possible answer though.
Offline
If it doesn't go away with systemd-umount either, then I guess - it's just not part of the concept? Perhaps it's able to resolve the dependency on mount but doesn't have a reverse-dependency on umount.
Sometimes it's intentional to have an active crypt container that isn't mounted (nor swap, lvm, ...). For example I have one such container to act as a key for other containers. So it's not as simple as closing all containers that don't seem to be in use...
For my backups I do it the same way, custom mount / umount script that handles it on demand.
Online
In the mean while I understand why it happens: the service systemctl-cryptsetup@backup.service remains active after cryptsetup close, hence the decryption isn't triggered again. This would make a good start into fixing the problem in a systemd way (just using systemd-umount, which I didn't know before, might already do the trick, can't test that easily anymore).
As said before: I'go with manual mount/unmount scripts, it's actually not even a workaround, it's a simpler solution than a complicated systemd configuration.
thanks!
Offline
Pages: 1