Docker Ordner für Volumes haben falsche Rechte. Wie korrigieren?

[Uhlhorn]

Moin,
ich habe es ziemlich häufig, dass wenn ich ein Docker-Container einrichte, dass dieser beim Start meine Ordner nicht akzeptieren will. Die Rechte scheinen nicht zu stimmen.

Beispiel:
1666371731: Error: Unable to open config file /mosquitto/config/mosquitto.conf.

Ich habe einen Ordner docker für alle Ordner/Volumes, die ich in Docker verwende. Normalerweise lege ich die gewünschten Ordner einfach an und wenn ich den Container das erste mal einsetze (deploy), werden die Rechte der Ordner angepasst. Alles läuft wunderbar.

Manchmal werden die Ordner aber nicht angepasst und dann erhalte ich die Fehlermeldung, dass der Container nicht in die Ordner schreiben kann. Okay, dich könnte die Ordner-Berechtigungen so setzen, dass die ganze Welt schreiben und lesen darf. Doch das möchte ich eigentlich nicht so gerne machen.

1. Wie muss man die User, Gruppen und Rechte korrekt setzen, damit diese Probleme nicht mehr auftreten?
2. Kann ich ein Volume in meinem Ordner docker auch mithilfe von Portainer erzeugen?
3. Wenn ich in einem App Template Stack das Kommando docker volume create mosquitto_data verwende, wo auf der Synology werden dann diese Container erzeugt? Kann ich sie auch im Ordner docker/mosquitto/ erzeugen lassen?

 

[MattCB]

Du kannst versuchen, beim Starten des Dockers per Environment die PUID und die PGID mitzugeben. Somit kann der Container mit deinen Rechten auf die Ordner zugreifen.

Um diese IDs herauszubekommen, verbindest du dich per SSH, loggst dich ein und gibst als Befehl nur ein:

id

Dann siehst du deine UID und die GID. Diese kannst du dann per Environment (Umwelt heisst es in der Dockeroberfläche der Synology) in Form von PUID und PGID dem Container mitgeben. In diesem YT-Video findest du eine entsprechende Anleitung. Ob das mit allen Containern klappt oder nur mit solchen, die diese Werte auslesen, kann ich dir aber nicht sagen.

Per Portainer kann man keine Ordner anlegen, die dann per Bind-Volume mit dem Container gekoppelt werden. Die Ordner müssen über die Filestation oder per SSH angelegt werden. Im Portainer lassen sich nur Volumes anlegen, die direkt eingebunden werden. Die entsprechenden Ordner liegen dann z.B. unter volume1/@Docker/volumes/ (volume1 kann bei dir auch anders sein).

 

[haydibe]

Du kannst versuchen, beim Starten des Dockers per Environment die PUID und die PGID mitzugeben

Das geht NUR, wenn das Image es auch unterstützt. Es ist ein Funktion eines Images, dass sein Maintainer extra eingebaut haben kann oder auch nicht. Zum Beispiel unterstützen ALLE Linuxserver-Images das sogenannte Usermapping,. Es gibt aber auch etliche andere die es unterstützen, teilweise heißen die Variablen dann anders. Viele Images unterstützen so etwas nicht.

Für Images die kein Usermapping bieten, aber grundsätzlich mit eingeschränkte Benutzer arbeiten, kann man bei docker run das --user Argument verwenden, bei docker-compose kann man in der Compose-Datei unterhalb der Service-Deklsaration user: dafür verwenden, um diesem User eine UID:GID unterzujubeln. Über die Syno-UI geht das allerdings nicht.

Ich habe einen Ordner docker für alle Ordner/Volumes, die ich in Docker verwende. Normalerweise lege ich die gewünschten Ordner einfach an und wenn ich den Container das erste mal einsetze (deploy), werden die Rechte der Ordner angepasst. Alles läuft wunderbar.

Auch das ist ein Feature eines Images, dass die Maintainer eingebaut haben. Typischerweise sind das dann Container die mit root starten und dann die Kernanwendung meistens mit einem eingeschränkter Benutzer starten.


Beides ist KEIN Standardverhalten von Containern und hat nichts mit Docker zu tun, sondern damit das Maintainer diese Features in Ihre Images extra einbauen - man kann nicht davon ausgehen das jedes Images diese Funktionalität mitbringt.


Normalerweise muss folgendes erfüllt sein:
Verzeichnis ohne Syno ACL: Besitzer UID:GID vom Verzeichnis muss zur UID:GID des Prozesses vom Container passen
Verzeichnis mit Syno ACL: zusätzlich muss "Jeder" in den ACL-Einstellungen berechtigt sein zu lesen/schreiben (was immer benötigt wird).

 

[Uhlhorn]

Hmm, das ist irgendwie unbefriedigend.

In diesem Fall geht um um die mosquitto-Datenbank eclipse-mosquitto:latest

Wenn ich da PGID und PUID angebe (bei Paperless musste ich das damals auch machen), bekomme ich dieselbe Meldung.

Wenn ich die Ordner für jedermann beschreibbar mache, funktioniert es auch nicht. Nur wenn ich die Volumes ganz weg nehme, dann funktioniert es.

 

[Uhlhorn]

Über die Syno-UI geht das allerdings nicht.

Aber über Portainer müsste es doch gehen, oder?

Danke für Deine Ausführungen. Das erklärt einiges.

 

[MattCB]

Normalerweise sollte es funktionieren, wenn du dem Nutzer "Everyone" alle Lese- und Schreibrechte gibst. Und nicht den Haken vergessen, dass das ganze auch für die Unterordner gilt.

 

[Uhlhorn]

Normalerweise sollte es funktionieren, wenn du dem Nutzer "Everyone" alle Lese- und Schreibrechte gibst. Und nicht den Haken vergessen, dass das ganze auch für die Unterordner gilt.

Nein, das habe ich probiert.

 

[haydibe]

Im Dockerfile wird ein Benutzer mit UID 1883 und GID 1883 angelegt. Der Container startet als root und chowned das Verzeichnis auf den User und startet dann Mosquito. Ob es das tatsächlich als eingeschränkter Benutzer startet, konnte ich nicht sehen.

Usermapping ist hier nicht implementiert. Sprich PUID und PGID haben keinen Effekt.

In Verbindung mit "Jeder/Everyone" Read-Write müsste das funktionieren.

 

[Uhlhorn]

In Verbindung mit "Jeder/Everyone" Read-Write müsste das funktionieren.

Leider nicht. (Vielleicht mache ich da auch irgendetwas falsch.)

 

[Uhlhorn]

Im Dockerfile wird ein Benutzer mit UID 1883 und GID 1883 angelegt. Der Container startet als root und chowned das Verzeichnis auf den User und startet dann Mosquito als eingeschränkter Benutzer.

Kann man denn der Synology irgendwie mitteilen, dass dieser Nutzer auf das Verzeichnis schreiben darf?

 

[haydibe]

Zeig mal bitte deine Volume mappings. Ich habe da so eine Vermutung.

 

[Uhlhorn]

 

[haydibe]

Wie ich es mir gedacht hab... Das erste Volume gibt es imho SO in der Beschreibung gar nicht. Es würde auch bedeuten, dass Du eine fertige mosquitto.conf in /volume1/docker/mosquitto/mosquitoo_conf haben müsstest. Hast Du die Datei selbst erzeugt? Oder händisch aus dem Container kopiert, bevor Du ein Bind-Volume dahin gemapped hast? Wenn die Antworten nein sind, dann ist das Dein Problem.

Update: Der Satz von mir stimmt nicht "Das erste Volume gibt es imho SO in der Beschreibung gar nicht.". Ich hatte nur in das Dockerfile geschaut und dort gibt es das Volume tatsächlich nicht. Es wird aber trotzdem vermutlich das Problem sein.

 

[Uhlhorn]

Ich hatte mich an dieser Beschreibung orientiert:
Shelly und Tasmota mit MQTT, Node-Red, InfluxDB ins Grafana Dashboard

Stimmt, nun startet der Container ohne diesen Fehler.
Vielen Dank, das war der richtige Hinweis.

Dafür habe ich nun einen anderen Fehler (Error: Address not available). Das ist aber möglicherweise ein Netzwerkproblem oder so.

 

[haydibe]

Siehe: https://github.com/eclipse/mosquitto/issues/2040

 

[Uhlhorn]

Ja, da hatte ich das auch gefunden. So lang man einen Suchbegriff zum googeln hat, findet man so was auch.
Danke vielmals.