How to Encrypt a Data Drive with LUKS (and Unlock It at Boot Without Typing a Passphrase)

If someone walks off with the server — a burglary, a move, a sale of the old hardware — the data drive's contents are readable on any Linux machine in minutes. LUKS is Linux's standard disk encryption: the drive holds ciphertext, a key unlocks it, and once unlocked it's an ordinary filesystem. The trick for a headless server is unlocking without a keyboard: a keyfile on the system disk (protects against the data drive alone leaving) or on a USB stick you remove (protects against the whole box leaving).

• Protects: the drive at rest. A pulled drive, a stolen box (with the keyfile removed), a drive sent for RMA or sold.
• Doesn't: anything while the server is running and unlocked — a compromised SSH session sees everything. Backups (23) are separately encrypted by restic (55) and rclone crypt (54) already. Tutorial 70's 2FA and 39's checklist protect the running system; LUKS protects the powered-off one.

This erases the drive. Back it up or use a new one. Partition it (sudo fdisk /dev/sdb → n, defaults, w), then:

sudo apt install cryptsetup -y
sudo cryptsetup luksFormat --type luks2 /dev/sdb1

Type YES, then a strong passphrase — this is the recovery key; it goes in the password manager (43) and on paper. Then:

sudo cryptsetup open /dev/sdb1 data
sudo mkfs.ext4 -L data /dev/mapper/data
sudo mkdir -p /mnt/data && sudo mount /dev/mapper/data /mnt/data

/dev/mapper/data is the unlocked device; everything from tutorial 22 applies to it. For ZFS, zpool create tank /dev/mapper/data (or use ZFS's own native encryption instead — -O encryption=on — which is the better choice for ZFS pools).

sudo dd if=/dev/urandom of=/root/data.key bs=512 count=8
sudo chmod 400 /root/data.key
sudo cryptsetup luksAddKey /dev/sdb1 /root/data.key

The drive now opens with the passphrase or the keyfile (LUKS has eight key slots). /root/data.key on the system SSD means: pull the data drive alone and it's useless; steal the whole box and the key goes with it. For the stronger version, put the key on a USB stick that lives in the server and leaves with you when the box does — see step 4.

sudo blkid /dev/sdb1 # the UUID of the LUKS container
sudo nano /etc/crypttab

data UUID=the-luks-uuid /root/data.key luks,discard,nofail

Then fstab uses the mapper device:

/dev/mapper/data /mnt/data ext4 defaults,nofail,x-systemd.requires=systemd-cryptsetup@data.service 0 2

sudo update-initramfs -u
sudo umount /mnt/data && sudo cryptsetup close data
sudo systemctl daemon-reload && sudo systemctl start systemd-cryptsetup@data.service && sudo mount -a
ls /mnt/data

Reboot to prove it. nofail on both lines keeps the boot going if the key or drive is missing — the drive just stays locked.

Format a tiny USB stick ext4 with a label keys, copy data.key onto it, and in crypttab:

data UUID=the-luks-uuid /dev/disk/by-label/keys:/data.key luks,discard,nofail,keyfile-timeout=10s

(Some distros use /dev/disk/by-label/keys:/data.key via the cryptsetup helper; the keyfile-timeout stops boot waiting forever.) The server boots and unlocks with the stick in; pull the stick before the removal men arrive, or when you sell the box, and the drive is sealed. Keep the passphrase as the fallback.

The LUKS header at the start of the drive holds the key slots. A bad sector there makes the whole drive unrecoverable, passphrase or not:

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/data-header.img

Store that file off the server, with the passphrase. luksHeaderRestore puts it back.

Nothing changes: /mnt/data mounts at boot, Docker and Samba use it, SMART (56) still reads the physical drive. Backups continue — restic encrypts separately. sudo cryptsetup luksDump /dev/sdb1 shows the slots; luksRemoveKey drops one; luksChangeKey rotates the passphrase.

Boot waits for a passphrase. crypttab points at a key path that isn't there, or update-initramfs wasn't run. nofail + keyfile-timeout so it gives up and boots.

"No key available with this passphrase". Wrong passphrase or wrong device; check with luksDump.

Mount fails at boot but works by hand. fstab lacks the x-systemd.requires dependency, so it tries before the unlock.

Performance drop. AES-NI makes it negligible on any Intel/AMD since ~2012; Pis lack it and lose real throughput — use adiantum cipher there (luksFormat --cipher xchacha20,aes-adiantum-plain64).

luksFormat, a passphrase for the safe, a keyfile for boot (on the system disk or a removable stick), crypttab plus fstab with nofail, a header backup off-site. The server runs exactly as before; a drive or a box that leaves without you is ciphertext.