我们最近将 Open Directory Master 和副本升级到 Mac OS X 10.6.4 Snow Leopard Server。我们的服务器 FQDN 和 LDAP 搜索库/Kerberos 域不匹配，因此我们导出了所有用户和组，创建了具有匹配 FQDN 和搜索库/域的新 Open Directory Master，重新导入了用户和组，并将所有服务器和工作站重新绑定到新的 OD Master。
与此同时，我们将 iCal/CalDAV 服务器升级到 Mac OS X 10.6.4 Snow Leopard Server。自升级以来，我们发现 iCal/CalDAV 服务器和 iCal 客户端在 Mac OS X 10.5 Leopard 和 Mac OS X 10.6 上都存在以下问题：
如果用户尝试移动或删除在升级到 10.6 Server 之前创建的事件（单个或重复），则会收到以下错误：
不允许访问帐户“blah”中的“blah”中的“blah”。
服务器对操作 CalDAVWriteEntityQueueableOperation 的响应是：“HTTP/1.1 403 Forbidden”。
添加到目录的新用户在尝试在 iCal 的偏好设置中添加他们的帐户时收到以下错误：
用户“blah”没有配置主体。
与您的网络管理员确认您的帐户至少配置了一个 CalDAV 主体。
有趣的是，我们后来发现用户似乎能够从旧的重复事件中删除单个事件而不会出现错误，但要摆脱重复事件需要大量的工作。
我要指出的是，我们有不是但按照 iCal_Server_Admin_v10.6.pdf 第 19 页的说明在 DNS 中添加了 SRV 记录。
进一步的调查：
在此特定情况下，用户尝试拒绝在升级到 Snow Leopard Server 之前创建的重复事件。授予用户完全写入权限sudo calendarserver_manage_principals --add-write-proxy users:user1 users:user2（确实有效）不允许删除事件。仍然出现常见错误：
Access to "blah blah" in "blah blah" in account "blah blah" is not permitted.
The server responded:
"HTTP/1.1 403 Forbidden"
to operation CalDAVWriteEntityQueueableOperation.
尝试删除其中一个事件时，iCal 服务器上的 /var/log/caldavd/error.log 中显示的错误是：
2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PUT /calendars/__uids__/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/calendar/XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.ics HTTP/1.1 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.implicit#error] Cannot change ORGANIZER: UID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
客户端上的 /var/log/system.log 中的错误是：
Mar 17 15:14:30 192-168-21-169-dhcp iCal[33509]: CalDAV CalDAVWriteEntityQueueableOperation failed: status 'HTTP/1.1 403 Forbidden' request:\n\nBEGIN:VCALENDAR^M\nVERSION:2.0^M\nPRODID:-//Apple Inc.//iCal 3.0//EN^M\nCALSCALE:GREGORIAN^M\nBEGIN:VTIMEZONE^M\nTZID:US/Eastern^M\nBEGIN:DAYLIGHT^M\nTZOFFSETFROM:-0500^M\nTZOFFSETTO:-0400^M\nDTSTART:20070311T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU^M\nTZNAME:EDT^M\nEND:DAYLIGHT^M\nBEGIN:STANDARD^M\nTZOFFSETFROM:-0400^M\nTZOFFSETTO:-0500^M\nDTSTART:20071104T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU^M\nTZNAME:EST^M\nEND:STANDARD^M\nEND:VTIMEZONE^M\nBEGIN:VEVENT^M\nSEQUENCE:5^M\nDTSTART;TZID=US/Eastern:20090117T094500^M\nDTSTAMP:20081227T143043Z^M\nSUMMARY:blah blah^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:urn:uuid^M\n :XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:user@d^M\n omain.tld^M\nEXDATE;TZID=US/Eastern:20110319T094500^M\nDTEND;TZID=US/Eastern:20090117T183000^M\nRRULE:FREQ=WEEKLY;INTERVAL=1^M\nTRANSP:OPAQUE^M\nUID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nORGANIZER;CN="First Last":mailto:[email protected]^M\nX-WR-ITIPSTATUSML:UNCLEAN^M\nCREATED:20110317T191348Z^M\nEND:VEVENT^M\nEND:VCALENDAR^M\n\n\n... response:\nHTTP/1.1 403 Forbidden^M\nDate: Thu, 17 Mar 2011 19:14:30 GMT^M\nDav: 1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search^M\nContent-Type: text/xml^M\nContent-Length: 134^M\nServer: Twisted/8.2.0 TwistedWeb/8.2.0 TwistedCalDAV/2.5 (iCal Server v12.56.21)^M\n^M\n<?xml version='1.0' encoding='UTF-8'?><error xmlns='DAV:'>^M\n <valid-attendee-change xmlns='urn:ietf:params:xml:ns:caldav'/>^M\n</error>
我注意到一件事，但我不确定这是否有任何实际影响，那就是在许多 Snow Leopard Server 迁移之前的事件中，ORGANIZER 的指定如下：
ORGANIZER;CN=First Last:mailto:[email protected]
但较新的版本更像以下两种版本之一：
ORGANIZER;CN=First Last;[email protected];SCHEDULE-STATUS=1
ORGANIZER;CN=First Last;[email protected]:urn:uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
iCal_Server_Admin_v10.6.pdf 指出“.db.sqlite”文件是完全一次性的，它们只是性能缓存，并且会即时重建，因此可以安全删除。我确实删除了组织者日历的文件，在重建数据库时，处理尝试删除事件的时间更长，但最终还是出错了。
FWIW 该错误是由此代码引发的：
https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/scheduling/implicit.py
还有其他建议吗？我在 Google 搜索中看到很多关于此问题的问题，但没有解决方案，这是我们 iCal Server 上普遍存在的问题。现在，我们主要试图让用户忽略它们（因此这个问题已经存在很长时间了），但时不时我会深入挖掘，试图找到罪魁祸首和/或解决方案。
答案1
对我来说，当我使用 iCal 和 Google 日历时，当我选择 @gmail.com 地址而不是 @googlemail.com 地址时，就会出现问题。从 iCal 中删除日历并再次添加后，[电子邮件保护]一切正常。
答案2
我遇到了完全相同的问题，并通过修复日历数据存储的所有者解决了该问题，如 iCal Server Admin 10.6 第 42 页所述。我在终端上发出了以下命令：
sudo chown -R _calendar:_calendar /Library/CalendarServer/Documents
我的“Documents”文件夹具有正确的权限，但几个目录下的某些文件或文件夹的所有者是“root”，因此上述命令修复了这个问题，并且不再有用户遇到错误。
您可能还需要使用 chmod 更改权限，但就我而言，它们没有问题。