Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation

I am having the exact same problem. I contacted Apple Care and they seemed pretty helpless to me. As for the "Error 500" they said they don't have anything in their documents about this and contacted HQ.

Their guess is that something in the OpenDirectory is broken. They mentioned that they have a bug which lets various things break if the keyword .local. is used for the domain name of the Lion Server. They actually asked if setting up the machine anew would be an option! 😠 However, changing the name is difficult since our entire ecosystem is built around this naming convention (servername.local.ourdomain). Besides, I am not aware of how to migrate the data of my users that are using mobile home syncing as well as the Wikis to a new machine with a new hostname...

The current status is that they are still investigating. If there would be a way to wipe the calendar and let users (and the shared calendars in the Wikis) start anew that would be good enough for me at the moment...

My current status:

* Shared Calendars broken

* Calendars for pre-10.7.2 users broken

* New users can access via iCal, but web is also still broken.

I also went through support which basically gave me 3 options: 1) Wait. 2) Reset PostgreSQL (lose all related info). 3) ReInstall Lion from scratch.

Here is the last response I received from support:

Hi Brandon,

I got a response from my Engineering group regarding the issues you are experiencing with your iCal Server. They have identified a few other reports of this problem that seem to correspond with the issues you are experiencing, and are currently investigating this. It appears that they are hoping to get this resolved with a future software update to 10.7; however it is unclear if they will be able to resolve it by the time 10.7.3 is released or if it will be included in another update.

As such, the best recommendation that I can provide at this time would be to keep an eye out for forthcoming updates, apply them as soon as possible when they are released, and test to see if you still experience the behavior. The only other option that I could currently provide would be to Reset your PostgreSQL database, which should get iCal back up and running, but this would also cause you to lose all Postgres -related data (including iCals, Wikis, Address Books, Webmail, and Profile Manager data). Considering this extensive data loss, awaiting an update to try to resolve the issues may indeed be our best option.

I will keep you updated if any more information or pertinent details are made available to me, or if an update is released that is anticipated to resolve these issues. Thanks for your patience, and I hope you have a good day.

So, iCal is still not working. Unlfortunately, I don't have the luxury of being able to wait because our company relies heavily on the calendar, personal and group calendars, and wiki services. I also cannot lose all our emails or wiki pages. I have had to switch our company over to Google docs and move our emails and calendars over. Calendar and Address book are easily backed up. Not confident yet that I can restore wiki pages back to a new machine - testing this before I kill lion.

Thank you for your reply. This is pretty sad since we've had so high hopes the OS X Server would make many things easier in our office. Bet on the wrong horse, I guess...

Anyway, I am also looking into exporting the Wiki from the current machine and importing it on a another one. Let's keep each other updated if we can make any progress?

Sascha,

Not sure if it was in this thread or another, but somewhere someone mentioned that it could have been that the 10.7.2 update breaks RPC. There is an Apple article about it, but it only mentions the upgrade to 10.7.1 (not .2) so I never tried it, fearing that it would make things worse.

Scott P. with Apple support has been helping me resolve this, and he sent the same article recently for me to try: http://support.apple.com/kb/TS4024 -- IT WORKED!!

It basically asks you to do the following (which I did):

sudo serveradmin stop calendar

sudo serveradmin settings calendar:Authentication:Wiki:URL = "http://127.0.0.1:8089/RPC2"

sudo serveradmin start calendar

Both my existing users and new users connect through iCal clients and wiki calendars without errors. Hope this works for you.

I had the same issue, but when I applied Apple's suggestion (iterated above), I get this, when clicking on a Wiki's Calendar link:

Forbidden

You don't have permission to access /webcal/.

Theoretically, I could ensure I have 755 on /webcal (recursively), but I'll be darned if I know where "/webcal" is located. Any ideas?

thellum, did you give the user access to the service?

I had to do this in Server.app under Accounts -> Users on the left side.

Choose the user in question and click "Edit Access to services..." then enable access to the iCal Server.

Hmm, interesting. However, after following your instructions, I saw that the macadmin account has access to all enabled services already. It was also interesting to note that the check boxes in that area were all enabled, but greyed-out:

Of note... I just saw that Profile Manager was not started or running. However, getting this running still did not affect whether or not "Hide" shows up under the gear icon.

: (

Had the same issue...after many hours of trying and fixing it (it seems that caldav is accessing a deleted node)...easiest solution was:

1. export cal data from an ical which wasnt working but had the data cached.

2. Delelete user

3. Create user again and attach to correct groups

4. Reimport caldav data...

As caldav doesnt really provide a cleanup function or admin interface...manually jumping through postgres will most likely do more harm then good.

Good luck!

Hi

Please forgive me if I've done this wrong as it's my first post.

This does appear as though it is the same issue that I am experiencing however it only effects one account getting the following error

The server responded with

“500”

to operation CalDAVAccountRefreshQueueableOperation.

The server consists of 5 users and only one has the issue.

I can see that in the logs..

'txdav.common.icommondatastore.InternalDataStoreError'>: Data corruption detected (BEGIN:VCALENDAR

2012-03-19 21:41:31+0000 [-] [caldav-0] VERSION:2.0

2012-03-19 21:41:31+0000 [-] [caldav-0] CALSCALE:GREGORIAN

2012-03-19 21:41:31+0000 [-] [caldav-0] PRODID:-//Apple Inc.//iCal 5.0.1//EN

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:VTIMEZONE

2012-03-19 21:41:31+0000 [-] [caldav-0] TZID:Atlantic/Canary

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:DAYLIGHT

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTART:19810329T010000

2012-03-19 21:41:31+0000 [-] [caldav-0] RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3

2012-03-19 21:41:31+0000 [-] [caldav-0] TZNAME:WEST

2012-03-19 21:41:31+0000 [-] [caldav-0] TZOFFSETFROM:+0000

2012-03-19 21:41:31+0000 [-] [caldav-0] TZOFFSETTO:+0100

2012-03-19 21:41:31+0000 [-] [caldav-0] END:DAYLIGHT

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:STANDARD

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTART:19961027T020000

2012-03-19 21:41:31+0000 [-] [caldav-0] RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10

2012-03-19 21:41:31+0000 [-] [caldav-0] TZNAME:WET

2012-03-19 21:41:31+0000 [-] [caldav-0] TZOFFSETFROM:+0100

2012-03-19 21:41:31+0000 [-] [caldav-0] TZOFFSETTO:+0000

2012-03-19 21:41:31+0000 [-] [caldav-0] END:STANDARD

2012-03-19 21:41:31+0000 [-] [caldav-0] END:VTIMEZONE

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:VEVENT

2012-03-19 21:41:31+0000 [-] [caldav-0] UID:CB5C6BAA5ED2409BB2BFDFACBAB2C88A00000000000000000000000000000000

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTART;TZID=Atlantic/Canary:20100223T200000

2012-03-19 21:41:31+0000 [-] [caldav-0] DTEND;TZID=Atlantic/Canary:20100223T201000

2012-03-19 21:41:31+0000 [-] [caldav-0] CREATED: 11231T000000Z

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTAMP:20100511T104744Z

2012-03-19 21:41:31+0000 [-] [caldav-0] RRULE:FREQ=WEEKLY;COUNT=400

2012-03-19 21:41:31+0000 [-] [caldav-0] SEQUENCE:1

2012-03-19 21:41:31+0000 [-] [caldav-0] STATUS:CONFIRMED

2012-03-19 21:41:31+0000 [-] [caldav-0] SUMMARY:Recycling

2012-03-19 21:41:31+0000 [-] [caldav-0] END:VEVENT

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:VEVENT

2012-03-19 21:41:31+0000 [-] [caldav-0] UID:CB5C6BAA5ED2409BB2BFDFACBAB2C88A00000000000000000000000000000000

2012-03-19 21:41:31+0000 [-] [caldav-0] RECURRENCE-ID;TZID=Atlantic/Canary:20100511T200000

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTART;TZID=Atlantic/Canary:20100511T200000

2012-03-19 21:41:31+0000 [-] [caldav-0] DTEND;TZID=Atlantic/Canary:20100511T201000

2012-03-19 21:41:31+0000 [-] [caldav-0] DESCRIPTION:Throw rubble in skip

2012-03-19 21:41:31+0000 [-] [caldav-0] DTSTAMP:20100511T104744Z

2012-03-19 21:41:31+0000 [-] [caldav-0] SEQUENCE:0

2012-03-19 21:41:31+0000 [-] [caldav-0] STATUS:CONFIRMED

2012-03-19 21:41:31+0000 [-] [caldav-0] SUMMARY:Recycling

2012-03-19 21:41:31+0000 [-] [caldav-0] END:VEVENT

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:X-CALENDARSERVER-PERUSER

2012-03-19 21:41:31+0000 [-] [caldav-0] UID:CB5C6BAA5ED2409BB2BFDFACBAB2C88A00000000000000000000000000000000

2012-03-19 21:41:31+0000 [-] [caldav-0] X-CALENDARSERVER-PERUSER-UID:01A411BE-968B-4BAE-B812-B1421677ECA5

2012-03-19 21:41:31+0000 [-] [caldav-0] BEGIN:X-CALENDARSERVER-PERINSTANCE

2012-03-19 21:41:31+0000 [-] [caldav-0] TRANSP:OPAQUE

2012-03-19 21:41:31+0000 [-] [caldav-0] END:X-CALENDARSERVER-PERINSTANCE

2012-03-19 21:41:31+0000 [-] [caldav-0] END:X-CALENDARSERVER-PERUSER

2012-03-19 21:41:31+0000 [-] [caldav-0] END:VCALENDAR

2012-03-19 21:41:31+0000 [-] [caldav-0] ) in id: 759

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:388:errback

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:455:_startRunCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:542:_runCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1076:gotResult

2012-03-19 21:41:31+0000 [-] [caldav-0] --- <exception caught here> ---

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/resource.py:309:renderHTTP

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twext/web2/static.py:127:renderHTTP

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twext/web2/resource.py:109:renderHTTP

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/method/report.py:134:http_REPORT

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/method/report_multiget_common.py:31 4:multiget_common

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/method/report_multiget_common.py:22 4:doResponse

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/method/report_common.py:340:_namedP ropertiesForResource

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1018:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/python/failure.py:350:throwExceptionIntoGenerator

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/twistedcaldav/resource.py:1129:iCalendarForUser

2012-03-19 21:41:31+0000 [-] [caldav-0] /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twis ted/internet/defer.py:1020:_inlineCallbacks

2012-03-19 21:41:31+0000 [-] [caldav-0] /usr/share/caldavd/lib/python/txdav/caldav/datastore/sql.py:664:component

2012-03-19 21:41:31+0000 [-] [caldav-0] ]

2012-03-19 21:41:42+0000 [-] [mailgateway] 2012-03-19 21:41:42+0000 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['HIGHESTMODSEQ', '1'], 'Highest']

2012-03-19 21:41:42+0000 [-] [mailgateway] 2012-03-19 21:41:42+0000 [IMAP4DownloadProtocol,client] Unhandled unsolicited response: ['OK', ['URLMECH', 'INTERNAL'], 'Mechanisms', 'supported']

any help would be appreciated, it's driving me bonkers

Hello there,

we run into the exact same problem and finally manage to solve it! Here is what we did.

The first thing we did was to backup the user's calendar:

# sudo calendarserver_export -u username > ~/Desktop/backup.ics

Then we ran the calendarserver_purge_principals, by first listing the principals:

# sudo calendarserver_manage_principals --list-principals users

This allowed to found out the user's UUID. Using it, we tried the following:

# sudo calendarserver_purge_principals -vc UUID

This resulted in a Python exception saying that the attribute isCalendarCollection does not exist in collection, at line 676 of the script purge.py. So we patched the script:

# cd /usr/share/caldavd/lib/python/calendarserver/tools/

# cp purge.py purge.py.backup

And performed the following modification:

676c676

< if (hasattr(collection, 'isCalendarCollection') and collection.isCalendarCollection()) or collName == "inbox":

---

> if collection.isCalendarCollection() or collName == "inbox":

Then we tried to run the script again:

# sudo calendarserver_purge_principals -vc UUID

and it worked ;-) In the meantime, we also changed the user password, but it is unlikely that this had anything to do with the issue.

Hope this helps!

elgringito

Thank you for your reply, I must be honest we did get lost at the

676c676

< if (hasattr(collection, 'isCalendarCollection') and collection.isCalendarCollection()) or collName == "inbox":

---

> if collection.isCalendarCollection() or collName == "inbox":

Thankfully, we carried out ther following to resolve this issue;

Lion Server 10.7.3

Installed phpPgAdmin

follow http://www.mactasia.co.uk/using-postgresql-in-lion-server

Viewed caldav/tables/calendar object

Click on Browse

Sort by resource_id

Deleted the corrupt UID entry

Issue resolved horah!

Good luck guys

Sorry for the late reply ! Not too bad though, since you appear to have solved you problem. But just in case the part:

676c676

< if (hasattr(collection, 'isCalendarCollection') and collection.isCalendarCollection()) or collName == "inbox":

---

> if collection.isCalendarCollection() or collName == "inbox":

simply is the difference between the original file and the file after having applied the patch. The number indicate the line in the file where you have to make the modifications. In other words, open the file

/usr/share/caldavd/lib/python/calendarserver/tools/purge.py

(after having backuped it, see my previous post), go to the line 676, and change

if collection.isCalendarCollection() or collName == "inbox":

by

if (hasattr(collection, 'isCalendarCollection') and collection.isCalendarCollection()) or collName == "inbox":

The rest goes as explained in my previous post.

it helped me to desable old accounts