So, this is a reminder for myself, because it took me again days to get some macOS clients (builtin iCal application) to connect to our internal nextcloud server.
I have problems for years now, but always got it working - somehow, never really understood why. And - this is the exact story you often read regarding the same issue: it simply works sometimes if you try hard enough.
Well, not really this time. No chance, macOS (in this case still running Catalina 10.15, but that’s not the problem) refused with its infamous “unable to verify account or password”.
- Nextcloud v25.0.4 on Ubuntu 22.04 on a proxmox cluster
- “real” install, no snap
- LAN or VPN-to-LAN only
- about 25 Android clients, macOS clients, Linux clients
- most clients use nothing but the calendar and all those use the same username “<whatever, doesn’t matter>” and this user has ~20 calendars. So this nextcloud is more or less a calendar-only-server.
All work fine except macOS. For years and years problems. Once connected, they seem to work, but the initial connection was always a pita. No matter what URL you try: “unable to verify account or password”. Great. I even migrated the server yesterday to a new VM, switching from sqlite to mysql - but nothing changed. The server was an old installation with originally owncloud, kinda grown system, that’s why I decided to migrate to a fresh machine. But didn’t help, because I also migrated all data and the database…
Although most CALDAV clients were running fine (once connected), I also noticed that the login to the web interface (eg. to alter calendars) got slower and slower over the years. And this finally led me to the solution…:
SELECT * FROM oc_authtoken;
1729 rows in set (0.038 sec)
DELETE FROM oc_authtoken WHERE uid=‘<our_shared_username>’;
Query OK, 1713 rows affected (0.103 sec)
And magically all macOS clients log in fast and without any problems. So the reason for the login problems was indeed a timeout during the initial authentication process:
(in Console on the Mac:)
[com.apple.calendar.accounts.authentication] [We timed out waiting for CalendarAgent to authenticate <our_shared_username>]
Tested with 10.15, BigSur and Ventura, URL used is
but it also worked with just the IP (if .well-known stuff is correct). So the next time I have those problems, I will find my answer here, great. And if anyone has an idea why there were so many authtokens flapping around in the database…