MiniGuide: Auto unlock LUKS volumes on boot. Works with MergerFS+SnapRaid too.

1st Official Post

    Hi guys.


    First, thanks a lot for OMV.

    I was following this guide michaelxander.com/diy-nas till I hit "After every reboot, all encrypted drives need to be unlocked through the Web UI".


    That did not seem right, if we dont trust our OS to keep LUKS key, why we trust the whole setup? Encrypting root partition is not part of this mini guide, it's a must, but will be next step. This only makes all encrypted data drives auto-unlocked, mounted and in a MergerFS pool on boot.


    - these steps do not mess with /etc/fstab :)

    - sda, sdb and sdc are data drives (data and parity). Its not where OS is installed (my OS drive is mmcblk0)

    - wdkey - can be any name, as well as /etc/luks-keys (you may use /root/keyfile for example)

    - assuming clean install and drives configured exactly as in michaelxander's guide (stop after doing 4.5. Create MergerFS pool).


    1. generate keyfile

    dd if=/dev/urandom of=/etc/luks-keys/wdkey bs=1024 count=4

    chmod 0400 /etc/luks-keys/wdkey


    2. add key to a LUKS slot

    cryptsetup -v luksAddKey /dev/sda /etc/luks-keys/wdkey

    cryptsetup -v luksAddKey /dev/sdb /etc/luks-keys/wdkey

    cryptsetup -v luksAddKey /dev/sdc /etc/luks-keys/wdkey

    Enter any existing passphrase:

    Key slot 0 unlocked.

    Key slot 1 created.

    Command successful.


    3. create /etc/crypttab

    /etc/crypttab is read before fstab, so that dm-crypt containers can be unlocked before the file system inside is mounted.


    The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that device is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/dm_name so as not to overwrite the encrypted data.


    Use blkid to get uuid (Use uuid of /dev/sdx ones, not /dev/mapper/sdx-crypt). No new line at the end.

    The fist item in each line, target, "sda-crypt", must be equal to output of blkid : "/dev/mapper/sda-crypt"


    vi /etc/crypttab (Content should look like this)

    sda-crypt UUID=2505567a-9e27-4efe-a4d5-15ad146c258b /etc/luks-keys/wdkey luks

    sdb-crypt UUID=12345678-9abc-def012345-6789abcdef01 /etc/luks-keys/wdkey luks

    sdc-crypt UUID=c67c557c-21b9-11eb-82d8-170fd1bb7315 /etc/luks-keys/wdkey luks


    chmod 400 /etc/crypttab


    4. backup luks headers

    Encryption > Select drive > Recovery > Backup

    Storage > Encryption > click the device and the backup header button becomes active (thanks Pluto2010)


    5. Thats it, reboot

    NASA : It is not as bad as it looks, it is much worse.

    Edited 10 times, last by johnlocke ().

    Thanks 2

  • KM0201

    Approved the thread.

  • KM0201

    Approved the thread.

    Thanks for the tutorial. However, I am stuck at the last step: Encryption > Select drive > Recovery > Backup. I don't see the Recovery option. Is it removed in the current version?

    • Official Post
    Quote from DrRobot

    Is it removed in the current version?

    Yep. Due to changes in the omv 6.x web interface framework, some features like Backup and unlock with a key file had to be removed.

    omv 7.7.9-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0.2 | kvm 7.1.8 | compose 7.6.9 | cterm 7.8.7 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.2


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    ryecoaaron


    What is supposed to be the recommended solution for the missing "auto-unlock" feature and the above workarounds ? Do you know, if there is something in development, have visited the GitHub for the plugin, but nothing found here. I really miss this feature coming from TrueNAS (and currently looking for a replacement, playing around last few days with OMV6).


    Thanks for any (even if short) feedback, brgds Fitz

    • Official Post
    Quote from FitzC

    What is supposed to be the recommended solution for the missing "auto-unlock" feature and the above workarounds ?

    Something from the command line like this thread recommends or someone other than me can write code to add the stuff.

    Quote from FitzC

    Do you know, if there is something in development, have visited the GitHub for the plugin, but nothing found here.

    I have no plans to add any other features to the luks plugin. I don't use luks at home, think luks is overkill at home, and really don't like working on the plugin. I work on the plugin just enough to port it to new versions of OMV.

    omv 7.7.9-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0.2 | kvm 7.1.8 | compose 7.6.9 | cterm 7.8.7 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.2


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Thanks 1

    Thanks for above statement, so it will be no encryption (for me) at the time being, but continuing to get familiar with OMV.


    Brdgs Fitz

    Hi

    Followed this in 2025 and it works perfectly!


    Been trying to do it with other guides that use fstab and it’s possible but doing it this way, after you setup the crypttab file you can then mount the file system etc with the omv wev gui.


    Quote

    4. backup luks headers

    Encryption > Select drive > Recovery > Backup

    for this, you go to

    Storage > Encryption > click the device and the backup header button becomes active

    According to the steps in post #1, you encrypt the drives with a key, that resides on the server itself?

    That's like locking your apartment and leaving the key under the doormat. Everyone can unlock your door.

    • Official Post
    Quote from bermuda

    That's like locking your apartment and leaving the key under the doormat

    The next step is to lock up the doormat.


    Quote from johnlocke

    if we dont trust our OS to keep LUKS key, why we trust the whole setup? Encrypting root partition is not part of this mini guide, it's a must, but will be next step

    The initial post is from 2020. I don't see any next step.

    I just wanted to clarify, that this is more than just an automated decryption of luks encrypted drives on boot. It basically negates the whole idea of encryption, if anyone has access to the key. Since the last post #7 was very enthusiastic about "this guide" to be still working.

    In fact I have written about this topic already. I use an initramfs which starts an ssh-server and waits for the admin to unlock the encrypted drives via passphrase. For my own purposes I also created a service that sends messages using XMPP whenever the server needs the passphrase or is being rebooted. There are no keys and no one can get the data without the passphrase.


    EDIT: TPM is not secure. It just covers some cases to make it more convenient. As long as someone is in possession of the server, they will have access.

    Edited once, last by bermuda ().

    I’m using encryption for when a disk fails and I have to return rather than the physical device being stolen.


    The key file is not stored on the data drive so perfect for returning a drive and reducing risk of the data being accessed.


    Would have saved me £300 as I didn’t want to return an unencrypted drive last time.

    Quote from bermuda

    In fact I have written about this topic already.

    I read your related post.

    However, in the focus of this thread is the automated unlocking, not the remote unlocking. In these terms, your ssh solution does not provide a solution. It however solves the issue having keys stored on the host.

    Thanks. I was merely pointing out the flaw in having the keys stored on the host itself, which defeats the aspect of achieving higher data security.

    Quote from eightbit

    That's not true, the LUKS key is not publicly available.

    Then what is the point of encrypting a drive and leaving the key on the same host other than adding an extra layer of computing? False security is no security at all.

    Quote from bermuda

    Then what is the point of encrypting a drive and leaving the key on the same host other than adding an extra layer of computing? False security is no security at all.


    You said, leaving the keys on the host system is like putting them under the doormat and everyone can unlock the drive. That's simply not true. There is a layer of security: An attacker either needs physical access to the drive or he needs to compromise the host system to get access.

    If your are talking about security, you should be precise.

    Everywhere you encounter tutorials and howtos for luks encryption people will warn you of the consequences when using keys for automated unlocking. It's a important flaw in the whole concept of security. People should simply be aware of that.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login