Support for encrypted drives?

Is there a way to mount LUKS encrypted drives in OSMC?

I have an external LUKS encrypted drive that I use to back up all my media onto, and currently the only way to mount it is to ssh into the box and run cryptsetup/mount. Not something my wife would be able to do :grin:

I am just curious if there is some sort of a helper or maybe an add-on that can do that?

You could write a systemd unit to do this on boot if it’s always attached

I had something similar set up on my earlier box, but the problem is I had to store clear-text password on the box itself, which partially defeated the purpose of having an encrypted drive.

If there is nothing existing, that’s fine, I will figure something out.

@sam_nazarko I see you wrote several udisks-based units. Is it safe to install udisks2 alongside with them?

No - I don’t recommend using UDisks2.

You could probably develop a basic Python script that brings up the Kodi keyboard and asks for the password

1 Like

Came up with this so far:







I am using udisksctl and it works well on my laptop (Ubuntu 24.04 with vanilla Kodi). Will try it shortly on my Vero V.

Nice. I manually mounted the drive after bootup, and updated the contents via rsync as and when I needed to. I had to install a few packages, and had to be careful about what filesystem features were compatible with the kernel on the Vero.
My other half is unlikely to ever delve into this stuff too…

Please excuse my limited perspective, but can anyone describe to me a use case where the use of an encrypted disk connected to a media player is useful/necessary?

3 Likes

I have a large backup drive where I store all my personal docs, including my media collection. Didn’t want to have 2 separate drives and didn’t feel like storing some of my personal data unencrypted.

Personally I just encrypt everything by default… there’s no reason why not to any more, other than minor inconvenience on occasion…
If nothing else it also means it’s safe to sell hdd on when you no longer need them.

1 Like

If anyone wants to test run the addon, it’s available here:

It doesn’t work on OSMC at the moment as it requires udisks2 and a few PolKit policies for udisksctl that come as part of the Ubuntu desktop.

It does work nicely on my laptop with Ubuntu 24.04 though.

@sam_nazarko is there a way for me to leverage OSMC udisks helpers instead of udisksctl to mount/unmount and lock/unlock partitions?

This way I can avoid dependency on udisks2.

It looks like armv7-udisks-osmc provides the old (version 1) udisks binary.

I was able to install udisks2 alongside with it and everything seemed to work… Just need to manually add a few polkit rules. @sam_nazarko will I break something by installing udisks2?

I don’t know – but I know without keeping udisks1 currently, you lose the automount integration. So we can’t swap UDisks1 for UDisks2 immediately.

If you want to look in to migrating to UDisks2 entirely I’m happy to work with you

I can give it a try, if you point me in the right direction. Is udisks-glue-osmc what does the auto-mount integration?

@sam_nazarko here are the options that I can see from my limited knowledge so far:

  1. Adapt udisks-glue-osmc to use UDisks2 D-Bus API.
  2. Adapt udisks-glue-osmc to use libudisks2.
  3. Replace udisks-glue-osmc with a few udev rules and helpers scripts.

My understanding is that all the magic happens in the udisks-glue.conf file provided by diskmount-osmc. And, from what I can tell it basically mounts/unmounts a given device and exposes it via Samba.

Did I miss anything?

Option 3 in combination with udisksctl from udisks2 looks to be the easiest route…

@sam_nazarko do you want me to continue here or should I raise an issue on github instead?

Let’s continue here. I’ll get back to you about this shortly.

You can use a key file generated by cryptsetup luksAddKey .... I think this is not a cleartext data format. I managed to mount a luks- encrypted hdd using /etc/fstab and /etc/crypttab.

Instead of a device path like /dev/sda1you can also use unqiue UUIDs. Example

/etc/crypttab:

# <target name> <source device>         <key file>      <options>
luksMyDisk UUID="dffe4620-66d1-48d1-b52f-23ebb15b7ec5" /home/osmc/luksKeyFile

(The UUID of the partition like /dev/sda1 you get with blkid)

/etc/fstab:

/dev/mapper/luksMyDisk   /mnt/luksMyDisk   ext4   defaults,noatime,nofail   0   0

The keyfile has to be created first like: dd if=/dev/zero of=/home/osmc/luksKeyFile bs=1M count=1.
And the passphrase is entered into the key file by

sudo cryptsetup luksAddKey UUID="dffe4620-66d1-48d1-b52f-23ebb15b7ec5" /home/osmc/luksKeyFile

(I think luksAddKey has to be entered case-sensitive otherwise you get an unknown action error or so).

1 Like

Thanks @JimKnopf. This is definitely better than having a plaintext file stored on the drive.

I’ve been looking at the last section of the udisks-glue.conf file, specifically:

match disks {
	post_insertion_command = '
		if [ $(/bin/lsblk -n -d -o RM "%device_file") -eq 1 ] || [ $(/bin/lsblk -n -d -o ROTA "%device_file") -eq 0 ]; then
			device=$(/bin/lsblk -n -d -o MAJ:MIN,TYPE -s "%device_file" | grep disk | sed "s/[^0-9:]*//g")
			echo 1024 | sudo tee "/sys/dev/block/$device/queue/read_ahead_kb" > /dev/null
		else
			sudo /sbin/hdparm -S 240 %device_file
		fi'
}

For removable (RM == 1) or non-rotational (ROTA == 0) media it sets read-ahead buffer to 1MB, and for rotational media it sets spin-down time to 20 minutes. In other words:

RM ROTA
 1 X    => 1MB read-ahead
 0 0    => 1MB read-ahead
 0 1    => 20min spin-down

However, my testing of different media types gives the following results:

            RM  ROTA
int nvme     0  0
int mmc      0  0
int sata     0  0
ext sata     0  1 (via usb)
int optical  1  1
ext optical  1  1 (via usb)
usb flash    1  1
  • External drives (both SSD and HDD) are reported as non-removable, but rotational media.
  • Both internal and external optical drives are reported as removable media.
  • USB flash drives are reported as removable and rotational media.

In other words, the logic in the above section seems completely broken… Optical drives would get 1M read-ahead buffer and external SATA drives would get 20-minute spin-down time instead.