mjsickel

Q: Calendar server responding with 403 Forbidden” to operation CalDAVWriteEntityQueueableOperation.

With the latest version of Mac Server (5.1.5 on OS X 10.11.6), when I try to migrate a large calendar via a client computer, it takes a long time and then I get an endless series of

The server responded with an error.

 

Access to “[name of cal event]” in “[name of calendar]” in account “[account name]” is not permitted.

 

The server responded:

“HTTP/1.1 403 Forbidden”

to operation CalDAVWriteEntityQueueableOperation.

 

[Go Offline]  [Revert to Server]

errors.  I have to leave something heavy on the enter key for a couple hours to get rid of all the errors. 

Migrating smaller calendars to the server (by importing the data in iCal to the hosted account's calendar) works mostly (there may be an error or 2).

I found a suggestion from years ago on another board that the permissions might be goofed up and to use this terminal command:

sudo chown -R _calendar:_calendar /Library/CalendarServer/Documents

However, this suggestion was for the 10.6 server and may no longer apply.

 

Any thoughts?

Posted on Aug 27, 2016 2:27 PM

Close

Q: Calendar server responding with 403 Forbidden” to operation CalDAVWriteEntityQueueableOperation.

  • All replies
  • Helpful answers

  • by mjsickel,

    mjsickel mjsickel Aug 28, 2016 1:35 PM in response to mjsickel
    Level 1 (4 points)
    Servers Enterprise
    Aug 28, 2016 1:35 PM in response to mjsickel

    Today I had the idea of trying to upload the calendar from the same computer that is serving the calendars.  Should be faster and better (and the same OS!)!

    So, made an account on he hosting Mac and started the import process, which seemed to go more smoothly, but then seemed like the same thing was happening: most of the CPU was getting taken up with various calendar-related activities and then after a while it started spitting out errors, but they were slightly different.  There's too many errors to just move everything over.  Also, trying to add more events to that calendar also fails.

    Now they say :

     

    The event "[event name]" was rejected by "[server]" because the maximum number of resources has been reached.

     

    Is there some limit to the size if a calendar?

    Am I doing something wrong or is this a limit of the software?

  • by mjsickel,

    mjsickel mjsickel Aug 28, 2016 2:08 PM in response to mjsickel
    Level 1 (4 points)
    Servers Enterprise
    Aug 28, 2016 2:08 PM in response to mjsickel

    OK, it looks like there's an arbitrary 10,000-item limit in the size of the calendars: https://discussions.apple.com/message/25764862#message25764862

    That post discusses the limit and a method for changing the limit, but the .plist file it talks about modifying is blocked to the administrator and it makes me a bit nervous to dig around in there. 

    The 10k limit sounds like a lot, but the calendar I'm trying to move there covers 10 years already and so that would only give 1000 items a year, so more than 4 things going on a day will easily blow past that limit.

  • by mjsickel,Solvedanswer

    mjsickel mjsickel Aug 28, 2016 7:46 PM in response to mjsickel
    Level 1 (4 points)
    Servers Enterprise
    Aug 28, 2016 7:46 PM in response to mjsickel

    I ended up modifying the .plist file (which was fairly straightforward) to raise the limit from 10k items to something much higher (50k) and re-imported the big calendar and it went off smooth as butter.

    Here's what I had to do:

    add administrator privileges to each of the folders and then the file to get to /Library/Server/Calendar and Contacts/Config/caldavd-system.plist

    Open caldavd-system.plist in textedit and add these lines somewhere in between the <dict> and the </dict> lines without encroaching on another pair of <thing> and </thing> lines (use whatever size you want instead of 20000):

         <key>MaxResourcesPerCollection</key>

         <integer>20000</integer>

    Save it, then restart the calendar server.  I restarted the computer to be safe, but that may have been unnecessary.