1 2 3 4 5 6 Previous Next 88 Replies Latest reply: Mar 26, 2012 5:25 PM by elgringito Go to original post
  • 75. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    bsibrandon Level 1 Level 1 (0 points)

    iCal still not working.

     

    I can't seem to figure out why a new account doesnt get the "operation CalDAVAccountRefreshQueueableOperation" error but existing users do -- but the wiki calendar still doesn't work for anyone.

     

    On a wiki page, the "Upcoming Events" side bar just hangs at "getting events" and the calendar itself still stays at "Getting events from server..."

     

    Screen Shot 2011-11-08 at 8.01.51 AM.png

     

    If I am quick enough, I can click the Settings button on the wiki calendar before it trys to get the events from the server:

     

    Screen Shot 2011-11-08 at 7.41.31 AM.png

    but whether I leave the same or change the settings, it will hang at "saving settings..."

     

    Screen Shot 2011-11-08 at 7.40.49 AM.png

     

    So, what would be the next step? Is this a database thing? Instead of trying to restore from a previous point before the 10.7.2 update (which I did, but didn't work), is there a way to just have os x lion create a new fresh calendar db?

     

    At this point, I care more about getting it to work than losing all the calendar events.

     

    Anyone have suggestions?

  • 76. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    Sascha Holesch Level 1 Level 1 (0 points)

    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.

  • 77. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    bsibrandon Level 1 Level 1 (0 points)

    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.

  • 78. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    Sascha Holesch Level 1 Level 1 (0 points)

    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?

  • 79. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    bsibrandon Level 1 Level 1 (0 points)

    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.

  • 80. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    thellum Level 1 Level 1 (0 points)

    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?

  • 81. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    Martin Baechtold Level 1 Level 1 (15 points)

    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.

  • 82. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    thellum Level 1 Level 1 (0 points)

    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:

    Access_all.jpg

  • 83. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    thellum Level 1 Level 1 (0 points)

    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.

     

    : (

  • 84. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    nexflo_ Level 1 Level 1 (0 points)

    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!

  • 85. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    ACEssex Level 1 Level 1 (0 points)

    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

  • 86. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    elgringito Level 1 Level 1 (20 points)

    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!

  • 87. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    ACEssex Level 1 Level 1 (0 points)

    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

  • 88. Re: Calendar Server Reported Error: Operation CalDAVAccountRefreshQueueableOperation
    elgringito Level 1 Level 1 (20 points)

    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.

1 2 3 4 5 6 Previous Next