DockerImage - Volume Berechtigungsprobleme bei Installation
Verfasst: Mo 11. Jul 2022, 10:11
Hallo Zusammen, ich nutze die Solaranzeige bereits seit Längerem als Datensammelstelle auf einem RPi4. Die Solaranzeige holt sich die Daten beim Wechselrichter, schreibt sie in die interne InfluxDB, stellt die Daten graphisch dar und stellt bestimmte Informationen via MQTT dem externen IOBroker zur Steuerung diverser Verbraucher zur Verfügung. Nun kam der Wunsch auf, die Solaranzeige auf ein QNAP NAS TS-453D mit Intel CPU zu verfrachten, welches bereits diverse Container ausführt. Nachdem ich mehrere Tage diverseste Konfigurationen ausprobiert habe, ist es mir endlich gelungen, eine Variante mit von der Container Station erstellten Volumes zum Laufen zu bewegen. Ich möchte aber gerne wie bei anderen Containern mit eigenen Volumes arbeiten. Allerdings scheint es tatsächlich ein Berechtigungsproblem (Permissions) mit den Volumes zu geben. Kann mir jemand erklären, warum die Berechtigungen nicht wie gedacht funktionieren und das auch nur bei diesem Image?
Grundlage waren die Angaben im Repository zum Bau von einem Container. Dort waren auch die möglichen Environment Parameter ersichtlich.
Angelegt habe ich ein Verzeichnis mit meinem Hauptuseraccount und dieser Account ist nicht der hier ersichtliche admin. Denn der admin Account ist bei mir deaktiviert.
Dann habe ich die PUID und GUID für dieses besagte Benutzerkonto via SSH ermittelt.
Anschließend habe ich basierend auf dem "Latest" Image der Solaranzeige den Container wahlweise via SSH, QNAP Container-Station oder Portainer angelegt.
Hierbei habe ich die User-ID und die Gruppe mitgegeben, sowie Mosquito und die InfluxDB aktiviert.
Als Netzwerktyp ist NAT gewählt.
Der Container wird dann erfolgreich angelegt und startet. Es werden alle Sourcen gezogen und die Ersteinrichtung durchgeführt.
Nach einem Neustart verbindet sich der Container mit dem Wechselrichter, holt die Daten, der Abruf via MQTT (Mosquito) ist möglich. Allerdings erscheint der berüchtigte Fehler:
Eine kurze Überprüfung ergibt, dass die InfluxDB sich nicht starten lässt, auch nicht manuell. Auch das Grafana Frontend auf Port 3000 wird nicht geladen. Die Verzeichnisse sind aber gefüllt. Es wurden also fleißig die Daten in die Shares geschrieben. Allerdings kann offenbar weder Grafana auf die DB im Share zugreifen und starten, noch die InfluxDB.
Ein anschließender Blick in die Berechtigungen der Volume Verzeichnisse ergibt, dass hier nicht mehr der ursprüngliche User steht, sondern entweder admin oder wahlweise die vom Image voreingestellten Werte, wenn ich nichts unter Environment mitgegeben hatte.
Der Container war so nicht nutzbar.
Letztlich hatte ich nur Erfolg, indem ich die Anlage direkt in der Container-Station durchführte. Keinerlei PUID oder GUID Angaben machte und die Shares direkt in der Container-Station erstellen und verwalten lies. So funktionierte alles. Allerdings habe ich so nur über Umwege Zugriff auf die Shares, um beispielsweise Daten zu sichern oder Sicherungen für Grafana und die InfluxDB bereitzustellen.
Es scheint nach diversen Setups tatsächlich an den Shares zu liegen und ich folgere, dass es die Berechtigungen sein müssen. Dafür würden auch folgende Meldungen im QCenter passen, denn die stammen aus den besagten Shares. Habe ich hier eine falsche PUID/GUID Kombination mitgegeben? Kann es sein, dass im Image nur 3stellige Integer für die User-ID vorgesehen sind? Eine 101 als User-ID wurde teilweise auch in den Shares eingetragen. Ich würde gerne verstehen, warum das nur bei diesem Container nicht so funktioniert, wie gedacht. Kann jemand meinen Geist erhellen oder das Problem nachstellen?
Grundlage waren die Angaben im Repository zum Bau von einem Container. Dort waren auch die möglichen Environment Parameter ersichtlich.
Angelegt habe ich ein Verzeichnis mit meinem Hauptuseraccount und dieser Account ist nicht der hier ersichtliche admin. Denn der admin Account ist bei mir deaktiviert.
Dann habe ich die PUID und GUID für dieses besagte Benutzerkonto via SSH ermittelt.
Anschließend habe ich basierend auf dem "Latest" Image der Solaranzeige den Container wahlweise via SSH, QNAP Container-Station oder Portainer angelegt.
Code: Alles auswählen
docker run -d -e USER_ID="1010" -e GROUP_ID="100" -e TIMEZONE="Europe/Berlin" -e UPDATE="yes" -e MOSQUITTO="yes" -e INFLUXDB="yes" -p 3000:3000 -v /share/Docker/Solaranzeige/SOLARANZEIGE_STORAGE:/solaranzeige -v /share/Docker/Solaranzeige/INFLUXDB_STORAGE:/var/lib/influxdb -v /share/Docker/Solaranzeige/GRAFANA_STORAGE:/var/lib/grafana -v /share/Docker/Solaranzeige/WWW_STORAGE:/var/www -v /share/Docker/Solaranzeige/PVFORECAST_STORAGE:/pvforecast --name=Solaranzeige --restart unless-stopped --tmpfs /tmp --tmpfs /var/log takealug/solaranzeige:latest
Als Netzwerktyp ist NAT gewählt.
Der Container wird dann erfolgreich angelegt und startet. Es werden alle Sourcen gezogen und die Ersteinrichtung durchgeführt.
Nach einem Neustart verbindet sich der Container mit dem Wechselrichter, holt die Daten, der Abruf via MQTT (Mosquito) ist möglich. Allerdings erscheint der berüchtigte Fehler:
Code: Alles auswählen
-Curl Fehler[2]! Daten nicht zur lokalen InfluxDB solaranzeige gesendet! Curl ErrNo. 7
Ein anschließender Blick in die Berechtigungen der Volume Verzeichnisse ergibt, dass hier nicht mehr der ursprüngliche User steht, sondern entweder admin oder wahlweise die vom Image voreingestellten Werte, wenn ich nichts unter Environment mitgegeben hatte.
Der Container war so nicht nutzbar.
Letztlich hatte ich nur Erfolg, indem ich die Anlage direkt in der Container-Station durchführte. Keinerlei PUID oder GUID Angaben machte und die Shares direkt in der Container-Station erstellen und verwalten lies. So funktionierte alles. Allerdings habe ich so nur über Umwege Zugriff auf die Shares, um beispielsweise Daten zu sichern oder Sicherungen für Grafana und die InfluxDB bereitzustellen.
Es scheint nach diversen Setups tatsächlich an den Shares zu liegen und ich folgere, dass es die Berechtigungen sein müssen. Dafür würden auch folgende Meldungen im QCenter passen, denn die stammen aus den besagten Shares. Habe ich hier eine falsche PUID/GUID Kombination mitgegeben? Kann es sein, dass im Image nur 3stellige Integer für die User-ID vorgesehen sind? Eine 101 als User-ID wurde teilweise auch in den Shares eingetragen. Ich würde gerne verstehen, warum das nur bei diesem Container nicht so funktioniert, wie gedacht. Kann jemand meinen Geist erhellen oder das Problem nachstellen?