LUKS + KeyFile + AutoMount? [SOLVED]

So I've seen some conversation around here, most of which were older and dated and not talked about much lately. So I wanted to start a fresh thread on this idea and see if anyone has successfully done it, and/or would like to share some insight/input on where to make the appropriate configurations. I've read a lot from Zack Reed whose script I believe is the basis of the SnapRAID script, and came about this thread: zackreed.me/encrypted-snapraid/.

I've got my encrypted disks setup, I've got the keyfiles created on an external USB drive, that I'd like to use as my way too simply "lock" the drives. What I need to do now, is alter the cryptTab and FStab to support mounting these automatically. Problem is, I'm not sure where to make these specific changes, as I recall OMV overwrites at least specifically the FStab through some normal configurations - aka upon restart I'll lose these changes.

An alternative option I might entertain, is storing the keyfiles on the system drive, but then having a mechanism to stop the boot of the OMV system drive without a USB device plugged in and available. Could simply be a keyfile for LUKS encryption on the system drive, or some other mechanism available that perhaps I don't even know of.

Is anyone able to shed some light on this dream of having a fully encrypted OMV system that can have a simple USB device removed to render the drives unreadable? The goal here is security and privacy. I'd like to ensure that if a drive was ever stolen/lost, it could not be read. I'd also like to produce a mechanism to "pull the plug" on the system if I was ever being forced to turn over drives. Call me paranoid, but with the advent of things these days, I'd love to have the peace of mind that it's possible.

SIDE NOTE: Any impact folks have seen on performance of things like NFS/CIFS/AFP transactions and/or throughput with the use of LUKS on their disks?

Omv onlyrewrites fstab in between the openmediavault tags. You can do anything you want before or after.
I guess If you want also the system drive encrypted you'll need an open /boot partition and some commands to execute when the initramfs is loading so you can mount the USB drive and make it available for decrypting the current devices.

@subzero79 - Good to know about what OMV overwrites and doesn't. That's an interesting tidbit I wasn't aware of. Possibly as I didn't "read the manual" vs just jumping into using. What you pointed to is basically the same type of setup as what I had from the Zack Reed post, but didn't have the initramfs component. Which I think is partially what I'm unaware of.

Seems though as @Nibb31 points out, OMV will auto mount the disks if they're unlocked, so perhaps I don't need that extra work there. @Nibb31 - Do you have anything special with those disks running as well? Anything like SnapRAID, RAID, or some other UFS sitting atop them? Right now all my data are on non-encrypted disks (4 total, 3 data 1 parity for SR, MergerFS pool as Storage1). The new encrypted setup mirrors this (4 total, 3 data, 1 parity w/ SR, MergerFS pool as Storage2). So I'm interested if the logical MergerFS volume (storage2) will be auto mounted as well? Once I've got this all operating as expected, the plan is to migrate the data, reformat the non-encrypted, then add in the additional disks to the SR/MergerFS pool.

And I guess a separate question is, when setting this script to run as a Scheduled Job on "boot" - does that truly run before the rest of the OMV stack starts? Because I do run things like Docker on top of these disks, and some other various minor tools. I just don't want a flood of apps/plugins that are going to fail on boot because the OMV stack doesn't WAIT for the LUKS unlock process to proceed first.

There is no Omv stack. Omv is web manager panel. Running on boot means it will run at cron daemon start, it doesn't have any dependencies.
Say your sharing a whole encrypted disk with samba(the root), if you don't unlock the disks the underlying mounting folder still exists, data will be written to the folder if someone has the adecuate permissions on that folder filling the rootfs. If you don't share the root disk sAmba usually outputs permission denied if the folder doesn't exist.

Docker will fail to start or worst it will start and maybe write data to folders under, un less you do some systemd research on how to link the mounted paths and the start of the service.

Ok so it seems like I could/should treat it just like another Linux host. I did something on my old docker host where I altered the systemd service file to use the RequiresMountsFor option to ensure my remote SMB/NFS shares were attached before starting the docker service. So if real issues arise, containers don't start because service isn't started. But if everything is fine and the mounts take a moment to come up, then the docker service doesn't miss the mounts because the mounts come up first.

I guess I may have to dig in and do some analysis of the startup order and better understand when the plugins get loaded and startup. If I can get an interrupt before that to insert something like this, I should be golden. I guess time to do some digging.

@ryecoaaron - I know you've been the plugin guru in many of the forum posts. Is there a certain event that triggers the start of the various plugins? And/or is there a single "choke" point I could use to interrupt in the startup of the various plugins?

I'd imagine that when it comes to the various services (CIFS/NFS/etc) - I'd have to likely find an early interrupt point in the boot process to hold those or individually mimic something like I did with my docker host originally for each of those individual services. But I'm trying to narrow in and find the single point I can delay in the startup. The idea here of course being to switch to a completely encrypted system, and if the disk aren't unlocked/mounted, the system should essentially fail to start. Logs and local/SSH access would be the only things I'd want available to troubleshoot essentially.

Is there a certain event that triggers the start of the various plugins? And/or is there a single "choke" point I could use to interrupt in the startup of the various plugins?

Most plugins don't really "start". They create a config file for a service. These services have start scripts/unit files that start them. If you wanted to unlock drives before those services start on OMV 3, you would need to create an unlock unit file that starts right away at boot to unlock the drives. Then you would need to add systemd override files with a dependency on your unlock unit file being start to each of the services that you wanted to wait for the drive to be unlocked. This is one way it can be done.

Ok I think I'm getting it. Forgive my archaic or foolish thinking here that OMV was like it's own mystical magical application or distribution. It seems to be more that it's just a nice pretty GUI to wrangle all the usually disparate things inside of a linux installation. I cling to it as I like the GUI config vs command line, but many times I find myself having to dig into the CLI anyway to really tune things the way I'd like/need. I always worry when I'm working with something like this though, as I feel like a bull in a china shop - somehow I'm going to tear through and miss something that just breaks the core thing.

So for my edification - I'm going to have to do some linux googling now too - I should be able to theoretically find a 'service' file (assuming in systemd location?) for the individual plugin services provided? Within those I can use the documentation for what can be listed in those files to create the "wait" state I'm looking for that delays startup of the service until the "unlock and mount locked drives" unit has been satisfied, aka completed?

BTW - I know we're getting a bit outside the realm of OMV and specifically what it provides here, but what I'd like to do is hopefully figure this out, iron it out, and then potentially validate with others who would like to comment or test the config. Then I'd like to write together a small blurb as either a post here, or a PR to the plugin Wiki page to provide further detail for others wishing to do the same. Bit of a learning curve ahead for me though.

Any help is always appreciated! ;o) On the positive side, I've got an ESXi box that I can run a virtual OMV system in to test this stuff out. I'm thinking it will make sense to create a dummy system with a basic OMV setup first that I can mimic my prod setup in. Obviously some minor differences in real world access vs virtual access to things like USB drives will slightly alter things, but the mechanics should be the same. Also has the benefit of no impact when restarting, vs my prod system which hosts a lot of things internally for me. Project for this weekend is likely to set that up. Then I can also test the suggestion you had for Duplicati with the mono certs without breaking my real storage system.

I'm all ears! My plan would be to put the keyfile on a local USB drive and plug that into the host. Plan is to leave it plugged in for all intensive purposes, so that locally the host will always restart properly without any issue. The moment I need to pull a drive and ship out for service, replace, discard, if it get's stolen - the local key is not available for the drive so it will effectively be useless. Though I may still "scrap" it by running a logical delete first. The other "emergency" situation is a server needs to be protected scenario, in which case I can pull the USB key and the system is rendered useless to startup or at least even be able to get to the content. Obviously if I want to keep a copy somewhere else this would be good as well as a backup, but if needed something as simple and cheap as a USB key can be destroyed rendering the disks essentially "unreadable".

I'm thinking my end result is going to be to create 3 keyfiles (inserted into the key slots for LUKS of course) for backup reasons - 1 will be on the USB key attached until needing to be detached. 1 will be on a physical USB media somewhere else outside the home (friend, family, etc). 1 will be kept digitally somewhere else in some obfuscated format as a last resort. This one could also be copied to multiple locations if needed. It's not a perfect system, but provides a degree or level of security beyond the usual and makes me feel warm/fuzzy inside knowing I've done my diligence to protect my content.

Have to get some work done now ... so I'll check back in later. Thanks for the help and guidance @ryecoaaron - you're always offering up your time, and just want to let you know it's extremely appreciated!!

I can get drives to auto unlock if I put the key in /root/ and add an entry to /etc/crypttab.
If you want to put the keyfile on a data disk, add an entry to /etc/default/cryptdisks to mount the disk before crypttab is processed.

Foolish me, I didn't login after you originally posted, so I didn't see the updates. My bad. It's taken me some time to get back to this as I just finished running through some hoops with new networking setup. Finally upgraded to the wonderfully troublesome yet beautiful Ubiquiti Unifi line. Learning a lot of router OS CLI work!

Anyhow - I've got a VM up and running with 3 vdisk. I've setup everything at is in my prod enviro, minus data of course and the extra shenanigans running from plugins. I'll build on it if I need to fully vet it out. I'm running into an issue even trying to get to the part of registering the keyfiles to key slots in the disk. When I attempt to browse for the keys in the GUI, I'm hit with an error.

There is a bug in the plugin if you use a certain combination of passphrases and keyfiles - adding a keyfile while supplying a passphrase. If you do it the other way around, it works fine. If you use all passphrases or all keyfiles, it works fine. So, just the one method is problematic. It isn't real high on priority list since it is still possible to get what you want.

Interesting. I think I had read this somewhere else, but as a general LUKS gotcha. Must have glossed past and note realized. I think it mentioned something along the lines of when using a passphrase and attempting to add a keyfile, the keyfile will be read as a string, so if there are any carriage returns essentially of the equivalent in binary, that it will cause the "enter" to be pressed before fully analyzing the key. Not sure if this is the same specific issue or not.

Either way, it's ok as I'm happy to test using only keyfiles, since that will be my production config. I will be sure of course to have multiple backups. Let me try again and see what I come up with this time.

I just recently moved all my data to encrypted drives. So basically i have 2x3TB disks encrypted, to unlock them i use another small virtual disk (could be a usb in case of bare metal i guess) that contains the keyfiles. That small virtual drive is encrypted also, so basically I unlock this drive at boot which has the keys to unlock the other drives, at the end of the boot sequence the key disk gets unmounted and closed.
This was done in a combination of crypttab and a custom script embedded in the initramfs.

You can do this by using just crypttab and fstab, and let systemd take care......but since systemd auto creates the dependencies at boot whenever you attempt to close the key disk, systemd will close and unmount all the related devices.