Kalender-Sync (caldav) funktioniert nur vom Server zum PC bzw. Smartphone, aber nicht zurück zum Server

Hallo,

mein Kalender lässt sich nur Richtung Server -> PC (oder auch Server -> Smartphone) synchronisieren.
Die Gegenrichtung klappt nicht.

Schritte zum Reproduzieren
1. neuen Kalender in Thunderbird (Lightning 4.7.8) mit angezeigtem Link aus OC angelegt
2. Verbindung zum Server herstellen und Daten abholen -> OK
3. neuen Termin in Thunderbird eintragen -> keine Reaktion
4. bestehenden Termin in Thunderbird ändern -> keine Reaktion

Erwartetes Verhalten
Wenn ich einen neuen Termin in Thunderbird eingebe, sollte der Termin in Thunderbird und in der Kalenderansicht von OC angezeigt werden.

Aktuelles Verhalten
Es wird weder in Thunderbird, noch in der Webansicht von OC, ein neuer Termin angelegt.

Server-Konfiguration
Betriebssystem: Raspbian 8
Webserver-Typ: Apache 2
Datenbank-Typ: MariaDB
PHP-Version: 5.6.29-0
ownCloud-Version: 9.1.4
Von einer älteren ownCloud-Version aktualisiert oder neu installiert?: Neuinstallation
Sonderkonfigurationen (external storage, external authentication, reverse proxy, server-side-encryption): nein
Kalender: interner Kalender (Calendar 1.4.1)

ownCloud log (data/owncloud.log)
keine Informationen dazu gefunden

Thunderbird Fehlerkonsole

Zeitstempel: 15.04.2017 10:18:05
Fehler: CalDAV: Unexpected status adding item to privat_OC9: 404
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20170415T081742Z
LAST-MODIFIED:20170415T081802Z
DTSTAMP:20170415T081802Z
UID:d1c4fc84-050a-4229-9aed-ec86f86e5769
SUMMARY:Testtermin
DTSTART;TZID=Europe/Berlin:20170422T101000
DTEND;TZID=Europe/Berlin:20170422T111000
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
Quelldatei: file:///home/oesel/.thunderbird/gzppshta.all-in-1/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendar.js
Zeile: 699

file:///home/oesel/.thunderbird/gzppshta.all-in-1/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendar.js
Zeile: 699

cal.ERROR("CalDAV: Unexpected status adding item to " +
                              thisCalendar.name + ": " + responseStatus + "\n" +
                              serializedItem);
                    listenerStatus = Components.results.NS_ERROR_FAILURE;
                listenerDetail = "Server Replied with " + responseStatus;
            }

            // Still need to visually notify for uncached calendars.
            if (!thisCalendar.isCached && !Components.isSuccessCode(listenerStatus)) {
                thisCalendar.reportDavError(calIErrors.DAV_PUT_ERROR, listenerStatus, listenerDetail);
            }

            // Finally, notify listener.
            notifyListener(listenerStatus, listenerDetail, true);
        }
    };

    this.sendHttpRequest(itemUri, serializedItem, MIME_TEXT_CALENDAR, null, (channel) => {
        if (!aIgnoreEtag) {
            channel.setRequestHeader("If-None-Match", "*", false);
        }
        return addListener;
    }, () => {
        notifyListener(Components.results.NS_ERROR_NOT_AVAILABLE,
                       "Error preparing http channel");
    });
},

Ergebis von http://example.com/index.php/settings/integrity/failed:
No errors have been found.

Was mich ein bisschen irritiert ist, dass die Fehlerkonsole von Thunderbird Code 404 ausgibt (also Toter Link), obwohl ich ja Daten vom Server abholen kann.
Die Kalenderdaten werden mir ja erstmal richtig angezeigt, ich kann jedoch keinen neuen Termin anlegen oder einen bestehenden ändern.

Weiterhin macht mich stutzig, dass ich bei der Anlage eines neuen Kalenders in Thunderbird kein Passwort für OC eingeben muss.

Ich würde also eher darauf tippen, dass es sich um ein Berechtigungsproblem handelt, das Thunderbird den schlichtweg keine Änderung vornehmen darf.

Wenn ich Testweise einen Kalender neu einbinde und die Offline-Unterstützung in Thunderbird deaktivierte, bekomme ich diesen Fehlercode:

Beim Schreiben in den Kalender privat_OC9 ist ein Fehler aufgetreten!
Fehlercode: MODIFICATION_FAILED
Beschreibung: Status-Code: 2147500037, Die Anfrage kann nicht verarbeitet werden.
Server Replied with 404

Das Problem besteht sowohl unter Ubuntu 16.04. LTS (wie oben erwähnt mit Thunderbird), als auch mit meinem Android Smartphone.
Sprich es ist wohl kein direktes Problem des Betriebssystems oder von Thunderbird selber.

Generelle Informationen zu solchen CalDAV, CardDAV und WebDAV Problemen findest Du hier:

Durch diesen Thread solltest Du Dich erst mal komplett durcharbeiten und auch mal den Litmus test gegen Deinen Webserver laufen lassen.

Solche Probleme sind zu 99% durch Fehlkonfigurationen auf Webserver-Seite zu suchen. Eine generelle Lösung gibt es leider nicht, deswegen bleibt hier leider nur obige FAQ.

Das funktioniert so nicht, Du kannst nicht aus Thunderbird heraus einen Kalender in ownCloud erstellen. Du musst zuvor einen Kalender in ownCloud anlegen und dann Thunderbird auf die URL des neuen Kalenders konfigurieren.

Edit

Bei Lightning solltest Du auch beachten, dass es ja nach Webserver-Configuration (SPDY oder HTTP/2) bekannte Probleme gibt:

https://bugzilla.mozilla.org/show_bug.cgi?id=1106727

Hi kljhlkhglklfgh,

zuerst einmal muss ich meine Aussage korrigieren.
Ich meinte natürlich nicht einen neuen Kalender anlegen, sondern einen neuen Termin anlegen.

So, ich bin nun als erstes die Schritte unter https://central.owncloud.org/t/how-to-fix-caldav-carddav-webdav-problems/852?source_topic_id=7029 durchgegangen:

There are few common reasons for such a problem:
1. You are using an outdated version of the client (upgrade to the newest version, available here47, and try again).
Nein, es ist die neuste Version!
2. Rewrite module is not enabled / not configured or not working properly
> root@raspberrypi:/home/pi# a2enmod rewrite
> Module rewrite already enabled
3. On the server running owncloud, a separate WebDAV module is enabled, and it interferes with owncloud's built-in WebDAV module.
> Nicht das ich wüsste! Wie kann ich das prüfen?
4. You could have some required HTTP verbs disabled
> Nicht das ich wüsste! Wie kann ich das prüfen?
5. Your webserver has configured a Basic Auth authentication
> Auch hier habe ich meines Wissens nichts geändert. Wie kann ich das genauer prüfen?
6. Your webserver isn't passing your credentials to php in the standard way (You will see a message like "Sabre_DAV_Exception_NotAuthenticated No basic authentication headers were found"). See below for more info.
> Nein, es kommt keine Fehlermeldung wie oben angegeben.
7. You have a security software/module (like SELinux) running
> Nein. Die Prüfung nach SELinux ergab
> root@raspberrypi:/# sestatus → bash: sestatus: Kommando nicht gefunden.
> root@raspberrypi:/# cat /etc/sysconfig/selinux → cat: /etc/sysconfig/selinux: Datei oder Verzeichnis nicht gefunden
8. One or more module listen in this47 FAQ is installed / enabled
Hier die Ergebnisse dazu:
pi@raspberrypi:~ $ apachectl -V
[Tue Apr 18 22:03:44.113708 2017] [alias:warn] [pid 1390] AH00671: The Alias directive in /etc/apache2/sites-enabled/owncloud.conf at line 36 will probably never match because it overlaps an earlier Alias.
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Server version: Apache/2.4.10 (Raspbian)
Server built: Sep 17 2016 16:40:43
Server's Module Magic Number: 20120211:37
Server loaded: APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture: 32-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"

pi@raspberrypi:~ $ apache2ctl -M
[Tue Apr 18 22:08:20.448754 2017] [alias:warn] [pid 1398] AH00671: The Alias directive in /etc/apache2/sites-enabled/owncloud.conf at line 36 will probably never match because it overlaps an earlier Alias.
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Loaded Modules:
core_module (static)
so_module (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
filter_module (shared)
headers_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
negotiation_module (shared)
php5_module (shared)
rewrite_module (shared)
setenvif_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
status_module (shared)

Nachdem mir oben ein Modul "auth_basic_module (shared)" habe ich mal versucht, dieses zu deaktivieren, jedoch:

pi@raspberrypi:~ $ a2dismod auth_basic_module
ERROR: Module auth_basic_module does not exist!

Weiter:

You might be running ownCloud behind a reverse proxy; in that case you should ensure that your proxy is configured to pass WebDAV queries. See this forum thread for the case of the Pound reverse proxy: https://forum.owncloud.org/viewtopic.php?t=494937
> Nein.
You are using php in cgi mode on CentOS23.
> Nein.

Dann habe ich Litmus heruntergeladen und installiert.
An dem Punkt übrigens vorab die Frage, ob ich es auf dem Client oder auf dem Server installieren muss?
Ich hab es auf dem Client installiert, weil ich ja in der Kommandozeile die Zieladresse eingeben muss und befürchtet habe, dass es dadurch schon zu Problemen kommen kann.

Litmus-Report:
root@oesel-quadcore:/usr/src/litmus-0.13# litmus https://meine-domain.org/remote.php/dav/calendars/oesel-admin/personal/ USER PASSWORD
-> running basic':
0. init.................. pass
1. begin................. FAIL (Could not create new collection
/remote.php/dav/calendars/oesel-admin/personal/litmus/' for tests: 405 Method Not Allowed
Server must allow MKCOL /remote.php/dav/calendars/oesel-admin/personal/litmus/' for tests to proceed)
<- summary for
basic': of 2 tests run: 1 passed, 1 failed. 50.0%
See debug.log for network/debug traces.

Ich habe versucht, dass Problem mit MKCOL zu lösen, nur bin ich hier überhaupt nicht weitergekommen.
Was muss ich denn hier ändern, damit der Server MKCOL zulässt?

Anschließend habe ich es noch mit dem CalDAVTester probiert. Hier schlugen alle Tests fehl.

Ran 197 tests in 9.628s
FAILED (ok=0, ignored=22, failed=0, errors=175)

Den Hinweis mit SPDY und HTTP/2 habe ich ebenfalls verfolgt, aber auch hier lande ich in einer Sackgasse.
Ich hab mir die Diskussion inzwischen mehrfach durchgelesen und keinen Hinweis darauf gefunden, wie ich meinen Webserver testweise umstellen kann.

Ein Blick in die owncloud.log (nach einem weiteren Versuch einen bestehenden Termin in Lightning zu ändern) zeigt übrigens keinen neuen Eintrag an. Die Anfrage scheint also gar nicht erst bei owncloud anzukommen und im log registriert zu werden.

Irgendwie komme ich mit dem ganzen Thema überhaupt nicht weiter und habe immer den Eindruck, ich drehe mich nur im Kreis. Ziemlich frustrierend... :disappointed:

Litmus installation auf dem Client ist richtig (würde aber auch auf dem Server gehen), nur die URL die Du verwendet hast nicht. Die Richtigen wären:

http://example.com/remote.php/webdav (das ist der "alte" WebDAV Endpunkt)
http://example.com/remote.php/dav/files/BENUTZERNAME (das ist der "neue" WebDAV Endpunkt)

Fügt auch am besten noch den -k parameter zu litmus hinzu dass der Test nicht nach dem ersten Fehler abbricht.

OK, neuer Versuch

litmus -k https://meine-domain.org/remote.php/dav/files/oesel-admin USER PASSWORD

-> running basic':
0. init.................. pass
1. begin................. pass
2. options............... WARNING: server does not claim Class 2 compliance
...................... pass (with 1 warning)
3. put_get............... pass
4. put_get_utf8_segment.. pass
5. put_no_parent......... pass
6. mkcol_over_plain...... pass
7. delete................ pass
8. delete_null........... pass
9. delete_fragment....... pass
10. mkcol................. pass
11. mkcol_again........... pass
12. delete_coll........... pass
13. mkcol_no_parent....... pass
14. mkcol_with_body....... pass
15. finish................ pass
<- summary for
basic': of 16 tests run: 16 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running copymove':
0. init.................. pass
1. begin................. pass
2. copy_init............. pass
3. copy_simple........... pass
4. copy_overwrite........ FAIL (COPY-on-existing with 'Overwrite: T' should succeed (RFC2518:S8.8.4): 423 Locked)
5. copy_nodestcoll....... pass
6. copy_cleanup.......... pass
7. copy_coll............. pass
8. copy_shallow.......... pass
9. move.................. pass
10. move_coll............. pass
11. move_cleanup.......... pass
12. finish................ pass
<- summary for
copymove': of 13 tests run: 12 passed, 1 failed. 92.3%
-> running props':
0. init.................. pass
1. begin................. pass
2. propfind_invalid...... pass
3. propfind_invalid2..... pass
4. propfind_d0........... pass
5. propinit.............. pass
6. propset............... pass
7. propget............... pass
8. propextended.......... pass
9. propmove.............. pass
10. propget............... pass
11. propdeletes........... pass
12. propget............... pass
13. propreplace........... pass
14. propget............... pass
15. propnullns............ pass
16. propget............... pass
17. prophighunicode....... pass
18. propget............... FAIL (Property {http://example.com/neon/litmus/}high-unicode had value , expected 𐀀)
19. propremoveset......... pass
20. propget............... pass
21. propsetremove......... pass
22. propget............... pass
23. propvalnspace......... pass
24. propwformed........... pass
25. propinit.............. pass
26. propmanyns............ pass
27. propget............... pass
28. propcleanup........... pass
29. finish................ pass
<- summary for
props': of 30 tests run: 29 passed, 1 failed. 96.7%
-> running locks':
0. init.................. pass
1. begin................. pass
2. options............... WARNING: server does not claim Class 2 compliance
...................... pass (with 1 warning)
3. precond............... SKIPPED (locking tests skipped,
server does not claim Class 2 compliance)
-> 1 test was skipped.
<- summary for
locks': of 3 tests run: 3 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running http':
0. init.................. pass
1. begin................. pass
2. expect100............. SKIPPED (skipping for SSL server)
3. finish................ pass
-> 1 test was skipped.
<- summary for
http': of 3 tests run: 3 passed, 0 failed. 100.0%

Hallo,

hat irgendjemand noch ein Idee, was ich machen kann, bzw. wo das Problem liegen könnte?