Problems with TbSync in Thunderbird with Owncloud 10.3 CalDAV and CardDAV

Steps to reproduce
Connecting Thunderbird adressbook with TbSync as follows

Expected behaviour
Get all the contacts from owncloud server

Actual behaviour
Tell us what happens instead
HTTP Error 500

<d:propfind xmlns:d=“DAV:”><d:prop><d:current-user-principal /></d:prop></d:propfind>


<?xml version="1.0" encoding="utf-8"?>

<d:error xmlns:d=“DAV:” xmlns:s=“”>
<s:message>explode() expects parameter 2 to be string, null given</s:message>

Server configuration

Operating system: ubuntu server 16.04 lts
Web server: apache
Database: mysql
**PHP version:**7.0
ownCloud version: 10.3.0 (stable)
Updated from an older ownCloud or fresh install: started with 9.0
Where did you install ownCloud from: repository

This is what the developer of TbSync said:
I am not sending an invalid request. The request triggers a php error (or something) because they use the explode() method with wrong parameters.

I cannot fix this. Standards are standards for a reason: interoperability.

So it would be nice if owncloud developers can fix this!


maybe you can do a posting in explaining why you have chosen the “Server-Apps” category which is about additional apps installed on your ownCloud for a problem with the ownCloud server? I think this could help the ownCloud team to improve the forums category description so that the correct categories are chosen.

For your problem itself you could have used the forums search like:

to find an existing thread for this message:

1 Like

For me it’s not easy to know where is the cut-off between the server application and the addon like contacts in this case.
The developer of TbSync found a solution for me and thats what he mailed me:
The bug is known at owncloud.
It is a bug in the underlaying SabreDav. You can fix it yourself by doing the changes to lib/composer/sabre/dav/lib/CardDAV/Plugin.php in your owncloud installation as described here:

For the right information click on “” in the frame!

I changed:
$contentType = $propFind->get(’{DAV:}getcontenttype’);
– delete 3 lines –

  •    list($part) = explode(';', $contentType);*
  •    if ('text/x-vcard' === $part || 'text/vcard' === $part) {*
  •        $propFind->set('{DAV:}getcontenttype', 'text/x-vcard');* 

– insert following lines

  •     if (null !== $contentType) {
  •         list($part) = explode(';', $contentType);
  •         if ('text/x-vcard' === $part || 'text/vcard' === $part) {
  •             $propFind->set('{DAV:}getcontenttype', 'text/x-vcard');
  •         }

The changes to the second file in that link are not needed, I think.

  • For my problem it was not needed to fix second file. Synchronisation is working between Owncloud and Thunderbird via TbSync is working fine now.

Hello - I had the same error , fixed the error with the “patch” of /sabre/dav/lib/CardDAV/Plugin.php. But now I same error Http Error 500 but the TBSync Log shows a message javascript should be activated after

. as i also got a http error 500 on with the same message javascript should be enaled on my android phone using DAVx5, I removed the patch. so at least I can sync my contacts with android phone

sorry there are lines missing -
the log shows a couple of script lines - the last one is
script src = /owncloud/core/js/files/client.js?v=
Than the message body id = body loging
dev is = nojavascript
This is the case for both TBsync and DAVx5

Problem Fixed
I just changed Plugin.php
Line 689 OLD list($part) = explode(’;’, $contentType);
Line 689 New list($part) = explode(’;’, $contentType ?: ‘’);
As suggested here :
I am now able to sync with thunderbird TBSync

I changed plugin.php as discripted.
And I have no more problems with TBsync, and DAVx5 on my android phone is syncing and on my iphone integrated CardDAV is syncing fine with the ownclound contacts on two different accounts.


After upgrade I had to do the same to get TBsync to work!
gedit Plugin.php
Ctrl-F list($part) = explode(’;’, $contentType);
change into
list($part) = explode(’;’, $contentType ?: ‘’);
What I don’t understand is, the bug was known bei owncloud, and they didn’t fix it right!


i don’t think this is correct. From what i have read in the links posted above the bug wasn’t known by ownCloud and only got reported after the release of ownCloud 10.3.0 to them via (ownCloud 10.3.0 release: 15.10.2019, bugreport: 19.10.2019).

I think because it was a bug in a 3rd party library used by ownCloud it could take some time until the fixed library is included in ownCloud. Maybe you can ask in when this will happen?