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.

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.

/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.

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.