Volumes werden nicht gemountet - häufige Konfigurationsfehler in Compose

Volume-Probleme in Compose sind tricky, weil kein Fehler geworfen wird – stattdessen entsteht still ein falsches Volume oder ein leerer Mount.

Fehler 1: Fehlender Top-Level-volumes-Block

Das ist der häufigste Fehler. Ein named Volume muss sowohl im Service als auch im Top-Level-volumes-Block deklariert sein.

# FALSCH – kein Top-Level-Block
services:
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

# RICHTIG
services:
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:  # Dieser Block ist zwingend notwendig

Fehlt der Top-Level-Block, erstellt Compose ein anonymes Volume mit einem Hash-Namen wie myapp_pgdata_a3f9b2c1 – aber keines mit dem erwarteten Namen. Die Daten landen an der falschen Stelle.

Fehler 2: Tippfehler im Volume-Namen

services:
  db:
    volumes:
      - pgdat:/var/lib/postgresql/data  # Tippfehler: fehlendes 'a'

volumes:
  pgdata:  # Wird nie verwendet

Compose erstellt dann ein neues Volume myapp_pgdat – kein Fehler, einfach leer und ohne die alten Daten.

Fehler 3: Relative Pfade

Compose löst relative Pfade relativ zum Speicherort der docker-compose.yml auf – nicht relativ zum aktuellen Arbeitsverzeichnis.

# compose.yml liegt in /home/user/myapp/
# Diese Konfiguration:
volumes:
  - ./data:/app/data
# Wird aufgelöst zu: /home/user/myapp/data:/app/data

# Wenn man compose aus /home/user/ aufruft:
docker compose -f myapp/docker-compose.yml up
# Pfad bleibt /home/user/myapp/data – korrekt

Fehler 4: Windows-Pfadformat

Auf Windows müssen Pfade im Compose-Format korrekt angegeben werden:

# FALSCH auf Windows
volumes:
  - C:\Users\user\data:/app/data

# RICHTIG
volumes:
  - C:/Users/user/data:/app/data
  # oder
  - /c/Users/user/data:/app/data

Fehler 5: SELinux-Labels fehlen

Auf SELinux-Systemen (RHEL, Fedora) werden Bind Mounts ohne das richtige Label blockiert:

# FALSCH auf SELinux-Systemen
volumes:
  - ./data:/app/data

# RICHTIG: :z für geteiltes Label, :Z für privates Label
volumes:
  - ./data:/app/data:z

Diagnose: Was wurde wirklich gemountet?

# Mounts eines laufenden Containers inspizieren
docker inspect mycontainer | python3 -m json.tool | grep -A 20 '"Mounts"'

# Oder gezielt
docker inspect mycontainer --format '{{json .Mounts}}' | python3 -m json.tool

Ausgabe zeigt Typ (volume/bind), Source (Pfad auf Host oder Volume-Name) und Destination (Pfad im Container).

Alle Volumes auflisten und Anomalien finden

# Alle Volumes anzeigen – viele Hash-Namen deuten auf anonyme Volumes hin
docker volume ls

# Unbenutzte Volumes anzeigen (potentielle Waisen)
docker volume ls -f dangling=true

Viele Volumes mit langen Hash-Namen bedeuten meist, dass irgendwo der Top-Level-volumes-Block fehlt oder ein Tippfehler vorliegt.