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. 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.
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 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 ownCloud 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 $