Tag Archives: wiki

Lion’s iCal server fails with error 500 response when user loses access to a wiki calendar

One of the fun errors that Lion’s iCal server likes to throw is the “500” response to CalDAVAccountRefreshQueueableOperation. This is telling you that Apache encountered an unexpected condition in fulfilling the request, so in these situations, you should find that you are getting a corresponding error in /var/log/caldavd/error.log.

The server responded with "500" to operation CalDAVAccountRefreshQueueableOperation.

Here is a condition that will see this error crop up, and workaround too:

If you change permissions on a Lion wiki, and remove access for a user who is subscribed to that wiki calendar in iCal, that user will then lose access to all calendaring, and will encounter a 500 response to every request.

The first step in troubleshooting calendaring related issues on OS X server is almost always to crank up the log verbosity. You can do this with the following command:

serveradmin settings calendar:DefaultLogLevel = "debug"

Upon another refresh, the more verbose log now reveals the cause of the error:

2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twistedcaldav.directory.wiki#debug] Wiki ACL result: user [CEC11D56-E3FA-4BC1-BC1B-5BD277EA237A], wiki [management], access [no-access]
2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twext.web2.server#info] Exception rendering:
2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twext.web2.server#error] [Failure instance: Traceback: <type 'exceptions.ValueError'>: list.remove(x): x not in list

Restoring permissive access for the affected user, refreshing, deleting the calendar from iCal, then revoking access again seems to be the quickest workaround. The relationships between users and calendars are defined in the calendar_bind table of the caldav postgres database, but removing matching entries from there does not seem to fix the issue.

Remember to return your calendar server to it’s standard level of verbosity with the following command when done:

serveradmin settings calendar:DefaultLogLevel = "warn"