[ZCS 9] Adding a Ca...
 
Notifications
Clear all

[ZCS 9] Adding a Caldav calendar not working ONLY in Zimbra

2 Posts
2 Users
0 Reactions
1,532 Views
(@r4v3n)
Joined: 3 years ago
Posts: 1
Topic starter  

Hello Zextras,

I recently discovered your ZCS 9 OSE Build and I thank you A LOT for building it. My upgrade from 8.8.7 to 8.8.15 and then 9.0.0 was pretty easy thanks to your work.

But I got a little "downside" since I upgraded.

I'm currently trying to add a Caldav calendar (hosted by 1and1/IONOS) in my Zimbra 9 OSE.
I can successfuly add this Caldav calendar in Thunderbird and the sync is perfectly working between Thunderbird and the 1and1 webmail calendar view.

I even can curl -u "user@domain.com:password" -X PROPFIND https://dav.mailxcha...v/CALENDARNAME without issue, even from my workstation or from my Ubuntu 18.04 VM hosting Zimbra.

But when I add this external calendar to Zimbra, nothing happens in the Zimbra web interface, and I got this stack trace in logs :

com.zimbra.common.service.ServiceException: system failure: error importing CalDAV data
ExceptionId:ScheduledTask-1:1623137259086:42deea478071cff7
Code:service.FAILURE
at com.zimbra.common.service.ServiceException.FAILURE(ServiceException.java:288)
at com.zimbra.cs.datasource.CalDavDataImport.importData(CalDavDataImport.java:101)
at com.zimbra.cs.datasource.DataSourceManager.importData(DataSourceManager.java:406)
at com.zimbra.cs.datasource.DataSourceManager.importData(DataSourceManager.java:362)
at com.zimbra.cs.datasource.DataSourceTask.call(DataSourceTask.java:83)
at com.zimbra.cs.datasource.DataSourceTask.call(DataSourceTask.java:31)
at com.zimbra.common.util.TaskScheduler$TaskRunner.call(TaskScheduler.java:79)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: com.zimbra.cs.dav.DavException: DAV server returned an error: 401
at com.zimbra.cs.dav.client.WebDavClient.sendMultiResponseRequest(WebDavClient.java:117)
at com.zimbra.cs.dav.client.CalDavClient.login(CalDavClient.java:119)
at com.zimbra.cs.datasource.CalDavDataImport.getClient(CalDavDataImport.java:171)
at com.zimbra.cs.datasource.CalDavDataImport.syncFolders(CalDavDataImport.java:225)
at com.zimbra.cs.datasource.CalDavDataImport.importData(CalDavDataImport.java:92)
... 10 more

 

So I got a 401 error, even if it's working with CURL and with Thunderbird. Then after this 401 I got some 404 errors when zimbra is retrying to sync the calendar.

On the IONIS side, in my account, I can see I got a connection from another software (not identified) than my Thunderbird, so it must be my zimbra connecting.

I tried some differents syntax when adding the calendar to Zimbra, but everytime I got a 401 error.

What could be my error ? Is it my Zimbra who got a problem ?

Maybe you have an idea about a bug in the Caldav code on the Zimbra side ?

Thanks a lot for your help !


   
Quote
Topic Tags
Matt
 Matt
(@matt)
Joined: 5 years ago
Posts: 41
 

Hello @r4v3n,

This is the code snippet regarding your error:

int status = response.getStatusLine().getStatusCode();
if (status >= 400) {
   throw new DavException("DAV server returned an error: "+status, status);
}

You can find the full source code here.

Basically, Zimbra sends an HTTP request and the DAV server replies with an HTTP error 401, which means that the client (the Zimbra server) is not authorized to get this resource.

I suggest checking the username and the password at first, then the other connection parameters and the permissions to access the resource.

If everything is OK, this means that there's probably an incompatibility between the DAV provider and Zimbra.

We're not aware of similar cases though.

If the DAV server is managed by you, maybe its logs can be more specific, you can also increase the logging level to debug so you'll have a trace of the full request/response dialogue and investigate this issue deeper.

Hope this helps.

This post was modified 3 years ago 2 times by Matt

   
ReplyQuote