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 September 2018: Ich habe das Problem mit dem User und den verschwindenden Ordnern gelöst und einige neue Erkenntnisse ergänzt.
Update März 2018: Ich habe mich noch einmal mit dem externen Speicher der Nextcloud befasst und den Beitrag dahingehend aktualisiert.
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 Photo Station, 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). Ich habe im Laufe der Zeit verschiedene Lösungen ausprobiert, die einen Aufwändiger als die anderen. Alle haben gewisse Vor- und Nachteile, leider habe ich noch keine perfekte Lösung gefunden.

\photo als externen Speicher in der Nextcloud (bevorzugte Lösung)

Nachdem der Speicher auf meiner DiskStation etwas knapp wurde, habe ich diese etwas aufgeräumt und wieder etwas Platz geschafft, dabei ist mir wieder der doppelte Speicherbedarf meiner Fotos eingefallen. Der ist zwar nicht besonders groß, dennoch ist die Lösung über die Netzfreigabe nicht sehr sauber. Außerdem habe ich, anders als erwartet, doch hin und wieder etwas an meiner Fotosammlung auf Rechnern geändert, die nicht auf die Freigabe zugreifen. Diese Änderungen landeten erst in der Photo Station, wenn ich meinen Standrechner zuhause hochgefahren habe. Also habe ich mich wieder mit dem externen Speicher der Nextcloud auseinandergesetzt. Die Photo Station hat in der letzten Zeit einige Updates erhalten und ist jetzt viel weniger zickig. Das Hinzufügen der Fotos und anlegen der Thumbnails funktioniert jetzt auch perfekt, wenn Dateien auch über andere Wege als den Photo Uploader nach \photo finden. Wie das ganze funktioniert könnt ihr hier nachlesen.

Einrichten

1. 1. Habt ihr schon eine Synchronisation zwischen Nextcloud und \photo eingerichtet, beendet bzw. löscht diese. Ich rate euch, eine Sicherungskopie eurer Fotos anzulegen.
   2. Loggt euch in den DSM eurer DiskStation ein.
   3. Installiert das Paket WebDAV Server über die Paketverwaltung. Nextcloud erlaubt zwar auch externen Speicher über SMB einzubinden. In der Dokumentation steht aber, dass das nur auf Windows-Servern gut funktioniert. Die DiskStation läuft auf einem Linux/Unix-System. Ich habe SMB ausprobiert, es aber nicht geschafft. WebDAV funktioniert einwandfrei.
   4. Öffnet den WebDAV Server und geht sicher, dass die Freigabe aktiviert ist.
   5. Loggt euch in das Webinterface eurer Nextcloud ein (achtet darauf euch mit einem Administrator einzuloggen).
   6. Installiert das Modul External Storage unter Apps.
   7. Geht jetzt in die Einstellungen, dort solltet ihr zwei Mal den Punkt Externen Speicher finden einmal unter Persönlich und einmal unter Verwaltung. Geht auf den Eintrag unter Verwaltung.
   8. Hier könnt ihr jetzt den externen Speicher einrichten, entweder für alle Nextcloud-User oder nur für bestimmte oder nur für bestimmte Gruppen.
      • Vergebt einen Odernernamen, der Name, den ihr hier eingebt, wird in der Cloud angezeigt und ist frei wählbar.
      • Wählt aus dem Dropdown WebDAV aus, es erscheinen jetzt weitere Eingabefelder.
      • Als Authentifizierung wählt Benutzername und Passwort.
      • Als URL* wählt ihr “http://127.0.0.1:5005” aus. Sofern ihr die Nextcloud auf der DiskStation laufen habt. Hier hat bei mir nur der Localhost funktioniert, die LAN-IP 192.168.X.X bzw. der Name der DiskStation haben nicht funktioniert. Wichtig ist es, denn Port nicht zu vergessen.
      • Als entfernter Unterordner gebt ihr “photo” ein, ohne den “\”. Solltet ihr nur einen Unterordner von \photo verwenden wollen (z.B. einen Unterordner pro NC-User) gebt diesen einfach mit an: “photo\Unterordner”.
      • Jetzt müsst ihr noch Benutzer und Passwort für die DiskStation angeben**.
      • Shares die im Adminbereich angelegt werden, sind per Default für alle Nextcloud-Benutzer sichtbar. Unter Verfügbar für kann der Zugriff auf einen Benutzer, einzelne Benutzer oder auf eine/mehrere Gruppen beschränkt werden. ***
      • Bestätigt das ganze durch klicken auf das Häkchen.
      • Neben dem Ordnernamen erscheint jetzt ein Laden-Icon, dass sich nach einem Moment in einen grünen Kreis verwanden sollte. Ist das der Fall, hat alles geklappt und ihr könnt den Ordner jetzt nutzen.
      • Sollte ein rotes Viereck erscheinen, hat die Einrichtung nicht funktioniert. Schaut unter Protokollierung, dort findet sich eine Fehlermeldung, die hilft meist bei der Lösungssuche.
      • Je nach Größe von \photo dauert es einige Zeit bis Nextcloud alles gescannt hat und im Webinterface richtig anzeigt.

Fehler: File is locked

Ganz unproblematisch ist die Lösung aber nicht. Nach einiger Zeit traten beim Synchronisieren Fehler auf. Nextcloud meldet “File cannot be synchronized, Server replied: File is locked”. Das Problem ist das File-Locking, eigentlich sollten Files nur solange gelockt werden solange sie gespeichert, also auf die Platte geschrieben werden. Hin und wieder gibt es Probleme mit dem Lock-System von Nextcloud. In Verbindung mit \photo sind diese Probleme aber beinahe ständig aufgetreten und die Locks wurden auch nicht merh aufgehoben. Die Lösung hierfür ist das deaktivieren des File-Locking. Das wäre nur dann kritisch, wenn in der Nextcloud viele Benutzer Schreibzugriff auf geteilte Ressourcen haben.
Um das File-Locking zu deaktivieren fügt in der config.php eurer Nextcloud die Zeile “‘filelocking.enabled’ => false,” (ohne ” aber mit ‘) hinzugefügt werden. ACHTUNG: Die config sollte nur über die Commandline bearbeitet werden. Beim bearbeiten über den Texteditor im DSM werden die Rechte und die Ownership verändert.
Jetzt müssen nur noch eventuell gelockte Dateien wieder freigegeben werden. Geht dazu in den phpMyAdmin oder Verbindet euch direkt mit der Nextcloud-Datenbank. Löscht jetzt alle Einträge in der Lock-Tabelle: DELETE FROM oc_file_locks WHERE 1

Es gibt aber eine bessere Lösung, die aber eventuell nicht auf jeder DiskStation funktioniert. Nextcloud empfiehlt redis für das File-Locking zu verwenden. Es hat eine viel bessere Performance als das Standardsystem. Bis vor kurzem musste man noch recht aufwendig die redis module selbst kompilieren, das ging aber nur für PHP 5.6 (zumindest gibt es keine Hinweise wie es für 7.0 funktioniert). Die Module sind jetzt Teil des PHP-Packets. Nur der Serverteil muss noch installiert werden.

1. Installiert redis aus den Community-Packeten im Paketzentrum.
2. Damit redis auch startet, müsst ihr das Start/Stop-Script anpassen: /var/packages/redis/scripts/start-stop-status

   start_daemon ()
   {
       setuid redis exec /usr/local/redis/bin/redis-server /usr/local/redis/var/redis.conf
   }

3. Jetzt könnt ihr redis starten.
4. Falls es noch nicht existiert, erzeugt die Datei /usr/local/etc/php70/conf.d/user-settings.ini. Redis kann leider nicht über die Profileinstellungen im DSM aktiviert werden, sondern über diese Datei. Meine sieht folgendermaßen aus:

   open_basedir = /tmp:/var/services/tmp:/var/services/web:/var/services/homes:/volume1/Nextcloud:/dev/urandom
   
   zend_extension = opcache.so
   zend_extension = xdebug.so
   
   extension = apcu.so
   extension = bcmath.so
   extension = bz2.so
   extension = calendar.so
   extension = curl.so
   extension = dba.so
   extension = exif.so
   extension = ftp.so
   extension = gd.so
   extension = gettext.so
   extension = gmp.so
   extension = iconv.so
   extension = imap.so
   extension = intl.so
   extension = ldap.so
   extension = mailparse.so
   extension = mcrypt.so
   extension = memcached.so
   extension = mysqli.so
   extension = openssl.so
   extension = pdo_dblib.so
   extension = pdo_mysql.so
   extension = pdo_pgsql.so
   extension = pdo_sqlite.so
   extension = pgsql.so
   extension = phar.so
   extension = posix.so
   extension = redis.so
   extension = shmop.so
   extension = soap.so
   extension = sockets.so
   extension = sqlite3.so
   extension = ssh2.so
   extension = sysvmsg.so
   extension = sysvsem.so
   extension = sysvshm.so
   extension = wddx.so
   extension = xmlrpc.so
   extension = xsl.so
   extension = zip.so

5. Jetzt könnt ihr das File-Locking wieder aktivieren und redis dafür nutzen. Fügt folgende Zeilen in eure Nextcloud-Konfiguration ein:

   'filelocking.enabled' => true,
   'memcache.locking' => '\\OC\\Memcache\\Redis',
   'redis' => array (
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 0,
     'password' => '',
     'dbindex' => 0, ),

Um sicher zu gehen, das alles richtig funktioniert, seht im Administrator-Bereich im Nextcloud-Webinterface nach. Dort sollte keine Fehlermeldung auftauchen.

Anmerkungen

*https: Sollten Nextcloud in die Photo Station nicht auf getrennten Systemen laufen, sollte unbedingt https verwendet werden. Setzt dazu beim externen Speicher den Haken bei “sicheres https” und ändert in der Serveradresse den Port von 5005 auf 5006. Befindet sich beides auf dem selben Host, ist http akzeptabel und solange sicher, solange kein Unbefugter Zugriff auf die DiskStation hat (und 127.0.0.1 auf sein eigenes System umleiten könnte). https funktioniert hier sowieso nicht, da 127.0.0.1 nicht im SSL Zertifikat eingetragen werden kann.
**Eigener WebDAV-User: Damit ich in der Nextcloud nicht meinen Hauptuser für die DiskStation angeben muss, habe ich einen eigenen User angelegt, dieser hat nur Rechte für den WebDAV Server und Schreibzugriff auf \photo, sowie Management-Rechte für die Photo Station (diese müssen in der Photo Station eingestellt werden und nicht im DSM). Der User muss unbedingt der Administrator-Gruppe angehören (leider), ein normaler User kann Dateien in \photo nicht anlegen, wenn sie über die Nextcloud hochgeladen werden.
***Externer Speicher per User: Es gibt noch eine zweite Möglichkeit um externen Speicher einzurichten, und zwar jeder User für sich. Dazu muss in der Admin-Verwaltung der Haken bei Benutzer erlauben, externen Speicher einzubinden und WebDAV gesetzt werden. Dann erscheint be jeden User in den Einstellungen der Punkt externer Speicher. Speicher der hier eingebunden wird ist nur vom jeweiligen Benutzer sichtbar. Allerdings kann jetzt jeder User externen Speicher hinzufügen, diese Option kann nicht eingeschränkt werden.

Sharing: Damit externer Speicher mit anderen Nextcloud-Usern geshared werden kann, muss Sharing aktiviert werden. Klickt dazu in den Einstellungen > externer Speicher auf das Zahnrad neben dem angelegten externen Speicher. Setzt dort den Haken bei “Teilen aktivieren”. Jetzt könnt ihr den Ordner bzw. dessen Unterordner teilen.

Fertig eingerichtet

Nach einigen Tests sollten folgende Punkte problemlos funktionieren:

• Dateien im Nextcloud-Webinterface hochladen –> Dateien erscheinen in der Photo Station, Thumbnails werden erzeugt
• Dateien am PC in den Sync-Ordner vom Desktop-Client ablegen  –> Dateien werden in die Nextcloud und somit \photo hochgeladen und erscheinen in der Photo Station, Thumbnails werden erzeugt
• Dateien in \photo ablegen –> funktioniert, da Nextcloud externen Speicher überwacht und neue Dateien einscannt
• Dateien in der Photo Station bearbeiten (z.B. Tags hinzufügen) –> Änderungen werden von Nextcloud übernommen und synchronisiert, aber sie werden von Nextcloud nicht in der Versionsverwaltung eingetragen
• Dateien löschen (Nextcloud) –> Dateien werden aus Photo Station entfernt, Thumbnails werden ebenfalls gelöscht, funktioniert auch in die andere Richtung
• Dateien verschieben –> Dateien werden in der Photo Station richtig verschoben, ebenso Thumbnails, funktioniert auch in die andere Richtung

Scheinbar haben sowohl Nextcloud als auch Synology hier nachgebessert. Als ich das erste Mal den externen Speicher genutzt habe (noch unter Owncloud), gab es massive Probleme, Dateien wurden nicht richtig indiziert und die Rechte der Bilder haben nicht gepasst, Bilder konnten nicht geöffnet werden und Thumbnails wurden auch keine erstellt.
Bei anderen Lösungen (z.B. die Lösung mit rsync – siehe unten) wurden beim Löschen und Verschieben von Bildern die Thumbnails in der Photo Station nicht entfernt oder aber die Bilder mussten jedes mal komplett neu indiziert werden, da alle Thumbnails gelöscht wurden. Änderungen die in der Photo Station gemacht wurden, wurden meist nicht in der Nextcloud übernommen bzw. sogar wieder überschrieben.

Die simple Lösung über Netzfreigabe

Bis jetzt war ich mit dem unten beschriebenen Script sehr zufrieden. Irgendwann habe ich aber angefangen die Photo Station  nicht nur zum Betrachten zu verwenden, sondern auch zur Organisation der Bilder. 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. Dadurch ergibt sich nachfolgende Möglichkeit:

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 Photo Station 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 Photo Station 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 Photo Station 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 Photo Station. 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. Sollte euch die Lösung nicht passen, könnt ihr gerne den Rest des Artikels lesen.

---

ACHTUNG:

Hier beginnt der ursprüngliche Artikel, die Lösungen sind sehr aufwändig und funktionieren nicht zu 100%. Die Lösungen könnten aber weiterhelfen, solltet ihr eine ältere Version der Photo Station haben.

---

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.

rsync -ah /volume*"$SOURCE" --stats --exclude=@eaDir/*** --exclude=@Logfiles/*** --exclude=#recycle/*** --exclude=#snapshot/*** --exclude=.DS_Store/*** --delete --backup --backup-dir=@Recycle/"$DATE"_$SCRIPTNAME "$DESTINATION"

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

    synoindex

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.

    synoindex -R dirpath

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.

if [[ $FILECOUNT == 0 && $DIRCOUNT == 1 ]];
  then
  find "$FILE" -mindepth 1 -maxdepth 1 -type d -print0 | while IFS= read -r -d '' EADIR
  do
    if [[ $EADIR == *"eaDir"* ]]
      then
      rm -rf "$FILE"
      synoindex -D "$FILE"
    fi
  done
elif [[ $FILECOUNT == 0 && $DIRCOUNT == 0 ]];
  then
  rm -rf "$FILE"
  synoindex -D "$FILE"
fi

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.

for db in music video photo; do
  for testfile in `/usr/bin/psql mediaserver postgres -tA -c "select path from $db;"`; do
    if [ ! -f "$testfile" ]; then
      echo "MISSING: $testfile"
      [ -n "$REMOVE" ] && synoindex -d "$testfile"
    fi
  done
done

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 Photo Station 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.

#!/bin/sh
# Backup - Quellen
# ------------------------------------------------------------------------
# Hier können beliebige, Backup-Quellen einer lokalen DS eingetragen     |
# werden.                                                                |
# Zu beachten ist, das immer der vollständige Pfad ohne Angabe des       |
# entsprechenden Volume anzugeben ist. Weiterhin ist auf die             |
# Schreibweise im Beispiel zu achten, pro Zeile je eine Backupquelle.    |
# ------------------------------------------------------------------------
SOURCES="/NextcloudData/Username/files/Meine Fotos
/NextcloudData/Username/files/Photos/Family Share
/NextcloudData/Username/files/Photos/Alte Fotos"

# Backup - Ziel
# Ziel ist der /photo Ordner der DS, denn nur der wird von der
# Photo Station berücksichtigt.
TARGET="/photo"

# Rotationszyklus für das Löschen von @Recycle und @Logfiles
#-------------------------------------------------------------------------
# Zeitangabe, wann Ordner bzw. Dateien in den System-Ordnern endgültig   |
# gelöscht werden sollen, die älter als x Tage sind.                     |
# Ein Feature aus dem original Backupscript.                             |
# ------------------------------------------------------------------------
RECYCLE_ROTATE="30"   # @Recycle-Daten die älter als "x" Tage sind, löschen
LOGFILES_ROTATE="30"  # @Logfiles-Daten die älter als "x" Tage sind, löschen

# ------------------------------------------------------------------------
# Ab hier bitte nichts mehr ändern, wenn man nicht weiß was man tut !!!  |
# ------------------------------------------------------------------------
SCRIPTFILE="${0##*/}"
SCRIPTNAME="${SCRIPTFILE%.*}"
DATE=`date +%Y-%m-%d_%Hh%M`
# RSync Optionen konfigurieren
# Für detailierte Infos lohnt sich ein Blick in der rsync-Dokumentation.
#-------------------------------------------------------------------------
SYNCOPT="-ah"
LOGSTAT="--stats"
# Die DS eigenen Systemfolder werden ausgeschlossen, würde das nicht gemacht werden,
# würden diese (und somit die Indizierung inkl. Thumbnails) bei jedem Sync im Ziel gelöscht werden,
# da diese im Nextcloud-Data-Verzeichnis nicht vorhanden sind.
EXCLUDE="--exclude=@eaDir/*** --exclude=@Logfiles/*** --exclude=#recycle/*** --exclude=#snapshot/*** --exclude=.DS_Store/***"
# --delete löscht nicht mehr vorhandene Files, da wir den Zustand der Bilder in der Cloud ja auf die Photo Station spiegeln wollen.
# Anstatt diese aber direkt zu löschen werden sie in einem Backupordner für einige Zeit zwischengelagert.
RECYCLE="--delete --backup --backup-dir=@Recycle/"$DATE"_$SCRIPTNAME"

# Umgebungsvariablen definieren
# Hier werden die Pfade richtig zusammengebaut.
#-------------------------------------------------------------------------
BACKIFS="$IFS"
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin
TARGET_EMPTY="/Backup_DS"
if [[ ${TARGET:0:1} != \/ ]] && [ -n "$TARGET" ]; then
  TARGET="/$TARGET"
fi
DEST="${TARGET#*/}"
TARGET_CUT="${TARGET#*/}"
TARGET_DECRYPT="${TARGET_CUT%%/*}"
TIMESTAMP=`date +%d.%m.%Y%t%H:%M:%S`
HR="------------------------------------------------------------------------------------------------"

# Variablen je nach Verbindung festlegen
#-------------------------------------------------------------------------
FIND="find"
SOURCE_TEST="test"
TARGET_TEST="test"

# DSM-Benachrichtigung: Script wird ausgeführt...
#-------------------------------------------------------------------------
#synodsmnotify @administrators "Script: $SCRIPTNAME" "Wird ausgeführt.."

# Speicherort des Logfiles festlegen
#-------------------------------------------------------------------------
mkdir -p `dirname $0`/@Logfiles
LOG="`dirname $0`/@Logfiles/"$DATE"_$SCRIPTNAME.log"
if test ! -d `dirname $0`/@Logfiles; then
  DSMNOTIFY="Es konnte kein @Logfiles Ordner erstellt werden!"
fi

# Ordner/Datei für das Protokoll anlegen und Kopfdaten generieren
#-------------------------------------------------------------------------
# Fehlererkennung
#-------------------------------------------------------------------------
if [ -z "$TARGET" ]; then
  STOP="Bitte TARGET setzen..." >> $LOG
fi

#-------------------------------------------------------------------------
if [ -z "$STOP" ]; then
  SOURCE_PATH="/volume*"
  TARGET_PATH="/volume*"
fi

# Zielordner checken
# Das original Backup-Script ermöglicht es Daten auch von und auf entfernte Server zu sichern.
# Dazu musste sicher gestellt werden, dass Quelle und Ziel auch erreichbar sind.
#-------------------------------------------------------------------------
if [ -z "$STOP" ]; then
IFS="
"
  IFS="$BACKIFS"
  DEST_DECRYPT="$TARGET_DECRYPT"
  if $TARGET_TEST ! -d $TARGET_PATH/@"$DEST_DECRYPT"@ && $TARGET_TEST -d $TARGET_PATH/"$DEST_DECRYPT"; then
    echo "Zielordner $TARGET_DECRYPT wurde lokalisiert..." >> $LOG
  fi
  if $TARGET_TEST ! -d $TARGET_PATH/"$DEST_DECRYPT"; then
    if [ -z "$STOP" ]; then
      STOP="Zielordner /$TARGET_DECRYPT nicht gefunden!"
    fi
  fi
fi

# Quellordner checken
#-------------------------------------------------------------------------
IFS="
"
for SHARE in $SOURCES; do
  if [[ ${SHARE:0:1} != \/ ]] ; then
    SHARE="/$SHARE"
  fi
  SHARE_CUT="${SHARE#*/}"
  SHARE_DECRYPT="${SHARE_CUT%%/*}"
  IFS="$BACKIFS"
  SOURCE_DECRYPT="$SHARE_DECRYPT"
  if $SOURCE_TEST ! -d $SOURCE_PATH/@"$SOURCE_DECRYPT"@ && $SOURCE_TEST -d $SOURCE_PATH/"$SOURCE_DECRYPT"; then
    echo "Quellordner $SHARE_DECRYPT wurde lokalisiert..." >> $LOG
  fi
done

# Ziel definieren
#-------------------------------------------------------------------------
if [ -z "$STOP" ]; then
  if [ -n "$TARGET" ]; then
    DEST_FULL=$(echo $TARGET_PATH/"$TARGET_DECRYPT")
    DEST_CUT="${DEST_FULL#*/}"
    DEST_VOL="${DEST_CUT%%/*}"
    DESTTARGET="/$DEST_VOL$TARGET"
    DESTINATION="$DESTTARGET"
  fi
  mkdir -p "$DESTINATION"
fi

# Check ob Zielordner erstellt wurde bzw. vorhanden war.
if $TARGET_TEST ! -d "$DESTINATION"; then
  if [ -z "$STOP" ]; then
    STOP="Zielordner $TARGET konnte nicht erstellt werden bzw. ist nicht vorhanden !"
  fi
fi

echo "" >> $LOG
echo "$HR" >> $LOG
echo "" >> $LOG
# Beginn der RSync-Datensicherung
#--------------------------------------------------------------------------
IFS="
"
for SHARE in $SOURCES; do
  if [ -z "$STOP" ]; then
    echo "" >> $LOG
    if [[ ${SHARE:0:1} != \/ ]] ; then
      SHARE="/$SHARE"
    fi
    IFS="$BACKIFS"
    unset FORERROR
    SOURCE="$SHARE"

    if $SOURCE_TEST ! -d $SOURCE_PATH"$SOURCE"; then
      ERROR="Quellordner $SHARE nicht erreichbar..." >> $LOG
      FORERROR="1"
    elif $SOURCE_TEST -d $SOURCE_PATH"$SOURCE"; then
      echo "Quellordner $SHARE erreichbar." >> $LOG
    fi
  
    SOURCE="$SHARE"

    if [ -z "$STOP" ] && [ -z "$FORERROR" ]; then
  
# Hier findet entlich der eigentliche Sync statt.
# Achtung wir sind immer noch in der Schleife die alle aufgelisteten Quellen durchläuft,
# d.h. rsync wrd für jede Quelle extra aufgerufen.
#-------------------------------------------------------------------------
      if [ -n "$DESTINATION" ]; then
        echo "$HR" >> $LOG
        echo "Starte Datensicherung: $REMOTEHOST$SHARE nach $DESTINATION" >> $LOG
        echo "$HR" >> $LOG
        rsync $SYNCOPT /volume*"$SOURCE" $LOGSTAT $EXCLUDE $RECYCLE "$DESTINATION" >> $LOG
        RSYNC_EXIT="$?"
      fi
      echo "" >> $LOG
      RSYNC_CODE="$RSYNC_EXIT"
    fi
  fi
done

# RSync Exit-Code = Fehlermeldung
#-------------------------------------------------------------------------
# Exit-Code: Entfernter Server ausgeschaltet?
if [ $RSYNC_CODE -eq 43 ]; then
  echo "Entfernte DS oder RSync komp. Server nicht Online? Bitte RSYNC Port kontrollieren!" >> $LOG
# Exit-Code: DSL-Verbindung getrennt?
  elif [ $RSYNC_CODE -eq 255 ]; then
    echo "Bitte Internetverbindung oder RSYNC Port kontrollieren!" >> $LOG
# Exit-Code ausgeben...
  elif [ $RSYNC_CODE -ne 0 ]; then
    echo "RSync Fehlermeldung (Exit Code): $RSYNC_CODE" >> $LOG
  fi

# RSync Exit-Code = Erfolgreich bzw. Unvollständig
#-------------------------------------------------------------------------
if [ $RSYNC_CODE -eq 0 ] && [ -z "$STOP" ] && [ -z "$ERROR" ]; then
  echo "$HR" >> $LOG
  echo "RSync-Datensicherung erfolgreich. Sicherungsziel: $DESTINATION" >> $LOG
  if [ -z "$DSMNOTIFY" ]; then
    DSMNOTIFY="RSync-Datensicherung erfolgreich. Sicherungsziel: $DESTINATION"
  fi
# RSync Exit-Code = Fehlermeldung
elif [ $RSYNC_CODE -ne 0 ] || [ -n "$STOP" ] || [ -n "$ERROR" ]; then
  echo "$HR" >> $LOG
  echo "RSync-Datensicherung unvollstaendig oder fehlgeschlagen - Sicherungsziel: $DESTINATION" >> $LOG
  if [ -z "$DSMNOTIFY" ]; then
    DSMNOTIFY="RSync-Datensicherung unvollstaendig oder fehlgeschlagen - Bitte Protokoll prüfen!"
  fi
fi
echo "$HR" >> $LOG; echo "" >> $LOG
if [ -n "$STOP" ]; then
  echo "FEHLER: $STOP" >> $LOG
fi
if [ -n "$ERROR" ]; then
  echo "FEHLER: $ERROR" >> $LOG
fi

# Rotationszyklus für das Löschen von @Recycle und @Logfiles
#-------------------------------------------------------------------------
# Dateien im Ordner @Recycle die älter als x Tage sind, löschen.
if $TARGET_TEST -d "$DESTINATION"/@Recycle/; then
  if [ -z "$STOP" ] && [ -n "$RECYCLE_ROTATE" ] && [ -z "$ERROR" ]; then
    $FIND "$DESTINATION"/@Recycle/* -type d -mtime +$RECYCLE_ROTATE -exec rm -rf {} \;
    echo  "HINWEIS: Daten aus dem Ordner /@Recycle, die mehr als $RECYCLE_ROTATE Tage alt waren, wurden geloescht." >> $LOG
    echo "" >> $LOG
  fi
fi

# Dateien im Ordner @Logfiles die älter als x Tage sind, löschen.
if $TARGET_TEST -d `dirname $0`/@Logfiles/; then
  if [ -z "$STOP" ] && [ -n "$LOGFILES_ROTATE" ] && [ -z "$ERROR" ]; then
    find `dirname $0`/@Logfiles -name "*.log" -type f -mtime +$LOGFILES_ROTATE -exec rm {} \;
    echo  "HINWEIS: Daten aus dem Ordner /@Logfiles, die mehr als $LOGFILES_ROTATE Tage alt waren, wurden geloescht." >> $LOG
    echo "" >> $LOG
  fi
fi

# Benachrichtigung an die DSM-Administratorengruppe sowie E-Mail senden
#-------------------------------------------------------------------------
if [ -n "$DSMNOTIFY" ] && [ -n "$STOP" ] || [ -n "$ERROR" ]; then
  synodsmnotify @administrators "Script: $SCRIPTNAME" "$DSMNOTIFY"
fi

# Die rsync option -a behält unter anderem Ownership und Zugriffsrechte der Files bei.
# Die passen der Photo Station aber nicht und werden entsprechend angepasst (User der auf die Photo Station auch zugreifen kann).
chmod -R 777 $DESTINATION
chown -R PSUser:users $DESTINATION

# Cleanup leerer Folder die wegen dem @eaDir nicht gelöscht werden konnten.
#-------------------------------------------------------------------------
FILECOUNT=0
DIRCOUNT=0

echo "Pruefe $DESTINATION auf leere Ordner" >> $LOG

# Diese Funktion durchsucht /photo rekursiv (zuerst in die Tiefe, dann in die Breite).
# Pro Ordner wird die Anzahl der Dateien und Unterordner gezählt.
# Wurde ein Ordner mit Bildern verschoben (unabhängig wie viele Unterordner er enthalten hat) bleibt nach dem Sync nur noch der @eaDir-Ordner übrig.
# Wurde ein Ordner nur mit Unterordnern verschoben (ohne je eine Datei enthalten zu haben) bleibt kein Ordner über, auch kein @eaDir.
# In diesen beiden Fällen kann der Ordner gelöscht und der Index entfernt werden.
recurse_traverse ()
{	
  # Das Script verarbeitet die einzelnen Ordner-Ebenen per Rekursion, daher ist -maxdepth 1.
  # Das stellt sicher, dass in $FILE auch nur ein Ordner steht und zwar der, den wir löschen wollen.
  find "$1" -mindepth 1 -maxdepth 1 -type d -print0 | while IFS= read -r -d '' FILE
  do
    # @eaDir nicht durchsuchen
    if [[ $FILE == *"eaDir"* ]];
      then
      continue
    fi
    
    # Unterordner verarbeiten
    recurse_traverse "$FILE"
	    
    # Im aktuellen Ordner werden alle Dateien und Unterordner gezählt.
    FILECOUNT=$(find "$FILE" -maxdepth 1 -type f | wc -l)
    DIRCOUNT=$(find "$FILE" -maxdepth 1 -type d | wc -l)
    # -1 weil find auch den Parent-Ordner mitzählt, glaube ich, ganz sicher bin ich mir nicht mehr
    ((DIRCOUNT--))
		
    # "Leere" Ordner die beim syncen überbleiben enthalten keine Dateien und nur der versteckten @eaDir Ordner
    if [[ $FILECOUNT == 0 && $DIRCOUNT == 1 ]];
      then
      # Sichergehen, dass der eine gefundene Ordner tatsächlich @eaDir heißt.
      find "$FILE" -mindepth 1 -maxdepth 1 -type d -print0 | while IFS= read -r -d '' EADIR
      do
        # Ordner löschen
        if [[ $EADIR == *"eaDir"* ]]
          then
          echo "loesche $FILE" >> $LOG
          # Den Ordner löschen...
          rm -rf "$FILE"
          # ...und aus der Index-DB entfernen.
          synoindex -D "$FILE"
        fi
      done
    # Komplett leere Verzeichnisse löschen.
    # Tritt auf, wenn ein Ordner nur Unterordner enthalten hat aber nie selbst Fotos,
    # dadurch gibt es auch kein @eaDir
    elif [[ $FILECOUNT == 0 && $DIRCOUNT == 0 ]];
      then
      echo "loesche $FILE" >> $LOG
      rm -rf "$FILE"
      synoindex -D "$FILE"
    fi
  done
}

recurse_traverse "$DESTINATION"

# Script beenden...
#-------------------------------------------------------------------------
if [ -z "$STOP" ] && [ -z "$RSYNC_CODE" ] && [ -z "$ERROR" ]; then
  exit 100
else
  exit $?
fi

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

#!/bin/sh
# Usage: ./remove_orphans.sh [-f]
# Wird das Script ohne -f aufgerufen, werden die Orphans nur ausgegeben aber nicht tatsächlich gelöscht.
# Das eignet sich gut um das Script zu testen ohne tatsächlich etwas zu löschen.
 
[ "$1" = "-f" ] && REMOVE=1
 
IFS='
'
# Für Musik, Videos und Fotos gibt es jeweils eine eigene Datenbank.
# Das Script kann auch nur auf eine einzelne DB angewendet werden.
# Die Indizes sind die Dateipfade, eingetragen in der Datenbank.
# Jeder dieser Pfade wird geprüft, ob es sich dabei um eine Datei handelt oder nicht.
# Existiert die Datei nicht, wird der entsprechende Index aus der DB gelöscht.
for db in music video photo; do
  for testfile in `/usr/bin/psql mediaserver postgres -tA -c "select path from $db;"`; do
    if [ ! -f "$testfile" ]; then
      echo "MISSING: $testfile"
      [ -n "$REMOVE" ] && synoindex -d "$testfile"
    fi
  done
done

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

• Backup-Script
• Synology-forum.de
• rsync

Ähnliche Beiträge