I have a new installation of ubuntu 22.04, with full disk encryption (LUKS) and ZFS picked from the ubuntu installer options. I need to make some edits to /etc/crypttab so that unlocking my drives works in an automatic way (fancy usb auto unlock), but the edits I'm making to /etc/crypttab aren't persisting to initramfs. What I'm doing is: - Editing /etc/crypttab - Running update-initramfs -u - Rebooting my machine into the the system that asks for the LUKS password (initramfs) - Checking the contents of /etc/ but crypptab isn't there. Have I got my concept of how this works incorrect? I need to persist some version of crypttab to the loader but it isn't working. Any pointers to what I'm doing wrong?

I have been trying to get LUKS disk encryption with TPM2 working on an HP EliteBook 850 G8 running Kali Linux 2022.3. However, I am struggling to get TPM2 disk decryption added to Initramfs. # Steps I have taken so far: * Ensured that TPM2 is enabled and accessible to the OS * Added the TPM as Keystore 1 to the already encrypted hard drive using systemd-cryptenroll --tpm2-device=auto /dev/nvme0n1p3 * Verified the correct LUKS setup by running cryptsetup luksDump /dev/nvme0n1p3 # What fails: Following the steps listed above, I tried to modify the /etc/crypttab to allow unlocking my LUKS2 encrypted disk during boot, similarly to the way Bitlocker works. Therefore, I had changed my crypttab file to the following:

nvme0n1p3_crypt UUID= none luks,discard,tpm2-device=auto

And then tried to rebuild the initramfs using update-initramfs -u -k all, which gives me the following errors:

└─# sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.18.0-kali5-amd64
cryptsetup: WARNING: nvme0n1p3_crypt: ignoring unknown option 'tpm2-device'

What baffles me, is that I thought this option should be present in systemd since version 248 and up. Despite having v251 it does not recognize this option. Can anyone shed some light on what is going on here? Is this something specific to Debian-based systems or am I missing something? Any help or hints are highly appreciated. # System environment: ## OS version:

└─# lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:        2022.3
Codename:       kali-rolling

## Systemd version:

└─# systemd --version
systemd 251 (251.3-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

I installed fedora 40 on a computer that was running parrot os. During install, I deleted all partitions except a 9TB luks data partition. Fedora installed fine, but when I add entries in /etc/fstab: UUID=56ec7d8d-1fed-4e16-831c-0b275ffd89db /mnt/home71 ext4 defaults 0 0 and /etc/crypttab: luks-56ec7d8d-1fed-4e16-831c-0b275ffd89db UUID=56ec7d8d-1fed-4e16-831c-0b275ffd89db none discard to mount the luks data partition during boot, prompting me for a password during boot to open the luks partition, a mount -a command fails with: mount: /mnt/home71: wrong fs type, bad option, bad superblock on /dev/sda5, missing codepage or helper program, or other error. I have no problem manually mounting the luks data partition using: cryptsetup luksOpen /dev/sda5 home71; mount /dev/mapper/home71 /mnt/home71 and after being mounted manually a lsblk -o name,fstype,label,uuid,mountpoint command returns:

├─sda5 crypto_LUKS 56ec7d8d-1fed-4e16-831c-0b275ffd89db 
│ └─home71 ext4 06e81132-ec1f-4685-bd73-be91c2d2b7bc /mnt/home71

I dont know why I am having such issues as I've set luks data partitions to mount this way plenty of times before. I am starting to wonder if maybe by keeping the luks data parition when installing fedora (I have been using debian distro variants for the past 15 years), while deleting all of the other system partitions and re-partitioning that somehow the system can't recognize the previously encrypted partition, even tho it can be manually mounted? I really don't want to have to wipe and delete the partition in order to try re-partioning and re-encrypting just to test if that works because I have a lot of data already on the partition (although it is backed up), and I just don't want to have to re-rsync it all unnecessarily. So I hope someone can maybe see something obvious I am overlooking here and save me and my HDD some time and wear and tear. Thks. --- --- ### Additional details when running command $ lsblk I get a snapshot of my current disk's partition setup.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                             8:0    0   9.1T  0 disk  
├─sda1                                          8:1    0     1G  0 part  /boot
├─sda2                                          8:2    0   512M  0 part  /boot/efi
├─sda3                                          8:3    0     8G  0 part  [SWAP]
├─sda4                                          8:4    0    30G  0 part  
│ └─luks-e4d6a6b0-6889-4317-b13e-4cfad6f37f4b 253:1    0    30G  0 crypt /var
├─sda5                                          8:5    0   8.9T  0 part  
└─sda6                                          8:6    0 164.6G  0 part  
  └─luks-bfb67d91-aa41-40b1-81e9-b480e563a93e 253:0    0 164.6G  0 crypt /

The information listed for /dev/sda5, the luks data partition in question, shows less details than I would expect. I would would think **TYPE** column should list the partition as **crypt** and not jusy **part**, almost like the system doesn't see /dev/sda5 as a luks_crypto partition, unless I manually feed it the info to luksOpen and mount it.

There is scattered information on how to set up a detached header for a LUKS-encrypted disk on Stack Exchange.  And by searching the web using Google, I found limited information.  Some of the best information I found is linked to at the bottom of the question.  Some of it was helpful, even to a newbie like me.  But some seemed incomplete and I was therefore motivated to write this.  Please see if you can help with the question below, to make it complete and working. I assume the reader has used lsblk to find that the drive of header that should be detached is sdb, and stored on some other drive sda. ---------- *Method 1: Making a header into a partition* 1) Find out the size of the header, and make a partition the correct size.  The following command will give you a lot of information.  Take note of the number next to offset under Data segments:

$ cryptsetup luksDump /dev/sdb
    ...
    Data segments:
      0: crypt
    	offset: 16777216 [bytes]
    	length: (whole device)
    	cipher: aes-xts-plain64
    	sector: 512 [bytes]
    ...

Execute fdisk (install it if you do not have it) with $ fdisk /dev/sda. Give it the command n and press Enter.  Make a primary partition with the default partition number; say it is *X*.  Choose and take note of the value of the default first sector (say it is the number *M*).  It will prompt you for the last sector; let's call it *K*.  To find a suitable number *K* to enter (and assuming that the size of a sector is 512 bytes), calculate *K* = *M* + *offset*/512; where *offset* is the number you found above using the luksDump command of cryptsetup.  It will make a partition that is exactly the size of the luks-header. Finally, write the changes with w. Now export the luks-header to ~/some/file/path/header.img and write it to the partition that you made:

   $ cryptsetup luksHeaderBackup /dev/sdb --header-backup-file ~/some/file/path/header.img
   $ dd if=~/some/file/path/header.img of=/dev/sdaX count=offset/512 bs=512 status=progress
   

where *X* and *K* are the numbers that were chosen with fdisk above.  Now the header is stored on sdaX, and for fun, if you open (and if necessary install) the gparted program, you will see that gparted thinks sdaX is a tiny LUKS-encrypted partition!  You will see with lsblk -f that the UUID of /dev/sdaX is the same as that of /dev/sdb. So you have to generate a new UUID (search Google for a 'uuid generator'). Suppose the newly generated UUID is *newuuid*; then change it by

$ cryptsetup luksUUID --uuid newuuid /dev/sdaX

2) Now we have to enter this information into /etc/crypttab.  Open the file with your text editor, and find the line that refers to sdb.  In the fourth column add the option header=/dev/sdaX. **See the answer of frostschutz for how to do this much better by setting header=/dev/disk/by-uuid/UUID.  Be sure to make this modification and upvote their answer.** Then write $ update-initramfs -u -k all.  If there were no errors, then I think you are good. ---------- *Method 2 : Letting the header be a file on a file system* The documentation and other sources say that it should be possible to just copy the header to a file system on sda and refer to it from there. Say we say that the file system of the partition sda1 has

UUID=###########-############-####-########

And relative to sda1, the header is in /some/path/header.img.  Then crypttab(5) says that in the fourth column of /etc/crypttab I should write

header=/some/path/header.img:UUID=###########-############-####-########

But if I do that, update-initramfs complains that the header isn't found. **QUESTION: CAN YOU PLEASE HAVE A LOOK AND QUOTE WHAT TO WRITE.  MY INSTALL OF DEBIAN IS FRESH, AND I CAN'T GET IT TO WORK UNFORTUNATELY.** ---------- In closing; you can erase the information in the existing header with cryptsetup luksErase /dev/sdb. If you ever want to apply cryptsetup to access information about the encrypted partition, you will now have to pass it the --header /dev/sdax-option. I have done my best to make sure everything is correct and detailed. But there could be a bug. Please feel free to edit. Of course, there is no warranty in case you lose your data or break something. Sources/other reading: - cryptsetup, detach header on existing volume (on Super User) - Detached LUKS header (on USB) for an existing full-disk encryption device with Ubuntu - How to use LUKS with a detached header (on LinuxConfig.org) - crypttab(5) on Debian Manpages - crypttab(5) on man7.org

I am following the Debian dev's guide to full disk encryption . I am currently on Section 4, step 3- editing /etc/crypttab. In the guide, in section 3 they set up keyslot 0 for something else and now in section 4 are setting up keyslot 1. However, during my setup, section 3 defaulted to keyslot 1, and therefore for section 4 I will need to use keyslot 0, by adding this to my /etc/crypttab: root_crypt UUID=... /etc/keys/root.key luks,discard,key-slot=0 (the guide has key-slot=1 here instead) I think. I worry that I may be wrong, put key-slot=0 when I should have put key-slot=1, so LUKS looks at the wrong slot for decryption, fails to decrypt due to wrong password, and cannot continue. And since everything's encrypted, I can't fix it with a live OS. So my question is: Does the key-slot= option makes LUKS **only** try that keyslot, or try that keyslot **first** and if it fails try the other ones? Assuming I am wrong and put key-slot=0 when I should have put key-slot=1, will LUKS try slot 0, fail, then try slot 1, and succeed? I've read through /etc/crypttab's manpage and found nothing but a reference to cryptsetup -S, but cannot find the manpage that describes this option. I can only find one page on cryptsetup, which doesn't include the -S option. Thank you very much!

I want to create setup with a encrypted root filesystem on my Arch Linux installation, so when I successfully mounted my /boot and /boot/efi partitions, I'm contuning with grub installation with grub, efibootmgr and os-prober packages. Then I'm making these changes on my /etc/default/grub file for both GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX lines: "net.ifnames=0 cryptdevice=UUID=:cr_root root=/dev/mapper/cr_root" But however, when I run grub-install then grub-mkconfig -o /boot/grub/grub.cfg, I cannot see cryptdevice parameter I specified in my /boot/grub/grub.cfg file. Instead of that, I'm seeing root=. So therefore, when I reboot to that system, bootloader can successfully load the kernel, but kernel cannot see the actual root filesystem because it's looking for the device with UUID of encrypted **filesystem inside the LUKS container**, not the **partition**. Thus, it's says that waiting for the device /dev/disk/by-uuid/uuid-of-the-encrypted-filesystem when attempting to boot the system, but cannot continue to the boot and neither asks for the decryption password. I've also tried adding root filesystem's entry to /etc/crypttab then re-running mkinitcpio, and also regenerating my grub.cfg, nothing worked.

After I upgraded from Linux Mint 21.1 to 21.2 the newest initrd stopped working. The older one works fine. Regenerating the initrd doesn't help. On startup with the newest initrd the error tells that the UUID of my decrypted Rootdrive does not exist, so I am guessing that the crypttab doesn't get used. I checked the crypttab that hasn't changed.

if you're using the live usb (this is specific to pop!_os 21.04, but i think it would apply to ubuntu etc) and you do a fresh reinstall, would you need to boot into the new system to get access to the newly created /etc/fstab file (and crypttab file?), and if not, how do you access it from the live usb after the fresh install? would you simply unencrypt the drive, mount, and then grab a copy there? or another way to go about it would be to use a copy of /etc/fstab (and /etc/crypttab ?) from a timeshift snapshot and edit it. then simply restore the edited /etc/fstab (and /etc/crypttab? ) with timeshift. this question is in response to the following answer: https://unix.stackexchange.com/a/636712/497219

I'm using EndeavorOS (basically Arch), but with systemd-boot and dracut for initrd. I have a simple setup with an unencrypted boot partition and LUKS-encrypted root and swap partitions. Specifically, the setup is described in the output below:

`
$ cat /etc/fstab
#                      
UUID=8A2F-4076                            /efi           vfat    defaults,noatime 0 2
/dev/mapper/luks-81733cbe-81f5-4506-8369-1c9b62e7d6be /              ext4    defaults,noatime 0 1
/dev/mapper/luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 swap           swap    defaults   0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

$ lsblk -f
NAME                                          FSTYPE      FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1                                                                                                                         
├─nvme0n1p1                                   vfat        FAT32             8A2F-4076                             915.6M     8% /efi
├─nvme0n1p2                                   crypto_LUKS 1                 81733cbe-81f5-4506-8369-1c9b62e7d6be                
│ └─luks-81733cbe-81f5-4506-8369-1c9b62e7d6be ext4        1.0   endeavouros d8d14c59-8704-4fb8-ad02-7d20a26bc1e1  843.6G     2% /
└─nvme0n1p3                                   crypto_LUKS 1                 9715a3f9-f701-47b8-9b55-5143ca88dcd8                
  └─luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 swap        1     swap        b003ea64-a38d-464c-8609-7278e21f8a0f                [SWAP]

` The problem is that each time I boot up the computer, I need to enter my password twice; once for the root partition and once of the swap (note I use the same password for both if that helps). This has become nuisance. So my question is: Is there a way to automatically decrypt my swap partition upon a successful passphrase for the root? There has been a question very similar to this with [a sensible answer](https://unix.stackexchange.com/a/392286/509294) , but did not work. The first part of the answer is Debian-centric with a script option not present in other distributions. The second part uses crypttab to specify the location of a keyfile used to decrypt other partitions. As of now, my crypttab in initrd looks like this, which specifies a /crypto_keyfile.bin that exists in the root partition to open either of the partitions:

`
$ lsinitrd --file /etc/crypttab
luks-81733cbe-81f5-4506-8369-1c9b62e7d6be /dev/disk/by-uuid/81733cbe-81f5-4506-8369-1c9b62e7d6be /crypto_keyfile.bin luks
luks-9715a3f9-f701-47b8-9b55-5143ca88dcd8 /dev/disk/by-uuid/9715a3f9-f701-47b8-9b55-5143ca88dcd8 /crypto_keyfile.bin luks

` This approach does not work for two reasons: 1. Contrary to what the linked answer suggests (being that the user is queried for the partitions by the order of crypttab entries), the order is random at each boot. Even if I could automatically open my swap partition after opening the root, if swap comes first, then I am still forced to enter the password for root since keyfile is on root. 2. It seems to me that after entering password for root, the filesystem is not mounted immediately. The /crypto_keyfile.bin is actually searched inside the initrd filesystem, which explains the following errors in journal appearing twice: systemd-cryptsetup: Failed to activate, key file '/crypto_keyfile.bin' missing. So if I am on the right track, how could I ensure systemd-cryptsetup to query me first for the root partition and second for the swap each time, and how can I ensure that after opening root, the filesystem is mounted and /crypto_keyfile.bin is successfully found to open the swap partition? Otherwise, if I am completely off track here, is there a way to achieve what I want? Thanks.

Here's what I'd like to do. Use autofs to automount an encrypted luks image file when the target directory is accessed. I've been playing with both fstab and crypttab, but to no luck. I do NOT want to use a key file to decrypt it. A password prompt window should appear when attempting to query the target mount folder /encrypted. cryptsetup should be mounting a file located at /secret/data.img which is a LUKS formatted file that once decrypted contains an ETX4 file system. That file system should then be mounted at /encrypted, but only after prompting the user for its password. Bonus question, after a period of idle(timeout) inactivity, autofs should be closing the luks volume so that further access requires reentering the key. Can this be done? Here is my current fstab and crypttab. --FSTAB-- UUID=11111111-2222-3333-4444-555555555555 /encrypted ext4 defaults,auto,x-systemd.automount,uid=1234,gid=1234,cache=no,rw 0 0 --CRYPTTAB-- trust-no-1 /secret/data.img none auto,rw There are no questions that contain both autofs and luks keywords. Is this even possible?

I know that by configuring **crypttab** I can automatically unlock **LUKS** drives by using keyfile stored on another drive in the machine which has been manually unlocked in advance. I have been wondering **if a keyfile stored in a different machine/device can also be used**, accessed e.g. over ssh. **Here is what I would like to achieve.** A machine with an encrypted LUKS drive would at startup look at a particular IP address in the local network and if a device (android phone) is present, it would read a keyfile from the device and use it to unlock its drive, otherwise it would ask for password. **Are there any better approaches to this?** I have found that there exists blueproximity which does something similar for lock-screen.

I have an encrypted partition that I configured with crypttab like /etc/crypttab:

name UUID= none luks,noauto

and /etc/fstab

UUID= /mnt/mountpoint ext4 defaults,noauto 0,0

Now, I want the unit nfs-server.service to start up automatically once I manually decrypted the partition using systemctl start systemd-cryptsetup@name.service. With some advice on the #debian-Matrix-Channel I finally got

# systemctl edit nfs-server.service
[Unit]
After=systemd-cryptsetup@name.service
After=mnt-mountpoint.mount
Requires=mnt-mountpoint.mount

With this setup I can start the nfs-server after decrypting manually. Still, I'd prefer systemd to automatically start nfs-server (which in turn should already auto-mount the then decrypted partition). How do I need to edit the nfs-server.service (or maybe even another unit?) in order for systemd to start it automatically once I decrypted the partition? I guess I could similarly use the logic for other units to start automatically after the nfs-server.service?

In ubuntu 19.10 I followed the example here . The keyfile is at the root of usb key filesystem. usbkey has uuid yyyy. the /etc/crypttab is like this:

encrypted UUID=xxxx /keyfile:UUID=yyyy luks,keyfile-timeout=60,x-systemd.device-timeout=2min

The automatically generated generator is /run/systemd/generator/systemd-cryptsetup@encrypted.service

# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
RequiresMountsFor=/keyfile:UUID=yyyy
BindsTo=dev-disk-by\x2duuid-xxxx.device
After=dev-disk-by\x2duuid-xxxx.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/lib/systemd/systemd-cryptsetup attach 'encrypted' '/dev/disk/by-uuid/xxxx' '/keyfile:UUID=yyyy' 'luks,keyfile-timeout=60'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'encrypted'

however, I did not see any thing related to mount the usb key in the journalctl. I always directly launch the system-cryptsetup and fail to find the file.

systemd-cryptsetup: Encountered unknown /etc/crypttab option 'keyfile-timeout=60', ignoring.
systemd-cryptsetup: WARNING: Locking directory /run/cryptsetup is missing!
systemd[1] : Started File System Check Daemon to report status.
systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/xxxx
systemd-cryptsetup: Failed to open key file.
systemd-cryptsetup: Failed to activate with key file '/keyfile:UUID=yyyy

On Fedora Workstation 35 here. systemd v249 I am trying to unlock root LUKS volume with smart card on BOOT, but it does not work. I added to /etc/crypttab mydisk UUID=496e1cd5-712f-44ab-ad02-5fb6f7419af8 none pkcs11-token-uri=auto,luks,discard My disk is properly enrolled with sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/... and I can the slot with luksDump I verified I can mount with sudo /usr/lib/systemd/systemd-cryptsetup attach MountName /dev/... none pkcs11-uri=auto In reboot there is a password prompt. Console reads: Entering Cryptography Setup712f-44ab-ad02-5fb6f7419af8: Please enter passphrase for disk WDS...[diskmodel]: **Only the recovery password works here. There is no way to use the smart card and enter the pin for it** I am using the same crypttab approach and same smart card to unlock other drives (external HDD) and it works (Although not in disks, only on boot, Disks app always asks for password when I try to mount, but this is another issue). The smart card is Yubikey based. As per the announcement here: https://www.phoronix.com/scan.php?pa...lock-Encrypted and man here: https://www.freedesktop.org/software...@.service.html This functionality should work. I quote from the documentation:

In order to unlock a volume a password or binary key is required. systemd-cryptsetup@.service tries to acquire a suitable password or binary key via the following mechanisms, tried in order:

If a key file is explicitly configured (via the third column in /etc/crypttab), a key read from it is used. If a PKCS#11 token, FIDO2 token or TPM2 device is configured (using the pkcs11-uri=, fido2-device=, tpm2-device= options) the key is decrypted before use.

If no key file is configured explicitly this way, a key file is automatically loaded from /etc/cryptsetup-keys.d/volume.key and /run/cryptsetup-keys.d/volume.key, if present. Here too, if a PKCS#11/FIDO2/TPM2 token/device is configured, any key found this way is decrypted before use.

If the try-empty-password option is specified it is then attempted to unlock the volume with an empty password.

The kernel keyring is then checked for a suitable cached password from previous attempts.

Finally, the user is queried for a password, possibly multiple times, unless the headless option is set.

This works: crypttab: sda2_crypt UUID=6bbba323-ddad-479d-863e-4bd939b46f96 none luks,swap sda3_crypt UUID=3087cec6-dcc9-44ee-8a08-5555bb2ca566 none luks fstab: /dev/mapper/sda3_crypt / ext4 errors=remount-ro 0 1 /dev/mapper/sda2_crypt none swap sw 0 0 But when I try to change it to this and run update-initramfs -u -k all, it gives me this error: cryptsetup: WARNING: failed to determine cipher modules to load for part_root_crypt crypttab: part_swap_crypt UUID=6bbba323-ddad-479d-863e-4bd939b46f96 none luks,swap part_root_crypt UUID=3087cec6-dcc9-44ee-8a08-5555bb2ca566 none luks fstab: /dev/mapper/part_root_crypt / ext4 errors=remount-ro 0 1 /dev/mapper/part_swap_crypt none swap sw 0 0 I wanted to change this because when I installed my operative system, this disk was sda, but afterwards I've added more disks and now it's sdb and I'd like to change it's name to something disk independent. What am I missing here?

I'm trying to mount two btrfs subvolumes from a same (luks-encrypted) device via the entries in fstab. The crypttab entry must be correct, since the system asks for the password on boot. But then it hangs with a black screen. The entries are: (**this example is correct, the only problem was the wrong UUID, which was of the encrypted partition, not the decrypted mapped device**. I'll leave the question in case anyone searches for a specific working example of btrfs and fstab). UUID={same uuid for device under /dev/mapper} /home/me btrfs defaults,ssd,subvol=home-me-dir,noatime 0 3 UUID={same uuid for device under /dev/mapper} /tmp btrfs defaults,ssd,subvol=tmp-dir,noatime,nodatacow,nodatasum 0 4 I tried both subvol=path and subvolid=id options. I ran sudo systemctl daemon-reload as was mentioned in the fstab file. I'm not sure whether my problem is with it or with systemd (I suspect the issue is with fstab and btrfs since IIRC I did this with ext4 and everything worked OK). So could anyone answer this, please: - How to specify a path for the subvolume in the options, i.e. the subvol=path option? There were no examples in the man 5 btrfs, only the statement, that the path is always relative to the root subvolume, so I tried subvol=some-dir and subvol=/some-dir to no avail; - Does the root subvolume have to be mounted to use the subvol=path or subvolid=id options for its children subvolumes in fstab? When I use subvol=some-dir the decrypted device is not even mounted yet. Thank you.

I have looked at how to be able to imbue in a crypttab stanza (referring to a LUKS device) to allow _a specific_ user or _any unprivileged_ user to map it. Roughly, I am looking for the equivalent of user in the mount options in /etc/fstab when mapping the LUKS device (i.e. before mounting it). The only (half way sensible) approach I have come up so far was to let my unprivileged user run a wrapper script which runs cryptdisks_start usint its absolute path as root without password, but with the name hardcoded in it. Obviously the script permissions make it impossible for the unprivileged user to tamper with it. Is there a more straightforward solution, perhaps akin to user in fstab? This is on Ubuntu 20.04 and so perhaps systemd offers some way to achieve this? After all there is a unit such as systemd-cryptsetup@.service being auto-generated by it, based on the entry in crypttab. As a side note: I am aware of pam_exec, but I am currently in the process of pondering which one works better for me. Either way it appears that there is no way to run it without superuser privileges.

I am troubleshooting a debian system that will not boot; the system booted fine, and one day ceased to do so (possibly but not definitely related to an apt upgrade). It has a small boot partition (sda1), a LUKS container on sda2. Inside the LUKS container is an LVM layer with two members formatted as ext4 (/ and /home). Upon booting, cryptsetup does not even run and the following error is shown: "WARNING: Failed to connect to lvmetad. Falling back to internal scanning." The computer then drops to an initramfs console. Mounting and chrooting the affected disk on another computer, I find when attempting to update initramfs that /etc/cryptsetup is invalid, despite appearing to be fine. The error is: "cryptsetup: WARNING: invalid line in /etc/crypttab for sd1 -" My crypttab file has merely the following: crypt UUID= none luks blkid or lsblk confirm that the appropriate UUID has been selected (that of /sda2, whose child is a LUKS container named crypt). Some version information: debian: 9.8 kernel: 4.9.0.6-amd64 cryptsetup: 1.7.3 lvm: 2.02.168(2) Note that sd1 is another LUKS device, that of the computer on which the faulty drive has been mounted for troubleshooting. Perhaps in that case, the warning can simply be ignored? Even so, the problem (crypt is bypassed) persists after update-initramfs when the faulty drive is used as the boot device. At this point, since I'm not really sure what the problem is, I am considering reinstalling grub and reinstalling the kernel. However, I would appreciate suggestions on alternative steps. Many thanks.

I have an ARM server that I want to have booted with (not booting FROM) a USB flash drive containing a LUKS keyfile, that's needed to decrypt a hard drive I have connected to the drive. So in order to run /etc/crypttab (to decrypt the drive) I need the USB mounted first in order to mount the drive (fstab runs after crypttab). How could I mount a partition before crypttab starts? On systemd and Linux 4.4. For clarity: 1. First, I'd like the USB drive partition (let's say /dev/sdb1) to be mounted at /mnt/usb (not encrypted) 2. Then, using crypttab to unlock the encrypted partition on one of the drives using a keyfile at /mnt/usb/mykeyfile 3. Then, mounting filesystem to /mnt/crypt_fs

I'm setting up an encrypted root fs, which I've done before, but this time I'm using a PGP-encrypted keyfile with a symmetric password to familiarize myself with the process. There are two places where configuration of encrypted roots seems to occur, in the kernel init options under cryptopts, and in /etc/crypttab, which seems to be used by mkinitramfs to bake certain things into the initramfs. It's kind of cumbersome to update things in both places; after all, what's the point of having it in two places if the one suffices? I do see the value of having things in /etc/crypttab, as the initramfs can be generated differently with different hooks and scripts if a LUKS volume is present. Using a previous example emended for this question, here's my crypttab: picrypt /dev/mmcblk0p2 /boot/diskkey.gpg luks,keyscript=/lib/cryptsetup/scripts/decrypt_gnupg Presumably, this tells the initramfs that /dev/mmcblk0p2 should be decrypted to use the name picrypt, specifying that we want to use luks and to pass the /boot/diskkey.gpg file to the /lib/cryptsetup/scripts/decrypt_gnupg script to generate a passphrase for the volume. Next, here are my cryptopts from my kernel init line: cryptopts=target=picrypt,source=/dev/mmcblk0p2,lvm=pi Again, we're re-specifying that /dev/mmcblk0p2 creates picrypt, and in this case we're also telling it that there's an LVM volume inside called pi which it should wait for before trying to mount the root filesystem specified by the root=/dev/mapper/pi-root kernel parameter. This setup isn't working, strangely enough, as it seems to be ignoring the crypttab's key file and key script parameters and not prompting for the GPG symmetric key passphrase, rather directly for a key. I'm going to emend my script to include keyscript and keyfile in cryptopts, but _why_ must I do this? Is there a way to include all of this (or at least most of it) in /etc/crypttab and not duplicate everything in the kernel init line? It's kind of ridiculous to have to change everything twice. Do these different sources simply provide different functions, crypttab in the form of hooks and cryptopts in the form of actual parameters to cryptsetup?