CalDAV Login Fails: Password, URL, and Permission Checks

“Authentication failed” can point to a wrong address, an app password requirement, or a blocked account. Keep the exact error and change one setting at a time. Before removing any connection, preserve appointments that have not synced yet.

The source account

Open the provider's website and sign in normally. Find the calendar and one recent appointment.

If the website is unavailable or the account itself is locked, solve that with the provider first. If it works, you have established that the service and calendar exist, but not yet that an external app is using the right sign-in method.

For example, a website may use an interactive single sign-on flow while a CalDAV app uses a separately generated password. Use the credential required by the external app, even when browser sign-in succeeds.

Server address and username

Compare the app's address with the provider's documented CalDAV server and calendar URLs. A calendar webpage or ICS feed address is not the account endpoint.

Look for an extra space, a missing path segment (for example, /remote.php/dav on Nextcloud), or a username copied from a display name. Fastmail documents its server and required credentials in its connection guide.

If the app offers automatic discovery, use the provider's recommended option first. For manual setup, match the hostname and path fields to the provider's instructions.

Use the supported credential

Check whether the provider requires an app-specific or device-specific password. Give the credential a recognizable name, such as the app and device, so it can be revoked individually later.

With two-factor authentication enabled, Nextcloud clients need a device password instead of the ordinary account password. See its connected-device guide.

For iCloud, Apple documents app-specific passwords, including their revocation after a primary password change. Use the method the app supports. Avum's iCloud connection uses an app-specific password.

Do not turn off two-factor authentication just to make an older setup form accept your main password. Check for a supported app-password or provider-login route instead.

Separate connection problems from calendar permissions

If the account connects and lists calendars but saving fails, authentication may be fine. Identify the calendar's owner and whether your access permits editing.

Try a test in a calendar you own, without guests. If that works but a shared calendar rejects the same operation, ask the owner to review sharing permissions. A read-only source can still be useful for viewing or authorized copies; it is not a writable destination. Review the calendar's read-only or write permissions.

If the account connects only on home Wi-Fi, check whether the self-hosted server is reachable from outside the network. A cloud service cannot use the phone's local network connection.

Check the receiving app or service

Open the app's connection status and look for its latest successful update. An old cached appointment can remain on screen after access stops.

In Avum, restore access to the CalDAV source, then review the source and destination selected in the Sync Rule. A source connection with expired access can leave the destination unchanged even when the receiving account is healthy. Avoid creating a second rule as a substitute for fixing the first connection.

After updating credentials, create a source test event, wait for it to appear in the destination, then change its time. Inspect the destination's web calendar as well as the phone.

If you need support, share the provider, app version, redacted server address, operation that failed, and exact error. Leave passwords and private feed links out.

Ready to try CalDAV copies after checking the connection? Start your free 30-day trial with Avum today.