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

Die simple Lösung über Netzfreigabe

Bis jetzt war ich mit dem unten beschriebenen Script sehr zufrieden. Irgendwann habe ich aber angefangen die PhotoStation  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 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.

\photo als externen Speicher in der Nextcloud

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 dei 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. Wie das ganze funktioniert und meine Erfahrung bisher, könnt ihr hier nachlesen.

Einrichten

    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.
      1. Vergebt einen Odernernamen, der Name, den ihr hier eingebt, wird in der Cloud angezeigt und ist frei wählbar.
      2. Wählt aus dem Dropdown „WebDAV“ aus, es erscheinen jetzt weitere Eingabefelder.
      3. Als Authentifizierung wählt „Benutzername und Passwort“.
      4. 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.
      5. 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“.
      6. Jetzt müsst ihr noch Benutzer und Passwort für die DiskStation angeben.
      7. 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.
      8. Bestätigt das ganze durch klicken auf das Häkchen.
      9. 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.
      10. 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.
      11. Je nach Größe von \photo dauert es einige Zeit bis Nextcloud alles gescannt hat und im Webinterface richtig anzeigt.
Externen Speicher einrichten
Externen Speicher einrichten

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

Nach einigen Tests sollten folgende Punkte problemlos funktionieren:

  • Dateien im Nextcloud-Webinterface hochladen –> Dateien erscheinen in der PhotoStation 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 PhotoStation Thumbnails werden erzeugt
  • Dateien in \photo ablegen –> funktioniert, da Nextcloud externen Speicher überwacht und neue Dateien einscannt
  • Dateien in der PhotoStation bearbeiten (z.B. Tags hinzufügen) –> Änderungen werden von Nextcloud übernommen und synchronisiert
  • Dateien löschen (Nextcloud) –> Dateien werden aus PhotoStation entfernt, Thumbnails werden ebenfalls gelöscht
  • Dateien verschieben –> Dateien werden in der PhotoStation richtig verschoben, ebenso Thumbnails

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 PhotoStation nicht entfernt oder aber die Bilder mussten jedes mal komplett neu indiziert werden, da alle Thumbnails gelöscht wurden. Änderungen die in der PhotoStation gemacht wurden, wurden meist nicht in der Nextcloud übernommen bzw. sogar wieder überschrieben.

Anmerkungen

https: Sollten Nextcloud in die PhotoStation 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 konnte ich noch nicht testen, da am Localhost nur 127.0.0.1 als Serveradresse funktioniert und diese nicht im SSL-Zertifikat eingetragen ist. Ein Umstellen auf https resultiert somit in einem Fehler, da Nextcloud das Zertifikat nicht akzeptiert.
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 PhotoStation (diese müssen in der PhotoStation eingestellt werden und nicht im DSM). Die Verbindung klappt zwar, allerdings lassen sich Dateien nicht hochladen. Unterordner werden zwar angelegt, verschwinden aber nach einigen Sekunden aus der Nextcloud (in der PhotoStation bleiben sie erhalten). Bestehende Dateien in \photo werden ebenfalls in der Nextcloud nicht angezeigt. Hier bleibe ich noch dran und werde ein Update posten, sollte ich eine Lösung gefunden haben.
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.

Usern erlauben externen Speicher einzurichten
Usern erlauben externen Speicher einzurichten

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.

Optionen für den externen Speicher
Optionen für den externen Speicher

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

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

  1. Habs über die Netzwerkfreigabe probiert und klappe erst einmal hervorragend. Benenne ich jedoch eine Datei auf Verzeichnisebene um, löscht der Client mir die Datei ohne Nachfrage….

    1. Hallo,

      Entschuldige die späte Antwort.
      Welche Verzeichnisebene meinst du? Im Windows-Explorer oder auf der DiskStation.
      Wenn du den Explorer meinst, dann ist das seltsam. Das sollte eigentlich nicht passieren.
      Die Cloud macht keinen unterschied ob Netzfreigabe oder nicht. Passiert das mit dem Löschen auch wenn du eine Datei umbenennst die nicht auf der Netzfreigabe liegt (aber trotzdem von der Cloud gesynct wird).

      Ich bin gerade wieder auf den externen Speicher in der Cloud umgestiegen und habe den Beitrag angepasst.

      Grüße,
      Andreas

Schreibe einen Kommentar

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