Description of problem:
If you have a partition encrypted with cryptsetup-luks dolphin is unable to
mount it. It asks for passphrase but then shows an error message in the bottom
of the window:
An error occured while accessing 'Volume (crypto_LUKS)', the system said:
This message is even shown if the entered passphrase is wrong.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. if not exists encrypt a volume with cryptsetup-luks
2. start dolphin and single-click on the volume in the left panel
3. enter passphrase
dolphin don't mount volume
dolphin mount volume properly
"mount.crypt /dev/sdX <Mountpoint>" (from package pam_mount) is working as
root. Also mounting in dolphin as root is working.
Another PolicyKit-related issue... davidz: Do you have any idea what's going
Sorry, let's keep the component at kdebase until we know what's really at
This is because KDE apparently lacks PolicyKit support; I'd ask KDE upstream to
include this; HAL has shipped with (working) PolicyKit support since Oct 2007
and it's been known since summer 2007 that it would be this way.
Anyway, the hint is this
The program calling into HAL needs to acquire an authorization by using a
PolicyKit Authentication Agent. It's explained here
Granted, it sounds a lot more complicated than it is; it basically amount to the
caller (I guess dolphin in this case) calling, via the D-Bus session bus, into
the standardized interface
e.g. the org.freedesktop.PolicyKit.AuthenticationAgent service on the _session_
bus (emphasis on session since HAL lives on the system bus).
Basically, you just take the first word out of the error messsage, this one
"org.freedesktop.hal.storage.crypto-setup-fixed" and do the moral equivalent of
$ dbus-send --print-reply --session
string:org.freedesktop.hal.storage.crypto-setup-fixed uint32:0 uint32:$PPID
from the code. To be hundred percent correct you also take out the second word
and run it through polkit_result_from_string_representation() and check that the
returned value isn't POLKIT_RESULT_NO or POLKIT_RESULT_UNKNOWN.
I'm unaware of any native KDE PolicyKit authentication agent other than someone
from Pardus starting to write one
Might be good to ask him what's up (if you find out please let me know). In the
mean time you can use the authorization agent available in the PolicyKit-gnome
package; it looks like this
Sorry about creating this additional amount of work for the Fedora KDE team but
I guess it's like this when things move fast...
Well. Is it really a kde problem? gnome-mount gives me the same error (this
time for a normal partition and started from a kde session and from tty1):
[testuser@localhost ~]$ gnome-mount -t -d /dev/sdb5
** (gnome-mount:3610): WARNING **: Mount failed
org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action,
The problem, as I understand it from David's explanation, is that the policy is
to pop up a dialog asking what to do, but PolicyKit-gnome appears not to be
running, so PolicyKit can only decide to default to denying.
(In reply to comment #4)
> Well. Is it really a kde problem? gnome-mount gives me the same error (this
> time for a normal partition and started from a kde session and from tty1):
> [testuser@localhost ~]$ gnome-mount -t -d /dev/sdb5
> gnome-mount 0.7
> ** (gnome-mount:3610): WARNING **: Mount failed
> for /org/freedesktop/Hal/devices/volume_uuid_45059444_f164_46fe_8221_5f70b45eb7ac
> org.freedesktop.Hal.Device.PermissionDeniedByPolicy :
> org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action,
Try without '-t'. If that doesn't work it's not unlikely I need to fix
gnome-mount for this too. Thanks for the heads-up.
(In reply to comment #5)
> The problem, as I understand it from David's explanation, is that the policy is
> to pop up a dialog asking what to do, but PolicyKit-gnome appears not to be
> running, so PolicyKit can only decide to default to denying.
PolicyKit-gnome is activated on demand and nothing will pop up automatically. As
I said in comment 3 you need to patch the program that calls Mount() on HAL to
properly deal with the org.freedesktop.Hal.Device.PermissionDeniedByPolicy
Btw, how does KDE / Dolphin etc. handle mounting fixed partitions in the first
place? That requires PolicyKit support as well, e.g.
# polkit-action --action org.freedesktop.hal.storage.mount-fixed
description: Mount file systems from internal drives.
message: System policy prevents mounting internal media
Once you clear org.freedesktop.hal.storage.crypto-setup-fixed you will run into
handling policy for this thing too for org.freedesktop.hal.storage.mount-fixed.
(Oh, I see, that's the problem in comment 5 (so removing -t will definitely work
Kubuntu appears to be using a hack where, due to lack of PolicyKit integration,
they're just hardcoding the password prompt dialog and the privilege elevation
code (they use kdesudo if available, kdesu otherwise, we can probably omit the
kdesudo part in Fedora):
It also contains a fix/workaround for bug 378041 (it tells kdebase not to pass
HAL the options it doesn't like).
(Please note that the Kubuntu patch is against KDE 3 and will probably have to
be ported to apply to KDE 4.)
We cannot backport this as KDE 4 uses a completely different API (media vs.
Solid). I'll try to create a patch to support PolicyKit in Solid in the next
The code is completely different, but the general ideas from the patch can be
Created attachment 298357 [details]
Untested port of the PermissionDeniedByPolicy part of the Kubuntu patch
This is my first attempt at porting/rewriting the Kubuntu patch for KDE 4:
* straight off the presses, may or may not compile, completely untested.
* The "omit uid= if NTFS" (a.k.a. bug 378041) hack from the Kubuntu patch is
not included in this version.
Note: an important restriction to keep in mind if you want to modify that patch
is that libsolid does NOT link against libkdecore, so only Qt-only stuff can be
used, no KStandardDirs, i18n etc.
By the way, IMHO we should also apply kubuntu_9915_userdiskmount.diff to our F8
KDE 3 packages, as this issue is likely to affect KDE 3 too and bug 378041
(which that patch also fixes) was even actually reported against KDE 3.
Created attachment 298359 [details]
Untested port of the Kubuntu patch
* added workaround for bug 378041 (IMHO still clearly a HAL bug),
* using explicit QString::fromLatin1 to convert string literals to QString.
the workaround ist included in kdelibs-4.0.2-12.fc9. Sebastian, couls you
please try again with the new version? thanks
Seems to work for USB devices and DVDs now. But in a short test I was unable to
mount a cryptsetup-luks encrypted partition. The password dialog is shown, but
the password not acceptet. I'll try to get some more informations about that.
Uh, USB devices and DVDs aren't supposed to require a root password at all...
(In reply to comment #16)
> Uh, USB devices and DVDs aren't supposed to require a root password at all...
Not the root password, the password for the encrypted partition. DVD and USB are
working without entering a password.
But weren't they before?
All this patch fixes is:
* prompts for the root password when PolicyKit denies permission to the user,
* NTFS partitions.
(In reply to comment #18)
> But weren't they before?
I've started the bug because I got an PolicyKit refuse error when trying to
mount encrypted partitions. But also normal ext3 partitions weren't mountable
if they are not listed in fstab.
> All this patch fixes is:
> * prompts for the root password when PolicyKit denies permission to the
With kdelibs-4.0.3-1.fc9.i386 this seems to work correctly now.
> * NTFS partitions.
Indeed. NTFS and VFAT-Partitions (here: a NTFS partition on a USB-HDD) is now
working. Ext3 partitions are still denied.