You use tcrypt in your command, but in your cryptab is tcrypt-veracrypt mentioned. What is it now? 
Beside… if you are looking for an automount, which run after the login, then use udisksctl and add commands to the startup. That is much more feasible for usb flash drives.
#Example:
udisksctl unlock --block-device /dev/sda1 --key-file /path/to/key
udisksctl mount --block-device /dev/dm-0
I carefully studied man-crypttab again and also looked at the udisksctl instructions. Which is not suitable for these purposes unless you attach crutches.
(Can I unlock veracrypt encrypted volumes with udisks? · Issue #894 · storaged-project/udisks · GitHub).
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…
This won’t as the run folder is only created when the user logs in.
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. 
Apparently, the point is precisely that I cannot mount the usb before crypttab starts working when the system boots.
this is confirmed by the command:
sudo systemctl start systemd-cryptsetup@cryptobox.service
Which works fine with the same USB flash drive when it is already mounted.
I saw that debian has a special solution for this case. But for me this problem remains open.
(Unlock LUKS Encrypted Volumes at Boot With a USB Key - Will Haley)
Is it possible that Changes to default password hashing algorithm and umask settings mentioned in the [Stable Update] 2023-10-09 announcement could be related?
Maybe.
I’m not enough of an advanced user to check. But I will try to roll back certain packages after the backup.
So thanks for the tip to you. Any thoughts would help.
Most welcome. I’m sure someone will come along to either support or trash the idea. Cheers.
Crypttab is still acting strange.
These settings sometimes work and sometimes they don’t. That is, crypttab creates /dev/mapper entries 1 time, but not the other time (after reboot).
Contents of my /etc/fstab:
UUID=H54T-4Q11 /run/media/user/usb/ auto nofail,auto,nodev,x-systemd.device-timeout=10s 0
Contents of my /etc/crypttab:
cryptobox /home/user/VeraCrypt/cryptobox /dev/null tcrypt-veracrypt,tcrypt-keyfile=/run/media/user/usb/key
I’m still trying to solve this bug. Because my keyfile is on usb.
How can I make this usb more accessible to crypttab?
Must the key remain on a USB? Most usage examples I’ve seen (in the last few minutes) seem to suggest dropping it in /root/key.
Otherwise, all I can think of currently is to somehow delay reading the secret key, in case the USB is simply not mounting quickly enough.
I know that crypttab has an option keyfile-timeout= (it should wait for the device with the keyfile).
But it doesn’t work.
Try increasing the value to, for example 30s, to test the theory; if it works, then try 20s, or whatever may be a more practical delay. Though I imagine you’ve already tried something similar.
I just found the following thread which might be relevant:
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.
Or, maybe add a post-start delay to the systemd-cryptsetup@cryptobox.service .
Something like
[Service]
ExecStartPost=/bin/sleep 30
I’ve never had to try this and am unsure of its accuracy, but it’s worth some further investigation. If it works, it should delay starting the service until the USB drive has mounted.
Test the concept with this:
sudo sleep 30s && systemctl start systemd-cryptsetup@cryptobox.service
Well … I did some research. Wouldn’t it be a more feasble idea to use a udev rule?
Like this:
File: /etc/udev/rules.d/99-my-usb-stick.rules
SUBSYSTEMS=="usb", ENV{ID_SERIAL_SHORT}=="your-usb-serial", RUN+="/usr/local/bin/mount-script.sh"
Run
udevadm monitor --environment --subsystem-match=block | grep ID_SERIAL_SHORT
to get serial id (plugin the usb stick). Why a serial? Because it is very unique, it will only work with that usb-stick and is not easy to fake.
A mount script could look like this:
File: /usr/local/bin/mount-script.sh
#!/usr/bin/bash
CONTAINER="/home/user/VeraCrypt/cryptobox"
KEYFILE="/tmp/usb/key-file"
UUID="UUID"
MAPPER="cryptbox"
TARGET="/mnt/decrypted"
mount -o defaults,X-mount.mkdir -U <UUID> /tmp/usb/
cryptsetup open --type tcrypt --key-file "$KEYFILE" open "$CONTAINER" "$MAPPER"
mount -o defaults,ro,X-mount.mkdir,users "/dev/mapper/$MAPPER" "$TARGET"
Don’t forget to make it executable.
Now everytime you plugin the USB Flash Drive with that specfic SERIAL ID (no other), it will mount it and decrypt it automatically, assuming that the key is not password protected.
Not tested myself, so rather a mental prototype, but I guess you get the idea here.
Except that it’s not the USB drive that’s encrypted, unless I’ve misunderstood the scenario.
No… the container is in @fedreit60 home folder. Only the key is on the USB-Stick. And here is problem… Crypttab needs the key, but the FS is not mounted yet xD
Yes, that was my understanding. Your suggestion seems more elegant than mine.
Then he could add discard, noauto, or nofail to the mount line, as needed.