You are not logged in.

#1 2009-02-17 01:47:38

mikemrh9
Member
Registered: 2009-02-17
Posts: 16

Permissions problem with automounter [Solved]

Hi.

I'm running KDE 4.2 and am struggling to get automounting of USB sticks working properly.

I appear to have all of the relevant packages installed, as the icon appears in Dolphin when I plug the stick in, and everything works if I'm logged in as root.

However, as my user when I click on the volume in Dolphin, I get the message:

org.freedesktop.Hal.Device.PermissionDeniedByPolicy:
org.freedesktop.hal.storage.mount-removable no <--(action,result)

I have inserted the following into /etc/PolicyKit/PolicyKit.conf as per the WIKI at http://wiki.archlinux.org/index.php/HAL … utomounter :

<config version="0.1">
   <match user="$USER">
      <match action="org.freedesktop.hal.storage.*">
         <return result="yes"/>
      </match>
      <match action="hal-storage-mount-fixed-extra-options">
         <return result="yes" />
      </match>
      <match action="hal-storage-mount-removable-extra-options">
         <return result="yes" />
      </match>
   </match>
</config>

My user is a member of the optical and storage groups, and CDs and DVDs mount fine - it's just USB devices that are the issue!

I've had a look through /etc/dbus-1/system.conf and /etc/dbus-1/system.d/hal.conf, but didn't see anything that appeared to be related to removable media.

Any help would be much appreciated!

Mike.

Last edited by mikemrh9 (2009-02-25 21:01:13)

Offline

#2 2009-02-17 11:48:53

whompus
Member
From: Durham. UK
Registered: 2005-08-09
Posts: 256

Re: Permissions problem with automounter [Solved]

mikemrh9 wrote:

<match user="$USER">

Did you copy this exactly? if you don't know the $USER is you actual user name and needs changing accordingly.

Offline

#3 2009-02-17 12:46:10

mikemrh9
Member
Registered: 2009-02-17
Posts: 16

Re: Permissions problem with automounter [Solved]

That worked - thanks very much!

The problem is solved, but it's thrown up another question:

I was rather surprised as I was expecting $USER to be replaced by the username, as it's an environment variable.  Then I realised that /etc/PolicyKit/PolicyKit.conf is not a bash style config file.

Is it an XML file?  If so, is there any way to get whatever process is reading the XML file to process environment variables?

Offline

#4 2009-02-17 14:35:07

z0idberg
Member
Registered: 2006-06-27
Posts: 20

Re: Permissions problem with automounter [Solved]

I had the usual automount problem and fixed it according to the wiki. However, the wiki entry also says "This was taken from Gullible Jones' "So long, Arch" thread as a hotfix for exactly this type of breakage and is probably not the best fix (especially for machines with a large number of users), but it works."

So, is this just a workaround or is it an actual solution? Is there a more proper way to fix this issue?

Offline

#5 2009-02-17 15:34:32

whompus
Member
From: Durham. UK
Registered: 2005-08-09
Posts: 256

Re: Permissions problem with automounter [Solved]

I think this is a workaround, it is a xml file but I have no knowledge of xml so can only follow solutions posted by others.

Offline

#6 2009-02-17 17:17:53

mikemrh9
Member
Registered: 2009-02-17
Posts: 16

Re: Permissions problem with automounter [Solved]

So, is this just a workaround or is it an actual solution?

I have been doing a bit of digging, and it would appear that this is a bug/feature of the latest release of HAL.
There is a report of it which you can see if you go to the bugs page and search for hal automount.

There is a comment concerning this issue and your choice of login manager as follows:

The new version of hal only works with consolekit. If you don't happen to use kdm or gdm as login manager, you need to add pam_ck_session.so to the login pam module and launch your desktop with ck-launch-session.

This will affect me, as I use slim as my login manager.  However, I haven't updated my login pam module, so I can't report any success or otherwise with it.

Last edited by mikemrh9 (2009-02-17 17:18:41)

Offline

#7 2009-02-18 08:55:55

damoppi
Member
From: Germany
Registered: 2008-02-10
Posts: 18

Re: Permissions problem with automounter [Solved]

If you don't use any loginmanager, you only have to edit the .xinitrc.  The line that starts your WM has to be

exec ck-launch-session startxfce4 (or the WM of your choise)

This fixed the problem for me.

Offline

#8 2009-02-18 12:16:23

dobedo
Member
From: Belgium
Registered: 2008-10-04
Posts: 113

Re: Permissions problem with automounter [Solved]

There is something I don't understand.

I have no login manager. X is started as soon as I log in VC1 (using the .bash_profile).
I'm using openbox as WM.

I'm using automount too but had no problem at all related to the new version of HAL.
Yes, the upgrade has brought consolkit and policykit but I have not made any config change and all is working fine!

I have not done any change in .xinitrc i.e. I have no ck-launch-session before my openbox-session.
But consolekit seems to be started anyway as it appears in the list of processes (as console-kit-daemon).

Anyone understands that mystery i.e. without changing my config
1. why do I have no problem with automount ?
2. how is console-kit-daemon started ?

Offline

#9 2009-02-18 12:28:22

z0idberg
Member
Registered: 2006-06-27
Posts: 20

Re: Permissions problem with automounter [Solved]

damoppi wrote:

If you don't use any loginmanager, you only have to edit the .xinitrc.  The line that starts your WM has to be

exec ck-launch-session startxfce4 (or the WM of your choise)

This fixed the problem for me.

I tried that too, using KDE4, it fixed the problem with my USB drive, but not with my NTFS-partitions. If I remember correctly (:)), the previously mentioned workaround fixed both.

Anyway, even if this is a feature, it should probably be configured by default to work, at least for most people. Does anyone know if this will be fixed in future versions of whatever package it's related to? Is it something that should be fixed upstream?

Offline

Board footer

Powered by FluxBB