While the password is escaped for the shell, it is not enclosed in single quotes. I will look at changing this. Until then avoid characters that are interpreted by the bash shell like parentheses, ampersand, and dollar symbols.

Just saw the updated LUKS plugin and that this was fixed. Thank you for doing this

Is it possible so halt on boot and wait für the encrypted disks to be unlocked through ssh?

I want to setup 2 encrypted drives and ZFS on top, so to prevent the pool to fail I need the drives unlocked quite early. Since there is almost no reboot, manual unlocking is fine for me, but it has to be possible through SSH, since I am physically not near the server.

Edit: I managed to unlock my drives during boot by sticking to this howto
Keyfile is stored in root directory.

Chaos is found in greatest abundance wherever order is being sought.
It always defeats order, because it is better organized.Terry Pratchett

The post was edited 1 time, last by riff-raff (May 21st 2018, 12:40pm).

I created a full-disk encryption for my drives and everything is running fine. But I was bored to enter the password trough the gui and wanted to do it trough ssh. I realised none of those command worked:

HI, this thread seems kind of alive still, so maybe someone can help me here.

I'm unlocking my encrypted drive manually in the OMV(4) webgui, but on bootup all the mounts based on that drive already failed and are not re-triggered after manual unlock.

That is: the drive itself is mounted, but not all the dependent mounts like shared folders etc.

Is this supposed to work? Is either the plugin checking the mount unit hierarchy and re-triggers all dependent mounts or is systemd itself supposed to re-try when a previously unavailable dependency comes online? If both is not: How would I fix this? Is there some place where I could add custom scripts to be executed on manual unlock?

I may suggest a micro improvement?
Remark in the plugin description that a reboot is required.

This is not necessary for all plugins and everyone has a knowledge of a part of the system.
If you forget to reboot, you get a
"Check that kernel supports aes-xts-plain64 cipher" error.
Than you try to load modprobe dm-mod but'modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.94-mvebu/modules.dep.bin'...

Right after the plugin install it was impossible to use it, I got failure in the interface( Check that kernel supports aes-xts-plain64 cipher ) and in the command line.

Looking around, someone suggested some module was missing (and I tried) but it was not this.
After a ...while, I realized I could try to reboot (I know that does not sound good "just reboot and see, maybe it works"): in this case that "fixed" the issue and I was able to unlock the disks.

You say that dm-mod is not required and I don't know what was wrong,
Riccardo