What is the recommended approach for automounting and decrypting a secondary encrypted drive?

Issues & Assistance
1

Hey, just installed CachyOS for the first time a day ago - all my previous linux experience is mainly Ubuntu/Debian/Unraid. Never used Arch before.

My main drive is a LUKS2 NVME.

Secondary is a standard SSD, also LUKS2 - both are btrfs.

I’m somewhat used to using fstab for non-encrypted drives but it’s different with an encrypted drive. The primary drive was set up for me so I don’t know what the process was to have the second drive match.

Also, I want to have both encrypted drives securely decrypt if possible - what is the recommended approach for that?

Is this a good route (Lumo AI)?

That error is exactly what we expected. The kernel sees /dev/sdc1 as crypto_LUKS (an encrypted container), not a filesystem. You can’t mount the container directly; you must unlock it first to reveal the Btrfs filesystem inside, then mount that.

Since you want automatic unlocking and mounting on boot, we need two steps:

  1. /etc/crypttab: Tells the system to unlock the drive automatically at boot (using a keyfile or your boot password).

  2. /etc/fstab: Tells the system to mount the unlocked drive.

Prerequisite: Create a Keyfile (For True Automation)

To unlock without typing a password at boot, you need a keyfile stored on your encrypted boot drive.

Run this to create the keyfile and add it to your LUKS drive:

sudo mkdir -p /etc/cryptsetup-keys && sudo dd if=/dev/urandom of=/etc/cryptsetup-keys/wdblue.key bs=512 count=1 && sudo chmod 0400 /etc/cryptsetup-keys/wdblue.key && sudo cryptsetup luksAddKey /dev/sdc1 /etc/cryptsetup-keys/wdblue.key

(You will be prompted for your current LUKS password to authorize adding the key.)

Step 1: Configure Auto-Unlock (/etc/crypttab)

This tells the system: “At boot, unlock /dev/sdc1 using the keyfile and call it wdblue.”

Run this one-liner:

grep -q "wdblue" /etc/crypttab || echo "wdblue  /dev/sdc1  /etc/cryptsetup-keys/wdblue.key  luks,discard" | sudo tee -a /etc/crypttab

  • wdblue: The name of the unlocked device (it will appear as /dev/mapper/wdblue).

  • luks,discard: discard enables TRIM support for your SSD (crucial for performance/lifespan).

Step 2: Configure Auto-Mount (/etc/fstab)

This tells the system: “Mount the unlocked device (/dev/mapper/wdblue) to /mnt/wdblue.”

Run this one-liner:

grep -q "/mnt/wdblue" /etc/fstab || echo "/dev/mapper/wdblue  /mnt/wdblue  btrfs  compress=zstd,noatime,x-systemd.automount  0  2" | sudo tee -a /etc/fstab

Step 3: Update Boot Image (Critical)

Since the keyfile is on the boot drive, the system needs to know about it before the main OS loads.

Run this:

sudo mkinitcpio -P

Step 4: Reload Systemd & Test

Reload systemd to pick up the new fstab/crypttab changes without rebooting immediately:

sudo systemctl daemon-reload

Then test the unlock and mount manually:

sudo cryptsetup open /dev/sdc1 wdblue --key-file /etc/cryptsetup-keys/wdblue.key && sudo mount -a

(If you get “Device already exists”, just run sudo mount -a).

Verification

Run lsblk -f. You should see:

  1. /dev/sdc1 (Type: crypto_LUKS)

  2. wdblue (Under /dev/mapper/, Type: btrfs, Mounted at /mnt/wdblue)

Now, on the next reboot, the drive will unlock and mount automatically without you typing a password! :rocket::locked_with_key:

2

I’ve previously described how I set this up: here.

The AI gets it mostly right, but does have some errors, and an unhealthy obsession with forced “one-liners”. Notably:

  • You should mkdir and set correct permissions on the mount point first (e.g. /mnt/wdblue)
  • 512 bytes is unnecessarily small for a crypt keyfile
  • Hiding the crypt keyfile away in /etc/cryptsetup-keys/ is unnecessary and invites forgetting about it (if/when you reinstall OS, you’ll want to remember to keep the keyfile / bring it along to new install). Better to put it directly in / or your home directory.
  • luks,discard is optional and missing in my instructions, has benefits and downsides
  • x-systemd.automount will delay mounting until you access the drive, undesirable IMO
  • The last column of a btrfs fstab should be 0, not 2
  • I don’t think there’s any need to run mkinitcpio for this. Wouldn’t hurt anything though.