UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Codierknecht]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Was ich noch nicht verstehe, ist die Zeile 3. Woher weiß das System, welches Image installiert werden soll. Ich möchte das garafana-oss verwenden.

Wenn Du als Registry "Docker-Hub" verwendest, kommt da der Name rein wie er in der Registry angegeben ist.

In Deinem Fall also grafana/grafana-oss

[legro]

@codierknecht @OliverIO

Vielen Dank.

Muss die Installationsdatei das Suffix yaml haben?

[OliverIO]

@legro

Ich gehe davon aus, dass deine aktuelle Konfiguration nicht starten wird, da du nach /etc/grafana getappt hast.
Wenn in deinem lokalen Ordner nicht alle Dateien aus /etc/grafana vorhanden sind, fehlen die auch im Image und höchstwahrscheinlich wird es deswegen nicht starten

[Codierknecht]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Wie sollte/muss diese Datei benannt werden?

Kann ich gerade nicht (mehr) nachsehen, weil ich meine Syno-VM schon wieder heruntergefahren habe.
Müsste aber grafana.yml lauten.

Wenn Du den Assistenten zum Erstellen nutzt, kannst Du als Quelle ja wählen "docker-compose.yml erstellen".
Dann erscheint unten ein Editor, in den das Compose einfach eingefügt wird.

[legro]

@codierknecht

Ich habe eure Vorschläge in die Tat umzusetzen versucht. Das Ergebnis ist wie gehabt: Der Container startet nicht. Hier das Protokoll ..

In der 3. Zeile habe ich die für voran gegangenen Versuche gelöscht.

[OliverIO]

@legro

Ich glaube, das ist das Log file des Container Managers
Schau mal in dieser Anleitung nach.
Wir brauchen das Log File des Containers selbst
https://mariushosting.com/synology-how-to-check-your-docker-container-logs/

Washast du mit meinem letzten Hinweis zum Mappen unternommen?

[legro]

@oliverio

Ich kann euch kein anderes Log bieten. Das Register Details ist ausgegraut.

[OliverIO]

@legro

ok dann liegt es wahrscheinlich am 2.volume

mache bitte aus
/etc/grafana
dann
/etc/grafana1

und startest den container. er dürfte dann ganz normal starten.
dann gehst du in die details zu deinem container und drückst den knopf mit dem >_ Zeichen bei Action

dann befindest du dich auf der shell IM container.
dort kopierst du den inhalt von /etc/grafana nach /etc/grafana1

im anschluss änderst du im docker-compose das
/etc/grafana1
nach
/etc/grafana

und startest den container neu

dann müsste er normal starten.
dann kannst du die datei grafana.ini die sich in deinem lokalen verzeichnis auf der synology befindet bearbeiten.

da diese datei die rechte vom innerhalb des container hat, wundere dich nicht, das da ggfs komische user/group anzeigen kommen.
auch kann es sein, das du diese dateien mit sudo bearbeiten muss.

der von grafana für docker vorgesehene weg wäre das setzen der environment variablen in einem zusätzlichen abschnitt des docker compose files

[legro]

@oliverio

Langsam aber sicher verstehe ich überhaupt nichts mehr. Was die user und group Rechte betrifft, habe ich selbstverständlich sudo chown -R 472:472 /volume2/docker/grafana2 ausgeführt (was ich jedoch hier im Thread noch nicht erwähnte). Sollte damit die von dir vorgeschlagene Akrobatik nicht mehr nötig sein?

[legro]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

ok dann liegt es wahrscheinlich am 2.volume

Ich fürchte: nein

Ich habe das Ganze bereits mit zwei, einem und keinem gemappt Volume ausgeführt. Nur bei letzterem konnte ich den Container starten.

[OliverIO]

@legro

woher hast du diese Anweisung?

evtl mal ein kurzabriss zu docker.
docker ist zu applikations abstraktion da.
d.h. in einem image ist alles enthalten, was eine applikation benötigt, inklusive dem jeweiligen betriebssystem + evtl weitere tools.
meist werden da seeeehr kleine betriebssysteme verwendet, die nur wenig mehr als den kernel + wirklich die notwendigsten dienste enthalten.
das standard image ohne zusätzlichen tag angaben verwendet alpine

wenn du ein volume mountest, dann ist das wie ein guckfenster auf das dateisystem in deinem container. das betriebssystem/applikation liest schreibt/liest da ganz normal drauf (zumindest was normal für das betriebssystem IM container ist).

durch das kopieren von /etc/grafana nach /etc/grafana1 sind eigentlich auch alle berechtigungen inklusive user/group/owner mitkopiert worden.
daher hättest du eigentlich nix machen müssen.

hat es den geklappt, nachdem du die dateien kopiert hast?

[OliverIO]

@legro sagte in Schreibrechte auf grafana.ini in Docker:

Ich fürchte: nein
Ich habe das Ganze bereits mit zwei, einem und keinem gemappt Volume ausgeführt. Nur bei letzterem konnte ich den Container starten.

existieren die lokalen verzeichnisse, die du da angegeben hast?

da /etc/grafana1 IM container definitv nicht exitiert, dürfte das eigentlich kein problem sein. dann muss das problem auf der lokalen seite des mappings liegen

bitte den aktuellen stand deines docker compose als text nochmal posten

[legro]

@oliverio

Mit dieser von dir vorgeschlagenen Änderung startet der Container ebenfalls nicht, sodass ich alle weiteren Vorschläge gar nicht erst angehen konnte.

[legro]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

existieren die lokalen verzeichnisse, die du da angegeben hast?

In diesem Beitrag findest du meine auf der Synology angelegten Verzeichnisse.

[legro]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

evtl mal ein kurzabriss zu docker.

Mir ist das Konzept durchaus klar und aus meinen ehemaligen beruflichen Tätigkeiten durchaus sogar vertraut. Auch konnte ich etwa bei InfluxDB problemlos meine Verzeichnisse mappen. Nur Grafana macht hier Zicken.

[OliverIO]

@oliverio sagte in Schreibrechte auf grafana.ini in Docker:

bitte den aktuellen stand deines docker compose als text nochmal posten

bitte als text und nicht als grafik

yaml ist mit den einrückungen empfindlich. evtl liegt es auch an dem

[legro]

@oliverio

Dein Wunsch sei mir Befehl.:slightly_smiling_face:

services:
   grafana:
      image: grafana/grafana-oss
      container_name: grafana2
      restart: unless-stopped
      ports:
         - 3000:3000
      volumes:
         - /volume2/docker/grafana2/data:/var/lib/grafana
         - /volume2/docker/grafana2/config:/etc/grafana1

[legro]

@oliverio

sudo chown -R 472:472 /volume2/docker/grafana2

Den Befehl fand ich zuhauf im Internet. Er wurde immer als letzte Rettung angepriesen.

In der Tat: Meine erste Installation beinhaltete nur das data Verzeichnis zum Mappen. Da auch hier der Start scheiterte, suchte ich nach Abhilfen und fand diesen Hinweis. Bei diesem Versuch konnte ich tatsächlich nach Ausführung dieses Befehls den Container starten.:slightly_smiling_face:

Da ich jedoch auch das config Verzeichnis mappen wollte, löschte ich diese (erfolgreiche) Installation und versuche mich seither vergebens, eine lauffähige Installation hinzubekommen.

[OliverIO]

@legro

ok ich habe deine konfiguration ausprobiert.
sie passt vom format.

ja den chown befehl muss doch sein, da grafana leider einen eigenen user/group verwendet und nicht wie sonst root oder 1000 verwendet.
ok ist ein sicherheitsaspekt, macht das aber etwas schwieriger.

bei mir war port 3000 auf dem host schon belegt, daher musste ich auf 3001:3000 ausweichen. evtl prüfst du das bei dir auch noch.

danach habe ich auf der shell im container alle dateien kopiert

cp -r /etc/grafana/* /etc/grafana1/

die docker-compose datei geändert und neu gestartet.
es funktioniert.

[legro]

@oliverio

Leider kann ich jedoch nicht deinen Weg beschreiten, da der Container bei mir selbst mit der Änderung zu grafana -> grafana1 ja nicht startet.