-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto unlocking LUKS drive fails #218
Comments
Hi, many thanks for the report. You're right, it should unlock normally. I did a quick check on a test device and it seems to work so far. Therefore some follow-up questions: How did you setup the device?, i.e. can you give the fdisk/cryptsetup command that will reproduce the same behaviour on another device (if you have one around for testing)? In any case, can you give the output of
By "the same session", do you mean the same login session or the same udiskie instance? i.e. does the issue occur again after stopping and restarting udiskie, or do you have to logout or even reboot?
It's interesting that the "/dev/sdd matched" line occurs twice. In normal cases it should not. That may have to do with the problem in one or the other way (symptom, or cause). You luks-formatted the device directly (without partitioning), is that correct? Is that all the output, even if waiting for another 30s or so?
This doesn't show that the device was unlocked at the beginning, which means either there is output missing at the beginning, or it was already unlocked before running udiskie?
Taken literally, the config above has slightly inconsistent indentation which would lead to errors - but since it seems to work I guess it was messed up during posting. |
Thanks Tomas!
It was some time ago, but is just a standard whole-of-disk encryption. I probably did:
The same login session, wihout restarting the daemon. If I reboot, the unlocking fails.
Yep.
That's all that was printed to the journal.
Yeah, I munged it while pasting :p |
Okay. Thanks for the info! Currently still no idea what the problem is. It might be more insightful to get some information from udisks itself what is going on while the device is inserted (once with and once without udiskie running). You can monitor for detailed udisks device activity using the following command:
and get access to the logs by:
Also, let me know if you run into the same problem with another device/another machine, and what your operating system is. It would greatly help if I could somehow reproduce the issue.
What happens if you mount+unmount the device, and kill udiskie and start it again without rebooting the machine? Does the issue occur or does it work as expected?
Did you just unmount the device or also "lock* it after the initial manual mount? The log seems to indicate that you didn't lock. If you didn't, what happens if you first manually unlock+muont and then unmount+lock, and then start udiskie again? Best, Thomas |
Thanks Thomas! The output of udisksctl monitor (first with udiskie service running, then after stopping it:
Now this is weird. I restarted the systemd --user service to perform the next test (killing udiskie) and plugged the drive in and it mounted correctly:
So it seems it is related to how the service is initially instantiated on this machine (Arch Linux). I'll test on my laptop. Edit: tested on my laptop (Arch Linux), and once I had whitelisted the device in usbguard, same behaviour. First load fails. Restart the service and autounlocking and mounting works. The service file is the same on both machines:
|
OK, it's definitely an issue with the systemd --user service. I disabled the service and started udiskie from There is obviously something in the environment that is picked up when the --user service is restarted that is not present at login. I'll have to dig in to how to try and debug that... Edit: Restarting the service adds some environment variables:
Edit 2: Adding DISPLAY and XAUTHORITY to the --user service environment and rebooting made no difference (which is good, I guess, and I don't want it to depend on X). Edit 3: Adding |
Oh you're starting from a unit file. The recommended way to start udiskie is from .xinitrc for now. As far as I know, there can also be some problems with the tray icon showing if starting as a .service. Furthermore, it's possible that you might need a different set of polkit permissions, (xxx-other-seat), see Permissions. |
OK, Thanks Thomas. I already have the polkit file on both machines. I wasn't aware that starting via a service file was unsupported. |
I don't have any new valuable information at this point, but I seem to be having the exact same issue. It seems weird that it would be related to environment somehow, because udiskie does show a popup (in Sway, using mako for showing the notifications) when the device has appeared. It just doesn't unlock it. I then have to to udiskie-mount -a to get it mounted. If I restart the systemd user service or start udiskie manually, it does seem to unlock automatically. |
I have noticed this phenomenon too. I’m not sure this is exactly the same situation as above, but if I start udiskie in With In the code, this message is logged in this method: Lines 243 to 250 in 2497c2c
Lines 200 to 222 in 2497c2c
Lines 319 to 333 in 2497c2c
Lines 356 to 378 in 2497c2c
If I understand correctly, the observed behaviour is what should be expected: when auto-unlocking, the method Since In fact, as can be observed above, there is already such a prompt check inside the method |
Udiskie 2.3.2
Udiskie is configured to auto-unlock a LUKS USB drive using a keyfile. This only works if I manually call
udiskie-mount
(either with the-a
option, or specify the device, eg.,/dev/sdf
, OR if I have during the same session manually unlocked the device, ie., manually unlocked it, dismounted, and then some time later replugged it, then udiskie behaves as documented.Using the debug switch, some output. First, when configured with
-id_uuid: XXXXXX
the device is not unlocked:When the device is not unlocked, I call
udiskie-mount -a
and it is unlocked/mounted. After a dismount, replugging and the device is successfully unlocked/mounted:Config is pretty basic:
Is there something I am missing here? Thanks!
The text was updated successfully, but these errors were encountered: