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/myluksdiskwill 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/crypttabconfiguration 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-lvmIn 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 duringcryptsetup 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:
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
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:
- Unlock
/dev/sdb1via keyfile. - Map it as
/dev/mapper/myluksdisk. - Activate
secure_vgautomatically. - Mount
secure_lvon 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
Fantastic! A clear description of getting a volume encrypted and mounted automatically. I tried using some other google suggested websites, but yours got my volume working in no time flat! Now I can safely transfer my home directory to the encrypted volume.
Peter
Hi,
I tried to follow your instruction on an Ubuntu Server 20.04. It works well but after rebooting it basically seems it decrypts the partition (HDD) but it doesn’t mount it. After booting I have to manually mount via ‘sudo mount’ command. Any idea how to fix it?
I found during the apt upgrade, I found this message:
cryptsetup: WARNING: ‘Private’ is missing some arguments, see crypttab(5)
‘Private’ is the location I am trying to mount. Are there arguments needed to be mounted in Ubuntu 20.04?
Any help would more than welcome. Thanks
Hi Carlos, if you have updated your fstab then it should mount automatically
here
Privateis the mount point or the LVM path?because you can try using UUID if this is the LVM path, sometimes kernel fails to recognise a device by name and we must use ID of the path
Hi, Thanks for you fast replay. ‘Private’ is the mounting point. Are you suggesting I try to repeat the whole steps and change the LVM path (e.g. /dev/sdc1) instead use the UUID (e.g. UUID=0209…) ?
No I assumed that was the LVM path but for mount point this will not help. Can you please share the content of
/etc/crypttaband/etc/fstabfor this encrypted path. The error says cryptsetup is missing some arguments so it is some configuration problem most likely. You can also check in the logs for any more informationFor /etc/crypttab:
#
Private UUID=01b742d6-8d5c-450d-9c3c-5d65d85ce2db9 /root/lukskey
For /etc/fstab:
LABEL=writable / ext4 defaults 0 0
LABEL=system-boot /boot/firmware vfat defaults 0 1
/dev/mapper/Private /Private ext4 defaults 0 0
These look correct (assuming your passphrase is
Private, do you anything else in the logs to further debug this?I solved it. It’s kind of weird, but after decrypting the partition, the file format is “vfat” not “ext4”. I cannot explain why, the partition I encrypted from an Ubuntu Desktop and after decrypting uses non-ext4 format. Anyway it works now. Thanks for your help!
I am glad it worked, and thanks for sharing the solution.
Why 2 keyslots are needed to auto mount 1 partition or am I understanding it wrong?
You created a keyslot, and another to add the keyfile, to automount with no password.
What does the first one do?
Thank you for highlighting this. I have created Key Slot 1 just for demonstration and left it there. You only need one key slot to auto mount the partition which I created for Key Slot 2
You can use
cryptsetup luksOpen --test-passphrase --key-slot 0 /dev/sdb1to verify the passphrase of your keyslotcan this will work on ubuntu live cd ?
can you provide some steps ?
I have not tried on Ubuntu but you can scroll up and check comment from Benjamin who seems to have used this steps on Kubuntu 18.04 and it worked for him.
I have a similar problem: a hard where the ‘/’ partition is encrypted and has to be decrypted at boot.
I created a keyfile, added it as a key into slot 0, and the key file is in ‘/boot’, the only partition that is *not* encrypted. However, when I reference the file in ‘/etc/crypttab’ as ‘/boot/keyfile’ it doesn’t find it. Even using the UUID of the ‘/boot’ partition didn’t work. Does anybody know how I can fix that?
I had written another article to migrate my root file system to encrypted device and then I used TANG server to provide the key for automatic boot. Please check them out and if you still face issues then let me know with more details about your environment such as list of LV, VG, PV and the partition encrypted. I can try to reproduce the behaviour in my environment and then I may be able to help you further.
Great Tutorial! Worked pefectly on Kubuntu 18.04! Cheers and thanks!
This is very close to what I am looking for, however, my goal is to defend against ransomware by backing up normally unmounted LUKS partitions on my file server to a remove server. I want to mount those partitions via script, run backups with duplicity, then dismount the partitions. The file server boots remotely without a passphrase and because I can recreate a Linux OS at will, I am concerned only for my data partitions. This is a network that I typically manage remotely for long periods of time before I am local again, so theft has to be considered.
Everything about duplicity backup and restore works with gpg keys to encrypt and decrypt using a “passless” ssh connection to my remote server, and all keys are kept in a remote location I can access if my file server and workstation have been replaced. This has all been confirmed in DR testing, but I am stuck trying to devise a scheme that allows me to mount and dismount a LUKS partition programmatically before and after each backup. Right now a calendar reminder has me ssh to file server, manually mount LUKS, cron runs duplicity, and then I manually dismount LUKS.
** caveats **
I recognize two flaws in my infrastructure. First is that my gpg key is stored as an environment variable so data could be restored by a reasonably sophisticated bad actor. My mitigation is that the crown jewels are symmetrically encrypted, and reside on an unmounted LUKS. Restoring them won’t be much help to the bad actor. The second flaw is that malware can find my passless ssh connection, connect, and encrypt my remote duplicity volumes. This is somewhat mitigated because the device is a file server that no one actually uses as a workstation, so email isn’t likely a problem. I am perfectly happy to ssh from my workstation to my file server and mount & dismount LUKS manually providing the passphrase on the occasions I need them.
I feel like using (cryptsetup) –key-file or environment variables within the script simply create convenience by exposing my LUKS passphrase to malware. I am aware that “if malware can find your files, you have have bigger problems”.
Does this mean that no scheme will work?
TIA
I use cryptsetup to securely store all the private and public keys for my network. And these keys are deployed on target nodes at a certain location wherein using a script these keys are first collected by mounting the encrypted partition on a loopback device, then deployed on target hosts using passphrase and lastly the encrypted partitions are then unmounted from the loop device. This is completely possible and safe. The cryptsetup passphrase are encrypted and is not in readable format. All you can see is some numbers so there is nothing to be worried here to be read by a hacker. More over once we unmount the partition after our job is done, no one can access these files unless the partition is mounted again.
Thank you.
The concept I don’t yet understand is “… mounting the encrypted partition on a loopback device”. I’ll study it.
I have sent you brief list of steps via mail to implement the same. Hope that helps.
Regards
Deepak
I am also interested in knowing this. Can you provide that to my email as well? Thanks
Can you describe how to do the same but using TPM for storing the key?
Thank you for sharing your suggestion, I will definitely try to write an article on this topic
I am using this to mount encrypted volume on my home server using a usb key. Generally the usb key is not plugged in. So on reboots I enter the passphrase. However when I am traveling and in a urgency the machine needs to be rebooted. My non techie family plugs in the usb and reboots the server. Its super convenient as they cant use dvorak layout on the keyboard
Is there any article explain how to do such usb key to auto provide the passphrase when prompted for LUKS
I had written another article to use NBDE and tang server to get the passphrase automatically for LUKS encrypted partition but if your question is for runtime requirement i.e. if we do luksOpen then the tool should automatically get the passphrase then that is something in my todo list. We can use expect script and do some dirty WA but I am also checking for similar solution. This is something already in my to-do list.
Just wondering why one would go to all the trouble of encrypting their disk data and then make the boot process automatically recover the pass phrase rather than prompting the user for it? Am I overlooking something?
We never know what we get as a requirement. Honestly even I wonder this question but there always should be a solution handy (if/when required) 🙂
It can be used as a solution to unlock a second encrypted hard drive or partition, by storing its keyfile onto the root partition that will be unlocked with password. Otherwise you would have to enter the passphrase for every encrypted drive/partition which is tedious…
Would there be a way to have BOTH password and keyfile decryption ? for example, to store the keyfile on a USB key which automatically unlocks the drive if present, or asks for LUKS password otherwise ? Maybe if the usb is mounted first, and both a passphrase and keyfile are present in the device keyslots ? I suppose that the crypttab must have the “luks”
I think this is something even I will have to try first before I can comment.
This is exactly why you would use a keyfile for decryption. Having the keys remotely for security. Using a usb key with the keyfile is pretty cool.
To answer your question, encrypting a USB Drive is in the case of it being stolen by a third party and loaded onto another machine. And having it loaded onto the original owner’s machine may become a tedious task when inserting and mounting it.
This is actually helpful, thanks.