Synology Drive und PhotoPrism

[DrHephaisos]

Liebe Foristen,

seit einigen Tagen leistet eine DS423+ im Heimnetzwerk hervorragende Dienste. Unter den installierten Paketen befinden sich Syn. Drive und der Container Manager. Nach einer Testphase verwarf ich Syn. Photos zu Gunsten von PhotoPrism. Dessen Docker Container ließ sich nach meinen spezifischen Anpassungen in docker-compose.yml...

working_dir: "/photoprism" # do not change or remove
    ## Storage Folders: "~" is a shortcut for your home directory, "." for the current directory
    volumes:
      # "/host/folder:/photoprism/folder"                # Example
      - "~/volume1/photo:/photoprism/originals"               # Original media files (DO NOT REMOVE)
      - "~/volume1/video:/photoprism/originals/video"
      # - "/example/family:/photoprism/originals/family" # *Additional* media folders can be mounted like this
      - "~/volume1/camerasync:/photoprism/import"                  # *Optional* base folder from which files can be imported to originals
      - "./storage:/photoprism/storage"                  # *Writable* storage folder for cache, database, and sidecar files (DO NOT REMOVE)

...fehlerfrei installieren. Auch PhotoPrism selbst läuft problemlos 'as designed and intended' und bereitet mir große Freude. Wäre da nicht eine ärgerliche PhotoPrism-Marotte, die sich terra-spaßbremsend aufs Zusammenspiel mit Syn. Drive auswirkt.

Die auf meinem Handy und dem meiner Frau installierten Syn. Drive-Apps arbeiten wie gewünscht: Sie schaufeln die Fotodateien automatisch in den dafür vorgesehenen NAS Ordner "~/volume1/camerasync:/photoprism/import". Deren Owner-Attribut enthält die der DS423+ bekannten Usernamen von mir oder meiner Frau. Syn. Drive ist für beide Benutzer freigegeben. So weit, so gut.

Auch der manuelle Import der Fotos durch PhotoPrism klappt unter der Vorgabe, sie in die Verzeichnisstruktur der Anwendung zu 'moven', problemlos. Vom ärgerlichen Detail abgesehen, daß die importierten Dateien klandestin einen neuen Owner erhalten: 'root'.

Genau dieser Umstand verhindert nämlich, daß der Syn. Drive-Client durch PhotoPrism importierte Dateien mit meinem Rechner synchronisiert. Syn. Drive akzeptiert den Benutzername 'root' nicht und kann deshalb für 'root' nicht freigegeben werden.

Die automatische Synchronisation wird im Moment nur ausgelöst, wenn ich den 'Owner' betroffener Dateien mit der Syn. File Station manuell von 'root' auf einen der freigegebenen Benutzer setze.

Nun zu meiner Frage: Kann man PhotoPrism dazu bewegen, nicht als 'root', sondern als ein in Syn. Drive konfigurierter Benutzer in Erscheinung zu treten? Etwa indem man die docker-compose.yml Parameter...

environment:
      PHOTOPRISM_ADMIN_USER: "admin"                 # admin login username
      PHOTOPRISM_ADMIN_PASSWORD: "insecure"          # initial admin password (8-72 characters)

...verändert?

Da mir deren Auswirkung und ihr Einfluß auf die darunter liegende Linux Distribution mangels nötigen Wissens unklar ist, frage ich lieber bei Euch nach, bevor ich ratenderweise und mit evtl. verheerendem Ausgang zu experimentieren beginne.

Cheers,
DrHephaistos

 

[Thorfinn]

Willkommen im Forum und

Willkommen in den Tiefen eines containerisierdem Multiuserbetriebssystem. Jetzt heißt es aufpassen und Nutzerverwaltung schnurgerade halten.

Ich weiss nicht wie du Photoprism aufgesetzt hast, aber das mit root Rechten der Synology laufen zu lassen ist imho fahrlässig.
Ist es vielleicht doch nicht der root des Synology Betriebssystems sondern der root des Containers.

kurzum: kämme die Rechteverwaltung und -vererbung in und aus dem Container heraus.

 

[DrHephaisos]

Vielen Dank für den freundlichen Empfang.

Ich bin einfach dem "Setup using Synology Container Manager" aus PhotoPrisms Getting Started gefolgt. Hier wird wiederum auf den Artikel "Synology Container Manager for Beginners" verwiesen, der exemplarisch die Installation von PhotoPrism aufzeigt.

kurzum: kämme die Rechteverwaltung und -vererbung in und aus dem Container heraus.

Hier liegt der Hase im Pfeffer: Ich habe mangels Know-How nicht den blassesten Schimmer davon, wie ich das anstellen sollte.

Cheers,
DrHephaistos

 

[Synchrotron]

Drive ist für mich nicht erste Wahl für den Sync von Photos. Die Hauptaufgabe von Synology Drive ist der Snyc von Dateien, dafür ist es optimiert.

Schau dir doch mal PhotoSync an: Langjährig bewährte App, iOS und Android, deutscher Entwickler, beherrscht eine Vielzahl von möglichen Speicherzielen und Protokollen. Vermutlich kommst du damit viel schneller zum Ziel als beim Versuch, Drive die Flausen auszutreiben.

https://www.photosync-app.com/de/index

 

[Benie]

Nutze auch PhotoSync und kann das nur bestätigenund kann die App auch mit gutem Gewissen empfehlen.

 

[DrHephaisos]

Syn. Drive, also Server, Mobile-App und Desktop-Client sind Akteure meines Use-Case und arbeiten völlig korrekt.

Das Problem entsteht nachdem die Drive Mobile-Apps Photos ans NAS übermittelt haben. Bei deren Import durch PhotoPrism, das die Photodateien - aus welchem Grund auch immer - mit dem neuen Owner 'root' versieht. DSM wiederum lässt es nicht zu, 'root' überhaupt als Benutzer zu registrieren:



Ein Systemuser dieses Namens existiert in DSM auch nicht, so daß 'root' für keine Anwendung frei gegeben werden kann. Dateien dieses Owners werden also einfach ignoriert. Auch von Syn. Drive.

Wenn im 2. Schritt der Syn. Drive-Client die Photobibliothek des NAS mit der meines Rechner synchronisieren soll, geht es erst dann weiter, wenn ich die Owner der von PhotoPrism importierten Dateien manuell auf einen für Syn. Drive frei gegebenen Username zurücksetze.

Thorfinn trifft mit seiner Diagnose ins Schwarze. Hier kollidieren die paranoiden Rechteverwaltungen von Debian-Linux, für das der User 'root' eine wichtige Rolle spielt, dem aufgepfropften DSM und Docker. Und ich habe nicht die geringste Ahnung, wie/ob sich PhotoPrism logisch konsistent in diese Landschaft integrieren lässt.

Cheers & Jah bless,
DrHephaistos

 

[DrHephaisos]

Update: Die Synchronisierung der Photobibliothek des NAS als Quelle und der Photos auf meinem Rechner als Ziel, lasse ich nicht mehr vom Syn. Drive Desktop-Client ausführen. Stattdessen habe ich die Aufgabe ans Windows Programm 'SyncFolder' abgegeben. 'SyncFolder' interessiert sich nicht für Dateiowner...

Dieser Workaround ist rein machbarkeitsorientiert und deshalb unschön. Denn das eigentliche Problem bleibt leider ungelöst.

Cheers,
DrHephaistos

 

[DrHephaisos]

Liebe Foristen,

ein neuer Workaround ermöglicht dem Syn. Desktop-Client nun doch die Synchronisation der PhotoPrism Bildbibliothek auf der DS423+ mit der Bildbibliothek meines Rechners. Dafür wird der Owner 'root' der von PhotoPrism während des Imports erzeugten Dateien, automatisch durch einen für Syn. Drive autorisierten Benutzer ersetzt. Dieser Job wird durch das beim Aufgabenplaner als ausgelöste Aufgabe registrierte und im Hintergrund laufende Bash-Skript 'PhotoPrism_Import_Owner_Change.sh' erledigt.

PhotoPrism ordnet importierte Photos als Kopien der Originale anhand ihrer Aufnahmedaten in folgende Verzeichnisstruktur ein:

Das Skript 'PhotoPrism_Import_Owner_Change.sh' überwacht diese Verzeichnisbäume und ändert den Owner neu erzeugter Dateien wie gewünscht.

Als notwendige Präliminarie muß man das Paket

der Quelle http://packages.synocommunity.com installieren, die vorher ins Paketzentrum aufzunehmen wäre. Weiterhin muß mindestens der Anwender das Kommando 'sudo' ohne folgende Passworteingabe ausführen können, der Bilder mit PhotoPrism importiert. In meinem rein privaten Netzwerk autorisiere ich alle Mitglieder der Gruppe 'users' durch einen entsprechenden Eintrag in der Datei '/etc/sudoers':


Das Skript 'PhotoPrism_Import_Owner_Change.sh'...

#!/bin/bash
#
# Um der Gruppe 'users' die Ausführung von 'sudo' ohne Passworteingabe zu ermöglichen, muß
# die Zeile '%users ALL=(ALL) NOPASSWD: ALL' in '/etc/sudoers' eingetragen werden.

BESITZER="$1"

{ while [ true ]
do
  inotifywait --format %w%f -r -e create /volume1/photo/ | grep --line-buffered /volume1/photo/20 | xargs -I{} sudo chown $BESITZER {}
done } &>/dev/null

...übernimmt als Argument den Namen des Benutzers, der den Owner 'root' ersetzt. Registriert man beispielsweise die Kommandozeile...

bash /volume1/homes/DS423plus_Admin/Work/PhotoPrism_Import_Owner_Change.sh Lurchi

...beim Aufgabenplaner, ist der für Syn. Drive autorisierte 'Lurchi' Besitzer aller importierten Bilder.

So funktioniert mein Photo-Synchronisationsworkflow mit der privaten Wolke auch außerhalb der Reichweite des heimischen WLAN.

Jah bless,
DrHephaistos