How to Auto Mount and Unlock LUKS Encrypted Partitions at Boot

After you encrypt a partition with LUKS, the volume stays locked until something runs cryptsetup open. For a data disk you want every boot, that unlock step belongs in /etc/crypttab, and the mount belongs in /etc/fstab.

This guide follows the same sequence for both unlock styles: wire crypttab and fstab, test on a running system without rebooting, then reboot once to confirm boot behavior. You can stop at a passphrase prompt (none in crypttab) or use a keyfile for unattended auto-mount. Day-to-day cryptsetup syntax lives in the cryptsetup command cheat sheet.

Examples use the LUKS2 volume on /dev/sdc1 (mapper name secure_data, ext4 label secure-data) from the encrypt walkthrough. Substitute your device names, UUIDs, and mount point in every command.

Tested on: Ubuntu 26.04 LTS (Resolute Raccoon); kernel 7.0.0-27-generic; cryptsetup 2.8.4.

What you need on your system

Before editing crypttab or fstab, collect these on your host:

Also confirm:

• Manual unlock and mount work before you edit boot config.
• If the LUKS header UUID changes after a restore, update crypttab to match.
• Take a LUKS header backup before risky header or key-slot work.

Quick reference

Get identifiers from the lab volume:

• LUKS UUID (crypttab): sudo blkid /dev/sdc1
• Filesystem UUID (fstab): sudo blkid /dev/mapper/secure_data after unlock

Wiring rules:

• crypttab unlock runs first and creates /dev/mapper/name.
• fstab mounts the filesystem inside that mapper once it exists.
• Do not put the LUKS UUID in fstab or the ext4 UUID in crypttab—that is the most common mistake.
• For each path below: configure both files → test without reboot → confirm with reboot.

Identify the LUKS partition

With the volume locked, the lsblk command shows crypto_LUKS on the partition and no mapper child yet:

lsblk -f /dev/sdc1

Sample output:

NAME FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdc1 crypto_LUKS 2           5f452b2f-3b11-4494-890b-d6c3e509c0ef

That UUID is the LUKS container ID for crypttab—not the ext4 filesystem UUID you will put in fstab.

Confirm the header when in doubt:

sudo cryptsetup luksDump /dev/sdc1 | head -8

Sample output:

LUKS header information
Version:       	2
Epoch:         	52
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	5f452b2f-3b11-4494-890b-d6c3e509c0ef
Label:         	(no label)
Subsystem:     	(no subsystem)

From that header dump:

• UUID must match lsblk -f and blkid on /dev/sdc1—that value goes in crypttab field 2.
• Version: 2 confirms LUKS2.

If luksDump reports not a valid LUKS device, recheck the partition with lsblk -f—you may have targeted an unencrypted or wrong /dev/sdX node.

Unlock once so you can see the mapper and filesystem layer:

sudo cryptsetup open /dev/sdc1 secure_data

A successful unlock prints nothing; /dev/mapper/secure_data appears when the passphrase is accepted.

lsblk -f /dev/sdc1 /dev/mapper/secure_data

Sample output:

NAME          FSTYPE      FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdc1          crypto_LUKS 2                 5f452b2f-3b11-4494-890b-d6c3e509c0ef
└─secure_data ext4        1.0   secure-data 9fe05bbb-e530-48ed-a8f7-461febc7329f
secure_data   ext4        1.0   secure-data 9fe05bbb-e530-48ed-a8f7-461febc7329f

The ext4 UUID on secure_data is what belongs in fstab—not the crypto_LUKS UUID on sdc1.

Close the mapper when you finish inspecting: sudo cryptsetup close secure_data.

UUID vs PARTUUID vs device path in crypttab

The second crypttab field names the block device that holds the LUKS header. Three forms are valid; only one belongs in production config.

Collect the values on your host:

sudo blkid -o value -s UUID /dev/sdc1

Sample output:

5f452b2f-3b11-4494-890b-d6c3e509c0ef

That line is the LUKS UUID for crypttab field 2.

PARTUUID comes from the GPT partition table—a different identifier used only in special layouts:

sudo blkid -o value -s PARTUUID /dev/sdc1

Sample output:

b2ec5a76-8585-4e6b-9926-3ca5094fcea1

Use in crypttab:

• Prefer UUID= from the crypto_LUKS line (blkid or luksDump).
• Reserve PARTUUID= only when the GPT partition slot is fixed but the LUKS header UUID is unknown (uncommon for data disks).
• Never copy the ext4 filesystem UUID into crypttab—that belongs in fstab only.

Manual unlock and mount (baseline)

Before editing boot config, prove the mapper and mount path work by hand. Mounting an unlocked LUKS mapper follows the same mount command workflow as any other block device. If you closed the mapper after the identify step, run cryptsetup open again. The sudo command prefix is required for cryptsetup and mount operations:

sudo cryptsetup open /dev/sdc1 secure_data

Enter the passphrase when prompted; a successful open prints nothing.

sudo mkdir -p /mnt/secure-data
sudo mount /dev/mapper/secure_data /mnt/secure-data

mount also exits quietly when the mapper path is correct.

Confirm the mount path:

mount | grep secure_data

Sample output:

/dev/mapper/secure_data on /mnt/secure-data type ext4 (rw,relatime)

That mount line is what you want fstab to reproduce after boot unlock.

When this host will not boot, you can open and unlock the LUKS disk on another Linux machine with the same mapper name and mount steps.

Close when finished testing:

sudo umount /mnt/secure-data
sudo cryptsetup close secure_data

After close, lsblk -f /dev/sdc1 shows only crypto_LUKS again—the mapper is gone until the next unlock.

The mapper name you choose here (secure_data) must match the first field in /etc/crypttab.

Install cryptsetup tools

On Ubuntu and Debian, install the base package (skip if cryptsetup is already present):

sudo apt install -y cryptsetup

apt may report the package is already installed—that is fine.

If this host also unlocks LUKS volumes during initramfs (root, resume, or crypttab entries with the initramfs option), install the initramfs integration package:

sudo apt install -y cryptsetup-initramfs

Confirm the initramfs hook package is installed with the dpkg command:

dpkg -l cryptsetup-initramfs | awk '/^ii/{print $2, $3}'

Sample output:

cryptsetup-initramfs 2:2.8.4-1ubuntu4

That ii package line confirms the initramfs hook is present.

Package roles on a secondary data disk:

• cryptsetup — enough for normal boot; systemd reads /etc/crypttab from the real root.
• cryptsetup-initramfs — only when root, resume, or crypttab entries use the initramfs option.

On Fedora and other distros, install the equivalent packages locally—the apt command examples here map to your package manager.

Boot unlock and auto-mount

Both paths use the same wiring: crypttab unlocks LUKS and creates /dev/mapper/name; fstab mounts the ext4 filesystem inside that mapper. The only difference is the third crypttab field—none waits for you at boot, a keyfile path unlocks silently.

For each path: configure both files → test without reboot → reboot to confirm.

Passphrase prompt at boot

On Ubuntu and Debian with systemd, a secondary data disk usually unlocks after the root filesystem is up—not in initramfs unless you add the initramfs crypttab option. Boot order:

1. systemd-cryptsetup@secure_data.service reads your crypttab line.
2. With key path none, boot prompts for the passphrase (Plymouth on desktop Ubuntu, or plain text on serial/server consoles).
3. Unlock creates /dev/mapper/secure_data.
4. fstab mounts the ext4 filesystem on that mapper.

crypttab entry

Edit /etc/crypttab (root) and add one line:

secure_data UUID=5f452b2f-3b11-4494-890b-d6c3e509c0ef none luks

crypttab options differ by volume type:

• Root volume — often adds initramfs so unlock happens before pivot root.
• Secondary data disk — plain luks is enough unless you deliberately want the prompt during initramfs.

fstab entry

Mount the filesystem UUID inside the mapper, not the LUKS UUID:

sudo blkid /dev/mapper/secure_data

Sample output:

/dev/mapper/secure_data: LABEL="secure-data" UUID="9fe05bbb-e530-48ed-a8f7-461febc7329f" BLOCK_SIZE="4096" TYPE="ext4"

Copy the UUID= value from that line into fstab—not the LUKS UUID from /dev/sdc1.

Add to /etc/fstab:

UUID=9fe05bbb-e530-48ed-a8f7-461febc7329f /mnt/secure-data ext4 defaults,noatime 0 2

Create the mount point once: sudo mkdir -p /mnt/secure-data.

Confirm crypttab names the mapper and LUKS UUID with grep:

grep secure_data /etc/crypttab

Sample output:

secure_data UUID=5f452b2f-3b11-4494-890b-d6c3e509c0ef none luks

Confirm fstab references the ext4 UUID inside the mapper—not the LUKS UUID:

grep 9fe05bbb-e530-48ed-a8f7-461febc7329f /etc/fstab

Sample output:

UUID=9fe05bbb-e530-48ed-a8f7-461febc7329f /mnt/secure-data ext4 defaults,noatime 0 2

Test without a reboot

Close the mapper so the test starts from a locked volume:

sudo umount /mnt/secure-data 2>/dev/null || true
sudo cryptsetup close secure_data

On systemd hosts, reload units and start the cryptsetup service—the same path boot uses (systemctl):

sudo systemctl daemon-reload
sudo systemctl start systemd-cryptsetup@secure_data.service

Type the LUKS passphrase when prompted. Then mount and verify:

sudo mount /mnt/secure-data
findmnt /mnt/secure-data

Sample output:

TARGET           SOURCE                FSTYPE OPTIONS
/mnt/secure-data /dev/mapper/secure_data ext4   rw,noatime

On Debian systems without systemd cryptsetup units, use sudo cryptdisks_start secure_data instead, then sudo mount /mnt/secure-data.

If unlock fails, check systemctl status 'systemd-cryptsetup@secure_data.service' before you reboot.

Confirm with a reboot

When the no-reboot test passes, reboot once to confirm boot behavior:

sudo reboot

With none as the key path, boot waits until you enter the LUKS passphrase.

On Ubuntu 26.04 with a desktop Plymouth boot, the prompt is graphical and names the crypttab mapper—here secure_data on partition primary. The exact wording can differ (Please enter passphrase for disk … vs Please unlock disk … on text consoles). After you type the passphrase, systemd unlocks the mapper and fstab mounts /mnt/secure-data.

After login, confirm the mount:

findmnt /mnt/secure-data
cat /mnt/secure-data/lab-check.txt

Keyfile automount (no boot prompt)

Keyfiles suit secondary data disks on servers in a locked datacenter. They are not a substitute for protecting the root filesystem and physical access controls.

On workstations with TPM2 or a FIDO2 security key, systemd-cryptenroll for LUKS2 is often a stronger unattended-unlock path than a static file on disk.

Create and register the keyfile

Create a random keyfile, then set root-only ownership with chown and mode 600:

sudo mkdir -p /etc/luks
sudo dd if=/dev/urandom of=/etc/luks/secure-data.key bs=512 count=4 status=none
sudo chown root:root /etc/luks/secure-data.key
sudo chmod 600 /etc/luks/secure-data.key

The keyfile is 2048 bytes of random data on disk—never store your only copy inside the encrypted volume.

Check ownership and mode before you register the key:

sudo ls -l /etc/luks/secure-data.key

Sample output:

-rw------- 1 root root 2048 Jul  5 19:46 /etc/luks/secure-data.key

root:root ownership and mode 600 are required before you add the key to a LUKS slot.

Register the keyfile—luksAddKey prompts for an existing passphrase and prints nothing on success:

sudo cryptsetup luksAddKey /dev/sdc1 /etc/luks/secure-data.key

A second active slot should appear in the header dump:

sudo cryptsetup luksDump /dev/sdc1 | sed -n '/Keyslots:/,/Tokens:/p' | head -20

Sample output:

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	...
  2: luks2
	Key:        512 bits
	Priority:   normal

Two luks2 entries mean both passphrase and keyfile can unlock the volume. Slot numbers need not be consecutive—slot 2 is common when slot 1 was used earlier.

After adding keys:

• Take a fresh header backup before you retire old slots (change LUKS passphrase or key slots).
• Do not keep your only keyfile copy on the encrypted volume it unlocks.
• Keep a recovery passphrase in another LUKS slot.

crypttab and fstab

Point crypttab at the keyfile instead of none:

secure_data UUID=5f452b2f-3b11-4494-890b-d6c3e509c0ef /etc/luks/secure-data.key luks

Keep the same fstab line as the passphrase path.

Keyfile placement:

• Secondary data disk (normal path) — store the key on the root filesystem (for example /etc/luks/secure-data.key); initramfs copy not required.
• Early-boot unlock — add initramfs to crypttab options, set KEYFILE_PATTERN in /etc/cryptsetup-initramfs/conf-hook, run sudo update-initramfs -u, and treat the generated initramfs as sensitive.

Test without a reboot

Close any open mapper, then prove the keyfile unlocks the volume:

sudo umount /mnt/secure-data 2>/dev/null || true
sudo cryptsetup close secure_data 2>/dev/null || true
sudo cryptsetup open --key-file /etc/luks/secure-data.key /dev/sdc1 secure_data
sudo mount /dev/mapper/secure_data /mnt/secure-data
cat /mnt/secure-data/lab-check.txt

Sample output:

luks lab file

Unmount and close again, then exercise the crypttab line the way boot will:

sudo umount /mnt/secure-data
sudo cryptsetup close secure_data
sudo systemctl daemon-reload
sudo systemctl start systemd-cryptsetup@secure_data.service
sudo mount /mnt/secure-data
findmnt /mnt/secure-data

No passphrase prompt should appear—the keyfile in crypttab handles unlock.

Confirm with a reboot

Reboot once. Boot should continue without a LUKS prompt; fstab mounts /mnt/secure-data after unlock:

sudo reboot

After login:

findmnt /mnt/secure-data
cat /mnt/secure-data/lab-check.txt
mount | grep secure_data

Sample output:

TARGET           SOURCE                FSTYPE OPTIONS
/mnt/secure-data /dev/mapper/secure_data ext4   rw,noatime
luks lab file
/dev/mapper/secure_data on /mnt/secure-data type ext4 (rw,noatime)

That triple check—findmnt, file readback, and mount—confirms auto-mount survived a full boot cycle.

crypttab options: nofail, timeouts, and discard

The fourth crypttab field accepts comma-separated flags. These matter most on systemd-based distros and SSD-backed LUKS volumes.

Examples:

secure_data UUID=5f452b2f-3b11-4494-890b-d6c3e509c0ef none luks,nofail,x-systemd.device-timeout=30s
secure_data UUID=5f452b2f-3b11-4494-890b-d6c3e509c0ef /etc/luks/secure-data.key luks,discard

For optional data disks, x-systemd.automount on the fstab line mounts on first access instead of blocking boot:

UUID=9fe05bbb-e530-48ed-a8f7-461febc7329f /mnt/secure-data ext4 defaults,noatime,nofail,x-systemd.automount 0 2

For a disk that must block boot until unlocked, omit nofail so a failed unlock surfaces immediately at the boot prompt.

About noearly:

• Debian crypttab/init-script option for older or non-systemd flows.
• Ignored for initramfs devices; not supported by systemd.
• For a normal secondary data disk, omit initramfs instead of relying on noearly.

When to update initramfs

For a normal secondary data disk that unlocks after the root filesystem is mounted, editing /etc/crypttab is usually enough. Systemd reads /etc/crypttab during boot and creates the matching [email protected].

Run sudo update-initramfs -u when:

• the LUKS device is needed in early boot, such as root, resume, or a device marked with the initramfs option;
• you intentionally want this data disk unlocked in the initramfs stage;
• you changed a keyfile that must be copied into the initramfs;
• you changed cryptsetup initramfs hook settings.

For the plain secondary-data-disk examples in this guide, use the Test without a reboot steps in each path above before you run Confirm with a reboot.

When early-boot unlock or initramfs keyfiles apply, regenerate the initramfs:

sudo update-initramfs -u

Sample output:

update-initramfs: Generating /boot/initrd.img-7.0.0-27-generic

Regenerate only when an item in the list above applies—secondary data disks without the initramfs option do not need this for every crypttab edit.

Troubleshooting

References

• cryptsetup man page — crypttab format
• systemd crypttab(5)
• Debian cryptsetup wiki — initramfs

Summary

1. Collect the LUKS UUID (blkid on the encrypted partition) and the ext4 UUID (blkid on /dev/mapper/name after unlock).
2. Add /etc/crypttab with mapper name, UUID=<luks-uuid>, key path (none for a passphrase prompt or a keyfile for auto-mount), and options (luks, plus nofail or discard when needed—omit initramfs for a normal secondary data disk).
3. Add /etc/fstab with the filesystem UUID on the mount point—not the LUKS UUID.
4. Test without a reboot (systemctl start [email protected] or cryptdisks_start, then mount).
5. Confirm with a reboot—passphrase path shows a boot prompt; keyfile path mounts silently.
6. Run update-initramfs -u only when early-boot unlock or initramfs keyfiles are required.