Udiskie not able to unlock while udiskctl is

[dotlambda]

When I try to mount my drive using udiskie-mount, it fails:

$ udiskie-mount /dev/sdb1 
Deprecation warning: Running on python 2.7. The next major version of udiskie will require at least python 3.5!
Enter password for /dev/sdb1: 
failed to unlock /org/freedesktop/UDisks2/block_devices/sdb1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdb1: Command-line `cryptsetup luksOpen "/dev/sdb1" "luks-b9ee78a4-1997-489e-8b3d-6f5919f36e9d" ' exited with non-zero exit status 1:

At first, I thought this was an issue with polkit permissions. But setting these as described in the wiki didn't help.
Then, I discovered that I'm perfectly able to unlock the device using udiskctl without sudo:

$ udisksctl unlock --block-device /dev/sdb1
Passphrase: 
Unlocked /dev/sdb1 as /dev/dm-3.

After that, I'm also able to mount it using udiskie-mount /dev/mapper/luks-b9ee78a4-1997-489e-8b3d-6f5919f36e9d.
Now, I'm really confused about what could be causing the problem.

If that helps, the output of cryptsetup is

cryptsetup luksOpen "/dev/sdb1" "luks-b9ee78a4-1997-489e-8b3d-6f5919f36e9d"
Device /dev/sdb1 doesn't exist or access denied.

Btw, I'm running 64-bit NixOS.

[coldfix]

Hi, thanks for reporting. This is indeed strange. The cryptsetup line looks fine too

Can you try the following script and see if it gives the same error?

from gi.repository import Gio

proxy = Gio.DBusProxy.new_for_bus_sync(
    Gio.BusType.SYSTEM,
    Gio.DBusProxyFlags.NONE,
    info=None,
    name='org.freedesktop.UDisks2',
    object_path='/org/freedesktop/UDisks2/block_devices/sdb1',
    interface_name='org.freedesktop.UDisks2.Encrypted',
    cancellable=None,
)

proxy.Unlock('(sa{sv})', 'YOURPASSWORD', {})

check both python2 and python3 if possible.

[dotlambda]

The script works fine using any of python2 or python3 (no error message whatsoever and the disk is unlocked afterwards).

[coldfix]

ok, weird, udiskie does essentially just that.

How did you acquire the cryptsetup output? Does it do the same if you manually enter the command as root? (I suppose not?)

The output is what is shown if cryptsetup is executed

• under the wrong user or
• on a non-existent device.

However, neither should apply here, because udisks is responsible for both and you verified that udisksctl unlock works fine.. unless the device name in udiskie contains some hidden characters (which would be really weird).

Can you go into udiskie/udisks2.py and edit the def unlock(self, password) method to spit out the current device name.

print(repr(self._P.Block.Device))

you may also print out the password to check if it contains any newlines etc (which shouldn't be the problem here according to the error message), but don't forget to delete this afterwards;)

I don't have any other idea right now... except for maybe:

• did you retry this some time after you successfully unlocked and locked it again with some other method (maybe the device was just still unavailable in the first few seconds?)
• can you lock the device from udiskie if it was unlocked via some other method?
• does it work if running udiskie under py3?
• can you try udiskie from the current master branch (this requires installing gbulb python package, usually pip install gbulb)

[coldfix]

Please reopen if anyone can reproduce. Could be related to #153.

[next-mad-hatter]

Seeing this with udiskie 1.7.6 on Slackware 14.2.
Above script works fine with both python2 and python3 and creates mapper device.
Adding print statements to udisks2.py as suggested above suggests that unlock never gets called, only unlock_keyfile.

[coldfix]

Hi, thanks for the info!

• can you check whether this problems still persists in the latest version (2.0.2)?
• do you have any special setting for --password-prompt or in the config file?
• what does the output look like, if you run udiskie with -v
• did you add print statements as above to unlock_keyfile then? if so, did the password look alright, does it have any non-ascii symbols or is it printed with a trailing newline?

[next-mad-hatter]

I noticed that keyfiles are "not supported" for daemon version 2.1.5, still, unlock_keyfile is preferred by the logic. The following works for me:

def unlock_keyfile(self, password, auth_no_user_interaction=None):
        if not self._daemon.keyfile_support:
            return self.unlock(password, auth_no_user_interaction)
        return self._M.Encrypted.Unlock(
            '(sa{sv})',
            '',
            filter_opt({
                'keyfile_contents': ('ay', password),
                'auth.no_user_interaction': ('b', auth_no_user_interaction),
            })
        )

[next-mad-hatter]

On a side note, udiskie 2 sadly does not work for me. Installed via pip3, trying to run udiskie-mount against a block device gives me following error:

Traceback (most recent call last):
  File "~/.local/lib/python3.7/site-packages/udiskie/cli.py", line 222, in _start_async_tasks
    self.udisks = await udiskie.udisks2.Daemon.create()
  File "~/.local/lib/python3.7/site-packages/udiskie/udisks2.py", line 715, in create
    version = await cls.get_version()
  File "~/.local/lib/python3.7/site-packages/udiskie/udisks2.py", line 727, in get_version
    Interface['Manager'], 'Version'))
AttributeError: 'Variant' object has no attribute '__info__'

Not really sure what this points to.

I checked and the typelibs are present on the machine. In case it's related: pygobject 3.18.2 is installed here (latest version requires newer glib2, which I'm reluctant to start replacing).

Would you have any idea where to start looking for a fix?

[coldfix]

Hi,

I noted that keyfiles are "not supported" for daemon version 2.1.5, still, unlock_keyfile is preferred by the logic. The following works for me:

Oh, so the problem is missing keyfile support in udisks itself? I can also release a version with a similar fix. I'm wondering why the bytes code branch was even taken. Is this running on python2?

On a side note, udiskie 2 sadly does not work for me. Installed via pip3, trying to run udiskie-mount against a block device gives me following error: [...]

I've not seen this kind of error so far. Unfortunately I don't have a lot of time in the next few days, and I can't promise that I can help much further with this anyway, if it is specific to old versions, but I will take another look as soon as I can. Maybe we can extract a minimal reproducing example from the source code, and fix accordingly.

[next-mad-hatter]

Hi,

Oh, so the problem is missing keyfile support in udisks itself? I can also release a version with a similar fix. I'm wondering why the bytes code branch was even taken. Is this running on python2?

Yes, 2.7. After a quick look the reason seems to be that isinstance("strink", bytes) == True in python2 (just checked, udiskie 1.7.7 behaves correctly when installed locally & run via pip3/python3.7). Which is now abandoned, so I'm not sure if there's a need for upstream patch at this point. Anyway, this problem is fixed for me now, so thank you for your assistance :).

On a side note, udiskie 2 sadly does not work for me. Installed via pip3, trying to run udiskie-mount against a block device gives me following error: [...]

I've not seen this kind of error so far. Unfortunately I don't have a lot of time in the next few days, and I can't promise that I can help much further with this anyway, if it is specific to old versions, but I will take another look as soon as I can. Maybe we can extract a minimal reproducing example from the source code, and fix accordingly.

Well, this is not critical, since 1.7 branch works without issues now. It's just unexpected, since afaics the requirements are met, and the stack trace isn't very helpful to me (never dealt with glib, gobject & Co). In case you have an idea where to look further, I'll be glad to hear it, but this is in no way urgent.