Is there a script to unlock several LUKS drives at once and restart docker+mergerfs?

  • I have several luks encrypted drives that I'm not interested in autodecrypting during boot. I'm fine with having to ssh in and run a script that asks for my passphrase once in order to unlock them all (plus also restart docker and mergerfs pool) whenever the machine needs to be restarted for whatever reason, is there a popular script/way to do this? Even if it's not quite what I need I could modify it. Searched the forum a little bit and didn't find anything quite like that. I found this https://github.com/TheFax/Auto…ster/automount_cryptodisk which isn't exactly what I need but I could modify it to fit me if there's nothing better out there. Just don't want to have to bang my head against the wall debugging a script trying to reinvent the wheel.

  • So I just got chatgpt to do the groundwork for the script and tweaked it afterwards. It works pretty well, had to add mount -a because otherwise omv was erratic in automounting them after decrypting... it left some unmounted while it did mount others but after I added mount -a it seems to be mounting them as expected. Anyways, is there a way to make sure it picks up and mount the drives right after decrypting in an omv "idiomatic" way? Also wanted to stop docker before mounting but had issue starting it afterwards so any suggestion would be appreciated. Below is the script.



  • Got one working that is very consistent. Still open to alternatives but this accomplishes the task I set out to do.


  • This script does only mount my first LUKS drive SDF.

    There ist a Raid5 with a LUKS MD0. This is not decrypted. What is wrong?


    sda linux_raid 1.2 raid5 ........

    └─md0 crypto_LUK 2

    sdb linux_raid 1.2 raid5 ........

    └─md0 crypto_LUK 2

    sdc linux_raid 1.2 raid5 ........

    └─md0 crypto_LUK 2

    sdd linux_raid 1.2 raid5 ........

    └─md0 crypto_LUK 2


    sdf crypto_LUK 2 SSD ......

  • chico11mbit you'll have to modify the script for raid drives. I have none with omv but chatgpt suggested this modification. You can try it or play with it and see how it goes and let us know.

  • Hello everyone,

    just wanted to share my own experience about encryption on OMV. Debian has had an native way to do this, which is also pretty easy to implement and it does not require any scripts or restarting of services. For everyone who is interested to implement this I would advise to look into the packages dropbear-initramfs and cryptsetup-initramfs. There are several descriptions already available on the internet in connection with debian and luks.


    Once installed there is very little to setup to make it work.


    • Basically one has to add/or edit their crypttab file under /etc/crypttab and define the mapper / source / key and options for the luks encrypted devices, example (option initramfs is needed if it is not the root-device but some other drive, keygroup1 and keyscript is used for devices with the same passphrase which is cached and reused, so you only have to type it once):
    Code
    # <target name> <source device>                              <key file>   <options>
    crypt-data-1    UUID=72a93932-28e3-442b-9b1b-2afe6ed75796    keygroup1    luks,keyscript=decrypt_keyctl,initramfs
    crypt-data-4    UUID=8322791f-ff5b-4300-8f3e-2718ba35b5da    keygroup1    luks,keyscript=decrypt_keyctl,initramfs
    crypt-data-2    UUID=01a86874-f8e7-4ace-bfd3-0da677560bbc    keygroup1    luks,keyscript=decrypt_keyctl,initramfs
    crypt-data-3    UUID=73db3a2a-5d1e-4630-a961-2ec931ab21e0    keygroup1    luks,keyscript=decrypt_keyctl,initramfs
    crypt-docker    UUID=d4d9d343-56b0-43eb-9d42-136e7eff772c    keygroup1    luks,keyscript=decrypt_keyctl,initramfs
    • Secondly, transfer that into /etc/initramfs-tools/conf.d/cryptroot in the appropriate format, example:
    Code
    # <target name>    ,<source device>                                 ,<key file>   ,<options>
    target=crypt-data-1,source=UUID=72a93932-28e3-442b-9b1b-2afe6ed75796,key=keygroup1,luks,keyscript=decrypt_keyctl
    target=crypt-data-4,source=UUID=8322791f-ff5b-4300-8f3e-2718ba35b5da,key=keygroup1,luks,keyscript=decrypt_keyctl
    target=crypt-data-2,source=UUID=01a86874-f8e7-4ace-bfd3-0da677560bbc,key=keygroup1,luks,keyscript=decrypt_keyctl
    target=crypt-data-3,source=UUID=73db3a2a-5d1e-4630-a961-2ec931ab21e0,key=keygroup1,luks,keyscript=decrypt_keyctl
    target=crypt-docker,source=UUID=d4d9d343-56b0-43eb-9d42-136e7eff772c,key=keygroup1,luks,keyscript=decrypt_keyctl
    • Setup dropbear.conf in /etc/dropbear/initramfs/dropbear.conf, also add your client pub-keys to authorized_keys
    • Setup initramfs.conf in /etc/initramfs-tools/initramfs.conf (using a DHCP with only one network-device doesn't need any config at all, otherwise you will have to at least define the device, if more than one is present)
    • Update/recreate your initramfs and you are done


    Basically with every boot a dropbear-sshd session is started, waiting for the admin to connect to it and to execute cryptroot-unlock thus entering the luks-passphrase and decrypting all previously defined luks-devices. After that the system is booted as usual. This is a very convenient way as it is:

    • native and clean (works with upgrades)
    • works also with mdadm arrays, lvm's and any other native disk-setups which are supported in initramfs
    • does not interfere with physical input via keyboard/display on the host (it's still available)

    and only needs the admin to ssh into the OMV host (or via attached a keyboard/display) to put in the passphrase before anything can happen.

    Edited once, last by bermuda: Further info/explanation ().

  • The reason for encryption is not personal convenience, but security.

    So things may be a little bit inconvenient for the sake of higher data security in my opinion. But there is always room for improvement thou.

    You are free to chose or develop a **more** convenient approach, if it suits your needs better. Best part of an open community :)

  • You brought convenience as an negative aspect of achieving higher data security. Those two aspects are exclusively opposite to each other. If security is not high valued but convenience, you might be better of not encrypting the drives at all.


    Server are usually used 24/7 and run uninterrupted for many weeks. I don't see that much inconvenience in that. All you need is a shell to ssh in and put in the passphrase once in a while.

  • You brought convenience as an negative aspect of achieving higher data security.

    No, I did not. That's your interpretation. I just mentioned two facts.


    Those two aspects are exclusively opposite to each other.

    In this absolute statement not true. This is not as black and white as you seem to think.

    In the opppsite, the most conviniet security features are the most successful as they really are adapted.



    Server are usually used 24/7 and run uninterrupted for many weeks. I don't see that much inconvenience in that. All you need is a shell to ssh in and put in the passphrase once in a while.


    That's obv. your setup and your personal view on it. Others might be different.


    Btw, just to use your own arguments, isn't it a bit unsecure to keep drives unlocked when not used? Since if someone could get access to the host, he could read out all data without problems. Hint: That's your "key under the doormap" argument.

  • People can leave their keys wherever they wish. It just makes everything less secure. So why not just leave the encryption and upload everything into public space? Apparently there is no security at all.

    People lock their apartment doors to make it not so convenient for someone to break in and steal their stuff. Apparently they want more security and sort of protection of their belongings. Same goes for data.

    As I said, you can **improve** things in an open community.

  • Hi,


    fresh omv-user here. Just want to share my experience

    I set up my system with Debian 12.11, FDE LUKS and initramfs unlock. Installed OMV7 on top.


    Basically the same as bermuda:

    Except I didn't ran /etc/initramfs-tools/conf.d/cryptroot and had big problems with LVM volumes on the encrypted raid. I decided to go with BTRFS without LVM which works wonderful. Otherwise, it works as you described. Very convenient.


    Had I found your post sooner, it would have made life a lot easier for me. ;)

  • While I knew of the dropbear setup I didn't know of decrypt_keyctl and keygroups, that's pretty neat! I might add this to my setup eventually as well. As it is it wouldn't make it any more convenient than the script (which I'm fine with). I may even integrate keygroups into the script, will explore that with an AI eventually. Thanks!

  • Well ... all I did is to apply a working concept to OMV or rather Debian and put the steps I had to take in here for everyone who's also interested in a similar solution.

    Glad to see that people actually appreciate that :)

Participate now!

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