Ich bin ein riesiger Fan von ownCloud und lasse inzwischen unsere externen Datei-Zugriffe von Kunden ebenso wie die Adress- und Terminverwaltung nur mehr über unseren eigenen ownCloud-Server laufen; auch wenn es manchmal noch Haken und Ösen gibt (vor allem nach Updates) so werden wir dafür dadurch entschädigt, dass wir die volle Kontrolle über unsere Daten haben.

Nach dem letzten Update hatten wir genau so einen Haken: im Webbrowser hat weiterhin alles perfekt funktioniert, im Windows-Client wurde zwar synchronisiert, aber es kam immer wieder zu kryptischen Fehlermeldungen (“ungültiges XML”). Besonders schlimm hat es aber die CardDAV- und CalDAV-Synchronisation unter Android getroffen: die funktionierte gar nicht mehr.

Nachdem das Problem schnell gelöst werden musste habe ich mich etwas in die Tiefen des ownCloud-Systems begeben. Warum im Webbrowser alles funktionierte, nicht jedoch die Clients war relativ schnell klar: ownCloud verwendet zur Kommunikation den WebDav-Standard (siehe auch http://webdav.org/), auf den wiederum CalDAV- und das WebDav-Protokoll aufsetzen - der Hund musste also irgendwo im Umfeld der WebDAV-Kommunikation begraben sein.

WebDav gibt es schon lange und ist für Internet-Verhältnisse eigentlich nichts wirklich neues: das HTTP/1.1-Protokoll wird einfach so erweitert dass es zusätzlich zu den üblichen GET- und POST-Requests eine Reihe von weiteren Anfrage-Methoden unterstützt werden. Läuft der Server unverschlüsselt über HTTP so könnte man also für erste Versuche einfach mit telnet webdav-server 80 seine eigenen Request absetzen. Aber natürlich kann man auf unsere ownCloud-Installation nur über HTTPS zugreifen…

Basis-Checks

Eine gut Übersicht über erste Checks, die man jedenfalls machen sollte, findet sich hier: https://doc.owncloud.org/desktop/1.7/troubleshooting.html.

Hier findet man auch gleich den Hinweis, dass man die allgemeine Funktionalität des WebDAV-Clients durch den Aufruf von

https://owncloud-server/remote.php/webdav

bzw. wenn ohne Verschlüsselung durch Aufruf von:

http://owncloud-server/remote.php/webdav

in einem beliebigen Browser testen kann. In unserem Fall: ja, alles bestens, aber auch nur bedingt aussagekräftigt, da in Wirklichkeit der WebDAV-Zugriff auf HTML umgesetzt wird - eben damit der Browser etwas damit anfangen kann:

Aber zumindest eine Fehlerquelle ausgeschlossen.

Windows-Client

Wenn man auf das ownCloud-Symbol in der Statusleiste:

doppelklickt (oder rechte Maustaste und im Kontextmenü “Einstellungen…” wählen) so öffnet sich das Fenster des Windows-Clients:

Hier steht allerdings nur eine allgemeine “geht/geht nicht”-Information. Allerdings gibt es einen versteckten Hotkey: im Fenster des Windows-Clients einfach die Taste F12 drücken so öffnet sich ein neues Fenster mit einem (äußerst ausführlichen…) Protokoll:

Zum Glück gibt es eine Suchfunktion - das Protokoll wird nämlich sehr schnell sehr umfangreich…

Die hardcore-Variante: cadaver

cadaver ist trotz seines leicht makabren Namens ein äußerst mächtiger Kommandozeilen-WebDAV-Client für Linux/Unix. In den meisten Distributionen reicht ein:

zypper in cadaver

bzw.

apt-get install cadaver

um es auf die Platte zu befördern.

Mit cadaver https://owncloud-server/remote.php/webdav/ verbindet sich der Client zum Server und fragt die Zugangsdaten (Benutzername/Kennwort) an, mit ls kann man sich den Inhalt des Basisverzeichnisses anzeigen lassen, help zeigt die verfügbaren Kommandos und help Kommando eine Kurzbeschreibung des jeweiligen Befehls:

Richtig interessant wird die Sache aber mit den Debug-Optionen; die Hilfe dazu kann man sich mit set debug anzeigen lassen, mit set debug socket,http,xml,httpauth,cleartext (Achtung, keine Leerzeichen!) aktiviert man alle Debugging-Ausgaben. Wenn man jetzt wieder ein ls macht so wird die Sache schon “etwas” ausführlicher:

(viele, viele Zeilen gelöscht)

Auflösung

Falls es jemanden interessiert: unsere Probleme rührten von mod_security2 her; sobald ich dieses für den ownCloud-Server deaktiviert hatte (einfach im VirtualHost-Eintrag von ownCloud

<IfModule mod_security2.c>
    SecRuleEngine Off
</IfModule>

einfügen; sollte auch über eine .htaccess funktionieren) lief wieder alles wie am Schnürchen. Natürlich ist das keine Dauerlösung (zumindest für mich), d.h., jetzt kommt erst die Knochenarbeit herauszufinden, welche der mod_security2-Regeln Verursacher der Probleme ist und nur diese gezielt zu deaktivieren.