Crypttab no longer works after the 10.2023 update.
Usually I always find or figure out the solution to problems on my system myself. But this time, I’m completely lost in guesswork, and already seem to have scoured the entire internet.
So please help!
Problem: Crypttab when starting the system no longer creates anything in /dev/mapper and just ignores the usb key file it seems. This happened after the last update and I’ve tried several rollbacks, but I’m convinced that the last update is the cause. Everything worked fine before and has worked fine for a long time!
Contents of my /etc/crypttab: cryptobox /home/user/VeraCrypt/cryptobox /dev/null tcrypt-veracrypt,tcrypt-keyfile=/run/media/user/usb/key
Contents of my /etc/fstab: UUID=H54T-4Q11 /run/media/user/usb/ auto nofail,auto,nodev,x-systemd.device-timeout=10s 0
It doesn’t work anymore, after I upgraded my system in Oct.
Everything still works, if I change the path to the key, which is not on the USB flash drive, but for example in /home/user/key - then everything works. So, the problem is in the interaction with the usb-flash.
If use cryptsetup manually, everything is fine: sudo cryptsetup --type tcrypt --key-file '/run/media/user/usb/key' open '/home/user/VeraCrypt/cryptobox' shared
As for the tcrypt and tcrypt-veracrypt options, this option always worked before:
tcrypt-veracrypt,tcrypt-keyfile= (guide: Automount VeraCrypt with Crypttab | Delightly Linux)
And it still works, but only if the key file is not on the USB flash drive. crypttab still decrypts if the keyfile is on the local system, such as home/user. But it does not read the key from the USB flash drive.
I wouldn’t want to replace crypttab and fstab with something else. Because it worked for a long time. I just don’t understand what happened after the recent update and it no longer works…
Maybe I’m missing the knowledge here, but logically a decryption key shouldn’t be on an encrypted partition. This is the same as if you throw the key into the apartment, close the door and then try to open the door with the key in the apartment.
Or have I misunderstood something?
If it’s an image and the key is right next to it, then that’s just as smart. In any case, the USB stick should be mounted first (so that it can reach the key), then the image should be unlocked and then the unlocked image should be mounted. Better would storing the key on the system like described on the linked tutorial.
Logically, cryptab runs first and then fstab on boot, but in your case it has to run the other way around. I have no idea why this worked.
The Keyfile is located on an unencrypted USB flash drive. I simply inserted it when I wanted the system to open my containers at startup.
But you are now saying that crypttab starts before fstab. If this is true, then this is even more puzzling… I don’t even know how to check this. I just tried a bunch of options already.
As a temporary measure, I just put the keyfile in a local folder so that I could get my containers. But in the long term this is completely unsuitable, since there is no point in having a lock if you keep the key to the apartment on a nail in front of the door.
I highly doubt that this worked. Logically it cannot. It would only work if it would be a real encrypted partition and not a container and all tutorials I read mention block devices and not containers. crypttab also doesn’t mention the possibility to use container files.
Use veracrypt to unlock and mount your containers after login.
I have already communicated with this person. And he tried to help as much as he could, but his problem turned out to be different. So it didn’t work for me.
Also, my /etc/mkinitcpio.conf remained unchanged after the manjaro 09.10 update. Namely, after him everything went to hell.