How to auto mount and unlock LUKS Encrypted Partitions at Boot using crypttab and fstab

User avatar placeholder
Written by Deepak Prasad

May 30, 2025

In my last article I had shared the steps to encrypt a partition using LUKS. Now in this article I will continue with LUKS disk encryption and will share the steps to auto mount LUKS device with and without encrypt key during boot up of the Linux node. If you have not enabled auto mount using secret key then you can use LUKS passphrase to manually mount the encrypted partition.

I will be using Ubuntu 24.10 for the demo, so the command may vary based on your distribution. For example in distros with SELinux, it is better to start with Permissive (setenforce 0) instead of enforcing.

 

Lab Environment

How to identify LUKS Encrypted Device

Before we start, you must know your LUKS encrypted device as this information will be required to perform the auto mount operation.

List down your available partitions along with the filesystem type using lsblk -f:

sda
├─sda1
├─sda2 ext4 1.0 0927eeeb-0481-4243-b654-b49c926d1079 1.6G 9% /boot
└─sda3 LVM2_member LVM2 001 FUwEIq-f1lP-AYKn-AtcU-vl3F-VoJ4-JnWLdJ
└─ubuntu--vg-ubuntu--lv ext4 1.0 55dc54e5-35b9-4e36-b0dd-f9aac1d96bae 9.3G 53% /
sdb
└─sdb1 crypto_LUKS 2 9cc957b0-fd12-4e73-affb-a96f2138d6e2

As you can see in my case /dev/sdb1 is the LUKS device.

We can also use cryptsetup luksDump to verify it's really LUKS. Let's try this on /dev/sda

golinuxcloud@server1:~$ sudo cryptsetup luksDump /dev/sda1
Device /dev/sda1 is not a valid LUKS device.

As you can see, we get an error that /dev/sda1 is not a LUKS device.

Let's try the same on /dev/sdb1:

golinuxcloud@server1:~$ sudo cryptsetup luksDump /dev/sdb1
LUKS header information
Version: 2
Epoch: 6
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 9cc957b0-fd12-4e73-affb-a96f2138d6e2
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
...

Once you have your LUKS device, proceed with next steps.

 

Get mapper name (Logical Name Assigned to Your LUKS Device)

If you are already familiar with the logical name you had assigned to your LUKS device during unlock (i.e. the name you provided while using cryptsetup open), you can skip this section.

However, if you're unsure or don’t remember the mapper name, follow these steps to retrieve or define it:

Check if LUKS device is already unlocked

ls -l /dev/mapper/

You may see available mappers like:

golinuxcloud@server1:~$ ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 May 30 19:49 control
lrwxrwxrwx 1 root root 7 May 30 19:49 ubuntu--vg-ubuntu--lv -> ../dm-0

Example: If you had run:

sudo cryptsetup open /dev/sdb1 secret

then secret became your mapper name.

If device is still locked — no mapper exists yet

If your LUKS device is not unlocked yet, you won’t see any corresponding mapper entry. In that case, you need to manually open the device and assign a new mapper name:

sudo cryptsetup open /dev/sdb1 myluksdisk
  • myluksdisk → this is the logical name you assign now.
  • After this, /dev/mapper/myluksdisk will be created.

You can use any name here based on your preference — this same name will later be used in /etc/crypttab as the mapper name.

Why is mapper name important?

  • Linux uses this name to refer to the unlocked LUKS device.
  • This name must match exactly in your /etc/crypttab configuration for auto-unlocking during boot.

Check filesystem inside (optional but strongly recommended)

Execute the following command:

golinuxcloud@server1:~$ sudo file -s /dev/mapper/myluksdisk
/dev/mapper/myluksdisk: symbolic link to ../dm-1

golinuxcloud@server1:~$ sudo file -sL /dev/mapper/myluksdisk
/dev/mapper/myluksdisk: LVM2 PV (Linux Logical Volume Manager), UUID: HpKeJx-tbRI-WkXA-mImh-rBWS-zf8b-QyP3bf, size: 5350883328

As you can see, in my case a LVM based file system exists in my mapper already so we are good. Next we can try to manually mount this:

# Activate LVM
sudo vgchange -ay

# List logical volumes
sudo lvs

# Then mount logical volume (assuming you have secure_lv already created)
sudo mount /dev/secure_vg/secure_lv /mnt/secure-lvm

In case there was no file system, then first we need to create a filesystem before we attempt to mount the partition:

# Create filesystem directly (no LVM)
sudo mkfs.ext4 /dev/mapper/<mapper_name>

# Or initialize new LVM (if you want LVM inside LUKS)
sudo pvcreate /dev/mapper/<mapper_name>
sudo vgcreate <vg_name> /dev/mapper/<mapper_name>
sudo lvcreate -L <size> -n <lv_name> <vg_name>
sudo mkfs.ext4 /dev/<vg_name>/<lv_name>

Ok, so at this stage you should have your LUKS encrypted partition information and the LUKS mapper name. We will need both these things in upcoming steps.

 

Auto mount encrypted partition using fstab without key (prompts for LUKS passphrase)

One of the options to auto mount the encrypted partition every time node boots up you can use fstab to auto mount LUKS device during boot stage using LUKS passphrase.

 

Update /etc/crypttab

First, get UUID of your encrypted partition:

golinuxcloud@server1:~$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="9cc957b0-fd12-4e73-affb-a96f2138d6e2" TYPE="crypto_LUKS" PARTUUID="daf1796a-01"

Now edit /etc/crypttab using sudo privilege and add following entry based on your UUID value:

myluksdisk UUID=9cc957b0-fd12-4e73-affb-a96f2138d6e2 none luks
  • myluksdisk → is the mapper name you originally assigned during cryptsetup open.
  • UUID → from blkid output.
  • none → tells system to ask passphrase at boot.
  • luks → to identify this as LUKS device.

 

Update /etc/fstab

Add below entry to your /etc/fstab

/dev/secure_vg/secure_lv /mnt/secure-lvm ext4 defaults 0 2

 This mounts your logical volume automatically after it's available.

 

Update initramfs

This is a mandatory step after crypttab change

sudo update-initramfs -u

If you are using Red Hat based distro then you will need to run dracut -f.

 

Next reboot the node and check if the reboot halts waiting for LUKS passphrase to mount the encrypted device. As you can see below, the prompt asking to mount the LUKS partition:

How to auto mount and unlock LUKS Encrypted Partitions at Boot using crypttab and fstab

 

Auto mount LUKS device using fstab with key (No prompt for LUKS passphrase)

Verify existing key slots

LUKS Disk Encryption supports up to 8 key slots. Each slot can store a different key (password or keyfile) to unlock the same encrypted data. We can use one of these keys (for example, a keyfile stored securely) to configure auto-mounting of LUKS devices

But do you wonder, why we will need so many slots?

This can actually help for scenarios like following:

Reason Why it helps
🔑 Multiple users Admin and user can have separate passphrases
🔄 Key rotation You can add a new key, test it, then remove old key — without re-encrypting the entire disk
🔐 Keyfiles for automation Use passphrase for manual unlock + keyfile for auto-unlock at boot
🎯 Backup key Keep an emergency recovery passphrase
🏢 Enterprise setups One slot for admin, one for automation, one for recovery, etc.

Let's dump the existing set of key slots using luksDump:

golinuxcloud@server1:~$ sudo cryptsetup luksDump /dev/sdb1
LUKS header information
Version: 2
Epoch: 5
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 9cc957b0-fd12-4e73-affb-a96f2138d6e2
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 4096 [bytes]

Keyslots:
0: luks2
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 256 bits
PBKDF: argon2id
Time cost: 4
Memory: 761034
Threads: 2
Salt: db 23 b5 e3 ab 47 e3 5d 1d 70 8c 13 20 2c 16 38
46 65 3e 5c 05 92 5d 55 5e ba fa 4d bb e1 da f4
AF stripes: 4000
AF hash: sha512
Area offset:32768 [bytes]
Area length:131072 [bytes]
Digest ID: 0

Tokens:
Digests:
0: pbkdf2
Hash: sha512
Iterations: 193607
Salt: 80 b9 5e 4b f8 cc f0 fb 3a 14 7b a4 90 be 30 d5
cd 75 e6 50 49 41 71 b2 89 f9 fe 2c 95 89 2d 2c
Digest: 84 1e 62 02 c5 64 26 79 0f 0e 4e 4f f5 c5 b5 94
a2 69 d3 49 03 1c 1a 19 db 86 cd a2 f8 40 05 6d
9c 05 70 2e 72 44 87 9c 71 bb 43 f2 3c b8 fe a0
0f 1d d9 e3 e9 35 58 d8 b7 cd 73 f8 5a a5 5e 7d

As you can see, currently only one active keyslot: Keyslot 0. This slot holds the encrypted copy of the master key — protected by the passphrase we entered during luksFormat.

When we run sudo cryptsetup open /dev/sdb1 <mapper_name> then we are using the passphrase stored in Keyslot 0 to decrypt the master key and unlock the disk.

Next we need to create a keyfile which will be used to auto mount the partition during reboot. As if you don't follow this then the boot up stage will halt at password prompt while trying to mount the encrypted disk.

 

Create keyfile to avoid interactive passphrase prompt

sudo dd if=/dev/urandom of=/root/keyfile.bin bs=512 count=4
sudo chmod 600 /root/keyfile.bin

Now add this key to LUKS:

sudo cryptsetup luksAddKey /dev/sdb1 /root/keyfile.bin

This will just add the keyfile into a new slot.

Let's re-verify the key dump:

golinuxcloud@server1:~$ sudo cryptsetup luksDump /dev/sdb1
LUKS header information
Version: 2
Epoch: 6
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 9cc957b0-fd12-4e73-affb-a96f2138d6e2
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 4096 [bytes]

Keyslots:
0: luks2
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 256 bits
PBKDF: argon2id
Time cost: 4
Memory: 761034
Threads: 2
Salt: db 23 b5 e3 ab 47 e3 5d 1d 70 8c 13 20 2c 16 38
46 65 3e 5c 05 92 5d 55 5e ba fa 4d bb e1 da f4
AF stripes: 4000
AF hash: sha512
Area offset:32768 [bytes]
Area length:131072 [bytes]
Digest ID: 0
1: luks2
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 256 bits
PBKDF: argon2id
Time cost: 4
Memory: 1048576
Threads: 2
Salt: 45 06 0a 8b fd ec 3a 03 60 71 9d 62 c2 ef 8b 8f
b3 75 76 dd 4a 38 28 40 5d 93 06 b4 d8 68 d4 b6
AF stripes: 4000
AF hash: sha256
Area offset:163840 [bytes]
Area length:131072 [bytes]
Digest ID: 0
NOTE:
If you want to delete the key slot then you can use sudo cryptsetup luksRemoveKey /dev/sdb1 which will remove that keyslot. If you know the exact keyslot to be removed then you can also use sudo cryptsetup luksKillSlot /dev/sdb1 1 where 1 is the slot to be deleted.

 

Configure /etc/crypttab for automatic LUKS unlock

First, get UUID of your encrypted partition:

golinuxcloud@server1:~$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="9cc957b0-fd12-4e73-affb-a96f2138d6e2" TYPE="crypto_LUKS" PARTUUID="daf1796a-01"

Now edit /etc/crypttab using sudo privilege and add following entry based on your UUID value:

myluksdisk UUID=9cc957b0-fd12-4e73-affb-a96f2138d6e2 /root/keyfile.bin luks
  • myluksdisk → this is the LUKS mapper name (/dev/mapper/myluksdisk)
  • Keyfile path is used to unlock automatically.

 

Configure /etc/fstab for LVM mount

Earlier we had created a directory /mnt/secure-lvm to mount our secure LVM /dev/secure_vg/secure_lv. So, now we will update our /etc/fstab to automatically mount this partition:

 

Update initramfs

Since we're modifying boot-time decryption:

golinuxcloud@server1:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.11.0-19-generic

Don't skip this — or else boot may fail because your crypttab changes won’t be loaded into initrd. If you are using Red Hat based distro then you will need to run dracut -f.

 

Test the full boot automation

Reboot your VM. System should automatically:

  1. Unlock /dev/sdb1 via keyfile.
  2. Map it as /dev/mapper/myluksdisk.
  3. Activate secure_vg automatically.
  4. Mount secure_lv on your target mount point.

As in my case, the partition is added automatically:

golinuxcloud@server1:~$ mount | grep secure
/dev/mapper/secure_vg-secure_lv on /mnt/secure-lvm type ext4 (rw,relatime)

  

 

In coming articles I will share the steps to extend or shrink (resize) LUKS encrypted partition in Linux.

 

Lastly I hope the steps from the article to auto mount LUKS device using fstab to boot with LUKS passphrase and with LUKS key on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

 

References:
An overview on LUKS encryption

Views: 7,220
Image placeholder

Deepak Prasad is the founder of GoLinuxCloud, bringing over a decade of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, Networking, and Security. His extensive experience spans development, DevOps, networking, and security, ensuring robust and efficient solutions for diverse projects. Certifications and Credentials:

  • Certified Kubernetes Application Developer (CKAD)
  • Go Developer Certification
  • Linux Foundation Certified System Administrator (LFCS)
  • Certified Ethical Hacker (CEH)
  • Python Institute PCAP (Certified Associate in Python Programming)
You can connect with him on his LinkedIn profile and join his Facebook and LinkedIn page.

Can't find what you're searching for? Let us assist you.

Enter your query below, and we'll provide instant results tailored to your needs.

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can send mail to admin@golinuxcloud.com

Thank You for your support!!

46 thoughts on “How to auto mount and unlock LUKS Encrypted Partitions at Boot using crypttab and fstab”

  1. Hæ Mate, thanks for the tutorial!

    Even though it’s a few years old now it’s still pretty up to date and I’d like to add some comments to prevent others from making a few mistakes:

    In crypttab, you have to give the option luks to work properly. So the line would have to look like this:

    secret /dev/sdb1 /root/lukskey luks

    The key is unnecessary weak. It’s not totally insecure, but there’s just no downside of choosing a 4096bit Key and generate it with “openssl genrsa -out /root/lukskey 4096”

    Make sure the key is not world readable! Otherwise every other program run in userspace on the system can steal it.

    This whole keyfile only makes sense, if the key itself is stored on a device which is strongly encrypted! Otherwise, if someone steals your computer he could just look for the key on the unencrypted drive and open the encrypted drive with it.

    Don’t misunderstand me, I don’t want to criticize your hard work here! Thanks again for your effort!

    Reply
  2. No. Don’t use on Kubuntu/Ubuntu 24.04, it will forward you to busybox and you will need to recover system with the manualy opening your luks root device.

    Here is missing all about the initrams update which is required.

    Reply
  3. Hi there. I want to install case “Auto mount encrypted partition using fstab without key (prompts for LUKS passphrase)”
    However, my os crashes a bit after entering a password during boot. As i understand fstab doesn’t know when it will obtain unencrypted mapped partition.

    x-systemd.device-timeout for my encrypted ext4 doesn’t help much. What else might went wrong on ubuntu 22.04?

    Reply
  4. Just in case: I had the problem that the devices from time to time didn’t automount correctly while booting. Problem was that sometimes it happened, that my system hdd was mounted as sdb and not sda and one of my external hdds were not mounted at all. My solution to this is to use the UUID in fstab and crypttab.
    If you encounter the problem: mount the encrypted devices manually and run:

    sudo blkid

    In my case:

    /dev/sda1: UUID="ee4ef57c-e4aa-43c1-a1ec-329b3239468e" TYPE="ext4" PARTUUID="6fd851d8-01"
    /dev/loop0: TYPE="squashfs"
    /dev/loop1: TYPE="squashfs"
    /dev/loop2: TYPE="squashfs"
    /dev/loop3: TYPE="squashfs"
    /dev/loop4: TYPE="squashfs"
    /dev/loop5: TYPE="squashfs"
    /dev/loop6: TYPE="squashfs"
    /dev/loop7: TYPE="squashfs"
    /dev/sdb1: UUID="ab44bd92-c9f1-49dd-a8f7-8e216da7ed53" TYPE="crypto_LUKS" PARTUUID="a337a472-1070-6540-b5ab-4144d19c4e32"
    /dev/sdc1: UUID="93a5d5b0-458f-4ec2-b5b4-399d8fee42eb" TYPE="crypto_LUKS" PARTUUID="2a5cc607-d9b3-4349-8902-033b8ab90e17"
    /dev/mapper/secret: UUID="6446f0d9-bc2f-4459-ae9f-aec7d705dd39" TYPE="ext4"
    /dev/mapper/backup: UUID="f44204f0-7634-4161-a9eb-49bf236da625" TYPE="ext4"

    There you see the UUIDs of the decrypted partitions (“TYPE=”crypto_LUKS”)and the UUIDs of the filesystems (TYPE=”ext4″)
    Put the TYPE="ext4" UUIDs in /etc/fstab and the Type="crypto_LUKS" in /etc/crypttab
    In my case fstab looks like this:

    UUID=ee4ef57c-e4aa-43c1-a1ec-329b3239468e /               ext4    errors=remount-ro 0       1
    /swapfile                                 none            swap    sw              0       0
    
    UUID=6446f0d9-bc2f-4459-ae9f-aec7d705dd39      /media/Benjis_ZS                 ext4    nofail,users,defaults        0 2
    UUID=f44204f0-7634-4161-a9eb-49bf236da625      /media/backup                    ext4    nofail,users,defaults        0 2

    and crypttab:

    secret UUID=93a5d5b0-458f-4ec2-b5b4-399d8fee42eb /root/lukskey
    backup UUID=ab44bd92-c9f1-49dd-a8f7-8e216da7ed53 /root/lukskey_backup

    This solved my issue. Hope that this helps someone out there….See you space cowboys…

    Reply
  5. and i forgot.. for anyone, who does not wanne use the cmd line, use “gnome-disks” for encrypting your drive, way easier for users.

    Reply
  6. oh.. ahm.. how to say this politly.. you do not store password in cmd lines, use this:

    cat password.file | cryptsetup …

    because it apears in “ps auxf ” and can be seen by any process,

    and i hope you encrypted the disk this is run on, or your security model just broke.
    Backups to unencrypted disks are done by creating a luks container on the drive, open it, format it, and copy the data into the container, close it, which makes it secure 😉

    Reply
  7. Hello there. Nice tutorial, thanks

    I would like Linux completely forget encrypted disk connected during the boot (not asking any password nor picking the password somewhere) as with my scritp (see below) I can do it when I want (i.e. at certain backup time when my NAS gets connected). Is it any way I can have Linux not paying attention nor request password for an encrypted device at the boot ? That would be magic !

    Here is my scripts:

    crontab -e:
    55 10 * * * /sbin/cryptsetup luksOpen /dev/disk/by-uuid/XXXXXXX secret -d /external-drive-mounted-where-the-key-is
    56 10 * * * mount /dev/mapper/secret /home/mydecrypteddisk
    
    00 12 * * * umount /home/mydecrypteddisk
    01 12 * * * /sbin/cryptsetup luksClose /dev/mapper/secret
    Reply
      • It is a good solution but I want encryption of my external hdd on client side be active always with the exception of the time frame while the nas performs its backup (to the unencrypted hdd on the client).
        I don’t believe, also, Synology nas can act the way you described the server.
        It looks too complicated. Need to investigate if I can load encryption modules on the fly and not at the beginning of boot process (simply adding few commands into my script)
        Thanks

        Reply
        • Please do share your observations, as I remember someone else had similar requirements for external disk. Unfortunately I have not been able to test this myself, will add it to my todo lists and if I can test this sometime then will create a new article.

          Reply

Leave a Comment