No. LUKS can have 8 slots for passwords and any of them can unlock the container. Just add another slot or change the passphrase from the command line.
That did the trick. Thanks!
No. LUKS can have 8 slots for passwords and any of them can unlock the container. Just add another slot or change the passphrase from the command line.
That did the trick. Thanks!
Hello everyone. I'm having some issues with LUKS plugin in OMV 7 on a Raspberry Pi Zero 2 W.
This device only has 512 MB of RAM and that prevented opening a LUKS disk neither via OMV web plugin (I would get 504 - Gateway Time-out) nor via command line as the system would halt because of low memory due to using a Argon2i key.
I was able to solve this issue, according to this SO answer, by adding from another computer, a PBKDF2 key which doesn't use extra memory and now I'm able to unlock the disk using the command line in the RaspberryPi with the S1 switch:
cryptsetup luksOpen -S 1 /dev/sda name
Unfortunately when using the OMV web plugin, it's still not possible to open the disk. I suspect that the plugin is trying to open the disk using the Argon2i key on slot 0 instead of the PBKDF2 on slot 1, and by doing that, it will exhaust all the memory until I'm forced to reboot. Using the command line all is well.
Unfortunately when using the OMV web plugin, it's still not possible to open the disk. I suspect that the plugin is trying to open the disk using the Argon2i key on slot 0 instead of the PBKDF2 on slot 1, and by doing that, it will exhaust all the memory until I'm forced to reboot. Using the command line all is well.
LUKS will open the slot that matches the passphrase you supply. If slot 0 and slot 1 have the same passphrase, then it will most likely open slot 0. You should use different passphrases for different slots anyway. You will still likely have problems since your rpi2w has less ram than required for OMV.
Thank you for replying. Indeed I'm living on the edge with the Rpizero2w as it's below OMV minimum requirements. For example, photoprism on podman is so slow that's impossible to use. However for the bare minimum (smb shares, ssh) it's actually very stable.
LUKS will open the slot that matches the passphrase you supply. If slot 0 and slot 1 have the same passphrase, then it will most likely open slot 0. You should use different passphrases for different slots anyway. You will still likely have problems since your rpi2w has less ram than required for OMV.
Unfortunately both slots have indeed different passphares so I suspect OMV is trying the wrong passphrase on slot 0 that, due to low memory, cannot detect that it has failed to open the disk and will continue until all memory is exhausted. Since this LUKS disk is for cold backup storage, I only use it seldomly so for me this is not an issue as I can open via the command line.
Thank you for the help and support, this community is great tbh.
Unfortunately both slots have indeed different passphares so I suspect OMV is trying the wrong passphrase on slot 0 that, due to low memory, cannot detect that it has failed to open the disk and will continue until all memory is exhausted. Since this LUKS disk is for cold backup storage, I only use it seldomly so for me this is not an issue as I can open via the command line.
OMV/the plugin isn't trying a slot. It is just trying to open the LUKS container with the luksOpen command and the passphrase. It is not specifying a slot to use. cryptsetup will try the passphrase on each slot until if finds one that is correct. If the exhausts all of your ram, that seems like a cryptsetup issue. You could try changing your slot order. Just create a third slot with a new passphrase, delete the first slot, and recreate the first slot.
You are indeed correct. Trying to mount the disk on the command-line without specifying the slot will fill all the available memory until it freezes the system. The most funny thing is that cryptsetup will even tell you about it but proceeds anyway:
Quotesudo cryptsetup luksOpen /dev/sda name
Enter passphrase for /dev/sda:
Warning: keyslot operation could fail as it requires more than available memory.
The solution is indeed to recreate the PBKDF2 key on the first slot of the disk.
Thank you rye for your help, much appreciated!
Hi,
just for the sake of interest i was playing around a little bit with LUKS plugin. But I was not able to finalize the process. What I did
1. Installed the Plugin
2. Wiped /dev/sda and /dev/sdb
3. created 2 new encryptions for sda and sdb.
4. Unlocked both
5. created a new File system for both. SDA was called "LUKS encrypted container on /dev/sda" while SDB was called "Device Mapper sdb-crypt"
What does that mean? Why are they in a different status? Can I format both of them with ext4-filesystem?
Hi there, does anybody know if there is a way to decrypt a drive again without wiping it?
Why not use the plugin to decrypt?
Why not use the plugin to decrypt?
Thanks a lot for the fast replies! Sorry, my question was a little bit misleading. I meant to permanently remove the encryption from the drive without wiping it.
I meant to permanently remove the encryption from the drive without wiping it
sudo cryptsetup reencrypt --decrypt /dev/sdX
Hi!
I installed OMV on a Raspi with one USB drive connected. I was able to use the LUKS plugin to encrypt this drive, format it as ext4 and to provide a shared folder via SMB in the local network. So far so good.
Now when i'm trying to lock this device (OMV -> Storage -> Encryption -> Lock Button), i always get the following error message:
Unable to lock encrypted device: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; cryptsetup luksClose 'sda-crypt' 2>&1' with exit code '5': Device sda-crypt is still in use.
OMV\Exception: Unable to lock encrypted device: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LC_ALL=C.UTF-8; export LANGUAGE=; cryptsetup luksClose 'sda-crypt' 2>&1' with exit code '5': in /usr/share/openmediavault/Device sda-crypt is still in use.engined/rpc/luks.inc:409
Stack trace:
#0 [internal function]: OMVRpcServiceLuksMgmt->closeContainer()
#1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array()
#2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
#3 /usr/sbin/omv-engined(544): OMV\Rpc\Rpc::call()
#4 {main}
Is it not possible to lock a drive, if there is a service (like SMB) using the drive?
Is it not possible to lock a drive, if there is a service (like SMB) using the drive?
Correct.
Okay thanks.
I guess it is also not possible to unmount the device (OMV -> Storage- > File systems), as long as there is a service using it? Because the Button is greyed out.
What i'm trying to achieve is to properly eject an external hard drive and connecting a new one, without restarting OMV. In this use case, without permanently connected drives, is LUKS the wrong tool for encryption? Or is there a way to work around this?
I guess it is also not possible to unmount the device (OMV -> Storage- > File systems), as long as there is a service using it?
Yep. The whole concept of OMV is to have always connected storage. Is a service is using the drive, it doesn't make sense to disconnect it without stopping the service. Otherwise, the service is broken.
What i'm trying to achieve is to properly eject an external hard drive and connecting a new one, without restarting OMV
External drives shouldn't be mounted using the Filesystems tab if you don't plan on leaving the drive connected to OMV. The usbbackup plugin will mount an external drive, sync it to a shared folder, and disconnect it. This is about the best use case for temporarily connected drives.
There is no reason to restart OMV but you will have to disable services and remove sharedfolders referencing the filesystem you are trying to "eject".
is LUKS the wrong tool for encryption? Or is there a way to work around this?
LUKS makes most things in OMV a pain unless they are auto-unlocked. Having a temporarily connected, LUKS encrypted external drive being used by an OMV service is about the most painful setup you can create in OMV.
Well, thanks for the explanation. Then i will have to rethink my use case.
You can use gen AI to create a bash script to mount and unmount it the drive which would simplify things for you. The script can do whatever you need it to before or after.
Don’t have an account yet? Register yourself now and be a part of our community!