GNOME Bugzilla – Bug 769575
Could not mount after unmounting
Last modified: 2017-04-09 11:20:59 UTC
Created attachment 332822 [details] Screenshot I got this weird error message in the screenshot after trying to mount Google Drive on nautilus. Not entirely sure if I can reproduce.
gnome-online-accounts is not directly involved in this case. Let's start with nautilus and see where it leads to.
oops, that makes sense, still hitting the issue, any idea where to start debugging?
Created attachment 332919 [details] Evo failing to sync with GOA/Google calendars Quite frankly, I'm starting to believe this is a GOA thing: No app can access any sort of Google data as of now, this is evolution failing to access my gmail and rh calendars, and I'm having similar issues with Documents and Calendar.
(In reply to Alberto Ruiz from comment #3) > Created attachment 332919 [details] > Evo failing to sync with GOA/Google calendars > > Quite frankly, I'm starting to believe this is a GOA thing: That is fine, but let's stick to facts. You can use d-feet to poke at the various D-Bus objects on the org.gnome.OnlineAccounts service. Most interesting would be the org.gnome.OnlineAccounts.Account:EnsureCredentials method and the org.gnome.OnlineAccounts.OAuth2Based:GetAccessToken method. If those work fine and the goa-daemon is not crashing then it is probably not a GOA issue. > No app can access any sort of Google data as of now, this is evolution > failing to access my gmail and rh calendars, and I'm having similar issues > with Documents and Calendar. That doesn't necessarily mean what you think it means. All the protocols and application specific logic come from the applications. That means that there is a lot of things that can go wrong. Does your non-Red Hat Google account work?
(In reply to Alberto Ruiz from comment #2) > oops, that makes sense, > > still hitting the issue, any idea where to start debugging? Did you check journalctl? Can you reproduce it with another network mount in Nautilus? Maybe a non-RH Google account, or an ownCloud account? Given that it could be anywhere between nautilus, the gvfs volume monitor, the gvfs backend and gnome-online-accounts, it is hard to say ... To look at the gvfs backend, kill the nautilus process (ensure that it is really gone using ps), and then re-run gvfsd as: $ GVFS_DEBUG=1 /usr/libexec/gvfsd -r Then run nautilus and try to reproduce the failure and see what the logs say. Other than that, I'd grep for the error string and start reading the code to understand what is causing it.
(In reply to Debarshi Ray from comment #4) > (In reply to Alberto Ruiz from comment #3) > > Created attachment 332919 [details] > > Evo failing to sync with GOA/Google calendars > > > > Quite frankly, I'm starting to believe this is a GOA thing: > > That is fine, but let's stick to facts. > > You can use d-feet to poke at the various D-Bus objects on the > org.gnome.OnlineAccounts service. Most interesting would be the > org.gnome.OnlineAccounts.Account:EnsureCredentials method and the > org.gnome.OnlineAccounts.OAuth2Based:GetAccessToken method. If those work > fine and the goa-daemon is not crashing then it is probably not a GOA issue. Ensure credentials basically timesout: 'g-io-error-quark: Timeout was reached (24)' same thing using gdbus: [1000][aruiz@raynor ~]$ gdbus call --session --dest org.gnome.OnlineAccounts --object-path /org/gnome/OnlineAccounts/Accounts/account_1470650591_0 --method org.gnome.OnlineAccounts.Account.EnsureCredentials Error: Timeout was reached However, GetAccessToken worked fine returning a token string and an int tuple > That doesn't necessarily mean what you think it means. All the protocols and > application specific logic come from the applications. That means that there > is a lot of things that can go wrong. Ah! gotcha! > Does your non-Red Hat Google account work? Nope, gmail doesn't work either.
(In reply to Debarshi Ray from comment #5) > (In reply to Alberto Ruiz from comment #2) > > oops, that makes sense, > > > > still hitting the issue, any idea where to start debugging? > > Did you check journalctl? Can you reproduce it with another network mount in > Nautilus? Maybe a non-RH Google account, or an ownCloud account? I just tried with a Flickr account and the dbus method gives me the timeout again > Given that it could be anywhere between nautilus, the gvfs volume monitor, > the gvfs backend and gnome-online-accounts, it is hard to say ... > > To look at the gvfs backend, kill the nautilus process (ensure that it is > really gone using ps), and then re-run gvfsd as: > $ GVFS_DEBUG=1 /usr/libexec/gvfsd -r Nothing, after a few seconds I get the "Timeout was reached" error, so no output other than this at startup: [1006][aruiz@raynor ~]$ GVFS_DEBUG=1 /usr/libexec/gvfsd -r Added new job source 0x56479fce7890 (GVfsBackendTrash) Queued new job 0x56479fce8020 (GVfsJobMount) send_reply(0x56479fce8020), failed=0 () backend_dbus_handler org.gtk.vfs.Mount:CreateFileMonitor Queued new job 0x56479fce8380 (GVfsJobCreateMonitor) send_reply(0x56479fce8380), failed=0 () backend_dbus_handler org.gtk.vfs.Mount:CreateFileMonitor Queued new job 0x56479fce8380 (GVfsJobCreateMonitor) send_reply(0x56479fce8380), failed=0 () backend_dbus_handler org.gtk.vfs.Mount:Enumerate Queued new job 0x56479fce6250 (GVfsJobEnumerate) send_reply(0x56479fce6250), failed=0 () backend_dbus_handler org.gtk.vfs.Mount:Enumerate Queued new job 0x56479fce63b0 (GVfsJobEnumerate) send_reply(0x56479fce63b0), failed=0 () > > Then run nautilus and try to reproduce the failure and see what the logs say. > > Other than that, I'd grep for the error string and start reading the code to > understand what is causing it.
The timeouts are very suspicious. Unless the D-Bus service (ie. the likes of goa-daemon) are crashing, it makes me wonder whether D-Bus itself is borked. Given that this is Fedora 24, I am thinking if this is 'the' fall out from systemd --user driven D-Bus sessions. On Fedora 24, D-Bus services running in the user session are not getting cleaned up when the final user session goes away. To check for systemd --user breakage, see if your problem goes away on reboot, and reappears if you log out/in (without a reboot).
So I've tried what you told me and after reboot everything went fine, then logged out and in again and now it throws me an "Invalidad credentials" error, so it doesn't look like that was the issue, and of course given that I rebooted I can't reproduce the previous problem any more... Will get back to you if I get the previous error again.
(In reply to Alberto Ruiz from comment #9) > So I've tried what you told me and after reboot everything went fine, then > logged out and in again and now it throws me an "Invalidad credentials" > error, so it doesn't look like that was the issue, and of course given that > I rebooted I can't reproduce the previous problem any more... The "invalid credentials" thing looks like the systemd --user related breakage. One theory is that gnome-keyring is still tied to a single session (because it is started by PAM), while goa-daemon is tied to the user bus. When you restart the session, somehow goa-daemon (which survived the log out) can no longer connect to gnome-keyring. Not sure though, I need to dig a bit more. By the way, I started a page on how to debug common gnome-online-accounts problems: https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Debugging It had been on my TODO for a while, and hopefully, as it matures, it will help with the debugging.
Let's run with systemd --user assumption. *** This bug has been marked as a duplicate of bug 764029 ***