# Carddav Syncing with EGroupware fails

Hello,

just got back my Jolla and applied the new update 10. Now I can set up a carddav sync account. I tried multiple settings I found in the forum, yet none worked.

I use a hosted EGroupware 14.2 Installation. My Egroupware installation is below xxx.xxx/egroupware

My Carddav Settings are

server_address = http://XXX.XXX/egroupware/groupdav.php auth/mechanism = password sync_profile_templates = ["carddav.Contacts"] CredentialsId = 31 carddav.Contacts/profile_id = carddav.Contacts-29 enabled = true

From the journal I get the following errors

[D] RequestGenerator::generateRequest:88 - generateRequest(): "" "http://xxx.xxx/egroupware/groupdav.php" "" "0" "PROPFIND" "<d:propfind xmlns:d="DAV:"><d:prop><d:current-user-principal /></d:prop></d:propfind>"
[D] {anonymous}::debugDumpData:48 - "<?xml version="1.0" encoding="utf-8"?>"
[D] {anonymous}::debugDumpData:48 - "<D:multistatus xmlns:D="DAV:">"
[D] {anonymous}::debugDumpData:48 - " <D:response xmlns:ns0="urn:uuid:c1111010-65b3-11d1-a29f-00aa00c14882/">"
[D] {anonymous}::debugDumpData:48 - "  <D:href>/egroupware/groupdav.php/</D:href>"
[D] {anonymous}::debugDumpData:48 - "   <D:propstat>"
[D] {anonymous}::debugDumpData:48 - "    <D:prop>"
[D] {anonymous}::debugDumpData:48 - "     <D:current-user-principal><D:href>/egroupware/groupdav.php/principals/users/xxx/</D:href></D:current-user-principal>"
[D] {anonymous}::debugDumpData:48 - "    </D:prop>"
[D] {anonymous}::debugDumpData:48 - "   <D:status>HTTP/1.1 200 OK</D:status>"
[D] {anonymous}::debugDumpData:48 - "  </D:propstat>"
[D] {anonymous}::debugDumpData:48 - " </D:response>"
[D] {anonymous}::debugDumpData:48 - "</D:multistatus>"
[D] RequestGenerator::generateRequest:88 - generateRequest(): "" "http://xxx.xxx/egroupware/groupdav.php" "/egroupware/groupdav.php/principals/users/xxx/" "0" "PROPFIND" "<d:propfind xmlns:d="DAV:" xmlns:card="urn:ietf:params:xml:ns:carddav"><d:prop><card:addressbook-home-set /></d:prop></d:propfind>"
[D] {anonymous}::debugDumpData:48 - "<?xml version="1.0" encoding="utf-8"?>"
[D] {anonymous}::debugDumpData:48 - "<D:multistatus xmlns:D="DAV:">"
[D] {anonymous}::debugDumpData:48 - " <D:response xmlns:ns0="urn:uuid:c1111010-65b3-11d1-a29f-00aa00c14882/" xmlns:ns2="urn:ietf:params:xml:ns:carddav">"
[D] {anonymous}::debugDumpData:48 - "  <D:href>/egroupware/groupdav.php/</D:href>"
[D] {anonymous}::debugDumpData:48 - "   <D:propstat>"
[D] {anonymous}::debugDumpData:48 - "    <D:prop>"
[D] {anonymous}::debugDumpData:48 - "    </D:prop>"
[D] {anonymous}::debugDumpData:48 - "   <D:status>HTTP/1.1 200 OK</D:status>"
[D] {anonymous}::debugDumpData:48 - "  </D:propstat>"
[D] {anonymous}::debugDumpData:48 - "   <D:propstat>"
[D] {anonymous}::debugDumpData:48 - "    <D:prop>"
[D] {anonymous}::debugDumpData:48 - "   </D:prop>"
[D] {anonymous}::debugDumpData:48 - "  </D:propstat>"
[D] {anonymous}::debugDumpData:48 - " </D:response>"
[D] {anonymous}::debugDumpData:48 - "</D:multistatus>"
[D] Buteo::LogTimer::LogTimer:72 - "void CardDavClient::syncFinished(int, const QString&)" :Entry
[C] CardDavClient::syncFinished:137 - CardDAV sync failed: 401 ""


What happens here? Has anyone an idea?

edit retag close delete

What about the (web) server side log? What do the "principals" requests look like? Double entries in the URL?

( 2015-01-01 12:47:20 +0200 )edit

Most likely due to a bug which was fixed recently in the CardDAV sync adapter (see https://github.com/nemomobile/buteo-sync-plugin-carddav/commit/1fe6c4f59d4d7afa3d9bed7e5d03f53677992e68) which could sometimes cause the adressbook home set PROPFIND request to be performed on the wrong URL. If this is the case, it will be fixed in the upcoming update (1.1.4).

Cheers, Chris.

( 2015-04-01 06:39:18 +0200 )edit

Sort by » oldest newest most voted

Since last update to Jolla 1.1.9.28 also the DST problem is solved. Now it works perfect for me. There was only one issue, that I had to delete the caldav/carddav account and create it again, to get rid of the wrong old entries.

more

Its a shame, but DST problem reoccurred. I don't know exactly when. Maybe with winter time or with last OS update to 2.0.0.10. The problem is occurs when creating or editing an event in jolla (e.g. 18:00) and syncing it to my egroupware server. There it is one hour to early (e.g.17:00). I don't know how to debug the problem. Does anybody know where I can find log infos or switch on logging in eGroupware?

( 2016-01-22 17:12:29 +0200 )edit

If you are able to edit the server side configuration, you might manage to setup carddav, otherwise I guess you will have to wait.

Here is how I got my owncloud installation working. The actual problems are most likely on the client side and thus you might want to try it out. As I said, it requires changes on the server side...

1. Install redirect for initial PROPFIND call on virtual host level. This looks as follows for your case:

RewriteEngine on
RewriteCond  %{REQUEST_METHOD}  ^PROPFIND$RewriteRule ^/$                 /egroupware/groupdav.php [P]

2. Configure your Carddav account on the Jolla as follows

• For the server set your http://xxx.xxx - no / at the end!
• Leave the calendar entry empty
• choose to sync Contacts only

Note that this should at least allow you to sync your contacts once. Please do not forget to have a recent backup at hand, because things might go wrong. What I also experienced is that if just one of your contact can not be successfully synchronized, the synchronization does not work after the initial run.

I hope this helps.

more

Thanks for you help, but it didn't work.

I asked in the Egroupware Mailing List too:

http://egroupware.219119.n3.nabble.com/Carddav-td4003899.html

It is a Jolla Bug, it has to be solved here

more

I asked at zendesk whether the problem is solved meanwhile. See this link https://jolla.zendesk.com/hc/en-us/requests/16091. With the coming update (beginning of April 2015) it should be solved. I'll try it then and will write my experience here.

more

This post is a wiki. Anyone with karma >75 is welcome to improve it.

I'm using yolla with eGroupware 14.2 since more than two month meanwhile and it works perfektly. The only issue is that with the one hour time shift during summertime DST. There are already other threads about it (https://together.jolla.com/question/60486/all-dates-shifted-by-one-hour-in-calendar-after-updating-to-11038/).

more