Restarting the daemon(s)

GNOME Online Accounts contains a D-Bus service and comes with two D-Bus daemons — goa-daemon and goa-identity-service. goa-daemon offers the application-facing interfaces, while goa-identity-service is a private daemon used by gnome-online-accounts itself to handle Kerberos credentials. Strictly speaking, daemons from different builds or versions should not be run together. They should always have the same version or be artifacts of the same build.

The easiest way to restart goa-daemon and goa-identity-service is to restart the GNOME session by logging out and then logging back in. On development systems the D-Bus session daemon might not know about the prefix in which you have installed gnome-online-accounts. In that case, you can restart the daemons manually:

$ /path/to/prefix/libexec/goa-identity-service &
$ /path/to/prefix/libexec/goa-daemon --replace &

Getting logs

Ensure that the G_MESSAGES_DEBUG environment variable is defined, and restart the daemons if needed (see above). It will make gnome-control-center, goa-daemon and goa-identity-service show some extra debug messages.

Run-time failures are always logged as WARNINGs and unexpected programming errors are logged as CRITICALs. Check your operating system's logging facilities (eg., journalctl) to find them.

If you are having problems while adding an account or updating the credentials, then the gnome-control-center logs are the most relevant. Otherwise, if it is some background failure, then look at the daemons.

Checking the D-Bus interface

Since gnome-online-accounts offers a D-Bus interface, it is useful to see whether the methods are working as expected. Fortunately, the D-Bus interface is not very big, so we don't run the risk of getting lost in the ocean.

The daemon runs as org.gnome.OnlineAccounts on the user or session bus. Each account is represented by a separate object under the /org/gnome/OnlineAccount/Accounts/ path and implements the org.gnome.OnlineAccounts.Account interface. Various properties on this interface will help you identify your accounts.

Credentials not working

Credentials like OAuth2 access tokens and passwords are stored in gnome-keyring. Therefore, if you are getting errors about missing or invalid credentials, check if your gnome-keyring is working properly. Your logs (see above) might already have something suspicious about it.

Use seahorse to look at the contents of your keyring. Searching for goa will show those entries that are related to your online accounts. Try to see if you can find a valid entry for your account.

Call the EnsureCredentials D-Bus method (see above) against the object representing your account. Normally, it is supposed to return an integer. Check if it is throwing an exception.

Depending on whether the account uses passwords or OAuth2 tokens, you might want to look at the org.gnome.OnlineAccounts.PasswordBased or org.gnome.OnlineAccounts.OAuth2Based interfaces.

D-Bus Timeouts

None of the D-Bus calls are expected to time out. They are either expected to succeed and return a value, or fail and throw an exception. Therefore, a timeout is a symptom of a bigger problem. They can be caused by goa-daemon crashes or deadlocks. If it is not a crash, then it is worth taking a few backtraces of the running goa-daemon process and checking for deadlocks.

Empty dialog when adding an account in Settings

Try running gnome-control-center as:

$ WEBKIT_DISABLE_COMPOSITING_MODE=1 gnome-control-center

If that works, then it is a bug in your operating system's graphics stack. Here is some discussion on the matter. It usually happens on virtual machines running on Parallels and VirtualBox.

Integration with Evolution

You can look at the Evolution documentation on how to gather debug logs.

Integration with GtkFileChooser and Nautilus

Some online storage services are integrated with GtkFileChooser and Nautilus. If this is not working, check whether you have GVfs' GOA volume monitor. It is a D-Bus daemon that uses org.gtk.vfs.GoaVolumeMonitor as the service name and the binary is called gvfs-goa-volume-monitor. If the binary is present, then check if it is running (with user privilege).

Use gvfs-mount -l to get a list of the drives, volumes and mounts seen by GVfs. On a functional system with a single Nextcloud account and hard disk, you would see something like this if the storage is not mounted:

$ gvfs-mount -l
Drive(0): ST320LT007-9ZV142
  Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Volume(0): rishi@cloud.gnome.org
  Type: GProxyVolume (GProxyVolumeMonitorGoa)
$

When mounted, you would see something like:

$ gvfs-mount -l
Drive(0): ST320LT007-9ZV142
  Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
Volume(0): rishi@cloud.gnome.org
  Type: GProxyVolume (GProxyVolumeMonitorGoa)
  Mount(0): rishi@cloud.gnome.org -> davs://rishi@cloud.gnome.org/remote.php/webdav
    Type: GProxyShadowMount (GProxyVolumeMonitorGoa)
Mount(1): rishi on cloud.gnome.org -> davs://rishi@cloud.gnome.org/remote.php/webdav
  Type: GDaemonMount
$

The GVfs integration is hinged on the org.gnome.OnlineAccounts.Files interface. GVfs' GOA volume monitor exposes all account objects implementing this interface as GVolumes that appear in the above output. You can mount and unmount volumes from the GTK+ UI or with gvfs-mount:

$ gvfs-mount google-drive://debarshi.ray@gmail.com/
$ gvfs-mount -u google-drive://debarshi.ray@gmail.com/

Mounting and any subsequent operations on the GVolume are performed by the respective GVfs backends that implement the service-specific protocol. For example, gvfsd-dav handles Nextcloud and gvfsd-google handles Google Drive. To check the GVfs backends, ensure that they are running in debug mode before mounting the volumes. The easiest way to do that is:

$ G_MESSAGES_DEBUG=all GVFS_DEBUG=1 /usr/libexec/gvfsd -r -d

Specific backends might have their own mechanisms for enabling revealing further backend-specific details. For example, GVFS_HTTP_DEBUG and LIBGDATA_DEBUG for the Nextcloud and Google Drive backends respectively.

For further details, you can look at the GVfs documentation.