Grafana/Grafana bekomme ich nicht zum Laufen

[Scrati]

Moin,

ich habe mir eine DS720+ gegönnt und kann endlich rumdockern.

Nun wollte ich Grafana zum Laufen bekommen und bekomme es ums verrecken nicht hin.

Ich habe Verzeichnisse eingebunden, wie hier dargelegt:
https://grafana.com/docs/grafana/latest/administration/configure-docker/





Wenn ich den Container so starte, sehe ich im log, dass es ein Rechte Problem gibt:



Nach etwas weiterem suchen, habe ich Informationen hier gefunden:
https://grafana.com/docs/grafana/latest/installation/docker/

Aber irgendwie trifft doch nichts so richtig davon zu. Es ist eine Neuinstallation. Nix mit migrieren und sobald ich den Container ohne extern eingebundene Volumes starte läuft er auch an.

Ist jemand von euch schonmal auf dieses Problem gestoßen?

Grüße

 

[haydibe]

Die einzig relevante Information ist: Default user ID is now 472.

Der Container-Prozess wird mit der UID 472 gestartet. Die Host-Seite des Volumes (in Wahrheit bind-mounts) muss entsprechend die UID 472 als owner haben, sonst darf Prozess nicht in das Ziel-Verzeichnis im Container schreiben.

1. Container stoppen
2. via ssh als root ausführen: chown 472:472 -R /volume1/docker/grafana (GID habe ich nur geraten, volume1 durch das Volume ersetzen auf dem das Docker-Share liegt)
3. Container starten

 

[Scrati]

Moin,

vielen Dank für deinen Tipp! Leider bringt er noch nicht den gewünschten Erfolg. Ich habe als letzte Aktion sogar mal alles und jedem Rechte auf den Ordner gegeben, aber selbst das hat nicht funktioniert.





Also ganz offensichtlich ist es ein Problem mit den Rechten. In den Tipps, steht hier noch etwas, was ich so verstehe, dass man den Container mit anderen Rechten starten soll, um dann die BErechtigungen aus dem Container heraus zu korrigieren.
https://grafana.com/docs/grafana/latest/installation/docker/



Das erscheint mir nicht alles sonderlich sinnvoll bzw. müsste man dann ja den Container von der Shell aus starten? Problem ist aber, dass der Container grundsätzlich stoppt, wenn die Ordner nicht gelesen/beschrieben werden können...

 

[Scrati]

Hallo zusammen kurzes Update nach zahlreichen Versuchen:

mit User-ID 472 und GID 0 funktioniert es. Es ist aber zusätzlich zu beachten, dass ich es nur geschafft habe, das Verzeichnis /var/lib/grafana umzubiegen. Das Verzeichnis /etc/grafana ging prinzipiell zwar auch, jedoch erwartet das Docker Image hier bereits ein configuration file und legt dies nicht selbst an. Hier scheinen die Entwickler auch auf Umgebungsvariablen zu setzen:


Quelle: https://grafana.com/docs/grafana/latest/administration/configure-docker/

@haydibe: Ich danke dir vielmals! Ich habe das jetzt noch etwas besser verstanden, wobei für mich noch unklar ist, warum ich die synology root Gruppe wählen muss, obwohl doch grafana scheinbar mit GID 1 im Container arbeitet.

Naja, sei es drum. Es läuft jetzt

 

[haydibe]

Ich hab mir mal mit docker history {image} die Befehle vom Dockerfile angeschaut.

Das hier läuft:

mkdir data
chown 472:0 data
docker run --rm --name grafana -p 3000:3000 -v $PWD/data:/var/lib/grafana grafana/grafana:7.3.6

Entgegen der Doku muss die GID 0 sein und nicht 1. Durch den Parameter --rm wird der Container beim beenden gelöscht.
Das Mapping auf /etc/grafana macht wenig Sinn, da die Konfiguration über Environment-Variablen gewollt ist - bitte wieder entfernen.

Wenn das mit dem chown auf dem Datenverzeichnis gemacht ist, kann man den Container auch problemlos über die UI starten.

Unglaublich wie schlecht die Doku ist....

 

[haydibe]

Es ergibt überhaupt keinen Sinn, dass die Anpassung der GID notwendig ist.

Im Image ist eine Gruppe mit der GID 0 vorhanden, zusätzlich wird der der Benutzer "grafana" mit der UID 472 angelegt. Am Ende werden die Verzeichnis mit chmod 777 versehen und der Besitzer auf "grafana:{groupenname von GID=0}" geändert. Danach wird auf den "gewechselt", was dazu führt, dass das Entrypointskript als Benutzer grafana ausgeführt wird. Das Entrypointskript prüft als Benutzer grafana, ob einzelne Verzeichnise gelesen/geschrieben werden können.... was mit 472:1 und 472:472 gescheitert ist - nur ergibt es überhaupt keinen Sinn das es gescheitert ist... Im Grunde sollte die GID egal sein, trotzdem lief es mit der verkehrten GID nicht. wirklich extrem merkwürdig.

update: es wird noch merkwürdiger.. jetzt geht es auch mit 472:1 und 472:472 problemlos. Vorher hat 472:1 nicht funktioniert. Mit anderen Worten es hätte vorher schon gehen müssen, was sich mit der Analyse des Dockerfiles und des Entrypointskripts deckt.

Teil mal bitte den Output von folgenden Befehlen:

sudo synoacltool -get /volume1/docker/grafana
sudo synoacltool -get /volume1/docker/grafana/data

 

[Scrati]

Hallo haydibe,

vielen lieben Dank, dass du dem so detailliert nachgehst. Eine Stunde vorher hatte ich durch etwas "rumprobieren" zum Laufen bekommen und zumindest im Rahmen von BlackBox Tests zum Teil rausbekommen, was du durch deine Detailanalyse aufgedeckt hast. Entschuldige, dass dir die Arbeit entstanden ist. Aber mein Beitrag von 19:38 wartet noch auf die moderative Freigabe. (Ich würde mir auch nicht übern Weg trauen ).

Ich hatte diverse Sachen probiert und auch mal Container mit meiner UID über die Shell gestartet. Das lief dann auch, daher bin ich dem noch etwas mehr nachgegangen und es über die Rechte auf den Ordner weiter versucht.

Aktuell läuft das ganze bei mir mit chown 472:0 -R /volume1/docker/grafana

Ich hatte auch irgendwann die Faxen dicke und habe den Container neu aufgesetzt gehabt. Vielleicht gab es hier auch noch irgendwelche komischen Wechselwirkungen im alten Format, warum die anderen Versuche mit der Rechtevergabe nicht klappten.

Verzeichnis gemounted ist nur noch /volume1/docker/grafana/data auf /var/lib/grafana

Hier die Ausgabe:

 

[haydibe]

Das Thema war gut vorbereitet und für mich interessant. Da investiert man dann auch mal eine halbe Stunde und schaut sich die Sachen näher an Ich mache den Kram ja auch beruflich und weiß das Eine oder Andere über Container (Docker/Kubernetes) und Cloud...

Die ACLs sind gerne mal der Grund warum Container keinen Zugriff auf gemappte Verzeichnisse haben können (obwohl Linux-Permissions und Owner passt).

Da es nun läuft, spare ich mir die ACLs zu interpretiere, das kann ich nicht ohne nachzuschauen was die einzelnen Flags bedeuten. Die Flag für owner sehen aber ziemlich vollständig aus, das müsste passen.

Freut mich das es jetzt läuft!