-
All replies
-
Helpful answers
-
Oct 8, 2015 5:31 PM in response to Northfolkby Filippo Antonica,same issue here.
It do not appear to be a server problem but a problem of the AddressBook.app of El Capitan.
I'm running Egroupware under Debian (Stable) and apache 2.4.
Apparently apache do not log errors or queries.
Let's hope apple will fix this under 10.11.1
-
Oct 14, 2015 12:50 AM in response to Northfolkby JoergSchulz,same issue here.
When I enter the data for new owncloud accounts, accountsd crashes:
Bad to hear that other caldav providers are affected, so it must be the fault of the Address book sync dialog.
process: accountsd [1891]
Path: /System/Library/Frameworks/Accounts.framework/Versions/A/Support/accountsd
Identifier: accountsd
Version: 113 (113)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: accountsd [1891]
User ID: 501
Date/Time: 2015-10-12 22:30:25.811 +0200
OS Version: Mac OS X 10.11 (15A284)
Report Version: 11
Anonymous UUID: DF869F1B-466C-AC13-8BA5-25CD7866E674
Time Awake Since Boot: 15000 seconds
System Integrity Protection: enabled
Crashed Thread: 3 Dispatch queue: com.apple.NSXPCConnection.user.1865
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
objc_msgSend() selector name: initWithCoder:
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8c05ec96 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c05e0d7 mach_msg + 55
2 com.apple.CoreFoundation 0x00007fff93167024 __CFRunLoopServiceMachPort + 212
3 com.apple.CoreFoundation 0x00007fff931664ec __CFRunLoopRun + 1356
4 com.apple.CoreFoundation 0x00007fff93165d38 CFRunLoopRunSpecific + 296
5 accountsd 0x0000000106800a12 0x106800000 + 2578
6 libdyld.dylib 0x00007fff9ae7d5ad start + 1
Thread 1:
0 libsystem_kernel.dylib 0x00007fff8c06478a __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff9b02b58c _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x00007fff9b029375 start_wqthread + 13
Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8c0650a2 kevent_qos + 10
1 libdispatch.dylib 0x00007fff98b8a1ad _dispatch_mgr_invoke + 216
2 libdispatch.dylib 0x00007fff98b89e15 _dispatch_mgr_thread + 52
-
Oct 20, 2015 8:48 PM in response to Northfolkby P.Hepner,Same problem for me. Upgraded to El Capitan and now I can't sync contacts with Owncloud. Sigh.
-
Oct 21, 2015 3:54 PM in response to P.Hepnerby Filippo Antonica,Looking around i saw OnwCloud 8.2 has been released.
What OwnCloud version are you using ?
Platee note also that 10.11.1 has been released.
I'haven't installed it so far. And you ?
-
Oct 22, 2015 10:45 AM in response to Filippo Antonicaby JoergSchulz,I have it all in the most current version and can confirm: it does not work yet.
Cheers....
-
Oct 22, 2015 4:47 PM in response to Filippo Antonicaby P.Hepner,I'm using Owncloud 8.1.3.
I solved the problem by adding the following
Redirect 301 /.well-known/carddav /owncloud/remote.php/carddav
Redirect 301 /.well-known/caldav /owncloud/remote.php/caldav
below the
DocumentRoot /var/www/html
entry in my Apache default-ssl.conf configuration file. All work fine now.
-
Oct 22, 2015 11:32 PM in response to P.Hepnerby JoergSchulz,This does not work for NEW accounts. Under some circumstances, old accounts can be reused.
-
Oct 29, 2015 8:05 PM in response to JoergSchulzby jsavvy,JoergSchulz wrote:
This does not work for NEW accounts. Under some circumstances, old accounts can be reused.
If you're using owncloud 8 or newer that should work. The only thing that you need to check is whether Owncloud is on the document root (http://example.com) or if it is in a sub folder (http://example.com/owncloud).
If its in a sub folder then use
Redirect 301 /.well-known/carddav /owncloud/remote.php/carddav
Redirect 301 /.well-known/caldav /owncloud/remote.php/caldav
in the site config file where owncloud is the subfolder name.
If its in the site's document root just remove the owncloud folder name like this
Redirect 301 /.well-known/carddav /remote.php/carddav
Redirect 301 /.well-known/caldav /remote.php/caldav
-
Oct 31, 2015 12:10 PM in response to jsavvyby hopchop,The redirect in /etc/apache2/sites-enabled/default-ssl.conf worked for me at first, but I still had the strange problem, that the calendar app was syncing some items, but still showed an error message.
So I checked the access log:
cat /var/log/apache2/ssl_access.log | grep 404
and found this problem:
xxx.xxx.xxx.xxx - someuser [31/Oct/2015:10:25:43 +0100] "PROPFIND /owncloud/remote.php/caldav/calendars/someuser/inbox/ HTTP/1.1" 404 1438 "-" "Mac+OS+X/10.11.1 (15B42) CalendarAgent/361"
The calendar app was trying to sync a calendar named "inbox", which I never had and was never required before.
In the account settings I found that El Capitan seems to suffer from Alzheimers and forgot the ssl setting, which it had accepted before. So I disabled the account and repeatedly checked this option until the setting actually stuck. This dialog is seriously broken and I had to try at least ten times until this input was accepted.
So I created this calendar using the owncloud web interface and sure enough the problems did go away.
One or more 404 errors from the server seem to cause the calendar agent to revert to non-ssl mode. Once the cause of the 404 errors is fixed, the configuration seems to be stable.
Maybe others don't have this "inbox" calendar either in their owncloud setup and are running into trouble even though the redirects are working properly.
Important is, that there is a failure mode, where the requests work for all existing calendars and just one missing calendar causes the configuration to blow up.
-
Oct 31, 2015 12:13 PM in response to Northfolkby Csound1,iCloud uses CardDav, so does Google, they work just fine. But you and most others here (maybe all) are using owncloud, which doesn't seem to work.
Find a more competent Dav server, the client is fine.
-
Oct 31, 2015 2:36 PM in response to Csound1by Fred Turner,Thank you, Csound1, for your comment. The client is most certainly NOT fine. By comparison, it WAS fine in Mac OS X 10.5, 10.6, 10.7, 10.8, 10.9, and 10.10. But it no longer works with the exact same settings in all iterations and releases of 10.11 to date. iCloud and Google do not use a standard CardDAV account configuration screen, they use their own. We're talking about a regular ("Other") CardDAV account config. That's what's not working.
<Edited By Host>
-
Nov 5, 2015 2:00 AM in response to Northfolkby mariobig,I have the same problem as described above. It means I can't synchronize my contacts stored at owncloud 8.1.4 with contacts v 9.0 (1679) runining on OSX EL Capitan.
Owncloud app is installed on debian server (wheezy) with Apache/2.2.22.
I get the following message on my Mac: Error CoreDAVHTTPStatusErrorDomain 405
Redirect mentioned in one of the reply does not help.
-
Nov 5, 2015 9:21 AM in response to mariobigby jsavvy,mariobig wrote:
I have the same problem as described above. It means I can't synchronize my contacts stored at owncloud 8.1.4 with contacts v 9.0 (1679) runining on OSX EL Capitan.
Owncloud app is installed on debian server (wheezy) with Apache/2.2.22.
I get the following message on my Mac: Error CoreDAVHTTPStatusErrorDomain 405
Redirect mentioned in one of the reply does not help.
Not sure why it's not working. 1. be sure the redirect is in the site config file for your owncloud site (not sure how Debian is set up) 2. Make sure the redirect is going to the right location. you may need to change it based on your server setup. 3. make sure mod_alias is enabled for the redirect to work (not sure if it's enabled automatically on Debian) 4. Do NOT use the advanced configuration to setup your calendar, on your Mac, use the automatic one. Hope that helps.
-
Nov 5, 2015 10:40 AM in response to Northfolkby Stephan Steiger,Same problem here. Cannot use the redirection workaround…
Please Apple, fix this as soon as possible, cannot be too hard, as it was working before.