A reminder for myself - Problems connecting macOS clients to CALDAV and solution

šŸ± Features & apps šŸ“† Calendar
1

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ā€.

Some facts:

  • Nextcloud v25.0.4 on Ubuntu 22.04 on a proxmox cluster
  • apache
  • ā€œ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;
[endless scrolling]
1729 rows in set (0.038 sec)

ouch. wtf?

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
https://ip-or-hostname/remote.php/dav/principals/users/username/
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ā€¦

1 Like