Encrypted drives in OMV6 re-lock themselves

Question

Encrypted drives in OMV6 re-lock themselves

Opened this issue 6 months ago · 17 comments

Have encountered a weird bug where the drives (after some time of them being unlocked) just lock themselves and I need to go to the OMV GUI and unlock them again. Bit of a hassle and haven't seen anything in the notifications that might show why this is happening.
Also, is there a way to permanently decrypt the drives if there is no fix for this?

Answer 1 · 2024-03-30T21:22:44.000Z

I assume you are using usb drives? If yes, they are lock when the usb controller puts the drive to sleep which is like disconnecting the drive. I don't know of a way to prevent this.

Answer 2 · 2024-03-31T11:02:10.000Z

Hi, tope, they're two hdds.
Though, I do use ProxMox and have passed thru the hdd to the omv vm. It used to work great before, but I've updated to both the latest proxmox and latest omv ( was running on older versions without issue for last 18 months).

Answer 3 · 2024-03-31T13:18:05.000Z

Are you setting the drives to spin down? OMV did just switch from hdparm to smartctl in 7.0.4-2
https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/debian/changelog#L9

Answer 4 · 2024-03-31T17:40:12.000Z

Everything looks to be disabled

Answer 5 · 2024-03-31T18:22:58.000Z

I can't explain it then. Something is causing a disconnect. The plugin isn't a service and isn't constantly interacting with anything. I would look for messages in dmesg. It would be worth your time to post on the forum where people who actually use luks in this way might have run into this before.

Answer 6 · 2024-04-01T11:35:21.000Z

Interesting. In any case, would (as per the example picture) the command to decrypt the hdd be the following:
"cryptsetup-reencrypt --decrypt /dev/sdc"

Answer 7 · 2024-04-01T12:33:10.000Z

No. It would be (need to replace CONTAINER_NAME with the one from your system - I don't know what it is - probably sdc-crypt):
cryptsteup luksOpen /dev/sdc CONTAINER_NAME

Answer 8 · 2024-04-01T12:57:37.000Z

Yes, correct, that's to decrypt them once, I was thinking to completely remove the encryption on the hdd.

Answer 9 · 2024-04-01T13:17:52.000Z

I've worked with LUKS for years and never tried that. Seems like it would still sit on a LUKS device with is weird. I will have to try it.

Answer 10 · 2024-04-01T13:20:28.000Z

This looks to be the one as of 2.6.0
cryptsetup reencrypt --decrypt
Will try over the next day.

Answer 11 · 2024-04-01T13:25:29.000Z

You are missing the --header flag. cryptsetup reencrypt --decrypt --header /test /dev/vdj

I just decrypted a container on my test system. It "moved" the ext4 filesystem from the container to the drive. So, it seems like it works well. Since fstab is mounting the filesystem, it just worked on reboot as well.

Answer 12 · 2024-04-03T10:40:41.000Z

Interesting, maybe the decryption option could be added to the plugin gui.
Also, noticed something interesting - I unencrypted it via the terminal using the luksOpen command and it worked and didn't re-crypt BUT for some reason it didn't actually mount the unencrypted drives in OMV.

Answer 13 · 2024-04-03T11:01:27.000Z

Since these filesystems are in fstab, there is nothing actively watching them to mount when they get unlocked.

Answer 14 · 2024-04-03T11:46:45.000Z

Hmm, so why is it when I decrypt using the plugin they remount automatically?
The default situation is that once the drives re-encrypt the mounted volumes show them as missing and once decrypted they automatically go online.

Answer 15 · 2024-04-03T12:02:59.000Z

the plugin tries to run a mount command after decrypting.

Answer 16 · 2024-04-03T12:55:53.000Z

Excellent, that explains it. For the simple people like myself - what would be that mounting command that's run?

Answer 17 · 2024-04-03T12:58:53.000Z

If you really want to keep it simple, just run "sudo mount -a" after everything is unlocked.