Die eigene Cloud: Nextcloud auf einer Synology DiskStation mit der PhotoStation kombinieren (DSM 6)

In dieser kleinen Anleitung zeige ich, wie ihr eure Fotos per Nextcloud verwalten könnt, und sie trotzdem mit der Photo Station betrachten könnt. Es gibt viele Gründe Nextcloud anstatt der Cloud Station zu benutzen, der höhere Funktionsumfang und das Webinterface sind nur zwei davon. Synology bietet ein eigenes Upload-Tool für Fotos an, in die Cloud Station (inklusive Desktop-Client) ist das ganze aber nicht eingebunden. Aber auch mit Nextcloud ist die Einbindung nicht ganz so einfach wie man zuerst vermuten mag.

Update Oktober 2017: Ich habe das Script jetzt durch eine etwas simplere Lösung ersetzt. Zwecks Vollständigkeit lasse ich den alten Beitrag unter der aktuellen Lösung bestehen. Vielleicht hilft das Script dem ein oder anderen bei anderen Problemen, bzw. helfen meine Ausführungen zur PhotoStation, diese besser zu verstehen.

Lösungsansätze

Die eigenen Fotos mit Nextcloud zu synchronisieren ist gar kein Problem, allerdings müssen Fotos, damit sie von der Photo Station angezeigt werden unter /photo abgespeichert sein (und zwar nur da, im Gegensatz zur Video Station lassen sich keine anderen Ordner einbinden). Wer sich für die Hintergründe und die Details von Photo Station und Medienindizierung interessiert bzw. wissen will, warum die Lösung so komplex ist, der kann hier gerne weiterlesen. Wer einfach nur die Lösung möchte, kann direkt zu Das finale Script springen.
Wie ihr Nextcloud auf eurer DiskStation zum Laufen bringt könnt ihr hier nachlesen.

Die simple Lösung über Netzfreigabe

Bis jetzt war ich mit dem unten beschriebenen Script sehr zufrieden. Vor kurzen habe ich aber angefangen die PhotoStation  nicht nur zum Betrachten zu verwenden, sondern auch zur Organisation. Ich habe Tags vergeben und musste feststellen, dass diese nach der Synchronisation wieder verschwunden waren. Anders als die Thumbnails waren diese nicht persistent. Ich vermute, dass die Tags in einer Datenbank hinterlegt werden, die durch das rsync-Script gelöscht wird. Ein Ignorieren dieser Datenbankdatei könnte das Problem beheben. Da ich aber immer wieder Probleme mit dem Script habe und das Recherchieren und Nachbessern leid bin, habe ich mich nach Alternativen umgesehen. Laut Synology-Dokumentation sollte am besten der Foto Uploader verwendet werden. Dieser unterstützt aber nur manuelle Uploads. Als Alternativen werden die Cloud Station und Netzwerkfreigaben erwähnt.

  1. Als Erstes müsst ihr die SMB-Freigabe auf eurer DiskStation aktivieren. Geht dazu im Kontrollzentrum auf „Freigabe Dienste“ und setzt dort den Haken bei SMB.
  2. Testet jetzt ob ihr die Netzfreigabe erreichen könnt, in dem ihr \\<DSName>\photo im Dateiexplorer eures Rechners eingebt. Geht sicher, dass der User, den ihr zum Anmelden benutzt, schreib und lese Rechte für \photo besitzt.
  3. Jetzt könnt ihr \photo als Netzlaufwerk hinzufügen. Geht dazu im Dateiexplorer auf „Netzlaufwerk hinzufügen“. Wählt einen Laufwerksbuchstaben und gebt wieder \\<DSName>\photo als Adresse ein. Auf \photo kann jetzt wie auf ein normales Laufwerk zugegriffen werden.

Jetzt könnt ihr eure Nextcloud ins Spiel bringen.

  1. Habt ihr bereits eine oder mehrere Ordnersynchronisationen im Nextcloud-Client eingerichtet, müsst ihr diese ändern. Habt ihr noch keine, könnt ihr Punkt 2 überspringen.
  2. Deaktiviert die Ordnersynchronisation in eurem Nextcloud-Client. Habt ihr eine Ordnersynchronisation für eure gesamte Cloud löscht diese (lokale Daten bleiben erhalten). Habt ihr einzelne Synchronisationen für unterschiedliche Ordner, löscht nur die, die ihr auch in \photo haben wollt.
  3. Legt jetzt ein oder mehrere (abhängig von eurer Ordnerstruktur bzw. euren Wünschen) Ordnersynchronisationen für eure Fotos an. Als lokalen Ordner wählt ihr das Netzlaufwerk \photo. Solltet ihr mehrere Nextcloud-Ordner in der PhotoStation haben wollen, müsst ihr für jeden einen Unterordner im Netzlaufwerk anlegen.
  4. Jetzt könnt ihr weitere Ordnersynchronisationen für eure restlichen Ordner anlegen.

Fotos könnt ihr jetzt ganz normal im Netzlaufwerk abspeichern, der Nextcloud-Client synchronisiert sie mit eurer Cloud und die PhotoStation kann ebenfalls darauf zugreifen.

Vorteile:

  • einfach und schnell einzurichten
  • geringer Wartungsaufwand
  • Thumbnailgenerierung und Indizierung läuft schnell und zuverlässig
  • gelöschte Elemente werden auch richtig aus der PhotoStation und den Indexdatenbanken gelöscht
  • Tags bleiben bestehen

Nachteile:

  • doppelter Speicher für Fotos wird benötigt
  • muss für jeden Rechner der Fotos hinzufügen soll extra eingestellt werden
  • sollen Fotos auch außerhalb des LANs hinzugefügt werden können, muss die Netzfreigabe im Internet freigegeben werden, da das Netzlaufwerk sonst nicht verfügbar ist
    • Eine mögliche „Lösung dieses Problems“: auf dem Rechner zuhause die Freigabe wie oben beschrieben einrichten, auf dem Laptop die Ordnersynchronisation ohne Netzlaufwerk einrichten. Bilder die unterwegs hinzugefügt werden, werden mit der Cloud synchronisiert. Sobald ihr den Rechner zuhause startet, lädt der Nextcloud-Client die Fotos in das Netzlaufwerk und ihr habt sie auch in der PhotoStation. Die Lösung kann auch nur auf einem Laptop eingerichtet werden.

Ich habe die Dateifreigabe nicht extern freigegeben. Da ich Fotos nur am Standrechner zuhause bearbeite, kann ich mit dieser Einschränkung leben. Ich werde aber auch nochmal den Versuch mit dem external Storage in Nextcloud wagen und die Ergebnisse hier berichten. Sollte euch die Lösung nicht passen, könnt ihr gerne den Rest des Artikels lesen.

 

—— Hier beginnt der ursprüngliche Artikel ——

 

\photo als externe Ressource in Nextcloud einbinden

Achtung: Diese Lösung habe ich noch unter Owncloud/Nextcloud 9 getestet, die Schilderungen sind eventuell nicht mehr 100%ig aktuell.
Nextcloud bietet die Möglichkeit externe Verzeichnisse/Laufwerke (Speicherorte die außerhalb vom Nextcloud-Data-Verzeichnis liegen) einzubinden. Im Nextcloud-Webinterface kann das gewünschte Verzeichnis als WebDAV oder SMB eingefügt werden, vorausgesetzt die App „External storage suppport“ ist aktiviert. Leider funktioniert diese Lösung nicht wie gewünscht. Die Einrichtung ist mühsam und scheitert oft an fehlenden Rechten. Die Photo Station ist sehr zickig (zickiger als alle anderen Synology-Pakete), Bilder die über Nextcloud (genauer gesagt per share, also WebDAV oder SMB) in /photo abgelegt werden, werden nicht indiziert. Zumindest nicht automatisch. Der Photo Station wäre es generell am liebsten, die Fotos würden nur über den Foto-Uploader hochgeladen werden. Andere Programme die auf /photo zugreifen, mag die Photo Station auch nicht. Fotos die auf diese weise synchronisiert werden, sind in der Photo Station meist nicht sichtbar. Aufgrund von unpassenden Zugriffsrechten lassen sie sich nicht öffnen und Thumbnails werden keine erstellt da die automatische Indizierung nicht anspringt. Selbst wenn man die Indizierung manuell starten würde (oder Zeitgesteuert), gibt es immer noch das Problem, dass die Photo Station beleidigt reagiert, wenn man per Nextcloud Dateien verschiebt oder löscht. Außerdem legt die DiskStaion selbst noch diverse Verzeichnisse an (z.B. Recylce sofern der Papierkorb aktiviert ist sowie das @eaDir in dem die Metadaten gespeichert werden. Das mag dann wiederum die Nextcloud nicht.

Fotos vom Nextcloud-Data-Verzeichnis nach /photo kopieren

Eine weitere Lösung wäre, die synchronisierten Fotos aus dem, von Nextcloud verwalteten Speicherort nach /photo zu kopieren/synchronisieren. Hier eignet sich am besten ein Skript basierend auf rsync, das über die Synology-Aufgabenverwaltung regelmäßig ausgeführt wird. Basierend auf dem Backup-Script von Tommes, habe ich ein Script ausgearbeitet, dass den von Nextcloud verwalteten Fotoordner mit /photo abgleicht. Das Script hat nach einigen Anpassungen auch funktioniert und auch die Indizierung der Fotos wurde ausgeführt.
Nachteil dieser Lösung, ist der doppelte Speicherplatzbedarf für die Fotos, einmal im Nextcloud-Data-Verzeichnis und einmal in /photo.
Möchte man kein reines Kopieren, sondern auch das Löschen nicht mehr vorhandener Fotos und hat man mehrere Quellordner, müssen diese als Unterordner des Ziels mitsynchronisiert werden. Es ist nicht möglich, den Inhalt mehrerer Ordner in einem einzelnen Ordner zusammen zu führen, da jede Quelle einzeln synchronisiert wird. Der nachfolgende Sync würde also den vorherigen überschreiben. Alternativ könnte man die Inhalte aller Quellen in ein temporäres Verzeichnis kopieren und dieses dann synchronisieren und danach das temporäre Verzeichnis wieder löschen. Das würde aber zusätzlichen Speicher für den Vorgang erfordern.

Synology-spezifische Ordner werden aus dem Sync ausgeschlossen. In der Quelle nicht vorhandene Dateien gelöscht und vorher noch in einen Backup-Ordner gelegt. Das komplette Script findet ihr – inklusive Erklärung – weiter unten.
Nach einiger Zeit habe ich festgestellt, dass die Lösung doch nicht zu 100% funktioniert. Gelöschte Dateien wurden immer noch angezeigt außerdem konnten verschobene/gelöschte Ordner nicht synchronisiert werden. Verschobene Ordner wurden zwar am neuen Ort angelegt, konnten am alten Ort aber nicht gelöscht werden. Nach einiger Recherche und unzähligen Tests habe ich das Problem gefunden.
Für das Indizieren von Dateien legt die DiskStation Datenbanken an, diese werden in den @eaDir-Verzeichnissen gespeichert und zwar ein @eaDir im Wurzelverzeichnis sowie je eines pro Unterordner. Diese @eaDir sowie auch die @Recycle werden beim synchronisieren nicht gelöst (sie sind bei rsync als zu Ignorieren eingetragen), daher kann rsync den Ordner nicht löschen, da dieser nicht leer ist. Würde man die Ordner nicht ignorieren, würden sie beim Synchronisieren gelöscht werden, da sie ja in der Quelle nicht vorhanden sind. Die DiskStation macht in diesem fall auch keine automatische Indizierung mehr, da die Hauptdatenbank im Wurzelverzeichnis unverändert bleibt. Hier würde wieder eine händische Indizierung nachhelfen, dies würde aber /photo komplett neu indizieren und je nach größe kann das ziemlich lange dauern und benötigt auch fast alle Ressourcen der DiskStation.
An dieser Stelle wurde ich etwas kreativ und habe das Skript dahingehend erweitert, dass Ordner, in denen nur noch das @eaDir vorhanden ist, gelöscht werden. So gut dieser Schritt auch funktioniert hat, in der Photo Station war davon nichts zu merken. Die Dateien und Ordner waren zwar physikalisch nicht mehr vorhanden, die PhotoStation hat sie aber dennoch aufgelistet. Grund dafür: die noch vorhandenen Einträge in den Indizierungsdatenbanken. An diesem Punkt wollte ich dann eine erneute Indizierung in kauf nehmen. Aber anstatt sie über die PhotoStation/DSM händisch anzustoßen, wollte ich das per Script erledigen. Ein bisschen recherchieren hat auch ergeben, dass die Indizierung über die Kommandozeile steuerbar ist und zwar viel detaillierter als über die GUI.

So kann man anstatt einer kompletten Neuindizierung auch nur eine Aktualisierung der Indizierungsdatenbanken durchführen. Das geht viel schneller und ressourcenschonender. Ich habe mein Script dementsprechend aktualisiert, geändert hat sich in der Photo Station aber gar nichts. Weitere Recherchen haben ergeben, das gelöschte Elemente von der Aktualisierung nicht erkannt werden, sondern nur neu hinzugekommene Dateien (im gegensatz zur Re-Indizierung über DSM, wo die Indexdatenbank komplett gelöscht und neu angelegt wird). Die Aktualisierung wird nur einseitig durchgeführt. Gibt es zu einer Datei einen Eintrag in der Datenbank passiert nichts, gibt es noch keinen Eintrag, wird einer angelegt. Umgekehrt wird aber nicht geprüft ob zu einem Eintrag auch eine Datei vorhanden ist.
Glücklicherweise bietet synoindex noch weitere Optionen. Mit synoindex können Ordner und einzelne Dateien gezielt aus der Indexdatenbank gelöscht werden.

Ich habe das Script, dass die verwaisten Ordner löscht um diese Zeile erweitert und siehe da. Nach dem Verschieben/Löschen von Ordnern, ist auch die Photo Station ordentlich aufgeräumt.

Bis hierhin habe ich meinen Workflow gerade aufgebaut und die Ordnerstruktur passend angelegt und bin damit lange Zeit gut gefahren. Vor kurzem habe ich aber begonnen meine Bilder weiter zu bearbeiten und für verschiedene Plattformen anzupassen. Etwas, das ich bis dahin nicht gemacht habe, kommt seit dem häufig vor: das Löschen einzelner Dateien. Als ich die Photo Station nach einiger Zeit wieder einmal aufgerufen habe, ist mir schnell ein logischer Fehler in meinem Lösungsansatz aufgefallen. Das Script findet nur verwaiste Ordner anhand des Inhalts aber gelöschte Dateien (aus Ordnern die weiterhin Dateien enthalten) hinterlassen aber ebenfalls verwaiste Indexeinträge. synoindex -R hilft hier, wie schon erwähnt nicht weiter, für synoindex -d müsste man die gelöschten files kennen.
Zum Glück hat auch hier schon jemand anderes ein ähnliches Problem gehabt und eine entsprechende (simple) Lösung parat. Die Indexdatenbank ist, wie der Name schon sagt nur eine Datenbank. Man kann also alle Dateinamen aus der Datenbank auslesen und prüfen, ob diese Datei tatsächlich existiert, wenn nicht, wird der Eintrag mit synoindex -d filepath gelöscht.

Das Script ist jetzt in der Lage alle Arten von Verunreinigungen in der Indexdatenbank aufzuräumen und kann auch für /movie und /music eingesetzt werden (mit oder ohne dem rsync part).

In der Zwischenzeit habe ich noch eine kleine Optimierung gefunden. Mit grep deleted erhält man eine Liste aller von rsync gelöschten Dateien. Diese können dann gezielt aus der Indexdatenbank entfernt werden, ohne über alle Dateien iterieren und deren Existenz überprüfen zu müssen. Sobald ich das getestet und in mein Script eingebaut habe, werde ich diesen Artikel aktualisieren.

Achtung: Tags (und eventuell auch andere Metadaten) die ihr in der PhotoStation hinzufügt überleben den Synchronisationsvorgang nicht. Vermutlich muss die Datei in der die Tags gespeichert werden in die Ignore-Liste von rsync aufgenommen werden.

Das finale Script

Hier findet ihr das komplette, dokumentierte Script. Wie schon erwähnt basiert es auf dem Backup-Script von Tommes und hat einige zusätzliche Features die nicht unbedingt notwendig sind.

Das aufräumen der Indexdatenbank, also das entfernen verwaister Indizes gelöschter Dateien, habe ich derzeit noch in einem eigenen Script.

Optimierung

  • Für das Entfernen verwaister Indizes werden alle Datei-Indizes aus der Datenbank abgefragt und zu jedem Index getestet, ob die entsprechende Datei existiert und ggf. gelöscht. Je schwächer der Prozessor der DiskStation und je größer die Datenbank, umso länger dauert der Vorgang. Ab welchen Dimensionen das ganze auf der DS spürbar bzw. störend wird, kann ich nicht sagen. Wie schon erwähnt, ist es aber möglich, die von rsync gelöschten Dateien aufzulisten. Anhand der Liste lassen sich dann die Indizes löschen.
    Das Problem übriggebliebener Ordner wird dadurch aber nicht gelöst, diese können durch rsync nicht gelöscht werden und zusätzlich zum Index muss auch der Ordner selbst gelöscht werden. Um das rekursive Durchsuchen der Ordner kommt man wohl nicht herum.
  • rsync legt derzeit noch Backups der gelöschten Dateien an. Da Nextcloud gelöschte Dateien selber verwaltet, ist das Backup nicht notwendig. Wenn ihr euch sicher seid, dass das Script ordentlich läuft, könnt ihr die Backup-Option aus dem rsync-Command nehmen.
  • Der Sync-Teil des Scripts enthält immer noch einige Sicherheitschecks aus dem Originalscript. Wenn sowohl der Nextcloud-Data-Ordner als auch /photo auf der selben DS liegen und nicht verschlüsselt sind/ausgehängt werden, könnten diese Checks entfernt werden, das Script wird dadurch übersichtlicher, Performance gewinnt man dadurch aber kaum.

 

Ich bin kein Freund von Shell-Scripting/Linux, ich befasse mich nur damit, wenn’s wirklich nicht anders geht. Solltet ihr also einfachere, schnellere oder kürzere Lösungen haben, postet doch einfach einen Kommentar.

Sonstige Lösung

Es gibt sicher noch die ein oder andere Möglichkeit die Daten aus dem Nextcloud-Data-Ordner nach /photo zu spiegeln. Da hier meist Probleme mit Nextcloud oder aber der Photo Station und dem Indexing entsteht, hab ich hier nicht mehr weiter recherchiert. Solltet ihr eine andere Lösung haben, könnt ihr sie uns gerne mitteilen.

Quellen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.