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 &
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.
Unexpected failures are always logged as WARNINGs. 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.
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.
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): firstname.lastname@example.org Type: GProxyVolume (GProxyVolumeMonitorGoa) $
When mounted, you would see something like:
$ gvfs-mount -l Drive(0): ST320LT007-9ZV142 Type: GProxyDrive (GProxyVolumeMonitorUDisks2) Volume(0): email@example.com Type: GProxyVolume (GProxyVolumeMonitorGoa) Mount(0): firstname.lastname@example.org -> davs://email@example.com/remote.php/webdav Type: GProxyShadowMount (GProxyVolumeMonitorGoa) Mount(1): rishi on cloud.gnome.org -> davs://firstname.lastname@example.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://email@example.com/ $ gvfs-mount -u google-drive://firstname.lastname@example.org/
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.