Hi Andre, Thansk for your answer! I checked out CalDAVClientLibrary shell and want to add an AdminPrincipal. Is it enough to add to (/etc/caldavd/caldavd.plist): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AccessLogFile</key> <string>access.log</string> <key>AdminPrincipals</key> <string>username</string> … afterwards saving the plist and restarting caldavd? Or do I have to add/edit more than this? Thanks, Sirko On 25.07.2013, at 22:47, Andre LaBranche <dre@apple.com> wrote:
On Jul 25, 2013, at 2:55 AM, Sirko Mann <smann@datameer.com> wrote:
Hi List,
we have another problem with our caldav server. I have to remove an event from the calendar of a co-worker. He gets a warning:
The server responded with an error. Access to "event" in "calendar" in account "servername" in not permitted.
The server responded: "403" to operation CalDAVWriteEntityQueueableOperation.
He tried to remove the event, but the problem is, he can not find this event in his calendar. I made a dump of the caldav database and imported this in a sandbox. I'm able to find:
caldav=# select resource_id, calendar_resource_id from calendar_object where icalendar_text like '%string%'; resource_id | calendar_resource_id -------------+---------------------- 159174 | 92159 (1 row)
caldav=#
How can I remove this from the database without break anything?
Hi Sirko,
You are correct for suspecting that directly editing the database might be bad :) In general, it's always best to make edits through CalDAV. In this case, you could try deleting the event using the CalDAVClientLibrary shell, logging in as an AdminPrincipal (these are specified by principal URL; e.g. you could add yourself or an admin account to this list in caldavd.plist)
Also there might be some access.log content describing the nature of the 403; like maybe the client is trying to access an event in a shared calendar to which the client no longer has access. Check to see if you have the 'err=' extended log item in the request that fails with 403; you might need to enable the extended logging first.
Cheers, -dre
Thanks, Sirko
------------------------------------------------------------------------------------------------ Datameer GmbH, Grosse Ulrichstrasse 7-9, D-06108 Halle (Saale), Amtsgericht Stendal, HRB: 10348, Geschäftsführer: Stefan Groschupf
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
------------------------------------------------------------------------------------------------ Datameer GmbH, Grosse Ulrichstrasse 7-9, D-06108 Halle (Saale), Amtsgericht Stendal, HRB: 10348, Geschäftsführer: Stefan Groschupf