Verschlüsselten Photo-Ordner in Photo Station einbinden

[EuglLEv]

Hallo zusammen,

folgendes Szenario möchte ich unter DSM 6 einrichten:

Nachdem die NAS gestartet ist, entschlüssel ich mein Foto-Share /volume1/encrypted_foto einmal manuell und binde es danach als Ordner unter /volume1/photo/share_encrypted_foto ein, damit
Medienserver und PhotoStation darauf Zugriff bekommen.

Ich habe mich dabei weitgehend an die Mount Bind Anleitung aus dem Wiki gehalten:

mount -o bind /volume1/encrypted_foto /volume1/photo/share_encrypted_foto

Da ich nach dem Start einmal manuell entschlüssel, lässt sich das Script bspw. nicht unter /usr/local/etc/rc.d/ einbinden. Aber egal, Verschlüsselung bedeutet immer manuellen Aufwand.
So, nach dem Mount erscheint der Ordner nun korrekt mit Inhalt in der File Station sowie im Terminal.
Ich dachte mir nun, dass der Medienserver/Photostation - nach einmaliger Neu-Indizierung - auch Kenntnis davon kriegen.

Leider falsch...: ich bekomme die PhotoStation einfach nicht dazu, dass der Foto-Ordner auch dort aufgelistet ist. Was mir bislang eingefallen ist:

• Index über SSH aktualisiert (synoindex -R photo)
• Medienserver sowie Photostation Dienst über Paketzentrum gestoppt/ neu gestartet
• Rechte über SSH gecheckt:

   /volume1/photo$ ls -al  ===> drwxrwxrwx  6 root       root   4096 May 21 22:25 share_encrypted_foto

Bisher ohne Lösung. Gibt es dafür einen weiteren Kniff?

Vielen Dank und Gruß

 

[jugi]

root:root? das sollte admin:user sein oder? (sollte bei 777 egal sein, aber wer wei?)

 

[EuglLEv]

Der Ordner hat vor dem Mount auch die Rechte admin:user. Da der mount Befehl root-Rechte benötigt, wird share_encrypted_foto anscheinend mit root: root überschrieben.

Dürfte also eigentlich kein Unterschied zum Link oben aus dem Wiki sein ...


// EDIT:

An der Berechtigung scheint es wohl nicht zu liegen. Über Samba und im Terminal kann ich Dateien mit meinem admin User nach /volume1/photo/share_encrypted_foto kopieren.

 

[EuglLEv]

Update:

Alle Fotos können auf einem DLNA Client (Smart TV) gestreamt werden. Daher muss es ein Video Station / DSPhoto Problem sein. Sehr schade, denn die Anwendungen stellen für mich den eigentlichen Mehrwert dar.

Für mich stellen sich dann die Fragen, ob:
a) das Problem erst neu ist und ab DSM6+ passiert. Der Mount Bind Artikel im Wiki hört sich danach an, als ob Photo Station in Kombination mit Mount Bind funktionieren würde.
b) das Ausführen des Skripts schon während des Startvorgangs obligatorisch ist. Theoretisch dürfte ein Neustart aber den gleichen Effekt haben wie das Neustarten der Video Station(?).

Konnte jemand dazu schon Erfahrungen sammeln?

 

[EuglLEv]

Ein weiteres Update:

• Unverschlüsselte Shares über mount bind
• Ein als als root:root angelegter Ordner innerhalb von /volume1/photo

sind beide sowohl in der File Station als auch in der Photo Station sichtbar.

Ein verschlüsseltes Share über mount bind ist in der File Station/Terminal/Samba sichtbar, jedoch nicht in Photo Station !

So, wie ich das sehe, deutet das auf ein spezielles Zugriffsproblem von Photo Station auf per mount bind gelinkte verschlüsselte Shares hin. Ich kenne mich mit den Details zu mount nicht hinreichend aus, und im Web lässt sich leider nichts zur einer Photo Station API finden.

 

[Fusion]

Die Photo Station ist wie alles andere auch eine Web-Anwendung. Deshalb würde ich drauf wetten, dass sich das "Problem" in der web-server config und Umgebung finden sollte. Der Zugriff via Terminal etc erfolgt ja auch mit anderen Nutzerrechten bzw. Nutzern als wenn die "Photo Station" zugreift.
Dafür wäre es hilfreich, wenn zunächst mal jemand zweites/drittes die Situation bei sich testet, um zu sehen, ob dies wirklich ein generelles Problem zu sein scheint. Persönlich kann ich leider nur unter DSM 5.2 den Gegentest machen.

Ich würde mal die Zugriffsrechte vergleichen. Im Terminal: Alle meine Alben zeigen z.B. user/users als Besitzer. /photo gehört zwar root/root, aber keiner der Unterordner.
Also vielleicht mal den mount-Punkt nach dem einhängen des verschlüsselten shares einem anderen Besitzer übereignen...

 

[EuglLEv]

Ich würde mal die Zugriffsrechte vergleichen. Im Terminal: Alle meine Alben zeigen z.B. user/users als Besitzer. /photo gehört zwar root/root, aber keiner der Unterordner.
Also vielleicht mal den mount-Punkt nach dem einhängen des verschlüsselten shares einem anderen Besitzer übereignen...

Unterordner gehören auch bei mir admin:users. Ein Chown auf Share hat leider nichts geändert.

Dafür wäre es hilfreich, wenn zunächst mal jemand zweites/drittes die Situation bei sich testet, um zu sehen, ob dies wirklich ein generelles Problem zu sein scheint. Persönlich kann ich leider nur unter DSM 5.2 den Gegentest machen.

Das wäre sehr hilfreich.

 

[jugi]

Habs grad mal gemacht, die dateien müssen entweder http:http gehören oder chmod 777(vllt reicht 774?) haben, dann gehts auch mit mount -o bind. auf gut deutsch: der webserver muss leserechte haben…

 

[EuglLEv]

danke fürs Testen. Habe es gerade einmal probiert mit chown http:http auf den mointpoint sowie einem file innerhalb des mountpoints.

drwxrwxrwx  3 http       http   4096 Jun  9 07:37 share_foto_test_enc
-rwxrwxrwx 1 http http 2117005 Jun  9 07:36 test.jpg

Danach Re-Indizierung, leider noch ohne Erfolg. Kannst Du Deine Vorgehensweise einmal erläutern?

 

[jugi]

öh, wenn ich mich noch richtig erinnere hab ich folgendes gemacht
1. verschlüsselten ordner "test" erstellt (über GUI)
2. über die shell einen leeren dummy-ordner unter /photo erstellt (mkdir test)
3. chown admin:users /volume1/photo/test
4. verschlüsselten ordner in dummy-ordner gemounted (mount -o bind /volume1/test /volume1/photo/test)
5. nochmal chown admin:users /volume1/photo/test - hatte aber keinen effekt mehr
6. via DS File eine Datei in den originalordner hochgeladen (die hatte, wenn ich mich jetzt richtig erinnere, erstmal admin:users 770)
7. synoindex -R /volume1/photo/test -> fehlanzeige
8. chmod 777 /volume1/test/image.jpg
9. synoindex -R /volume1/photo/test -> voila

nagel mich jetzt nicht auf die details fest, hatte es nur eben schnell beim warten aufm handy hingefrickelt - auf jeden fall sah ich am ende in der DS photo app meinen ordner "test" mit einem Bild drin. es geht also.

edit: 10. vergessen: in den nun sichtbaren ordner via DS Photo ein Bild hochgeladen und in der shell angeschaut: http:http 777

 

[Fusion]

ok, habs jetzt unter DSM 5.2 getestet. Allerdings ohne den verschlüsselten Ordner.

/volume1/test-share/test/ erstellt und in test ein jpg abgelegt
Sowohl test wie auch das jpg gehören user.users und sind auf 777
Dann den Ordner per mount bind unter /volume1/photo/test/ eingehängt. Diesen Testordner vorher auf dieselben Besitzer/Rechte gesetzt wie den obigen Testordner, mount bind hat daran dann nichts geändert.
Sowohl original wie mount bind zeigen jetzt selben Namen und Rechte auf der Konsole.
Danach eine Medienindizierung angstoßen. (Eine Indizierung des Ordners hätte gereicht und nicht so lange gedauert, wie Homer sagen würde: doh)
In dem Photo Ordner den ich auch per Cloud Station mit einem Ordner auf meinem Rechner abgleich ist der Ordner test auch aufgetaucht, aber nicht das Bild darin. Melde ich mich allerdings mit user am DSM an sehe ich das Bild in der File Station. Keine Ahnung wieso die Cloud Station das nicht synced.

Ich habe die PS Konten separat und neue Alben werden automatisch als privat angelegt.
Das Bild/Album ist erstmal nur beim admin Konto welches die Verwaltungsrechte hat aufgetaucht. Erst als ich in der PS auch meinem Nutzer die Browse Rechte gegeben habe konnte dieser das Bild/Album auch sehen.

Prinzipiell kann ich also die Ergebnisse von @jugi bestätigen.

 

[EuglLEv]

@jugi

deine Vorgehensweise deckt sich auch in etwa mit meiner. Der synoindex Befehl unter Punkt 9 hat mich jedoch auf den Hinweis gebracht, wie ich es auch bei mir endlich zum Laufen kriegen konnte.

Es klingt banal, war aber in meinem Fall ausschlaggebend, damit auch die Fotos im Mount-Ordner indiziert wurden:
der synoindex musste mit dem Mount-Ordner direkt angestoßen werden ( synoindex -R /volume1/photo/test ) statt nur auf dem photo-Ordner ( synoindex -R /volume1/photo ).
Technisch kann ich mir das grad noch nicht erklären... Im Falle von symbolischen Links ist mir nur bekannt, dass Kommandos hier u.U. stoppen.

Einsicht 2 bei mir war, dass für PhotoStation nur wichtig ist, was als Rechte im Programm eingestellt werden. Ordner auf dem Terminal mit Rechten umbiegen musste ich keine.

Im Ergebnis also an manchen Stellen etwas kniffelig und uneinsichtig . Ich freue mich aber, dass auch eine Verschlüsselung von den DLNA-Foldern mit relativ geringem (Script)-Aufwand möglich ist, solange Synology nicht selbst eine Option dafür anbietet. In meiner Augen sind ja gerade die Home sowie Foto Ordner diejenigen, die mir am wichtigsten sind.

@Fusion bezüglich mount bind und Cloud Station Problemen meine ich mal gelesen zu haben, dass es dann hilft, den CloudStation Dienst einmal komplett zu stoppen und neu zu starten.