LUKS disk encryption plugin

    • OMV 2.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • You can always see the changes (when installed) here: /usr/share/doc/openmediavault-luksencryption/changelog.gz
      Or, I usually post new release here too: github.com/OpenMediaVault-Plug…t-luksencryption/releases

      You were too quick to install it for me though!
      New in 2.0.0:
      • Key file support!
      • Kill slot renamed to erase slot.
      • Kill (erase) slot now done without key verification (batch-mode).
      • Warning added when removing the last key.
      • Check for multi-device BTRFS filesystems when auto-mounting improved.
      • Dependency updated now that OMV 2.1.19 is out.
      • Dependency updated to require omv-extras plugin >=2.9 for custom (multi-file) upload.
    • I see you are improving BTRFS filesystems auto-mounting. Any plans to do the same for aufs?

      What about having a user defined script run, if it exists, after unlocking and auto-mounting is completed? Something along the lines of how /etc/rc.local is done. Or an extra options box like there is in the SMB/CIFS and SSH modules where shell code could be pasted in.

      I could handle those aufs mounts that way.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I have no plans for aufs at the moment I'm afraid. The BTRFS check was small and easy - don't mount if not all devices are ready - because a BTRFS filesystem can be mounted by giving just one of any of the component devices.
      Extra options might be the way to go, I might look into it when it comes to auto-unlocking. I have little experience with aufs and I'd prefer to get a stable version of the plugin out sooner though.
      You could probably write a script that reacts to the unlock via udev to do your aufs mount in the mean time.
    • Looks like a good starting point, thanks.

      Edit:

      Not sure why, but automounting after unlocking no longer works here. When I do the mount manually from the Filesystems module, I do get something written to the console that I could probably grab and use in udev, or maybe upstart.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380

      The post was edited 1 time, last by gderf ().

    • Upstart is an Ubuntu thing, not sure that will help.

      Auto-mount only works for filesystems that are known to OMV, which is to say, they appear in the config.xml (and also /etc/fstab) - unmounting them via the Filesystems tab undoes this, it removes the fstab and config.xml entries, so make sure you are not doing this if testing.
    • OK, I get it now, just don't unmount and it will auto-mount in the future when unlocked.

      Here's what I find odd then.

      I can't lock a disk unless I manually unmount it first - the option to lock is grayed out until the Filesystem is unmounted. Then, since I decided to unmount the filesystem it will not auto-mount the next time the disk is unlocked.

      Perhaps the lock button could be made 'smarter' - unmounting a filesystem if mounted, then locking the disk, but not making changes to fstab or config.xml so that auto-mounting still works next time?
      Of course if I am shutting the machine down normally or rebooting, none of this matters, as these operations do not alter /etc/fstab or config.xml.
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • Will people want to repeatedly unlock & lock devices?
      I prefer to leave the current lock button behaviour as it is, since it serves two purposes: 1) it forces the user to think about the consequences of locking and why do they want to do it
      2) it minimises surprises and mimics current OMV behaviour - having to stop/remove services before unmounting, unmount before locking, etc., the user realises what they have to do
      Auto-mounting is basically for first boot. I envisaged that users boot, decrypt and then leave running.
    • Having some problems now. I am on v2.0.0 of the plugin.

      Trying to setup an encrypted USB stick. I press Create and select it from the dropdown list, enter passphrase twice, and continue. The plugin throws the following error in a popup box:

      Error #4001:
      exception 'OMVException' with message 'Unable to create the encrypted device: Device /dev/sdd is not a valid LUKS device.' in /usr/share/openmediavault/engined/rpc/luks.inc:492
      Stack trace:
      #0 [internal function]: OMVRpcServiceLuksMgmt->createContainer(Array, Array)
      #1 /usr/share/php/openmediavault/rpcservice.inc(125): call_user_func_array(Array, Array)
      #2 /usr/share/php/openmediavault/rpc.inc(79): OMVRpcServiceAbstract->callMethod('createContainer', Array, Array)
      #3 /usr/sbin/omv-engined(500): OMVRpc::exec('LuksMgmt', 'createContainer', Array, Array, 1)
      #4 {main}

      If I try from the CLI in a shell with:

      cryptsetup -y -v luksFormat /dev/sdd

      it is successful, the device then appears in the plugin, it can be unlocked, and then formatted and mounted in the File Systems page.

      Ideas?
      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • Thanks for making this plugin! This is a great addition to OMV.

      I started playing with it on my OMV VM. After creating one encrypted partition, I get what's below - the encrypted partition is listed six times. It kind of works aside of this "cosmetic" issue, but I'm sure that's not the intended behavior :)

      Note my setup is not standard, in that I have partitioned the single RAID5 array, and I use these partitions for different purposes (so different keying). It might (must?) be related to why we're seeing this.

      Any insight?

    • igrnt wrote:

      Thanks for reporting. So what's your setup, is /dev/md127 a RAID array? What is the partitioning on it like, and which of those partitions are LUKS containers? If you can tell me this, I will attempt to reproduce and work out where the plugin is going haywire.


      Pleasure: /dev/md127 is a RAID5 array. It has been partitioned into three partitions (/dev/md127p1..3). In the current test, only p2 is a LUKS container - p1 and p3 are not. (I made this setup to test my own LUKS-on-top-of-OMV setup, before I bumped into your cool plugin; my setup had three partitions, one "plain" and two LUKS containers with different key configurations).

      Thank you!

      The post was edited 1 time, last by doron ().