GNOME CalDAV: Calendar Sync Setup
Getting CalDAV to sync reliably in GNOME involves two distinct layers that are easy to conflate: GNOME Online Accounts (GOA), which manages authentication and account metadata, and Evolution Data Server (EDS), which performs the actual CalDAV synchronisation in the background. Both must be configured and functioning correctly for GNOME Calendar to show remote events. This page covers the CalDAV configuration flow through GNOME Online Accounts, the correct URL format for different server types, how to verify that EDS is syncing, and the troubleshooting path when GNOME Calendar shows blank calendars or refuses to connect. These notes are based on observed behaviour with Nextcloud, Baikal, Radicale, and Fastmail CalDAV endpoints. This page is part of the technote section. For the technical context of how GNOME apps use web APIs and credentials, see GNOME Apps and Web APIs.
Architecture: GOA and Evolution Data Server
GNOME Online Accounts manages the account credentials and stores the CalDAV server URL. Evolution Data Server (evolution-data-server) is the background daemon that actually synchronises calendar data — it reads the account from GOA, connects to the CalDAV server, and populates a local calendar store. GNOME Calendar reads from this local store via EDS's D-Bus interface, not directly from the CalDAV server. This means GNOME Calendar sync frequency is controlled by EDS, not by GNOME Calendar's own settings.
The separation matters for troubleshooting: if GNOME Calendar shows no events, the problem might be at the GOA authentication layer, the EDS sync layer, or the display layer. Each has distinct failure signatures.
Adding a CalDAV account
CalDAV accounts for servers that are not first-party GNOME providers (Google, Microsoft, Nextcloud if using the specific Nextcloud provider) are added via Settings → Online Accounts → Other.
The "Other" CalDAV account type in GNOME Online Accounts requires a specific URL format to trigger automatic calendar discovery. Providing just the server base URL often works if the server implements CalDAV well-known URIs (/.well-known/caldav), which redirects to the correct principal URL. Providing the full principal URL directly is more reliable for servers that don't implement well-known URI redirection. Baikal and Radicale sometimes require the direct principal URL; Nextcloud's well-known URI implementation is generally reliable.
Common CalDAV URL formats to try:
# Nextcloud (well-known, usually works):
https://nextcloud.example.com
# Nextcloud (direct principal):
https://nextcloud.example.com/remote.php/dav/principals/users/username/
# Baikal:
https://baikal.example.com/dav.php/principals/username/
# Radicale:
https://radicale.example.com/username/
# Fastmail:
https://caldav.fastmail.com/dav/principals/user/user@example.com/
If the account addition dialog says "Cannot connect" or "Server not found," the URL is not resolving the CalDAV principal correctly. If it adds the account but shows no calendars, the URL resolved but calendar discovery failed — try the full calendar collection URL instead.
Verifying EDS sync
After adding the account, Evolution Data Server handles background sync. Verifying that EDS is active and has queued sync for your account:
# Verify EDS calendar service is running:
systemctl --user status evolution-calendar-factory
# List known calendar sources (should include your CalDAV account):
gsettings list-recursively org.gnome.Evolution | grep caldav
# Force an EDS data refresh:
evolution --force-shutdown
evolution-calendar-factory &
Evolution Data Server stores calendar data and account metadata in ~/.local/share/gnome-online-accounts/ and ~/.local/share/evolution/calendar/. If you've removed and re-added a CalDAV account multiple times during troubleshooting, stale EDS data directories can prevent clean re-sync. Removing the relevant subdirectory in ~/.local/share/evolution/calendar/ and restarting EDS forces a clean download from the CalDAV server.
Common failure modes
The most frequent CalDAV sync failure in GNOME is a TLS certificate validation error that is never surfaced to the user. If the CalDAV server uses a self-signed certificate or a certificate from a CA not in the system trust store, EDS silently fails to connect. GNOME Calendar shows the calendar (from cached data if any exists) but stops updating. The fix is to add the CA certificate to the system trust store (/usr/local/share/ca-certificates/ on Debian-based systems, then update-ca-certificates), not to mark the connection as insecure in EDS.
Authentication failures produce a different symptom: the Online Accounts panel shows a "Credentials Required" warning for the account. Clicking this prompts for password re-entry. This often happens after a password change on the remote server, a GOA session token expiry on Nextcloud, or after an OS upgrade that wipes the keyring.
# Kill and restart goa-daemon (handles credential refresh):
pkill goa-daemon
# It restarts automatically via D-Bus activation
# Restart EDS:
systemctl --user restart evolution-calendar-factory
systemctl --user restart evolution-source-registry
Sync frequency
EDS's default CalDAV refresh interval is not user-configurable through GNOME Calendar's UI. The interval varies between 5 minutes and 30 minutes depending on EDS version and account type.
Early GNOME 4x releases used a relatively infrequent default sync interval that caused GNOME Calendar to feel stale compared to mobile calendar clients. Later EDS versions reduced the default interval and added idle-triggered sync for accounts that support push or change notification (via calendar-auto-schedule or scheduling extensions). Nextcloud's CalDAV implementation does not provide push notifications, so GNOME Calendar on Nextcloud still syncs on a polling basis.
For near-real-time calendar updates, the practical workaround is using Evolution (the full application) instead of GNOME Calendar, as Evolution provides manual sync triggers and more visibility into sync status. GNOME Calendar is designed for calendar display, not for calendar management, and the sync layer is intentionally background and passive.
Practical assessment
CalDAV in GNOME works reliably once the initial URL and authentication are correctly configured, and once EDS has completed a full initial sync. The setup friction is front-loaded: the URL format sensitivity and the EDS-as-background-service architecture make initial troubleshooting non-obvious. After it's working, sync is robust across reboots, network changes, and account credential refreshes.