ddung docs

berechtigungen

2 min read

Tags: homelab docker ugreen nas troubleshooting

Das Problem

Wenn ein Bind-Mount-Zielordner (z.B. /volume2/appdata/<stack>) noch nicht existiert, wenn docker compose up das erste Mal läuft, legt Docker selbst den Ordner an – und zwar als root:root, unabhängig davon, was PUID/PGID im Compose-File gesetzt ist und unabhängig von den Berechtigungen des übergeordneten Ordners.

Das führt zu Fehlern wie:

Error: EACCES: permission denied, mkdir '/app/data/db'

…obwohl PUID/PGID korrekt gesetzt wurden.

Warum das passiert

  • PUID/PGID steuern nur, mit welcher Identität der Container-Prozess läuft
  • Sie beeinflussen NICHT, mit welchen Rechten Docker einen fehlenden Bind-Mount-Ordner auf dem Host anlegt
  • Docker legt fehlende Bind-Mount-Ziele grundsätzlich als root:root an
  • Der Container-Prozess (läuft z.B. als dominik/1000) kann dann nicht in den root-Ordner schreiben → EACCES

Diagnose

ls -la /volume2/appdata/<stack>

Verdächtig, wenn der Zielordner root root gehört, obwohl der übergeordnete Ordner korrekt dominik admin zeigt:

drwxr-xr-x  1 root    root    0 ... .
drwxrwxrwx+ 1 dominik admin 104 ... ..

Fix (nachträglich)

docker compose down
sudo chown -R 1000:10 /volume2/appdata/<stack>
sudo chmod -R 775 /volume2/appdata/<stack>
docker compose up -d

Prävention – aktualisierter Workflow für JEDEN neuen Stack

Immer den appdata-Zielordner manuell anlegen, BEVOR docker compose up das erste Mal läuft:

# 1. Ordner manuell anlegen (bevor Docker es tun kann)
mkdir -p /volume2/appdata/<stack-name>
sudo chown -R 1000:10 /volume2/appdata/<stack-name>
 
# 2. compose.yml erstellen (PUID=1000, PGID=10)
 
# 3. Erst DANACH starten
cd /volume2/docker-compose/<kategorie>/<stack-name>
docker compose up -d

Diese Reihenfolge stellt sicher, dass Docker den Ordner bereits vorfindet (mit korrekten Rechten) statt ihn selbst als root neu anzulegen.

Verwandte Notizen

Graph View

Backlinks