This started during the whole bug 343033 thing. I can not mound drives with nautilus or gvfs-mount. If I try, I get a "Unable to mount location - Not Authorized" message. However, using GDU succeeds. I've tried reinstalling shadow, polkit, and consolekit. Ive tried downgrading them. I've tried updating gvfs and GDU to unstable. I've also tried as a new user. Nothing so far seems to help. After some poking around online, I found a Mandriva bug on an upstream consolekit version ( https://qa.mandriva.com/show_bug.cgi?id=60627 ) which pointed me in the direction of strace. For some reason nautilus/gvfs is being associated with consolekit "Session1" which is the inactive tty login session. GDU is properly associated with "Session2" which is the active X session. I have no idea what's going on or what originally caused this. Reproducible: Always Steps to Reproduce:
Created attachment 252485 [details] GDU polkit strace output
Created attachment 252487 [details] Nautilus polkit strace output
Is gnome-extra/polkit-gnome installed?
And does running '/usr/libexec/polkit-gnome-authentication-agent-1' by hand help? Assuming autostart from polkit-gnome-authentication-agent-1.desktop didn't kick in for some reason.
Yes, I have polkit-gnome installed, and polkit-gnome-authentication-agent-1 is running. $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount --process $(pgrep nautilus) $ echo $? 0 $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount-system-internal --process $(pgrep nautilus) --allow-user-interaction polkit\56temporary_authorization_id=tmpauthz0 $ echo $? 0 $ killall polkit-gnome-authentication-agent-1 $ pkcheck --action-id org.freedesktop.udisks.filesystem-mount-system-internal --process $(pgrep nautilus) --allow-user-interaction polkit\56retains_authorization_after_challenge=1 Authorization requires authentication but no agent is available. $ echo $? 2 Killing polkit-gnome-authentication-agent-1 and manually running it has no affect.
Don't know then, only seen 'Not authorized.' when polkit-gnome is missing with gvfs. Unusure where to even begin without reproducing it first, sorry.
Ok, bit of an update: Per chance, I stumbled across an awesome little DBUS explorer called DFeet ( http://live.gnome.org/DFeet/ ). From nautilus.polkit.out: write(1, "** (process:3628): DEBUG: checking whether system-bus-name::1.16 is authorized for org.freedesktop.udisks.filesystem-mount\n", 123) = 123 system-bus 1.16 refers to /usr/libexec/gvfs-gdu-volume-monitor. Sure enough, all of the GVFS daemons have the XDG_SESSION_COOKIE of the inactive TTY1 consolekit session. If I restart gvfs-gdu-volume-monitor, it replaces the existing process, inherits the correct XDG_SESSION_COOKIE, and mounting works again. I'm guessing that this also goes back to the shadow update, with there now being 2 consolekit sessions, rather than 1. Though when I tried downgrading shadow it didn't help. But I may have missed something so I'll try that again. So, I guess the question now is what's actually spawning the GVFS daemons ans why are they receiving the old XDG_SESSION_COOKIE.
How are you starting Gnome? I remember you had some weird symlink in bug 343033, that's not the case now, is it?
Heh, that's an interesting question. I'm basically using gnome-light, but with xfce4-session and xfce4-panel instead of gnome-session and gnome-panel (thus avoiding a bunch of depreciated GNOME packages and upower) The link wasn't all that weird. Instead of using XSESSION="Xfce4" (which ultimately calls startxfce4) or startxfce4 (which just calls /etc/xdg/xfce4/xinitrc), I directly called /etc/xdg/xfce4/xinitrc. It was the xinitrc file that was broken, not my use of it. Regardless, my ~.xinitrc is now: #!/bin/sh command="xfce4-session" if [ -d /etc/X11/xinit/xinitrc.d ] ; then for f in /etc/X11/xinit/xinitrc.d/* ; do [ -x "$f" ] && . "$f" done unset f fi exec $command I've also tested it with command="startxfce4" and there was no difference.
uh... just use 'exec ck-launch-session gnome-session' or 'exec ck-launch-session startxfce4'
Just an idea in /etc/X11/xinit/xinitrc.d try moving 80-dbus *after* 90-consolekit, so to 95-dbus for instance then your .xinitrc might work, if that's the case, reopen the bug
Bug 329317 might have been fixed wrong...
Using "exec ck-launch-session startxfce4" worked, and updating to dbus-1.2.24-r2 also worked. So it looks like this can be properly resolved by stabilizing dbus-1.2.24-r1 or -r2.
(In reply to comment #13) > Using "exec ck-launch-session startxfce4" worked, and updating to > dbus-1.2.24-r2 also worked. > > So it looks like this can be properly resolved by stabilizing dbus-1.2.24-r1 or > -r2. > bug 343323
