FS#32952 - [dbus] 1.6.8-3 update breaks gvfs support in Nautilus

Attached to Project: Arch Linux
Opened by Shawn Nock (nocko) - Monday, 03 December 2012, 20:08 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 13 December 2012, 15:59 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Jan de Groot (JGC)
Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description: After updating to 1.6.8-3, udisks2 support in Nautilus doesn't work. Addionally, browsing network directories via ssh:// URLs is also broken. Both are implemented via GVFS. Reverting to 1.6.8-1 restores functionality.

Please let me know what logs / information would prove useful to you.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Thursday, 13 December 2012, 15:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  in core
Comment by Jan de Groot (JGC) - Monday, 03 December 2012, 22:10 GMT
How do you start GNOME?
Comment by Shawn Nock (nocko) - Monday, 03 December 2012, 23:11 GMT
gdm via systemd. I run xmonad and load several useful gnomish services using the following script run by the gdm xsession file:

#!/bin/bash

export DE='gnome'
export VDPAU_DRIVER=r600

trayer --edge top --align right --SetDockType true --SetPartialStrut true --width 5 --height 12 --transparent true --tint 0x000000 &
/usr/lib/gnome-settings-daemon/gnome-settings-daemon &
gnome-screensaver &
gtk-redshift -l38.89:-77.03 -t6000:3700 &
if [ -x /usr/bin/gnome-power-manager ]; then
sleep 1
gnome-power-manager &
fi
if [ -x /usr/bin/nm-applet ]; then
nm-applet --sm-disable &
fi

if [ -e $HOME/.xmodmap ]; then
xmodmap $HOME/.xmodmap
fi

unclutter &
/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &

eval $(gnome-keyring-daemon)
export GNOME_KEYRING_CONTROL SSH_AUTH_SOCK GPG_AGENT_INFO GNOME_KEYRING_PID
exec xmonad
Comment by Shawn Nock (nocko) - Monday, 03 December 2012, 23:39 GMT
Additional data point: If I start Nautilus under the default Gnome session (gnome-shell with dbus 1.8.6-3) it functions correctly.

Any idea why there would be a regression for other configurations? There's nothing obvious in the logs for dbus or nautilus.
Comment by Tom Gundersen (tomegun) - Monday, 03 December 2012, 23:54 GMT
i added a patch, but i seriously doubt that it is the problem.

could you have a look in "journalctl -b" to see if there are any relevant messages? also have a look in ~/.xsession-errors, and try starting the broken apps from a terminal to see if they spit out anything to the console.
Comment by Shawn Nock (nocko) - Tuesday, 04 December 2012, 00:43 GMT
Filtered journalctl output is attached. No .xsession-errors file is generated.

Nautilus produces no CLI output at startup and nothing during the broken operations. It isn't clear from the nautilus man page how one could output debugging or verbose information.
   messages (20.1 KiB)
Comment by Peter Wu (Lekensteyn) - Tuesday, 04 December 2012, 09:25 GMT
I see starting these messages after upgrading to dbus 1.6.8-3:
dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activated service 'org.freedesktop.nm_dispatcher' failed: The permission of the setuid helpe
r is not correct
dbus[389]: [system] Activated service 'org.freedesktop.nm_dispatcher' failed: The permission of the setuid helper is not correct

I have not experienced issues though (KDE).
Comment by Peter Wu (Lekensteyn) - Tuesday, 04 December 2012, 10:46 GMT
Observation:
dbus-daemon is not running as root.

/usr/share/dbus-1/system-services/org.freedesktop.nm_dispatcher.service wants to run as root with User=root.

The permission error message is DBUS_ERROR_SPAWN_PERMISSIONS_INVALID which is set in check_permissions at bus/activation-helper.c:167 (called from check_dbus_user which is called from run_launch_helper)
Three cases need to be passed before the check returns success:
- The specified DBus user needs to be valid. dbus is valid: OK
- Real user ID of process should equal the dbus user: `ps u -p 389` shows dbus: OK
- Effective user ID should be root: presumably OK too for /usr/lib/dbus-1.0/dbus-daemon-launch-helper?

Could it have anything to do with systemd-user-session.patch?

Comment by Tom Gundersen (tomegun) - Tuesday, 04 December 2012, 12:36 GMT Comment by Tom Gundersen (tomegun) - Tuesday, 04 December 2012, 14:10 GMT
Please test -5 in testing. Should work now.
Comment by Peter Wu (Lekensteyn) - Tuesday, 04 December 2012, 15:54 GMT
dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
dbus[389]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

-5 works for me.
Comment by Shawn Nock (nocko) - Tuesday, 04 December 2012, 16:28 GMT
GVFS plugin regression (smb, ssh, udisks2) still present in -5 in my configuration.
Comment by Tom Gundersen (tomegun) - Tuesday, 04 December 2012, 23:04 GMT
@nocko: if you add 'dbus-launch --sh-syntax --exit-with-session' to your scritp, does that make everything work as before?
Comment by Shawn Nock (nocko) - Tuesday, 04 December 2012, 23:45 GMT
eval $(dbus-launch --sh-syntax --exit-with-session) added to my xsession script fixes the problems.

Thanks for your help!
Comment by Ng Oon-Ee (ngoonee) - Tuesday, 11 December 2012, 01:42 GMT
  • Field changed: Percent Complete (100% → 0%)
Tom, just a quick question whether the solution here is a (necessary?) hack or something we should have all the time from here on.
Comment by Tom Gundersen (tomegun) - Tuesday, 11 December 2012, 01:44 GMT
@ngoonee: the most recent version of dbus reinstated the old behaviour (by adding back /etc/X11/xinitrc.d/30-dbus), so the workaround shown here is not necessary. Maybe we will revisit this in the future (as the xinitrc.d stuff is a bit weird imho), but for the time being this will continue working as before.

Loading...