Raid Array 1 + LUKS encryption not mounting correctly upon reboot

  • Hello everyone I have multiple issues going on. My goal is to get LUKS encryption on my Raid ARRay 1 compromised of a Rasbperry pi 5, 2 Samsung 500GB 2.5" SSDS connected via USB to the PI.
    I have successfully created the Raid Array accessible via SMB; Users can authenticate and read/write files.
    The main problems are as follows:
    1. The main issue is when I encrypted the Raid Array and access it with a user account that has read/write permissions to it, The shared folder connected to the encrypted raid array is empty or doesn't exist. AI seemed to think this had to do with the time decryption and unlocking the LUKS device itself. I did a lot of the backend configuring through CLI as OMV has issues sensing USB connected drives instead of SATA. In OMV GUI, The shared folder can't be assigned to the encrypted file system (probably why it's empty).

    2. After configuring fstab to mount the drive and ensure that group I have has read/write access to it; upon reboot, ssh and OMV gui access denied. I have to remove the FSTAB entry for it to fix.

    My assumption for the issues I have is because the hardrives are connected via USB which has issues with the OMV gui so I have to configure it via CLI. Help would be greatly appreciated, Thanks.

  • macom

    Approved the thread.
  • MD RAID on drives connected by USB are not avail via the WebUI for the simple reason it's highly likely to cause problems and potentially loss of data.


    Creating such an array is not prevented if you use the CLI, but you proceed at your own risk and against forum advice.


    Typically, you MD RAID device, /dev/md0, is then used as the device which is LUKS encrypted ( not the individual drives on the array ) . Only when the LUKS device is unlocked can it be formatted with a filesystem which can then be mounted. So where do your store and access the key needed for the unlock process? Encryption is only going to protect your data when it's at rest and locked, not when it's in flight and in use. Storing your key on the main OS drive to enable auto unlocking on boot is not secure. A popular alternative is the issue of "dropbear ssh" - but that requires intervention over a ssh login every time you boot the OMV device. Otherwise, you need to use a system which retrieves the "key" from another remote server automatically.


    Search on "how to unlock LUKS using dropbear ssh keys remotely" ....

  • Hello FNF Game 24 I have multiple issues going on. My goal is to get LUKS encryption on my Raid ARRay 1 compromised of a Rasbperry pi 5, 2 Samsung 500GB 2.5" SSDS connected via USB to the PI.
    I have successfully created the Raid Array accessible via SMB; Users can authenticate and read/write files.
    The main problems are as follows:
    1. The main issue is when I encrypted the Raid Array and access it with a user account that has read/write permissions to it, The shared folder connected to the encrypted raid array is empty or doesn't exist. AI seemed to think this had to do with the time decryption and unlocking the LUKS device itself. I did a lot of the backend configuring through CLI as OMV has issues sensing USB connected drives instead of SATA. In OMV GUI, The shared folder can't be assigned to the encrypted file system (probably why it's empty).

    2. After configuring fstab to mount the drive and ensure that group I have has read/write access to it; upon reboot, ssh and OMV gui access denied. I have to remove the FSTAB entry for it to fix.

    My assumption for the issues I have is because the hardrives are connected via USB which has issues with the OMV gui so I have to configure it via CLI. Help would be greatly appreciated, Thanks.

    Your symptoms usually mean the LUKS array isn’t unlocked before SMB tries to mount it, so OMV sees an empty path. Avoid fstab for encrypted arrays; use OMV’s LUKS unlock + systemd mount units instead to prevent boot lockouts.

Participate now!

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