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:

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 How to fix CalDAV|CardDAV|WebDAV problems 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: ownCloud Central
> 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’:
  16. init… pass
  17. begin… pass
  18. copy_init… pass
  19. copy_simple… pass
  20. copy_overwrite… FAIL (COPY-on-existing with ‘Overwrite: T’ should succeed (RFC2518:S8.8.4): 423 Locked)
  21. copy_nodestcoll… pass
  22. copy_cleanup… pass
  23. copy_coll… pass
  24. copy_shallow… pass
  25. move… pass
  26. move_coll… pass
  27. move_cleanup… pass
  28. finish… pass
    ← summary for copymove': of 13 tests run: 12 passed, 1 failed. 92.3% -> running props’:
  29. init… pass
  30. begin… pass
  31. propfind_invalid… pass
  32. propfind_invalid2… pass
  33. propfind_d0… pass
  34. propinit… pass
  35. propset… pass
  36. propget… pass
  37. propextended… pass
  38. propmove… pass
  39. propget… pass
  40. propdeletes… pass
  41. propget… pass
  42. propreplace… pass
  43. propget… pass
  44. propnullns… pass
  45. propget… pass
  46. prophighunicode… pass
  47. propget… FAIL (Property {http://example.com/neon/litmus/}high-unicode had value , expected 𐀀)
  48. propremoveset… pass
  49. propget… pass
  50. propsetremove… pass
  51. propget… pass
  52. propvalnspace… pass
  53. propwformed… pass
  54. propinit… pass
  55. propmanyns… pass
  56. propget… pass
  57. propcleanup… pass
  58. finish… pass
    ← summary for props': of 30 tests run: 29 passed, 1 failed. 96.7% -> running locks’:
  59. init… pass
  60. begin… pass
  61. options… WARNING: server does not claim Class 2 compliance
    … pass (with 1 warning)
  62. 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’:
  63. init… pass
  64. begin… pass
  65. expect100… SKIPPED (skipping for SSL server)
  66. 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?