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

Server
3

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: