cannot mount usb volumes: "Not authorized", after upgrade to Karmic

Bug #478274 reported by David Decotigny on 2009-11-08
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Fix Released
consolekit (Ubuntu)

Bug Description

Binary package hint: yelp

My machine (amd64) was running fine under jaunty (amd64) until yesterday, when I upgraded to Karmic. Things seem to run well, except for (at least) a devkit/policykit problem.

When I plug a USB memory stick, a window shows up telling me that the volume cannot be mounted because I'm "Not authorized". This stick could be mounted OK on the jaunty 64 before, and can be mounted OK on another machine (amd64) on which I installed karmic from scratch yesterday. So I'd say it's an upgrade problem. But I cannot manage to determine where the permissions are managed.

I tried "devkit-disks --mount ..." by hand and, effectively, it tells me:
shell>devkit-disks --mount /dev/sdc1
Mount failed: Not Authorized

I don't see any big difference with my working other karmic machine. In particular, I belong to the same /etc/group groups.

However, when trying:
shell> polkit-auth --show-obtainable
on the failing machine, the output is empty.
If I run the same on the working karmic, I get 4 lines:
Comparing the strace outputs from both machines didn't show me any conclusive differences.

Another problem which might (not ?) be related: when I try "users-admin", the small key icon at the bottom tells me that I am "Not authorized to make changes". It happens that this is working as expected on the other karmic64 machine.

I also noticed another problem, which might (not ?) be related: when I try to suspend the machine (user menu / suspend), all it does is fire up the screen saver. Likewise, when trying "restart" or "shutdown", all it does is log me out and bring me to the gdm screen. I suspect another authorization problem which forbids me to perform system-wide actions. It happens that all this is working as expected on the other karmic64 machine.

ProblemType: Bug
Architecture: amd64
Date: Sun Nov 8 12:34:14 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/yelp
NonfreeKernelModules: nvidia
Package: yelp 2.28.0-0ubuntu2
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: yelp
Uname: Linux 2.6.31-14-generic x86_64
 (gnome-settings-daemon:2620): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:2620): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2705): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2700): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:2699): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window

Well, I used 'yelp' to file this bug report, so this bug report appears related to yelp. Of course it doesn't have anything to do with yelp. IMHO, it's probably more related to devkit pour policykit.

mark it related to policykit

affects: yelp (Ubuntu) → policykit (Ubuntu)
summary: - cannot mount usb volumes: "Not authorized"
+ cannot mount usb volumes: "Not authorized", after upgrade to Karmic
Chris Coulson (chrisccoulson) wrote :

Thank you for your bug report. Please post the output of "ck-list-sessions" from the session that you're having issues with.

This is most likely a local config issue rather than a bug. All the symptoms described point to you not being on the local active console, and therefore, Policykit is actually behaving as expected.

affects: policykit (Ubuntu) → policykit-1 (Ubuntu)
Changed in policykit-1 (Ubuntu):
importance: Undecided → Low
status: New → Incomplete

Thank you for your support. The following is the output from ck-list-sessions:
 unix-user = '1000'
 realname = 'david'
 seat = 'Seat4'
 session-type = ''
 active = FALSE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-12T08:31:07.329854Z'
 login-session-id = '4294967295'
The 'tty7' is in accordance with the output from who, w, etc.
Since I filed the bug report, I rebooted several times and I still do have the same problems.

Some further information coming from the beginning of my ~/.xsession-errors:
(polkit-gnome-authentication-agent-1:2658): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
(polkit-gnome-authentication-agent-1:2658): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

Chris Coulson (chrisccoulson) wrote :

You aren't on the active console, so policykit is actually doing the correct thing here. How are you logging in?

Well, I just chose my login name from the gdm login screen, typed my password and that's it. I'm physically on the machine. How is that 'active' flag determined ?

If it can help, here is what /var/log/ConsoleKit/history tells me since I last rebooted:
1258028674.109 type=SEAT_ADDED : seat-id='Seat2' seat-kind=0
1258028721.681 type=SEAT_ADDED : seat-id='Seat3' seat-kind=1
1258028721.931 type=SEAT_SESSION_ADDED : seat-id='Seat3' session-id='Session1' session-type='LoginWindow' session-x11-display=':0' session-x11-display-device='/dev/tty7' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=105 session-creation-time='2009-11-12T12:25:21.681323Z'
1258028920.862 type=SEAT_SESSION_REMOVED : seat-id='Seat3' session-id='Session1' session-type='LoginWindow' session-x11-display=':0' session-x11-display-device='/dev/tty7' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=105 session-creation-time='2009-11-12T12:25:21.681323Z'
1258028920.862 type=SEAT_REMOVED : seat-id='Seat3' seat-kind=1
1258028920.964 type=SEAT_ADDED : seat-id='Seat4' seat-kind=1
1258028920.986 type=SEAT_SESSION_ADDED : seat-id='Seat4' session-id='Session2' session-type='' session-x11-display=':0' session-x11-display-device='/dev/tty7' session-display-device='' session-remote-host-name='' session-is-local=TRUE session-unix-user=1000 session-creation-time='2009-11-12T12:28:40.964345Z'

Note: output from id gdm = uid=105(gdm) gid=113(gdm) groups=113(gdm)

And ps uaxw | grep gdm:
root 1462 0.0 0.1 74936 3752 ? Ss 13:24 0:00 gdm-binary
root 1508 0.0 0.1 76864 3932 ? S 13:24 0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
root 1509 2.1 3.9 180276 122132 tty7 Rs+ 13:24 2:05 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-4Q2YHk/database -nolisten tcp vt7
gdm 1925 0.0 0.0 26156 784 ? S 13:25 0:00 /usr/bin/dbus-launch --exit-with-session
root 2513 0.0 0.1 89288 3388 ? S 13:25 0:00 /usr/lib/gdm/gdm-session-worker

Just FYI... I tried to force /usr/bin/ck-launch-session to run in /etc/X11/Xsession.d/90consolekit because it was not enabled at STARTUP as XDG_SESSION_COOKIE is defined. This doesn't make things better: it just created another parallel inactive session. Both sessions were still marked "active = FALSE".

Why on earth is this session marked not active ? Should I force the running session to be marked "active" using dbus ?

Well, the "dbus" trick didn't make it either.
I tried with the following script:
import dbus, traceback

bus = dbus.SystemBus()
mgr = bus.get_object('org.freedesktop.ConsoleKit',
for seat_name in mgr.GetSeats():
    seat = bus.get_object('org.freedesktop.ConsoleKit',
    for session_name in seat.GetSessions():
        session = bus.get_object('org.freedesktop.ConsoleKit',
        if session.is_local:
            print "### Session '%s':" % (session.GetId(),)

and all tells me is (ran with sudo):
### Session '/org/freedesktop/ConsoleKit/Session2':
Traceback (most recent call last):
  File "./", line 15, in <module>
  File "/usr/lib/pymodules/python2.6/dbus/", line 140, in __call__
  File "/usr/lib/pymodules/python2.6/dbus/", line 620, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.GLib.UnmappedError.CkSeatError.Code0: Activation is not supported for this kind of seat

What is the "kind" of seat am I sitting on ?!???

Digging somewhat more, it appears that none of the seats allow to activate sessions (CanActivateSession) except one. The strange thing is that that one seat doesn't contain any session. The other strange thing is that none of the seats are associated with any device (GetDevices).

Anyway, here is what a slightly more complete version of the script above tells me in a graphical session:
# Seat '/org/freedesktop/ConsoleKit/Seat2':
  can_activate: 1
  devices: dbus.Array([], signature=dbus.Signature('(ss)'))
  active_session: None
# Seat '/org/freedesktop/ConsoleKit/Seat14':
  can_activate: 0
  devices: dbus.Array([], signature=dbus.Signature('(ss)'))
  active_session: None
  # Session '/org/freedesktop/ConsoleKit/Session12':
Traceback (most recent call last):
  File "./", line 25, in <module>
  File "/usr/lib/pymodules/python2.6/dbus/", line 140, in __call__
  File "/usr/lib/pymodules/python2.6/dbus/", line 620, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.GLib.UnmappedError.CkSeatError.Code0: Activation is not supported for this kind of seat

One last strange thing... When I log out from my graphical session and type ck-list-sessions in a console terminal, I can notice that gdm has a session of its own, but that session is not active either and, in fact, none of the sessions is marked as 'active', even my console session:
 unix-user = '1000'
 realname = 'david'
 seat = 'Seat18'
 session-type = ''
 active = FALSE
 x11-display = ''
 x11-display-device = ''
 display-device = '/dev/tty1'
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-14T15:38:16.887770Z'
 login-session-id = '4294967295'
 unix-user = '105'
 realname = 'Gnome Display Manager'
 seat = 'Seat15'
 session-type = 'LoginWindow'
 active = FALSE
 x11-display = ':0'
 x11-display-device = '/dev/tty7'
 display-device = ''
 remote-host-name = ''
 is-local = TRUE
 on-since = '2009-11-14T15:37:34.131625Z'
 login-session-id = '4294967295'
Would anybody have any clue for that ?

Some info relevant to my problem: see issue #363568

I looked at the consolekit sources and it appears that the only flags that are set are:

        res = ck_connector_open_session_with_parameters (ckc,
                                                         "unix-user", &uid,
                                                         "display-device", &display_device,
                                                         "x11-display", &x11_display,
                                                         "x11-display-device", &x11_display_device,
                                                         "remote-host-name", &remote_host_name,
                                                         "is-local", &is_local,

The thing I still don't understand is that the same package seems to work on another machine (same arch, same distrib, etc.) I installed from scratch. On that machine, a user logged in at the console for example, has its active flag set to TRUE.

This means that something is expected to set the active flag, which is not pam_ck_connector. But what is it ?

Anyway, this seems to mean that there must be some garbage left behind by the previously installed jaunty or even intrepid, that prevents the "active" flag from being set correctly.

Bug seems to lie somewhere between consolekit and policykit. It is apparently not related to gdm (happens with console logins as well).

Changed in policykit-1 (Ubuntu):
status: Incomplete → New
Chris Coulson (chrisccoulson) wrote :

The fact that Consolekit is adding your sessions to dynamic seats seems to be wrong (they should all be on Seat1). The only thing I can think of that would cause this would be /etc/ConsoleKit/seats.d/ being missing. Could you please post the contents of that file

Changed in policykit-1 (Ubuntu):
status: New → Incomplete

Thanks for the feedback. Here is the contents of /etc/ConsoleKit/seats.d/
[Seat Entry]
Name=Primary seat
Is there anything wrong with it ?

Chris Coulson (chrisccoulson) wrote :

That looks normal. Could you please edit the "Exec=" line in /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service to read "/usr/sbin/console-kit-daemon --debug", then restart, log in and attach your /var/log/syslog?


Bingo ! Thank you very much Chris ! You were right: it was a local configuration issue. But I'd say consolekit seems overly sensitive and I'm not sure its behavior is really legitimate.
Here is what /usr/sbin/console-kit-daemon --debug tells me (in /var/log/daemon.log):
Nov 15 10:50:07 xyz console-kit-daemon[940]: WARNING: Unable to load seats from file /etc/ConsoleKit/seats.d/.svn: Not a regular file
So, indeed, I started (shortly before the upgrade to karmic but I didn't notice that bug in jaunty) to have my /etc managed by subversion, and this caused console-kit to fall apart. By moving the .svn directory away, I confirm that the system now behaves as expected (gdm drums that I will promptly shut off, login melody that I will promptly turn off too, mount usb stick, system shutdown, etc.).
However, I am not sure that having console-kit-daemon half-fail (and "half" only) because it sees some directory where it expects only regular files, is a perfectly nice behavior. I'd rather it fails completely or simply ignores non-regular files.
Anyway, I should have noticed that problem before, as it has always been reported to daemon.log but I did not notice it (looking for the wrong log files and/or log message prefixes).
Thank you very much for your very valuable help !

affects: policykit-1 (Ubuntu) → consolekit (Ubuntu)
Changed in consolekit (Ubuntu):
status: Incomplete → Fix Released
Chris Coulson (chrisccoulson) wrote :

Thanks. I'll keep this open for now, as consolekit probably shouldn't fall apart when /etc is controlled under SVN.

Changed in consolekit (Ubuntu):
status: Fix Released → Confirmed

Reopening this issue. I am afraid there is a real problem here...

As I understand by looking at the code (mainly ck-manager.c:load_seats_from_dir()), the fact that there is an invalid regular file in /etc/ConsoleKit/seats.d/ has only the following impacts:
 - the first correct seat created will have id "Seat2" instead of "Seat1"
 - there is one more iteration in the while loop in ck-manager.c:load_seats_from_dir()
But I don't see anything else.

So how is it possible that we get:
   Matched x11-display-device /dev/tty7 to /org/freedesktop/ConsoleKit/Session1
when there is no .svn directory... and we don't get anything when there is a .svn dir ? Is it because there is an internal error that prevents Seat2 from being visible for the matching routines whereas Seat1 is visible ? Is there something hard-wired for "Seat1" (in config files or code) ? Is this a race condition because of the additional iteration in the while loop (highly improbable).

Besides, perhaps a suggestion (?): in ck_seat.c:ck_seat_new_from_file(), add calls g_key_file_free() where relevant ?

Changed in consolekit (Ubuntu):
status: Confirmed → In Progress

Chris: sorry, we changed the status in parellel with my former comment. Restoring to "Confirmed" as you set it.

Changed in consolekit (Ubuntu):
status: In Progress → Confirmed
Changed in consolekit (Ubuntu):
status: Confirmed → Triaged
Changed in consolekit:
status: Unknown → Confirmed

I can confirm SVN was causing this issue on my box. Only needed it for one thing so removed all traces of SVN from my machine using Synaptic and the issue went away. Using Karmic.

Brian Burch (brian-pingtoo) wrote :

I apologise for not opening a new bug, but I think my observations of a clean karmic install would be helpful because I had the same symptoms - both usb memory stick and greyed-out admin-users authenticate. Following this particular bug helped me because I found a different entry in /var/log/daemon.log:

gdm-binary: WARNING: Unable to load file '/etc/gdm/custom.conf': no such file or directory

Sure enough, the file hadn't been created during my (clean partition, remember?) installation. I found the default file on another karmic system that I'd recently upgraded from jaunty - the file contains a load of comments and 8 empty clauses. I copied this file to my defective system, rebooted and now everything runs fine!

Ciarán Mooney (ciaran-mooney) wrote :


I had the same problem. Brian Burch's suggestion worked. Just to confirm the "workaround".


mrg666 (drgungor) wrote :

I am running Ubuntu 9.10-x86 Karmic and all of the administrator options are disabled in the Gnome administration utilities (users and groups, time and date, etc.) with a gray button stating "Not authorized to make changes". I have edited the file as Chris suggested in post #17 and the only suspicious line in /var/log/syslog is the following.

console-kit-daemon [941]: DEBUG: Unable to stat: /dev/ssh: No such file or directory

I actually do not have any ssh* in /dev directory.

Brian Burch's suggestion is not working for me since I already have /etc/gdm/custom.conf

Created an attachment (id=32586)
Don't fail when reading and invalid seats file

When reading an invalid seats file, ck_seat_new_from_file() will return NULL.
In that case, check for NULL before using the seat variable in add_seat_for_file()

Great! Applied. Thanks.

*** Bug 25097 has been marked as a duplicate of this bug. ***

Changed in consolekit:
status: Confirmed → Invalid
Changed in consolekit:
status: Invalid → Unknown
Changed in consolekit:
status: Unknown → Fix Released
gglaser (g-glaser) wrote :

Brian, Ciaran,

It seems that I am having the same issue with not being able to access my USB peripherals or change the Users/Groups. I also do not have the file /etc/gdm/custom.conf. Unfortunately I don't have another install of Karmic to copy from. Can you tell me what was in this file that is needed. thanks!

Same issues as above. Unable to mount (NTFS, USB, etc) and unable to use Users/Groups. Have a file /etc/gdm/custom.conf

Session info:

        unix-user = '1000'
        realname = 'Gavin Carothers'
        seat = 'Seat1'
        session-type = ''
        active = FALSE
        x11-display = ':0'
        x11-display-device = '/dev/tty8'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2010-02-18T01:43:14.736153Z'
        login-session-id = '4294967295'

This is however the active session. Contents of /etc/gdm/custom.conf


Possibly related, issue came up after installing kubuntu-desktop but there were a number of other upgrades in the last two days as well.

Paul Gear (paulgear) wrote :

A couple of comments:
1. The behaviour is not consistent on different systems: this affects my wife's PC (and annoys her no end), but doesn't affect mine. Both are karmic, upgraded step by step from hardy, but mine is amd64 and hers is x86.
2. Surely this can't be low priority. If it stops a USB stick from being plugged in and working, it surely must be at least medium.
3. On my wife's system which doesn't work, manually calling gnome-mount and gnome-umount works fine.

JorgeHPM (jorgehpm-yahoo) wrote :

I also have the same problem, checked everything as stated here:
a) Don't have SVN and .svn folder
b) Have custom.conf as stated here
My box info (let me know if I have to add something)
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic
Linux 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686 GNU/Linux

Inserted an USB thumb drive and it appears as USB0, it states is unable to set permissions (but it can "read" as it shows the contents but to delete/copy/create folders the only way I had to do it is by "remounting" it as root.

Please advise

Bas Doodeman (bas-doodeman) wrote :

@Paul Gear & JorgeHPM

Could it be that you are seeing this bug instead (535521)?

Changed in consolekit:
importance: Unknown → Medium
Changed in consolekit:
importance: Medium → Unknown
Changed in consolekit:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.