LUKS volume does not get unlocked automatically w/o reboot when auto-unlock is set up

Troubleshooting
1

Brief description of problem

According to Rockstor’s LUKS documentation setting up auto-unlock via keyfile should mean that the LUKS volume will be unlocked at runtime:

Note: Currently this device is auto started by systemd in the background but only if Auto unlock via keyfile has been configured; it can take up to 30 minutes to appear. This is a known inelegance and is slated to be sorted shortly (ie to open the volume directly after the keyfile config is applied). […]

But this never works for me. I find that I always need to find the right systemd service and start it manually to unlock the LUKS volume and make it show up on the Disk page.

Steps to reproduce

You need an unused disk in the system. From the Disks page, go to the disk’s setup page by clicking on the eye symbol.

Set disk role by selecting Whole Disk (None) - active and then check Tick to enable Whole Disk Encryption (LUKS Format)... and enter a LUKS master passphrase in the fields below before clicking Submit.

Return to the disks page. Click on the little locked padlock symbol, which takes you to the LUKS setup page at /#disks/luks/{disk_id}.

Under “Boot up configuration” select Auto unlock via keyfile, then tick the checkbox next to “Create keyfile (native)” and enter the passphrase again in the field below. Make a note of the keyfile’s name, as it contains the LUKS volume’s UUID, which you’ll need, then click Submit.

It looks like nothing happened, but in fact, a new systemd service is created in the background. To find it in the CLI you’ll need the UUID from before.

Example

Last time I added a disk, the keyfile got called /root/keyfile-a1a55667-1204-42dc-b4a3-e6f34fc05aa6 so the volume’s UUID was a1a55667-1204-42dc-b4a3-e6f34fc05aa6.

In the CLI, I looked for a systemd service whose name starts with systemd-cryptsetup@luks… and then continues with the above UUID somewhere in there. I found this:

# systemctl status systemd-cryptsetup@luks\\x2da1a55667\\x2d1204\\x2d42dc\\x2db4a3\\x2de6f34fc05aa6.service 
○ systemd-cryptsetup@luks\x2da1a55667\x2d1204\x2d42dc\x2db4a3\x2de6f34fc05aa6.service - Cryptography Setup for luks-a1a55667-1204-42dc-b4a3-e6f34fc05aa6
     Loaded: loaded (/etc/crypttab; generated)
     Active: inactive (dead)
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:systemd-cryptsetup@.service(8)

(Note that \x2d encodes the humble dash - and that \ itself needs to be escaped again in the shell, hence the \\.)

I waited for over an hour and the service never got started, so the unlocked LUKS volume never showed up in the Disks page.

Personally, this doesn’t bother me too much, since I figured out how it works and know I can just start the service with systemctl start systemd-cryptsetup@luks….service, but I feel like this might be a bit of a trap for new players.

2 Likes
2

Well, when I set up the fulll disk encrytpion via keyfile, I just restarted the server afterwards to (1) unlock the drives and (2) test whether the auto-unlock really works :person_shrugging:

2 Likes
3

Yeah, reboot works, of course.

And so does the method I outlined above for finding and starting the systemd service by hand, if you want to avoid reboots and see the unlocked volume immediately.

But it’s not very elegant – I find – and it does bother me a little that the whole thing doesn’t work as advertised in the docs.

Now it’s documented here, at least, in case someone searches the forums.

2 Likes
4

Thanks for documenting this here. I believe, the LUKS docs were written back during Rockstor’s 3.x days when it still had CentOS as its underpinnings. So, the behavior described there has apparently changes (as you observed). That part of the code has not had much attention in the last few years, so it’s another area that will eventually benefit from some TLC, hopefully.

Of course, if you’re game, you are more than welcome to create an issue/PR in the documentation to update the procedure with its changed behavior (including some more recent screenshots).

5

I think I’d prefer restoring the documented behaviour.

At least I could try.

Let me see, if I can find the time for that.

1 Like
6

That is of course the preferred approach, as you’ve said, making it simple enough for a user new to LUKS.

1 Like