GNOME Bugzilla – Bug 756420
Error mounting location: volume doesn't implement mount
Last modified: 2015-10-26 10:13:04 UTC
I added a google account using gnome-online-accounts. gvfs-mount -l shows Volume(0): hussam********@gmail.com Type: GProxyVolume (GProxyVolumeMonitorGoa) mounting the device however says: Error mounting location: volume doesn't implement mount
Do not forget to specify "google-drive" scheme: gvfs-mount google-drive://hussam********@gmail.com It doesn't work without the scheme: gvfs-mount hussam********@gmail.com Error mounting location: volume doesn't implement mount But I wonder whether we might do it better and e.g. show the volume with scheme...
Hello, I was trying to mount through nautilus. I only ran `gvfs-mount -l` to check if everything is actually configured properly.
(In reply to Hussam Al-Tayeb from comment #0) > I added a google account using gnome-online-accounts. > > gvfs-mount -l shows > > Volume(0): hussam********@gmail.com > Type: GProxyVolume (GProxyVolumeMonitorGoa) > > mounting the device however says: > > Error mounting location: volume doesn't implement mount Hmm... g_vfs_goa_volume_mount in monitor/goa/goavolume.c implements the mount_fn method. I wonder if the GOA volume monitor is crashing. Hussam, did the gvfs-goa-volume-monitor process crash on your system? Before using nautilus, can you please either run /usr/libexec/gvfs-goa-volume-monitor in gdb or if it is already running then attach gdb to it and see if gvfs-goa-volume-monitor is getting called?
This may be a downstream archlinux package issue because it works with kdbus=1 but not without. I'll contact the package maintainer.
*** Bug 756614 has been marked as a duplicate of this bug. ***
Jan, I hope you don't mind that I cc'ed you here. This bug appears in the stock arch linux kernel but not in your kernel with kdbus activated.
Things that I learnt from amigadave on IRC today: This is not specific to the Google backend. It also happens with the WebDAV backend when trying to mount ownCloud accounts from GOA. This problem is also present on Fedora Rawhide (ie. F24) which has kdbus built into the kernel, but not on by default. Booting with "kdbus=1" also fixes the problem there.
Reassigning to the GOA volume monitor.
If it works with kdbus=1 but not kdbus=0, the issue could be an environment difference between systemd --user and dbus-daemon.
To clarify, gvfs added user session services in 1.26.1, which now cause dbus-daemon to defer to systemd for launching. So, in this case the services are not affected by environment pushed to dbus-daemon via UpdateActivationEnvironment. However, in the kdbus case it is systemd which reacts to UpdateActivationEnvironment, and there's no difference anymore.
*** Bug 756629 has been marked as a duplicate of this bug. ***
Bug 756629 says that it works when opening the location from "Other Locations".
"Open in New Tab" or "Open in New Window" works from "Other Locations". "Left Click" still produces same error. Also once mounted drive opens fine from sidebar.
I'm having the same problem with owncloud drives. I'm using arch and nemo as my file manager so I don't have Other Locations to try this. And I'm also having issues opening files if I mount a path via sftp - the drive mounts but keepass says it can't read from the path but I can copy the files with nemo. This was working in 1.24 and once I've downgraded all gvfs packages it's again working.
Seems to be an environment problem indeed - with a userspace bus pam_systemd doesn't set DBUS_SESSION_BUS_ADDRESS for the systemd --user instance (from the systemd-user PAM stack).
Upstream bug: https://github.com/systemd/systemd/issues/1600
(In reply to Jan Alexander Steffens (heftig) from comment #16) > Upstream bug: https://github.com/systemd/systemd/issues/1600 I also have another question related to dbus stuff. Is this normal? Both systemd-bus-proxyd and dbus-daemon are running on my user. ps -Af | grep dbus systemd+ 406 1 0 10:57 ? 00:00:00 /usr/lib/systemd/systemd-bus-proxyd --address=kernel:path=/sys/fs/kdbus/0-system/bus hussam 557 524 0 10:58 ? 00:00:00 /usr/lib/systemd/systemd-bus-proxyd --address=kernel:path=/sys/fs/kdbus/1000-user/bus hussam 569 563 0 10:58 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
at-spi-bus-launcher is spawning it according to pstree while my user systemd is starting systemd-bus-proxyd.
After some discussion on the systemd and dbus bug tracking systems, the conclusion was that this would make sense to fix in both dbus and gvfs. The background of the breakage is that a check for DBUS_SESSION_BUS_ADDRESS was added to gvfs in 2009 to solve Bug #526454, in which non-X11-session processes (for example a system service), or processes under su or similar inside an X11 session, could cause a dbus-daemon to be autolaunched via dbus-launch. If there was no X11 display to represent the lifetime of a session, the dbus-daemon would potentially run forever, causing a "leaked" process; additionally, other uses of D-Bus by the same uid would start more dbus-daemons. This becomes potentially problematic on systems with the "user bus" model introduced in dbus 1.10: libdbus, GDBus and sd-bus will now all try the per-uid socket XDG_RUNTIME_DIR/bus before attempting autolaunch, so if those are known to be the only implementations in use on a "legacy-free" system, setting DBUS_SESSION_BUS_ADDRESS is meant to be unnecessary. (I think part of the problem here may be that Arch Linux's packaging is trying to be more legacy-free than the projects that use D-Bus are really ready for.) To fix this from the dbus side, Jan has proposed a patch that will make the user bus socket define DBUS_SESSION_BUS_ADDRESS for systemd services, which is a pragmatic approach to this for the next few years. However, that ideally shouldn't be necessary: the major D-Bus implementations (libdbus, GDBus and sd-bus) will all try XDG_RUNTIME_DIR/bus if DBUS_SESSION_BUS_ADDRESS isn't set. One approach to fixing this in gvfs would be to duplicate more of the logic from GDBus: if DBUS_SESSION_BUS_ADDRESS isn't set, but XDG_RUNTIME_DIR/bus has the desired properties (exists, is a socket, and is owned by us), then we can use it. Another possible approach would be to remove the check altogether. The bad effects of autolaunching that existed in 2009 shouldn't happen now, because dbus-launch and libdbus were modified in 2011 to solve this more generally: dbus-launch will now refuse to autolaunch a dbus-daemon unless there is an X11 display that it can use to determine the session lifetime (a similar check for GDBus is Bug #723506).
(In reply to Jan Alexander Steffens (heftig) from comment #10) > To clarify, gvfs added user session services in 1.26.1, which now cause > dbus-daemon to defer to systemd for launching. So, in this case the services > are not affected by environment pushed to dbus-daemon via > UpdateActivationEnvironment. However, in the kdbus case it is systemd which > reacts to UpdateActivationEnvironment, and there's no difference anymore. If you have infrastructure in Arch to push environment variables into the activation environment, please consider using the new dbus-update-activation-environment tool, which was added to dbus at the same time as "systemd --user" integration. It can upload to both dbus-daemon and systemd. https://anonscm.debian.org/cgit/pkg-utopia/dbus.git/tree/debian/20dbus_xdg-runtime is how we run it in Debian's X11 session startup scripts (Xsession.d), with https://anonscm.debian.org/cgit/pkg-utopia/dbus.git/tree/debian/95dbus_update-activation-env additionally used for backwards compat with traditional uses of Xsession.d on systems that have the dbus-x11 package.
(In reply to Hussam Al-Tayeb from comment #17) > Is this normal? Both systemd-bus-proxyd and dbus-daemon are running on my > user. Yes, the session bus and the AT-SPI bus are different. Full details: https://bugzilla.gnome.org/show_bug.cgi?id=755637#c3
Created attachment 313951 [details] [review] Accept XDG_RUNTIME_DIR/bus as a valid D-Bus session/user bus These checks for DBUS_SESSION_BUS_ADDRESS were added to solve https://bugzilla.gnome.org/show_bug.cgi?id=526454, in which non-X11-session processes (for example a system service), or processes under su or similar inside an X11 session, could cause a dbus-daemon to be autolaunched via dbus-launch. If there was no X11 display to represent the lifetime of a session, the dbus-daemon would potentially run forever, causing a "leaked" process; additionally, other uses of D-Bus by the same uid would start more dbus-daemons. This becomes potentially problematic on systems with the "user bus" model introduced in dbus 1.10: libdbus, GDBus and sd-bus will now all try the per-uid socket XDG_RUNTIME_DIR/bus before attempting autolaunch, so if those are known to be the only implementations in use on a "legacy-free" system, setting DBUS_SESSION_BUS_ADDRESS is unnecessary. Check for that socket before giving up. XDG_RUNTIME_DIR/bus as implemented by dbus 1.10 with systemd avoids several of the down sides of autolaunching: it will never start more than one session bus per uid, and the socket and bus will automatically be cleaned up when the corresponding "systemd --user" exits. --- Potential patch
(In reply to Simon McVittie from comment #21) > (In reply to Hussam Al-Tayeb from comment #17) > > Is this normal? Both systemd-bus-proxyd and dbus-daemon are running on my > > user. > > Yes, the session bus and the AT-SPI bus are different. Full details: > https://bugzilla.gnome.org/show_bug.cgi?id=755637#c3 Ah ok. Thank you for the explanation.
Review of attachment 313951 [details] [review]: This makes sense to me.
Comment on attachment 313951 [details] [review] Accept XDG_RUNTIME_DIR/bus as a valid D-Bus session/user bus commit ac80e77f6e45a3b688238e1fbf5b8baba98b58b4
Thanks!