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. 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. 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. Forgive my archaic or foolish thinking here that OMV was like it's own mystical magical application or distribution. 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. 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.Īnd 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. The new encrypted setup mirrors this (4 total, 3 data, 1 parity w/ SR, MergerFS pool as Storage2). 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). Seems though as points out, OMV will auto mount the disks if they're unlocked, so perhaps I don't need that extra work there. Which I think is partially what I'm unaware of. 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. Possibly as I didn't "read the manual" vs just jumping into using. That's an interesting tidbit I wasn't aware of. 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 - Good to know about what OMV overwrites and doesn't. Call me paranoid, but with the advent of things these days, I'd love to have the peace of mind that it's possible. 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. I'd like to ensure that if a drive was ever stolen/lost, it could not be read. 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. 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. 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.Īn 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. What I need to do now, is alter the cryptTab and FStab to support mounting these automatically. 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. I've read a lot from Zack Reed whose script I believe is the basis of the SnapRAID script, and came about this thread. 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. So I've seen some conversation around here, most of which were older and dated and not talked about much lately.