After installing policykit, gnome-mount fails silently when run by an ordinary user (but works for root). Reproducible: Always Steps to Reproduce: 1.In 99-storage-policy-fixed-drives.fdi, change the keyword "true" to "false" so gnome-mount will not ignore fixed-drives. Restart hald. 2.As root, e.g. "gnome-mount -d /dev/hda1" should work and the disc icon should appear on the (ordinary user's) desktop. 3.As a user, polkit-auth (properly) asks for authentication before executing gnome-mount, but nothing gets mounted and there are no error messages. From now on polkit-auth will not ask for authentication but the mount fails silently. Expected Results: Once authenticated by polkit-auth, a normal user should be able to gnome-mount a fixed drive just like a removeable memory stick. (BTW, polkit does *not* break gnome-mounting a removable drive for normal users, just fixed-drives.)
Does this work with plugdev-based policy, rather than with policykit-based policy? That is, is it a policykit bug, or a hal bug? Looking through the hal code, it looks like hal only lets non-root users mount vfat, ntfs, ntfs-3g, iso9660, hfs, or udf, since those filesystems don't record UID/GID in the FS. Is this FS one of these? If not, hal will not let you mount it as non-root.
Oops, my apologies -- I just didn't understand how the policykit settings work (and I probably still don't ;o) but by fooling with polkit-gnome-authorization I finally got it working again. In polkit-gnome-authorization I navigated to org.freedesktop.hal.storage and changed the setting for 'mount filesystems from internal drives' so that anyone using the active console has permission (same as for mounting removable drives). One thing that seems very strange is that I did all this as a user, not as root, and I had to authenticate with my user's password, not root's. I'm in the wheel group -- maybe that makes a difference? All very confusing when first starting out!
Lots of things in policykit are permitted to "administrator" rather than to "root". "Administrator" means wheel, typically. I believe there's a compile-time option to change that. Changing policy is one of the things that's permitted to "administrator". However, fixed_storage is also permitted to "administrator" and it did prompt you for your password, so I'm not sure why that didn't properly authenticate. Unfortunately, if you fixed your issue, we probably can't reproduce and fix it. If anyone hits this again, and is willing to help me reproduce and fix, please re-open.
I can reproduce the authentication failure every time if I set the policy to require it -- so that actually is a bug, I guess? Same for removable disks if I set the policy to require authentication. I'm asked for my password and when I give it absolutely nothing happens. I ran strace when I used gnome-mount as root (which worked) and compared it to the strace I ran as a user (which failed) and I can't see much difference, though I know there must be a difference. When I give my password polkit-grant-helper logs a message that it granted me permission, so the mount failure occurs downstream from there. Can you suggest any other helpful diagnostics?
I had the same similar problem. It turned out that it was due to hal trying to mount my ntfs drive with options not specified in the hal policy regarding ntfs-3g, so basically you need not only the permission to mount the drive but also to pass it extra options (wasn't able to pinpoint exactly which option hal policykit chokes on). So you need to add the folowing permissions for your user. <match action="hal-storage-mount-fixed-extra-options"> <!-- for internal devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> <match action="hal-storage-mount-removable-extra-options"> <!-- for external devices mounted with extra options like a wished mount point --> <return result="yes" /> </match> I'd like to ask the devs to contemplate on the issue of either adding this to default policies or at least to document it somewhere. Therefore reopening the bug. References: http://bbs.archlinux.org/viewtopic.php?id=65070 http://bbs.archlinux.org/viewtopic.php?pid=496619
I seem to be suffering from the same issue - the behaviour seems to be that the first time I run gnome-mount for a particular device, I get an authorisation pop-up from (I assume) policykit-gnome, enter my password, and nothing happens. Second and subsequent times, I get no pop-up, but still the device is not mounted. gnome-mount is proving awkward to debug, partly because it seems to be forking, but I have seen some interesting output from "strace -f -v -e write=1,2,4 -e read=4 gnome-mount -b -v -h <HAL UDI of device to be mounted>". In particular: ** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_782CBBC32CBB7B28 org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, result) "hal.storage.mount-fixed" is the action corresponding to "Mount filesystems from internal drives" in the polkit-gnome-authorization UI; I can revoke my prior authorisation using this UI and do indeed get re-prompted for authentication next time I run gnome-mount, but it still ultimately fails. The PolicyKit "auth_admin_keep_always" error means "Access denied, but authentication of the caller as an administrative user will grant access any caller with the given uid in the future.". I read that as "prompt them for their password, then I'll do it" - but by that point in time, I have already authenticated myself! Something is clearly wrong, because I am being denied access to something I have already authenticated for, with an error that implies I need to authenticate myself. I can work around the issue by using polkit-gnome-authorization to give everyone implicit authorisation to mount fixed drives - removing implicit authorisation again brings back the old behaviour, so the bug is consistent. The fact that I can perform the action when I have implicit authorisation again points the finger at some sort of authorisation-checking bug. Make sense? ;)
