sameersbn redmine docker image löscht beim Starten Dateifreigabe

[MaxTheCB]

Hallo,
ich habe auf einer RS815+ mit DSM5.23.-25426 Update 2 die aktuelle Docker Version installiert.
Darin habe ich das aktuelle Abbild von sameersbn redmine heruntergeladen und erfolgreich gestartet. Das Redmine-Datenverzeichnis ist über Volume auf einen freigegebenen Ordner ausgelagert. Jedoch immer nach dem Start des Containers sind alle Dateiberechtigungen verschwunden (es wird nur noch lesend für "Everyone" freigegeben), unter FileStation kann ich die Ordnerstruktur noch einsehen und die Berechtigungen wieder nachtragen. Mache ich dies nicht, lässt sich der Container auch nicht mehr neu starten....
Der Container läuft nicht mit hoher Priorität... hat jemand eine Idee, warum das passiert ?

Danke.

 

[haydibe]

Eine Idee, nö. Die Möglichkeit das zu Analysieren: ja.

Eins vorab: das Image verwendet "user remapping" über die Environment Parameter USERMAP_UID und USERMAP_GID, die verwendest Du auch?

Bei Bau des Images wird der Benutzer "Redmine" angelegt. Die beiden Parameter von Oben werden verwendet, um diesem Benutzer die damit übergebene UID und GID zu verpassen. Der Container selbst startet als root und führt die Vorbereitsungsarbeiten auch als root durch (IDs von USERMAP_?ID auf den Container-Benutzer anwenden, Environment-Variablen in Konfigurationen rendern) um dann als letztes als Benutzer "Redmine" die Anwendung zu starten..

Das Verhalten das Dich stört wird durch das Entrypoint ausgelöst. Die Funktion initialize_logdir() und initialize_datadir() aus dem Bash-Skript https://github.com/sameersbn/docker-redmine/blob/master/assets/runtime/functions sind dafür verantwortlich.

Solange Du nicht die UID/GID deines Hauptbenutzers (mit dem du von ausserhalb auf das Datenverzeichnis zugreifen können willst) als USERMAP_* verwendest und ihn zum Owner des gemappted Verzeichnisses und der Unterverzeichnisse machst (und ggf. die SynoACLs für diese Verzeichnisse entfernst), wirst Du mit dem Problem leben müssen. Das Skript tut nämlich genau das und kann dabei mit SynoACL's nichts anfangen - kein Container kann das...

 

[MaxTheCB]

Erst mal danke für Deine Antwort
Ich habe mit den USERMAP Variablen gespielt... allerdings mit dem Erfolg, dass dann gar nichts mehr funktioniert hat...als ID werden Zahlen erwartet, Gruppen und User in Zahlen anzulegen brachte keine Hilfe...
Ich habe auf einem anderen NAS das System erfolgreich eingerichtet...(und das neue System auf Basis dessen Einstellungen errichtet) ohne USERMAP...dort läuft es...leider habe ich nie zeitgleich Zugriff auf beide Systeme...
Muss dann wohl von jeder Seite Fotos machen und weitersuchen

 

[haydibe]

Die Idee ist das man UID und GID von existierenden Benutzern des NAS verwendet.. auf der Shell bekommt man die (wenn man sich mit dem Benutzer eingeloggt hat) mit id -u und id -g. Diese ID's sollten natürlich zum Besitzer des Verzeichnisses passen:stat /volume1/docker/mein/pfad/ -c '%u:%g'.

So ist gewährleistet, dass a) der Container berechtigt ist in das Verzeichnis zu schreiben und b) ein NAS Benutzer auf den Inhalt auch zugreifen kann.

Zu Deinen Erfahrungen kann ich nur sagen: nichts ist eindeutiger als Quelltext. Was er tut habe ich in meinem vorherigen Post geschrieben.