Ich teste derzeit, ob ownCloud auf einem Webspace, über den ich einigermassen Kontrolle habe, ein Ersatz für DropBox sein kann.

Als Webspace habe ich mich erst einmal für Uberspace entschieden, weil ich

  • deren Philosophie sympatisch finde,
  • die Server quasi ums Eck in Frankfurt stehen (ja Leute, think Global, host Local chrchrch) und zuguterletzt
  • die Möglichkeiten der Konfiguration per Konsole/SSH so umfangreich sind, dass die Wahrscheinlichkeit, wegen irgendeiner Config-Sackgasse nicht weiter zu kommen, relativ gering ist - was dafür, dass es "nur" ein Shared-Hosting ist, schon ziemlich fett ist.

Das Einrichten der ownCloud ist im Wiki von Uberspace gut dokumentiert, und wenn man sich mit der Konsole und SSH nicht ganz fremd fühlt, kommt man da sehr schnell zu einer nutzbaren Installation.

Also habe ich meine knapp 1.2GB Daten aus dem mit der Dropbox synchronisierten Verzeichnis lokal in ein neues Verzeichnis verschoben, welches ich mittels des owCloud Desktop-Clients mit der frisch eingerichteten ownCloud auf dem Uberspace verbunden habe.

Soweit so gut, prompt fing der Desktop-Client die Synchronisation an, was bei einem mageren Upload von ca 250kbit/sec doch ein bisschen länger dauert.

Erste Überraschung: Einige Dateien können nicht synchronisiert werden, da sie "unerlaubte Zeichen" im Dateinamen enthalten. Es betraf bei mir ein Verzeichnis, in dem ich, bevor ich so etwas wie ReadItLater (jetzt: Pocket) benutzte, Bookmarkdateien abgelegt hatte - am Mac werden die als "blah blah Title wie in HTML Tag".webloc abgelegt - offenbar schmeckt das dem ownCloud Client nicht und er ignoriert da also einige der Bookmark-Dateien. Das ist nun für meinen Kram nicht so schlimm, aber wer weiss, wo/mit welchen anderen Dateien da Fehlerpotential lauert.

Zweite Überraschung: Neben den oben erwähnten Bookmark-Dateien gibt es noch eine andere Datei, die nicht gesyncht wird, und bei dieser wird kein Grund angegeben: Ich habe ein relativ kleines Truecrypt Containerchen in das ich Dateien wie Einnahme/Ausgabe Excelsheets reinlege, wenn ich daran von meheren Orten arbeite - diese Datei wurde nicht synchronisiert. Im Log von ownCloud steht kein Grund, in der "Aktivität" Ausgabe des Client steht kein Grund und mehrfaches Umbenennen des Containers, verschieben, löschen, wieder mit reinnehmen ins ownCloud Verzeichnis änderte an dem Verhalten nix.

Ich habe dann diese Datei per Webinterface auf den ownCloud Server hochgeladen, und das wurde dann anstandslos auf einem weiteren Rechner synchronisiert. Dort habe ich die Datei lokal gemountet und Inhalte darin modifiziert, und da war dann die dritte Überraschung: Schon das Mounten des Containers (noch nichts geändert, nichts gespeichert) veranlasst einen Upload der gesamten Container-Datei. Während man in dem gemounteten Container arbeitet, wird ebenfalls immer die gesamte Datei hochgeladen und schliesslich noch einmal, wenn man den Container unmountet.

OwnCloud kann derzeit kein Delta-basiertes Synchronisieren, sondern überträgt bei jeder Modifikation einer Datei die gesamte Datei, und das offenbar auch mehrfach - damit wird der Upstream ordentlich lahmgelegt. Ich habe ein bisschen danach gesucht und nur den wenig versprechenden Feature Request auf github gefunden, aus dem hervorgeht, dass es eher ein (Server)Protokoll Problem ist, als ein Problem von ownCloud und dass diese Änderung zwar nützlich wäre, aber eher nur mittelfristig angegangen wird. :-/

Zurück an meinem ersten Rechner habe ich übrigens die lokale Container-Datei gelöscht, Resultat: Nix, kein Synch. Dann habe ich eine andere Datei, die bereits erfolgreich synchronisiert wurde, gelöscht, damit wurde ein erneuter Synch ausgelöst und mit diesem wurde dann der bereits auf dem Server liegende Container ebenfalls runtergeladen und ist seitdem auch synchronisiert.

Ich habe keine Ahnung, warum diese Datei zunächst ignoriert wurde.

Mein Fazit bislang:

Es macht Spaß, sich relativ schnell ein einigermassen funktionierendes Cloudsystem hinzubauen. Und bei Uberspace sowieso.

Genau für meinen Use-Case mit dem verschlüsselten Container ist ownCloud wegen der komplett-Uploaderei aber nicht echt sinnvoll nutzbar, hier muss ich also entweder meinen Workflow anders gestalten oder die serverseitige Verschlüsselung, die ownCloud anbietet, nutzen und dafür keinen Truecrypt-Container mehr in die Cloud legen. Prima wäre natürlich, wenn ownCloud bald Delta-Synch, wie es zb Dropbox beherrscht, implementiert, aber da habe ich so meine Zweifel, das scheint eine größere Sache zu sein.

Neben diesem Use-Case habe ich mich noch nicht mit den anderen Möglichkeiten wie Photo-, Kontkate- und Kalender-Synchronisierung beschäftigt, das werde ich in den nächsten Tagen/Wochen angehen.

Generell erscheint es mir sinnvoll, über den eigentlichen Zweck solcher Clouddaten nachzudenken. Für reinen Datenaustausch mit anderen Personen/Geräten ist das gut geeignet (sofern die Dateinamen nicht durch das "verbotene Zeichen" Raster fallen), für eine von überall erreichbare Festplatte, auf der sich allerhand Zeug sammelt, was dann vielleicht auch nur dort liegt, ist mir das Ganze zu hakelig.

Für den Einsatz im Job werde ich weiterhin um Dropbox nicht herumkommen, da zu viele Bekannte und Kunden diese im Einsatz haben. Aber immerhin habe ich dort mal alles ausgeräumt, was nicht mit anderen geteilt wird. Nicht, dass da ein Sack Rice drüberstolpert, gell.

Update (1.5.2014)

Das mit dem Sync des Truecrypt Containers bleibt weiterhin rätselhaft. Nachdem die Datei nach den oben beschriebenen Anlaufschwierigkeiten nun auf meinen Geräten syncronisiert ist, habe ich, damit nicht jedesmal der Upstream lahmgelegt wird, sobald das Ding lokal gemounted ist, mir einen Workaround zurechtgelegt: Ich kopiere mir die Containerdatei erst aus dem OwnCloud Verzeichnis ins lokale Dateisystem, mounte sie von dort, mache meine Änderung an den Inhalten, unmounte das Ding und kopiere sie dann zurück ins ownCloud Verzeichnis.
Mit dem Ergebnis: Sie wird nicht syncronisiert. Erst wenn ich dann, und diese Erkenntnis ist ganz frisch, die Datei aus dem ownCloud Verzeichnis heraus mounte, wird der sync Vorgang angestossen. Es reicht sogar, sie nur zu mounten, keine Änderung an den Inhalten sind nötig. Mounten, kurz warten (der sync startet nicht gleich) und dann die Datei wieder unmounten, und das Ding wird mit der ownCloud syncronisiert.
Ich habe da leider zu wenig Ahnung, wie so eine Containerdatei funktioniert, hätte aber erwartet, dass eine Kopie der Datei, die lokal gemountet und deren Inhalte modifiziert wurden, beim zurückkopieren als geänderte, also zu syncronisierende Datei erkannt wird. Warum ein mounten der Datei direkt aus dem ownCloud Verzeichnis heraus das "sync mich" Signal aussendet, eine 'extern' geänderte Version der Datei beim Zurücklegen ins ownCloud Verzeichnis offenbar als 'nicht verändert, kein sync nötig' betrachtet wird, das verstehe ich nicht.

Update (12.1.2015)