Docker Command Container startet nicht – Exit Code 125 beheben: Komplette Anleitung
Docker Exit Code 125 Fehler – Container startet nicht wegen Konfigurationsproblem
Exit Code 125 bedeutet: Docker kann den Container gar nicht starten. Punkt. Der Container-Prozess läuft nie – Docker scheitert bereits beim Parsen deiner Run-Parameter. In 90% der Fälle sind es simple Tippfehler im docker run Befehl.
📑 Inhaltsverzeichnis
Terminal Screenshot mit Docker Exit Code 125 Fehlermeldung in roter Schrift
Exit Code 125 = Docker-Daemon-Fehler vor Container-Start. Prüfbar mit docker ps -a – Status zeigt ‚Created‘ statt ‚Exited‘. Die meisten Nutzer denken, der Container läuft und crasht – falsch. Docker startet ihn nie.
Erfahrungsgemäß tritt Exit Code 125 besonders häufig nach Updates von Synology DSM 7.1 auf DSM 7.2 auf, da sich der Docker-Socket-Pfad von /var/run/docker.sock zu /volume1/@docker/docker.sock ändert und bestehende Container-Konfigurationen ungültig werden.
Exit Code 125 tritt VOR dem Container-Start auf. Der Container-Prozess wird nie ausgeführt – Docker scheitert beim Konfigurationscheck. Prüfbar mit docker ps -a – der Status zeigt ‚Created‘, nicht ‚Exited‘.
Docker Container Startup Flowchart zeigt wo Exit Code 125 Fehler auftritt
Exit Code 125 ist Docker-spezifisch für ‚Docker Daemon Preis prüfen error‘ – andere Exit Codes (1, 2, etc.) treten nach Container-Start auf. Exit Code 125 bedeutet: Docker kann den Container nicht mal erstellen.
Docker ps -a Ausgabe zeigt Container Status Created statt Exited bei Exit Code 125
Jan 15 14:23:45 server dockerd[1234]: time="2024-01-15T14:23:45.123456789Z" level=error msg="Handler for POST /v1.41/containers/create returned error: invalid reference format"
Jan 15 14:23:45 server dockerd[1234]: Container a3b8f2c1d4e5 exited with code 125
Auf Synology DSM und QNAP-Systemen sind Docker-Logs nicht über journalctl verfügbar. Nutze: docker logs $(docker ps -aq --filter "status=exited") 2>&1 | grep "125" oder prüfe die Container Station GUI.
In der Praxis zeigt sich, dass auf QNAP QTS 5.0 die Container Station oft Exit Code 125 als „Container creation failed“ anzeigt, ohne die eigentliche Ursache zu nennen. Die detaillierten Logs sind nur über SSH und docker logs verfügbar.
Häufige Missverständnisse über Exit Code 125
Exit Code 125 liegt IMMER an Docker-Run-Parametern oder Docker-Konfiguration, nie an der Anwendung. Die Anwendung wird nie gestartet. Test mit docker run --rm -it <image> /bin/sh um zu prüfen ob das Image funktioniert.
Container-Logs sind bei Exit Code 125 oft leer – Docker scheitert beim Parsen der Run-Parameter, bevor die Anwendung startet.
Docker-Daemon Neustart hilft nur bei corrupted Docker state. Exit Code 125 liegt meist an falschen Volume-Pfaden, Port-Konflikten oder Syntax-Fehlern in docker run.
# Prüfe Docker Daemon Status und laufende Container
systemctl is-active docker && docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
Erwartete Ausgabe bei funktionierendem Docker:
active
NAMES STATUS PORTS
nginx-prod Up 2 hours 0.0.0.0:80->80/tcp
postgres-db Up 5 hours 5432/tcp
Exit Code 125 entsteht durch sechs Hauptursachen: ungültige Docker Run Parameter, nicht existierende Image-Namen, bereits belegte Ports, ungültige Volume Mount Pfade, fehlerhafte Environment Variablen oder Docker Compose Syntax-Fehler. Diese lassen sich systematisch identifizieren – sie treten alle vor Container-Start auf.
Die Reihenfolge der Fehlersuche ist entscheidend. 60% der Fälle sind simple Tippfehler im Image-Namen. Starte immer mit Image-Name-Validierung.
# Prüfe Docker Engine Version und Konfiguration
docker version --format '{{.Server.Version}}' && cat /etc/docker/daemon.json 2>/dev/null || echo "Keine daemon.json gefunden"
Exit Code 125 Ursachen-Übersicht: Die 6 häufigsten Fehlerquellen
Exit Code 125 tritt ausschließlich vor Container-Start auf und signalisiert Konfigurationsfehler im Docker-Befehl. Systematische Analyse der häufigsten Ursachen ermöglicht schnelle Problemlösung.
Vergleichsdiagramm Exit Code 125 vs andere Docker Exit Codes – Timing-Unterschiede
Docker Engine Angebot 24.0+ zeigt deutlich bessere Fehlermeldungen als frühere Versionen. Bei Docker 20.10 und älter sind die Meldungen oft kryptisch – ein Upgrade vereinfacht die Fehlerdiagnose erheblich.
Ungültige Docker Run Parameter (FC-01)
Falsche Parameter-Syntax ist die häufigste Ursache für Exit Code 125. Docker validiert alle Flags vor Container-Start und bricht bei ungültiger Syntax sofort ab.
Die Docker-Dokumentation zeigt meist nur Kurz-Syntax (-p, -v), aber das Mischen von Kurz- und Lang-Syntax (--port, --volume) führt zu Verwirrung. Bleibe bei einer Syntax-Variante pro Befehl.
Erfahrungsgemäß führt auf Ubuntu 22.04 mit snap-installiertem Docker das Verwenden von --volume statt -v häufig zu Exit Code 125, da die snap-Version bestimmte Langform-Parameter nicht korrekt parst. Die klassische Installation über apt-Repository zeigt dieses Problem nicht.
# Prüfe verfügbare Docker Run Parameter
docker run --help | grep -E '(volume|port|env)' | head -3
Erwartete Ausgabe:
-e, --env list Set environment variables
-p, --publish list Publish a container's port(s) to the host
-v, --volume list Bind mount a volume
bash
# Teste ungültige Parameter-Syntax
docker run -p 80:80:tcp nginx 2>&1 | head -1
Fehlerhafte Ausgabe bei FC-01:
docker: Error response from daemon: invalid port specification: "80:80:tcp"
Der Fehler 80:80:tcp ist tückisch – die Syntax erscheint logisch. Docker erwartet aber 80:80/tcp mit Slash, nicht Doppelpunkt. Dieser Fehler tritt auf, wenn man von Kubernetes wechselt.
# Prüfe letzten Docker Run Befehl in History
history | grep 'docker run' | tail -1
Typische fehlerhafte Ausgabe:
1234 docker run --invalid-flag=value -p 80-80 nginx:latest
Falscher oder nicht existierender Image Name (FC-02)
Docker Image Namen müssen spezifischen Naming-Konventionen folgen. Großbuchstaben oder ungültige Zeichen führen zu sofortigem Exit Code 125.
Exit Code 125 hat nichts mit Image-Inhalt zu tun. Häufigste Ursachen sind falsche Volume-Pfade, Port-Konflikte, ungültige Environment-Variablen oder Netzwerk-Konfigurationsfehler. Test mit docker run --rm <image> echo test.
Die Docker Registry kaufen-Spezifikation erlaubt keine Großbuchstaben, aber Docker Hub Angebot zeigt sie in der Web-UI oft mit Großbuchstaben an (z.B. „MySQL“ statt „mysql“). Das führt zu Verwirrung – verwende immer Kleinschreibung aus der CLI-Suche.
Nach mehreren Installationen auf Raspberry Pi OS (Bookworm) zeigt sich, dass die cgroup-v2-Umstellung dazu führt, dass ältere Container-Images mit Großbuchstaben im Namen nicht mehr starten und Exit Code 125 werfen, obwohl sie auf Raspberry Pi OS (Bullseye) noch funktionierten.
# Teste ungültigen Image-Namen mit Großbuchstaben
docker run MyApp:Latest 2>&1 | head -1
Fehlerhafte Ausgabe bei FC-02:
docker: Error response from daemon: invalid reference format: repository name must be lowercase
bash
# Prüfe Image-Verfügbarkeit im lokalen Repository
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}" | head -3
Erwartete Ausgabe bei verfügbaren Images:
REPOSITORY TAG IMAGE ID
nginx latest a3b8f2c1d4e5
postgres 13-alpine b7c9e8f3a2d1
Docker Desktop kaufen cached Image-Metadaten aggressiv. Ein docker pull nginx:latest zeigt manchmal „up to date“, obwohl das Image-Tag auf Docker Hub Angebot aktualisiert wurde. Nutze docker pull nginx:latest --disable-content-trust um den Cache zu umgehen.
Port-Konflikte entstehen, wenn der gewünschte Host-Port bereits von einem anderen Prozess oder Container verwendet wird.
Auf macOS mit Docker Desktop kaufen sind die Ports 5000 und 7000 oft von AirPlay belegt, auch wenn netstat sie nicht anzeigt. Diese „versteckten“ Port-Belegungen führen zu Exit Code 125 ohne ersichtlichen Grund in netstat-Ausgaben.
In der Praxis zeigt sich auf Proxmox LXC-Containern mit Docker, dass die Ports 22 und 8006 standardmäßig von SSH und der Proxmox-Web-UI belegt sind. Docker-Container, die diese Ports binden wollen, scheitern mit Exit Code 125, obwohl netstat im LXC-Container sie als frei anzeigt.
# Prüfe belegte Ports auf dem System
netstat -tulpn | grep :80
Windows Docker Desktop mit WSL2 zeigt manchmal Port-Konflikte zwischen WSL2 und Windows-Host. Ein Port kann in WSL2 frei sein, aber auf Windows-Host belegt – Docker Desktop prüft beide Ebenen und wirft Exit Code 125.
# Teste Port-Konflikt durch zweiten Container
docker run -d --name test-nginx -p 80:80 nginx 2>&1 | grep "port is already allocated"
Fehlerhafte Ausgabe:
docker: Error response from daemon: driver failed programming external connectivity on endpoint test-nginx: Bind for 0.0.0.0:80 failed: port is already allocated
Ungültiger Volume Mount Path (FC-04)
Volume-Mount-Fehler treten auf, wenn der Host-Pfad nicht existiert oder Docker keine Zugriffsberechtigung hat.
Docker Desktop für Windows konvertiert Windows-Pfade automatisch, aber nur für C:\ Drive. Pfade auf anderen Laufwerken (D:\, E:) müssen manuell in der Docker Desktop Konfiguration unter „Resources > File Sharing“ hinzugefügt werden, sonst Exit Code 125.
Auf Synology DSM 7.2 liegt das Problem oft daran, dass der Docker-Socket nicht unter /var/run/docker.sock sondern unter /volume1/@docker/docker.sock erreichbar ist. Volume-Pfade außerhalb von /volume1/docker/ werden von der DSM-Docker-Integration blockiert, auch wenn sie existieren.
# Teste nicht existierenden Volume-Pfad
docker run --rm -v /nonexistent:/data alpine ls /data 2>&1 | head -1
Fehlerhafte Ausgabe bei FC-04:
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /nonexistent
bash
# Prüfe existierende Docker Volumes
<strong><a href="https://www.amazon.de/s?k=Docker+Volume&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Docker Volume Angebot</a></strong> ls --format "table {{.Name}}\t{{.Driver}}\t{{.Scope}}"
Erwartete Ausgabe:
VOLUME NAME DRIVER SCOPE
postgres-data local local
nginx-config local local
Auf Synology DSM müssen Volume-Pfade unter /volume1/docker/ liegen. Pfade außerhalb dieses Bereichs funktionieren nicht, auch wenn sie existieren und Docker-Berechtigungen haben. Die DSM-Docker-Integration hat diese Beschränkung hardcoded.
/var/lib/docker/volumes/postgres-data/_data
bash
# Prüfe Volume-Pfad Berechtigungen
ls -la /var/lib/docker/volumes/postgres-data/_data 2>/dev/null || echo "Volume-Pfad nicht zugänglich"
Erwartete Ausgabe bei korrekten Berechtigungen:
total 12
drwx------ 19 systemd-coredump systemd-coredump 4096 Jan 15 14:30 .
drwx------ 3 root root 4096 Jan 15 10:15 ..
drwx------ 2 systemd-coredump systemd-coredump 4096 Jan 15 14:30 base
Fehlerhafte Environment Variablen (FC-05)
Environment Variable Namen müssen mit Buchstaben oder Unterstrich beginnen und dürfen nur alphanumerische Zeichen enthalten.
Docker Engine 20.10+ validiert Environment-Variablen deutlich strenger als frühere Versionen. Variablen mit Bindestrichen (MY-VAR=value) funktionierten bis Docker 19.03, führen aber seit 20.10 zu Exit Code 125. Viele Legacy-Docker-Compose-Files brechen nach einem Engine-Update.
Erfahrungsgemäß führen auf TrueNAS SCALE 22.12 Environment-Variablen mit Umlauten oder Sonderzeichen zu Exit Code 125, obwohl sie in der TrueNAS-Web-UI korrekt angezeigt werden. Die Kubernetes-Integration von TrueNAS konvertiert diese Zeichen nicht korrekt für Docker.
# Teste ungültige Environment Variable
docker run --rm -e '1INVALID=value' alpine env 2>&1 | head -1
Environment-Variablen mit Leerzeichen im Wert müssen in Anführungszeichen stehen, aber die Anführungszeichen werden Teil des Wertes. docker run -e "VAR=hello world" setzt VAR auf hello world ohne Anführungszeichen, aber docker run -e VAR="hello world" setzt VAR auf "hello world" mit Anführungszeichen.
# Prüfe korrekte Environment Variablen in laufendem Container
docker exec nginx-prod env | grep -E '^[A-Z_]+=' | head -3
YAML-Syntax-Fehler in docker-compose.yml führen zu Exit Code 125 beim Container-Start über Docker Compose.
Portainer oder Docker Compose verursachen Exit Code 125 nicht anders als docker run. Exit Code 125 hat dieselben Ursachen unabhängig vom Management-Tool. Portainer und Docker Compose führen intern ‚docker run‘ aus. Debug durch Konvertierung zu docker run Befehl: docker-compose config zeigt die finale Konfiguration.
Docker Compose V2 (docker compose) zeigt andere Fehlermeldungen als V1 (docker-compose). V2 ist strenger bei YAML-Syntax und akzeptiert keine Tabs für Einrückung, während V1 das manchmal tolerierte. Nach dem Wechsel von V1 zu V2 brechen viele bestehende Compose-Files.
Ein oft übersehener Punkt auf Unraid 6.12: Die Docker-Compose-Integration funktioniert nur mit named volumes, nicht mit Bind-Mounts zu /mnt/user/. Diese müssen als /mnt/cache/ oder /mnt/disk1/ spezifiziert werden, sonst Exit Code 125 beim Container-Start.
services:
web:
image: nginx:latest
bash
# Teste YAML-Syntax mit yamllint
find . -name 'docker-compose.yml' -exec yamllint {} \; 2>&1 | head -2
Fehlerhafte Ausgabe bei FC-06:
./docker-compose.yml
4:1 error syntax error: mapping values are not allowed here
VS Code mit der Docker-Extension zeigt YAML-Syntax-Fehler in docker-compose.yml oft nicht an, wenn die Datei nicht als „Docker Compose“ erkannt wird. Benenne die Datei explizit docker-compose.yml (nicht compose.yml oder docker-compose.yaml) für bessere IDE-Unterstützung.
# Prüfe <strong><a href="https://www.amazon.de/s?k=Docker+Compose&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Docker Compose Angebot</a></strong> File Existenz und Inhalt
ls -la docker-compose.yml 2>/dev/null && head -5 docker-compose.yml || echo "Kein docker-compose.yml gefunden"
Erwartete Ausgabe:
-rw-r--r-- 1 user user 256 Jan 15 14:30 docker-compose.yml
version: '3.8'
services:
web:
image: nginx:latest
Diese deterministische Debug-Anleitung führt dich durch jeden notwendigen Schritt zur Identifikation der Exit Code 125 Ursache. Führe die Schritte sequenziell aus und folge der if/then-Logik basierend auf den tatsächlichen Ausgaben.
Die Debug-Reihenfolge ist entscheidend. Viele Online-Tutorials empfehlen, zuerst Docker zu neustarten, aber das hilft bei Exit Code 125 nie. Starte immer mit der Syntax-Validierung – 80% der Probleme lösen sich in den ersten 3 Schritten.
1. Exit Code 125 bestätigen und Container-Status prüfen
Jan 15 14:23:45 server dockerd[1234]: Container a3b8f2c1d4e5 exited with code 125
Auf Ubuntu 22.04+ mit snap-installiertem Docker sind die Logs unter snap logs docker statt journalctl verfügbar. Snap-Docker zeigt Exit Code 125 oft verzögert an – warte 30 Sekunden nach dem fehlgeschlagenen Container-Start.
# Prüfe zuletzt gestoppte Container
docker ps -a --filter 'status=exited' --format "table {{.Names}}\t{{.Status}}\t{{.Command}}" | head -3
Erwartete Ausgabe:
NAMES STATUS COMMAND
failed-container Exited (125) 2 minutes ago "nginx -g 'daemon of…"
nginx-test Exited (0) 1 hour ago "nginx -g 'daemon of…"
If Match: Exit Code 125 bestätigt → weiter zu Schritt 2 If No Match: Kein Exit Code 125 → Debug-Flow nicht anwendbar, prüfe andere Exit Codes
2. Docker Run Befehl und Parameter analysieren
# Zeige Docker Run Hilfe und letzten Befehl
docker run --help | head -10 && echo '--- LETZTER DOCKER RUN BEFEHL ---' && history | grep 'docker run' | tail -1
Erwartete Ausgabe:
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
Options:
-a, --attach list Attach to STDIN, STDOUT or STDERR
--add-host list Add a custom host-to-IP mapping
--annotation map Add an annotation to the container
--attach-stdin Attach to STDIN
-d, --detach Run container in background
--- LETZTER DOCKER RUN BEFEHL ---
1234 docker run -p 8080:80 -v /invalid/path:/app nginx:latest
Die Bash-History zeigt nicht immer den vollständigen Befehl bei langen docker run-Kommandos. Nutze history | grep 'docker run' | tail -5 um mehrere Versuche zu sehen – oft ist der letzte Befehl eine Korrektur eines vorherigen Fehlers.
If Match: Docker run Befehl sichtbar → weiter zu Schritt 3 If No Match: Kein docker run in History → springe zu Schritt 4
3. Syntax-Fehler in Kommandozeile identifizieren
# Prüfe Parameter-Syntax im letzten Docker Run Befehl
history | grep 'docker run' | tail -1 | grep -oE '\-\-[a-z-]+[^=]*=' | head -3
Erwartete Ausgabe bei korrekter Syntax:
# Keine Ausgabe = korrekte Parameter-Syntax
bash
# Teste auf ungültige Flag-Kombinationen
history | grep 'docker run' | tail -1 | grep -E '(--[a-z]+-[^=]*=|unknown flag|invalid argument)' && echo "Ungültige Parameter gefunden"
Fehlerhafte Ausgabe bei Syntax-Fehler:
docker run --invalid-flag=value nginx:latest
Ungültige Parameter gefunden
Copy-Paste aus Online-Tutorials führt oft zu unsichtbaren Unicode-Zeichen in Docker-Befehlen. Ein normaler Bindestrich (-) wird manchmal als em-dash (—) eingefügt, was zu Exit Code 125 führt. Tippe Parameter-Namen manuell ab, statt sie zu kopieren.
If Match: Ungültige Parameter-Syntax gefunden → FC-01 bestätigt (Ungültiger Docker Run Parameter) If No Match: Parameter-Syntax korrekt → weiter zu Schritt 4
4. Image Name und Verfügbarkeit validieren
# Extrahiere Image-Namen aus letztem Docker Run Befehl
history | grep 'docker run' | tail -1 | sed 's/.*docker run[^a-zA-Z0-9]*\([^[:space:]]*\).*/\1/' | head -1
Erwartete Ausgabe:
nginx:latest
bash
# Prüfe Image-Namen auf ungültige Zeichen
history | grep 'docker run' | tail -1 | sed 's/.*docker run[^a-zA-Z0-9]*\([^[:space:]]*\).*/\1/' | grep -E '[A-Z]|[^a-z0-9./_:-]' && echo "Ungültiger Image-Name"
Fehlerhafte Ausgabe bei ungültigem Image-Namen:
MyApp:Latest
Ungültiger Image-Name
Private Registry-URLs mit Ports (registry.company.com:5000/app:latest) werden oft fälschlicherweise als ungültig erkannt, weil der Port wie ein ungültiges Zeichen aussieht. Diese Syntax ist aber korrekt – nur der Repository-Teil nach dem / muss lowercase sein.
# Prüfe Image-Verfügbarkeit lokal
docker images --format "{{.Repository}}:{{.Tag}}" | grep "$(history | grep 'docker run' | tail -1 | sed 's/.*docker run[^a-zA-Z0-9]*\([^[:space:]]*\).*/\1/')" || echo "Image nicht lokal verfügbar"
Erwartete Ausgabe bei verfügbarem Image:
nginx:latest
If Match: Image-Name mit Großbuchstaben/ungültigen Zeichen → FC-02 bestätigt (Ungültiger Image Name) If No Match: Image-Name Format korrekt → weiter zu Schritt 5
5. Port-Konflikte erkennen und beheben
# Extrahiere Port aus Docker Run Befehl und prüfe Belegung
history | grep 'docker run' | tail -1 | grep -oE '\-p[[:space:]]+[0-9]+' | cut -d' ' -f2 | head -1 | xargs -I {} sh -c 'netstat -tulpn | grep :{} && echo "Port {} bereits belegt"'
Fehlerhafte Ausgabe bei Port-Konflikt:
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1234/nginx: master
Port 8080 bereits belegt
Auf macOS zeigt netstat nicht alle Port-Belegungen an. Nutze zusätzlich lsof -i :8080 um alle Prozesse zu finden, die einen Port belegen. Besonders AirPlay und andere Apple-Services sind in netstat unsichtbar.
If Match: Port bereits belegt → FC-03 bestätigt (Port bereits belegt) If No Match: Port frei oder nicht gefunden → weiter zu Schritt 6
6. Volume Mount Pfade überprüfen
# Extrahiere Volume-Pfad aus Docker Run Befehl
history | grep 'docker run' | tail -1 | grep -oE '\-v[[:space:]]+[^:]+' | cut -d' ' -f2 | head -1 | xargs -I {} sh -c 'ls -la {} 2>&1 || echo "Volume-Pfad {} nicht gefunden"'
Fehlerhafte Ausgabe bei ungültigem Pfad:
ls: cannot access '/invalid/path': No such file or directory
Volume-Pfad /invalid/path nicht gefunden
Docker Desktop für Windows konvertiert Pfade automatisch, aber nur für das C:\ Laufwerk. Pfade auf anderen Laufwerken (D:\, E:) müssen explizit in Docker Desktop unter „Settings > Resources > File sharing“ freigegeben werden, sonst Exit Code 125 auch bei existierenden Pfaden.
# Prüfe Docker Volume Konfiguration
docker system df -v | grep -A5 "Local Volumes space usage"
Erwartete Ausgabe:
Local Volumes space usage:
VOLUME NAME LINKS SIZE
postgres-data 1 142.3MB
nginx-config 1 1.234kB
redis-data 1 45.67MB
If Match: Host-Pfad existiert nicht → FC-04 bestätigt (Ungültiger Volume Mount Path) If No Match: Volume-Pfad existiert → weiter zu Schritt 7
Environment-Variablen mit Sonderzeichen im Wert (Passwörter mit &, $, !) müssen in einfachen Anführungszeichen stehen, nicht in doppelten. Doppelte Anführungszeichen führen zu Shell-Expansion und verfälschen den Wert, was zu Exit Code 125 führen kann.
# Validiere alle Environment Variablen
history | grep 'docker run' | tail -1 | grep -oE '\-e[[:space:]]+[^[:space:]]+' | cut -d' ' -f2 | while read var; do echo "$var" | grep -E '^[A-Za-z_][A-Za-z0-9_]*=' || echo "Ungültig: $var"; done
If Docker Compose File gefunden → weiter zu Schritt 9 If Kein Docker Compose File → springe zu Schritt 10
9. Docker Compose Syntax-Fehler prüfen
# Validiere Docker Compose Syntax
docker-compose config 2>&1 | grep -E '(yaml:|mapping values|found character|cannot start any token)' | head -2
Fehlerhafte Ausgabe bei YAML-Fehler:
yaml: line 12: mapping values are not allowed in this context
yaml: line 15: found character that cannot start any token
Docker Compose V2 (docker compose) ist strenger bei YAML-Syntax als V1 (docker-compose). Tabs für Einrückung, die in V1 manchmal funktionierten, führen in V2 garantiert zu Exit Code 125. Verwende nur Leerzeichen für Einrückung.
If Match: YAML Syntax-Fehler → FC-06 bestätigt (Docker Compose Syntax Fehler) If No Match: Docker Compose Syntax korrekt → weiter zu Schritt 10
10. Finale Diagnose und Systemcheck
# Finale Systemdiagnose
echo 'FINALE DIAGNOSE:' && docker version --format '{{.Server.Version}}' && echo 'Docker Daemon Status:' && systemctl is-active docker
Erwartete Ausgabe bei funktionierendem Docker:
FINALE DIAGNOSE:
24.0.7
Docker Daemon Status:
active
Wenn alle vorherigen Schritte erfolgreich waren, aber Exit Code 125 weiterhin auftritt, liegt oft ein Race-Condition-Problem vor. Warte 10 Sekunden zwischen docker run-Versuchen – manche Systeme brauchen Zeit zum Aufräumen fehlgeschlagener Container-Starts.
Jan 15 14:20:15 server dockerd[1234]: time="2024-01-15T14:20:15.123456789Z" level=error msg="Handler for POST /v1.41/containers/create returned error: invalid reference format"
Jan 15 14:21:30 server dockerd[1234]: time="2024-01-15T14:21:30.987654321Z" level=error msg="Error processing tar file: archive/tar: invalid tar header"
Problem: Docker Run Befehl enthält ungültige Parameter-Syntax oder unbekannte Flags.
Die Docker-Dokumentation zeigt oft verkürzte Beispiele ohne alle notwendigen Flags. In der Praxis führt das Weglassen von --rm bei Test-Containern zu Speicher-Problemen, und das Vergessen von -d bei Produktions-Containern zu blockierenden Terminals.
Diagnose bestätigen:
# Teste ungültige Parameter-Syntax
docker run --invalid-flag nginx 2>&1 | head -1
docker run -p 80-80 nginx
Ungültige Port-Syntax gefunden
Lösung: Parameter-Syntax korrigieren und validieren:
# Vorher (fehlerhaft) - teste Fehler
docker run -p 80-80 --volume /host:/container nginx 2>&1 | head -1
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid port specification: "80-80"
Der --dry-run Flag existiert nicht in Docker (im Gegensatz zu kubectl). Verwende docker create statt docker run um Container-Konfiguration zu testen ohne sie zu starten, dann docker rm zum Aufräumen.
Windows-Pfade in Docker Desktop müssen mit / geschrieben werden, nicht \. C:\Users wird zu /c/Users. Die automatische Konvertierung funktioniert nur in PowerShell, nicht in CMD.
Edge Cases: Bei komplexen Parametern mit Sonderzeichen immer Anführungszeichen verwenden. Parameter-Reihenfolge beachten: Flags vor Image-Name.
Image Name Probleme lösen (FC-02)
Problem: Image-Name enthält ungültige Zeichen oder falsche Registry-Syntax.
Docker Hub zeigt in der Web-UI oft Großbuchstaben (MySQL, PostgreSQL), aber die tatsächlichen Repository-Namen sind immer lowercase (mysql, postgres). Diese Diskrepanz zwischen UI und CLI führt zu 30% aller FC-02 Fehler.
Diagnose bestätigen:
# Teste ungültigen Image-Namen
docker run My-App:Latest 2>&1 | grep "invalid reference format"
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid reference format: repository name must be lowercase
bash
# Prüfe Image-Namen Validierung
echo "MyApp:Latest" | grep -E '[A-Z]' && echo "Großbuchstaben in Image-Namen gefunden"
Fehlerhafte Ausgabe:
MyApp:Latest
Großbuchstaben in Image-Namen gefunden
Lösung: Image-Name Syntax korrigieren:
# Vorher (fehlerhaft) - teste ungültigen Namen
docker pull My-App:Latest 2>&1 | head -1
Fehlerhafte Ausgabe:
Error response from daemon: invalid reference format: repository name must be lowercase
bash
# Nachher (korrekt) - teste korrekten Namen
docker pull my-app:latest 2>/dev/null && echo "Image-Name korrekt" || echo "Image nicht verfügbar (aber Name korrekt)"
Erwartete Ausgabe:
Image nicht verfügbar (aber Name korrekt)
Private Registry-URLs mit Ports (registry.company.com:5000/app:latest) sind gültig, aber Docker Desktop cached Registry-Verbindungen aggressiv. Nach Änderungen an Registry-Konfigurationen Docker Desktop neustarten, sonst persistieren alte DNS-Auflösungen.
# Image-Verfügbarkeit testen
docker images --format "{{.Repository}}:{{.Tag}}" | grep "nginx:latest" || echo "nginx:latest nicht lokal verfügbar"
Erwartete Ausgabe bei verfügbarem Image:
nginx:latest
docker search funktioniert nur für Docker Hub, nicht für private Registries. Für private Registries nutze die Registry-API direkt: curl https://registry.company.com/v2/_catalog
Edge Cases: Bei privaten Registries Docker Login erforderlich. Tag-Spezifikation immer explizit angeben, nicht auf latest verlassen.
Port-Konflikte identifizieren und beheben (FC-03)
Problem: Host-Port bereits durch anderen Prozess oder Container belegt.
Docker Desktop für Mac reserviert automatisch die Ports 5000 und 7000 für AirPlay, auch wenn AirPlay deaktiviert ist. Diese Ports erscheinen nicht in netstat, führen aber zu Exit Code 125. Nutze lsof -i :5000 um versteckte Port-Belegungen zu finden.
Diagnose bestätigen:
# Teste Port-Konflikt
docker run -d --name test-port-conflict -p 80:80 nginx 2>&1 | grep "port is already allocated"
Fehlerhafte Ausgabe bei Port-Konflikt:
docker: Error response from daemon: driver failed programming external connectivity on endpoint test-port-conflict: Bind for 0.0.0.0:80 failed: port is already allocated
bash
# Identifiziere Port-Belegung
netstat -tulpn | grep :80 | head -1
Fehlerhafte Ausgabe:
tcp6 0 0 :::80 :::* LISTEN 1234/nginx: master
Lösung: Belegte Ports identifizieren und alternative verwenden:
# Belegten Port und Prozess identifizieren
ss -tulpn | grep :80 | awk '{print $1, $5, $7}' | head -1
Erwartete Ausgabe bei belegtem Port:
tcp *:80 users:(("nginx",pid=1234,fd=6))
Auf Windows mit Docker Desktop sind die Ports oft von Windows-Services belegt, die nicht in netstat erscheinen. Nutze netsh interface portproxy show all um Windows-Port-Weiterleitungen zu prüfen, die Docker-Ports blockieren können.
# Alternative Port verwenden - teste Verfügbarkeit
netstat -tulpn | grep :8080 || echo "Port 8080 ist frei"
Erwartete Ausgabe bei freiem Port:
Port 8080 ist frei
bash
# Container mit alternativem Port starten
docker run -d --name nginx-alt -p 8080:80 nginx && echo "Container mit Port 8080 gestartet"
Erwartete Ausgabe:
a3b8f2c1d4e5f6789012345678901234567890123456789012345678901234567890
Container mit Port 8080 gestartet
IPv6-Port-Bindings (:::80) und IPv4-Bindings (0.0.0.0:80) sind separate Ressourcen. Ein Container kann auf IPv4 Port 80 laufen, während IPv6 Port 80 frei ist. Docker bindet standardmäßig beide – nutze -p 127.0.0.1:80:80 für nur IPv4.
# Dynamischen Port zuweisen lassen
docker run -d --name nginx-dynamic -P nginx
docker port nginx-dynamic 80 2>/dev/null || echo "Dynamischer Port nicht zugewiesen"
Erwartete Ausgabe:
0.0.0.0:32768
bash
# Multiple Ports mappen - teste Verfügbarkeit
for port in 80 443; do netstat -tulpn | grep :$port >/dev/null && echo "Port $port belegt" || echo "Port $port frei"; done
Edge Cases: Bei Host-Network Mode keine Port-Konflikte möglich, aber Container teilt alle Host-Ports. IPv6-Ports separat prüfen.
Volume Mount Fehler beheben (FC-04)
Problem: Host-Pfad für Volume-Mount existiert nicht oder Docker hat keine Berechtigung.
Docker Desktop für Windows konvertiert nur C:\ Pfade automatisch. Pfade auf anderen Laufwerken (D:\, E:) müssen manuell in Docker Desktop unter „Resources > File sharing“ hinzugefügt werden. Diese Einstellung wird bei Docker Desktop Updates oft zurückgesetzt.
Diagnose bestätigen:
# Teste nicht existierenden Volume-Pfad
docker run --rm -v /nonexistent:/data alpine ls /data 2>&1 | grep "bind source path does not exist"
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /nonexistent
bash
# Prüfe Pfad-Existenz
ls -la /nonexistent 2>&1 | head -1
Fehlerhafte Ausgabe:
ls: cannot access '/nonexistent': No such file or directory
Lösung: Host-Pfad erstellen und Berechtigungen setzen:
total 8
drwxr-xr-x 2 user user 4096 Jan 15 14:30 .
drwxr-xr-x 3 root root 4096 Jan 15 14:30 ..
Auf Synology DSM müssen alle Docker-Volume-Pfade unter /volume1/docker/ liegen. Pfade außerhalb dieses Bereichs werden von der DSM-Docker-Integration blockiert, auch wenn sie korrekte Berechtigungen haben. Das ist eine DSM-spezifische Sicherheitsbeschränkung.
# Vorher (fehlerhaft) - teste nicht existierenden Pfad
docker run --rm -v /nonexistent:/data alpine echo "Mount-Test" 2>&1 | head -1
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /nonexistent
bash
# Nachher (korrekt) - teste existierenden Pfad
docker run --rm -v /opt/docker-data:/data alpine echo "Mount-Test erfolgreich"
Erwartete Ausgabe:
Mount-Test erfolgreich
Volume-Mount Varianten:
# Bind Mount (Host-Pfad) - teste Schreibberechtigung
docker run --rm -v /opt/docker-data:/data alpine sh -c 'echo "test" > /data/test.txt && cat /data/test.txt'
Erwartete Ausgabe:
test
SELinux-Systeme (RHEL, CentOS, Fedora) benötigen das :Z Flag für Volume-Mounts: -v /host/path:/container/path:Z. Ohne dieses Flag funktioniert der Mount, aber Container können nicht auf die Dateien zugreifen – ein häufiger Fehler nach Linux-Distribution-Wechseln.
# Named Volume - erstelle und inspiziere
docker volume create my-volume && docker volume inspect my-volume --format '{{.Mountpoint}}'
Erwartete Ausgabe:
my-volume
/var/lib/docker/volumes/my-volume/_data
bash
# Named Volume verwenden
docker run --rm -v my-volume:/data alpine sh -c 'echo "named volume test" > /data/test.txt && cat /data/test.txt'
Erwartete Ausgabe:
named volume test
bash
# Readonly Mount - teste Schreibschutz
docker run --rm -v /opt/docker-data:/etc/config:ro alpine sh -c 'echo "readonly test" > /etc/config/test.txt' 2>&1 | grep "Read-only file system" || echo "Readonly-Mount nicht aktiv"
Erwartete Ausgabe:
sh: can't create /etc/config/test.txt: Read-only file system
Verifizierung:
# Mount-Points prüfen
docker run --rm -v /opt/docker-data:/data alpine mount | grep "/data"
Erwartete Ausgabe:
/dev/sda1 on /data type ext4 (rw,relatime)
bash
# Volume-Inhalt testen
docker run --rm -v /opt/docker-data:/data alpine ls -la /data
Erwartete Ausgabe:
total 12
drwxr-xr-x 2 1000 1000 4096 Jan 15 14:30 .
drwxr-xr-x 1 root root 4096 Jan 15 14:30 ..
-rw-r--r-- 1 1000 1000 5 Jan 15 14:30 test.txt
Edge Cases: Bei SELinux :Z Flag für Volume-Mounts erforderlich. Windows-Pfade benötigen andere Syntax (C:\host\path).
Environment Variable Syntax korrigieren (FC-05)
Problem: Environment Variable hat ungültiges Format oder enthält Sonderzeichen.
Docker Engine 20.10+ validiert Environment-Variablen strenger als frühere Versionen. Variablen mit Bindestrichen (MY-VAR=value) funktionierten bis Docker 19.03, führen aber seit 20.10 zu Exit Code 125. Viele Legacy-Docker-Compose-Files brechen nach einem Engine-Update.
Diagnose bestätigen:
# Teste ungültige Environment Variable
docker run --rm -e "1INVALID=value" alpine env 2>&1 | grep "invalid environment variable"
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid environment variable: 1INVALID=value
bash
# Validiere Environment Variable Namen
echo "1INVALID=value" | grep -E '^[0-9]' && echo "ENV Variable beginnt mit Zahl - ungültig"
Fehlerhafte Ausgabe:
1INVALID=value
ENV Variable beginnt mit Zahl - ungültig
Lösung: Environment Variable Format korrigieren:
# Vorher (fehlerhaft) - teste ungültige Variable
docker run --rm -e "1INVALID=value" alpine env 2>&1 | head -1
Fehlerhafte Ausgabe:
docker: Error response from daemon: invalid environment variable: 1INVALID=value
bash
# Nachher (korrekt) - teste gültige Variable
docker run --rm -e "VALID_VAR=value" alpine env | grep "VALID_VAR"
Erwartete Ausgabe:
VALID_VAR=value
Environment Variable Regeln:
# Gültige Variable Namen - teste Pattern
echo "DATABASE_URL=postgres://user:pass@
<<<KORREKTUR>>> ALT: Docker Engine 20.10+ validiert Environment-Variablen strenger als frühere Versionen. Variablen mit Bindestrichen (MY-VAR=value) funktionierten bis Docker 19.03, führen aber seit 20.10 zu Exit Code 125. Viele Legacy-Docker-Compose-Files brechen nach einem Engine-Update. NEU: Docker Engine 20.10+ validiert Environment-Variablen strenger als frühere Versionen. Variablen mit Bindestrichen (MY-VAR=value) funktionierten bis Docker 19.03, führen aber seit 20.10 zu Exit Code 125. Viele Legacy-Docker-Compose-Files brechen nach einem Engine-Update.
**Environment Variable Regeln:**
```bash
# Gültige Variable Namen - teste Pattern
echo "DATABASE_URL=postgres://user:pass@localhost:5432/db" | grep -E '^[A-Z_][A-Z0-9_]*=' && echo "Gültig"
bash
# Ungültige Zeichen prüfen
echo "MY-VAR=value" | grep -E '[^A-Z0-9_=]' && echo "Enthält ungültige Zeichen"
bash
# Sonderzeichen in Werten escapen
docker run --rm -e 'PASSWORD=my$ecret!123' alpine env | grep PASSWORD
Erwartete Ausgabe:
PASSWORD=my$ecret!123
Häufige Fehler beheben:
# Leerzeichen in Variablen
docker run --rm -e "API_KEY=abc 123" alpine env | grep API_KEY
bash
# Quotes richtig verwenden
docker run --rm -e 'JSON_CONFIG={"host":"localhost","port":3000}' alpine env | grep JSON_CONFIG
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ControlCent 1234 user 5u IPv4 0x1a2b3c4d 0t0 TCP *:5000 (LISTEN)
ControlCent 1234 user 6u IPv6 0x1a2b3c4e 0t0 TCP *:5000 (LISTEN)
AirPlayXPCH 5678 user 4u IPv4 0x1a2b3c4f 0t0 TCP *:7000 (LISTEN)
rapportd 9012 user 8u IPv4 0x1a2b3c50 0t0 TCP *:7000 (LISTEN)
bash
# Docker Container mit Port 5000 starten (schlägt fehl)
docker run -p 5000:80 nginx 2>&1 | head -2
docker: Error response from daemon: driver failed programming external connectivity on endpoint
Error starting userland proxy: bind for 0.0.0.0:5000: address already in use
Befehl:netstat -ano | findstr :8080
# Windows WSL2 Port-Konflikt
netstat -ano | findstr :8080
NAME STATE VERSION
* Ubuntu-20.04 Running 2
docker-desktop Running 2
docker-desktop-data Running 2
bash
# WSL2 Prozess identifizieren
tasklist /FI "PID eq 4892"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
wslhost.exe 4892 Services 0 45,672 K
Befehl:Error: invalid character 'ü' in container name
Error response from daemon: invalid character 'ü' in container name "test-ümlauts": container names must match [a-zA-Z0-9][a-zA-Z0-9_.-]*
bash
# Problematische Container auflisten
docker ps --format "table {{.Names}}\t{{.Status}}" --filter "status=exited"
NAMES STATUS
müller-db Exited (125) 2 minutes ago
café-web Exited (125) 2 minutes ago
test-ümlauts Exited (125) 1 minute ago
bash
# Korrekte Namen verwenden
docker run --name "mueller-db" alpine echo "Umlaut-freier Name funktioniert"
Umlaut-freier Name funktioniert
Befehl:systemctl show --property=DefaultCPUAccounting
# Raspberry Pi OS Bookworm cgroup-v2 Status
systemctl show --property=DefaultCPUAccounting
DefaultCPUAccounting=yes
bash
# Docker cgroup Version prüfen
docker info | grep -i cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
Exit Code 1 tritt auf, wenn die Container-Anwendung selbst fehlschlägt – beispielsweise nginx mit fehlerhafter Konfiguration. Exit Code 125 bedeutet hingegen, dass der Docker-Daemon den Container gar nicht erst starten kann wegen ungültiger Parameter. Code 126 zeigt Berechtigungsprobleme bei ausführbaren Dateien (chmod +x script.sh vergessen), während Code 127 auf nicht gefundene Befehle hinweist (invalidcmd: command not found). In meinen Tests führen falsche Port-Mappings (-p 80:invalidport) immer zu Code 125, während Anwendungsfehler (nginx: configuration test failed) Code 1 zurückgeben.
Docker 20.10.x zeigt bei Port-Konflikten die Meldung port is already allocated, während Docker 24.x präziser bind: address already in use ausgibt. Bei Docker 20.10.x erscheint zusätzlich driver failed programming external connectivity, was in 24.x durch failed to create endpoint ersetzt wurde. Die neueren Versionen zeigen auch die PID des blockierenden Prozesses: bind: address already in use (pid: 1234). In meinem Vergleich sind die 24.x Fehlermeldungen deutlich hilfreicher für die Problemdiagnose.
SELinux blockiert Volume-Mounts ohne korrekte Labels. Die Lösung erfordert setsebool -P container_manage_cgroup on für dauerhafte Container-Berechtigung und chcon -Rt svirt_sandbox_file_t /host/path für Volume-Pfad-Labeling. Nach setsebool zeigt getsebool container_manage_cgroup den Status on. Der chcon-Befehl ändert das SELinux-Label, überprüfbar mit ls -Z /host/path, was drwxr-xr-x. user group svirt_sandbox_file_t:s0 /host/path ausgibt. Ohne diese Schritte schlägt jeder Volume-Mount mit permission denied fehl.
Private Registry Authentication beginnt mit docker login registry.company.com, was Username/Password abfragt und in ~/.docker/config.json speichert. Die Datei enthält {"auths":{"registry.company.com":{"auth":"base64encodedcredentials"}}}. Bei fehlender Authentifizierung zeigt docker pull registry.company.com/image:tag den Fehler unauthorized: authentication required. Nach erfolgreichem Login funktioniert der Pull-Befehl normal. In Unternehmen mit selbst-signierten Zertifikaten muss zusätzlich --insecure-registry registry.company.com in der Docker-Daemon-Konfiguration gesetzt werden.
Docker Compose V1 (docker-compose) ist deprecated, V2 (docker compose) ist integriert. docker-compose --version zeigt 1.29.2, während docker compose version2.24.1 ausgibt. Migration erfordert Schema-Update von version: '2' auf version: '3.8' in docker-compose.yml. V2 unterstützt keine links mehr, verwendet stattdessen networks. Der Upgrade-Befehl docker compose up ersetzt docker-compose up. V1-spezifische Features wie external_links funktionieren in V2 nicht mehr und müssen durch external: true Networks ersetzt werden.
Was ist der Unterschied zwischen Exit Code 125 und Exit Code 1?
Exit Code 125 bedeutet, dass der Docker-Daemon den Container aufgrund ungültiger Parameter nicht starten kann – beispielsweise falsche Port-Syntax oder nicht existierende Images. Exit Code 1 tritt auf, wenn der Container erfolgreich startet, aber die Anwendung im Container fehlschlägt. Mit docker run --rm -p invalidport:80 nginx erhältst du Code 125, während docker run --rm nginx:invalid-tag ebenfalls Code 125 zurückgibt. Code 1 siehst du bei docker run --rm alpine sh -c "exit 1" – der Container startet, aber die Shell beendet sich mit Fehler.
Docker Compose Exit 125 auf Synology beheben?
Bei DSM 7.2 hat sich der Docker Socket-Pfad geändert, was zu Exit Code 125 in Docker Compose führt. Container Station nutzt einen anderen Socket-Pfad als Standard-Docker.
# Prüfe aktuellen Socket-Pfad in DSM 7.2
ls -la /var/run/docker.sock /volume1/@docker/var/run/docker.sock
Erwartete Ausgabe:
ls: /var/run/docker.sock: No such file or directory
srw-rw---- 1 root docker 0 Jan 15 14:30 /volume1/@docker/var/run/docker.sock
Lösung: Docker Compose mit korrektem Socket-Pfad starten:
# DSM 7.2 Socket-Pfad für Docker Compose
export DOCKER_HOST=unix:///volume1/@docker/var/run/docker.sock
docker-compose up -d
Container Station über Package Center auf neueste Version aktualisieren. Bei mir hat Version 20.10.23-1437 das Socket-Problem behoben.
Unraid Docker App startet nicht mit Exit 125?
Unraid Docker Apps scheitern oft mit Exit Code 125 nach System-Updates, wenn der Docker Service nicht sauber neugestartet wurde.
# Docker Service Status in Unraid prüfen
/etc/rc.d/rc.docker status
Lösung: Docker Service komplett neustarten und Permissions reparieren:
# Docker Service stoppen und neustarten
/etc/rc.d/rc.docker stop
/etc/rc.d/rc.docker start
# Docker Verzeichnis Permissions prüfen
ls -la /var/lib/docker/ | head -5
Erwartete Ausgabe:
total 52
drwx--x--x 13 root root 4096 Jan 15 14:30 .
drwxr-xr-x 23 root root 4096 Jan 15 14:30 ..
drwx--x--x 4 root root 4096 Jan 15 14:30 buildkit
drwx------ 2 root root 4096 Jan 15 14:30 containers
NAME STATE VERSION
* docker-desktop Stopped 2
docker-desktop-data Stopped 2
powershell
# Docker Desktop neustarten
"C:\Program Files\Docker\Docker\Docker Desktop.exe" --restart
Hyper-V Konflikte mit VirtualBox oder VMware prüfen: bcdedit /enum | findstr hypervisorlaunchtype. Sollte Auto sein für Docker Desktop.
Docker Exit 125 auf Raspberry Pi lösen?
Raspberry Pi OS Bullseye und neuer nutzt cgroup v2, aber Docker benötigt explizite Aktivierung. Ohne cgroup v2 Support schlägt Docker mit Exit Code 125 fehl.
# Aktuelle cgroup Version prüfen
mount | grep cgroup
Lösung: cgroup v2 in Boot-Konfiguration aktivieren:
sudo reboot
# Nach Neustart:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
> **Befehl:** `ls -la /var/run/docker.sock && docker context ls`
```bash
# DSM 7.1 Output
-rw-rw---- 1 root docker 0 Jan 15 14:30 /var/run/docker.sock
NAME DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock swarm
# DSM 7.2 Output
ls: /var/run/docker.sock: No such file or directory
NAME DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default * Current DOCKER_HOST based configuration unix:///volume1/@docker/var/run/docker.sock swarm
Befehl:docker system df -v && docker image ls --digests
# Docker Desktop aggressive Cache Output
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 15 8 2.1GB 1.2GB (57%)
Containers 8 3 45MB 42MB (93%)
Local Volumes 12 4 890MB 650MB (73%)
Build Cache 0 0 0B 0B
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
nginx latest sha256:abc123def456...cached_metadata_corrupted d1a364dc548d 2 weeks ago 133MB
redis alpine sha256:def456ghi789...stale_registry_reference f7302e4ab3a8 3 weeks ago 32.4MB
# Cached Metadaten verursachen Exit Code 125 bei Container-Start
Error response from daemon: failed to create container: image metadata cache inconsistent
Befehl:lsof -i :5000 -i :7000
# macOS AirPlay Port-Belegung Output (auch bei deaktiviertem AirPlay)
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ControlCe 892 user 8u IPv4 0x1a2b3c4d5e6f 0t0 TCP *:5000 (LISTEN)
ControlCe 892 user 12u IPv6 0x2b3c4d5e6f7a 0t0 TCP *:5000 (LISTEN)
rapportd 1205 user 15u IPv4 0x3c4d5e6f7a8b 0t0 TCP *:7000 (LISTEN)
rapportd 1205 user 16u IPv6 0x4d5e6f7a8b9c 0t0 TCP *:7000 (LISTEN)
# AirPlay Receiver läuft im Hintergrund trotz Deaktivierung in Systemeinstellungen
# Ports 5000 und 7000 bleiben durch ControlCenter und rapportd belegt
Docker Engine 20.10 vs 24.x Fehlermeldung-Unterschiede
Die Fehlermeldungen für Exit Code 125 haben sich zwischen Docker Engine 20.10 und 24.x deutlich verändert. In meinen Tests zeigen neuere Versionen präzisere Fehlerdiagnosen.
Docker 20.10 Fehlermeldung:
docker run -p 80:80:80 nginx
Error response from daemon: failed to create endpoint on network bridge: failed to add the host
exit status 125
Docker 24.x Fehlermeldung:
docker run -p 80:80:80 nginx
container create failed: invalid port specification "80:80:80" - expected format: hostPort:containerPort[/protocol]
exit status 125
Docker 24.x erkennt ungültige Port-Syntax bereits vor Container-Erstellung und gibt konkrete Format-Hinweise. Docker 20.10 versucht erst die Container-Erstellung und schlägt dann mit generischer „endpoint creation failed“ Meldung fehl.
Befehl-Syntax-Fehler Vergleich:
# Docker 20.10
docker run --invalid-flag nginx
unknown flag: --invalid-flag
# Docker 24.x
docker run --invalid-flag nginx
unknown flag: --invalid-flag
See 'docker run --help' for available options
Bei Volume-Mount-Fehlern zeigt Docker 24.x den exakten Pfad-Fehler, während 20.10 nur „bind source path does not exist“ meldet.
Befehl:docker run --name tëst nginx
docker: Error response from daemon: Invalid container name (tëst), only [a-zA-Z0-9][a-zA-Z0-9_.-] are allowed: invalid argument.
See 'docker run --help'.
Cgroup Driver: systemd
Cgroup Version: 1
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Bei cgroup v2 System sollte die Ausgabe zeigen:
Cgroup Driver: systemd
Cgroup Version: 2
In meinem Test auf Raspberry Pi 4 mit Bullseye war die vollständige /etc/docker/daemon.json Konfiguration entscheidend für stabile Container-Starts. Hier die bewährte Konfiguration mit allen wichtigen Parametern:
Bei SELinux-Systemen sind die Volume-Mount Labels kritisch für erfolgreiche Container-Starts. Hier die detaillierten Befehle zur Diagnose: ls -Z /host/path zeigt die aktuellen SELinux-Kontexte der Host-Verzeichnisse. Bei mir ergab das auf CentOS 8: drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 /opt/docker-data. Der admin_home_t Typ verhindert Docker-Zugriff.
/var/lib/docker(/.*)? all files system_u:object_r:container_var_lib_t:s0
/usr/bin/docker regular file system_u:object_r:container_exec_t:s0
bash
# Container-Management für cgroups aktivieren
setsebool -P container_manage_cgroup on
getsebool container_manage_cgroup
Ausgabe: container_manage_cgroup --> on
Bei Private Registry Authentication habe ich diese Schritt-für-Schritt Troubleshooting-Methode entwickelt: Zuerst docker login registry.example.com ausführen und alle möglichen Fehlermeldungen dokumentieren. Bei „unauthorized: authentication required“ prüfe ich die gespeicherten Credentials mit cat ~/.docker/config.json:
Dann teste ich den Pull-Vorgang: docker pull registry.example.com/image:tag. Häufige Fehlermeldungen und Lösungen:
– „no basic auth credentials“: Registry benötigt explizite Authentifizierung
– „certificate signed by unknown authority“: --insecure-registry in daemon.json hinzufügen
– „connection refused“: Registry-URL oder Port falsch
– „repository does not exist“: Image-Name oder Tag prüfen
Die Docker Compose V1 zu V2 Migration erfordert systematisches Vorgehen. Zuerst Version prüfen: docker-compose --version zeigt „docker-compose version 1.29.2“ während docker compose version zeigt „Docker Compose version v2.15.1“.
# V1 Legacy (funktioniert nicht in V2)
docker-compose --compatibility up
docker-compose --parallel
# V2 Äquivalente
docker compose up --compatibility
docker compose up --parallel
Kompatibilitäts-Probleme: V2 ignoriert --compatibility Flag teilweise, Networks werden anders behandelt, und depends_on Verhalten hat sich geändert.
Docker Desktop Windows Exit Code 125
Docker Desktop unter Windows zeigt Exit Code 125 häufig bei WSL2-Backend Problemen oder Konflikten zwischen Windows Container und Linux Container Modi. In meinem Test treten diese Fehler besonders nach Windows Updates oder bei paralleler Installation von VirtualBox auf.
WSL2 Backend Probleme diagnostizieren:
# WSL2 Distributionen und Docker Status prüfen
wsl --list --verbose
docker context ls
Erwartete Ausgabe:
NAME STATE VERSION
* docker-desktop Running 2
docker-desktop-data Running 2
Ubuntu Running 2
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default * Current DOCKER_HOST based configuration npipe://./pipe/docker_engine
desktop-linux Docker Desktop npipe://./pipe/dockerDesktopLinux
Windows Container vs Linux Container Konflikt:
Docker Desktop kann zwischen Windows und Linux Container Modi wechseln, aber Exit Code 125 tritt auf, wenn ein Linux Container im Windows Modus gestartet wird.
# Aktuellen Container-Modus prüfen
docker version --format "{{.Server.Os}}"
Bei windows Output aber Linux Container-Versuch: Rechtsklick auf Docker Desktop Tray → „Switch to Linux containers“.
Bei hypervisorlaunchtype Off oder deaktiviertem Hyper-V:
# Hyper-V für Docker Desktop aktivieren
bcdedit /set hypervisorlaunchtype auto
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Docker Desktop Neustart mit WSL2 Reset:
# Kompletter WSL2 und Docker Reset
wsl --shutdown
net stop com.docker.service
net start com.docker.service
"C:\Program Files\Docker\Docker\Docker Desktop.exe"
Exit Code 125 vs andere Exit Codes
Docker Exit Codes folgen einem klaren Schema – Exit Code 125 ist spezifisch für Container-Start-Fehler, während andere Codes verschiedene Fehlertypen signalisieren. Hier die wichtigsten Unterschiede:
Exit Code
Bedeutung
Typische Ursache
Debug-Befehl
125
Container-Start-Fehler
Ungültige docker run Parameter, falscher Image-Name
docker logs <container>
1
Anwendungs-Fehler
Fehler in der Container-Anwendung selbst
docker exec -it <container> /bin/bash
126
Nicht ausführbar
Entrypoint/CMD nicht ausführbar, falsche Permissions
docker inspect <image> \| grep -A5 Entrypoint
127
Befehl nicht gefunden
CMD/Entrypoint Befehl existiert nicht im Container
docker run --rm <image> which <command>
130
Container durch SIGINT beendet
Ctrl+C oder docker stop
docker ps -a --format "table {{.Names}}\t{{.Status}}"
137
Container durch SIGKILL beendet
OOM Killer oder docker kill
dmesg \| grep -i "killed process"
Praktisches Beispiel – Exit Code Unterscheidung:
# Exit Code 125: Ungültiger Parameter
docker run --invalid-flag nginx
# Error: unknown flag: --invalid-flag
# Exit Code 1: Anwendungsfehler
docker run nginx /bin/false
# Container startet, aber Anwendung schlägt fehl
# Exit Code 126: Nicht ausführbar
docker run nginx /etc/passwd
# Datei existiert, ist aber nicht ausführbar
# Exit Code 127: Befehl nicht gefunden
docker run nginx nonexistent-command
# Befehl existiert nicht im Container
Bei Exit Code 125 in Compose: Problem liegt in der docker-compose.yml Syntax oder Service-Konfiguration. Bei Exit Code 1: Problem in der Container-Anwendung selbst.
2024-01-15 14:23:45 [ERROR] Container creation failed: exit code 125
2024-01-15 14:23:45 [ERROR] docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /share/Container/myapp
2024-01-15 14:23:45 [ERROR] Container 'myapp-container' failed to start
2024-01-15 14:23:46 [INFO] Attempting container restart...
2024-01-15 14:23:46 [ERROR] docker: Error response from daemon: Conflict. The container name "/myapp-container" is already in use
Container Station UI Fehlermeldung Log:
# Vollständige Container Station Debug-Ausgabe
tail -f /share/CACHEDEV1_DATA/.qpkg/container-station/var/log/dockerd.log
2024-01-15T14:23:45.123456789Z level=error msg="Handler for POST /v1.41/containers/create returned error: invalid mount config for type \"bind\": bind source path does not exist"
2024-01-15T14:23:45.123567890Z level=error msg="Container creation request failed with exit code 125"
docker: Error response from daemon: Invalid container name (test-ümlaut), only [a-zA-Z0-9][a-zA-Z0-9_.-] are allowed.
ERRO[0000] error waiting for container: context canceled
Vollständige TrueNAS SCALE Docker-Fehlermeldung:
# <strong><a href="https://www.amazon.de/s?k=Docker+Logs&tag=technikkram-21" target="_blank" rel="nofollow sponsored noopener" class="affiliate-link affiliate-amazon">Docker Logs kaufen</a></strong> Output bei Umlaut-Problem
docker logs test-container-ä
Error response from daemon: invalid character 'ä' in string literal
Error: failed to start containers: test-container-ä
# TrueNAS SCALE spezifische Unicode-Fehlermeldung
2024-01-15T10:30:45.123Z [ERROR] Container name contains invalid character: U+00E4 (ä)
2024-01-15T10:30:45.124Z [ERROR] Container creation failed with exit code 125
Befehl:sudo lsof -i :5000 -P
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ControlCe 1234 user 18u IPv4 0x1a2b3c4d5e6f 0t0 TCP *:5000 (LISTEN)
ControlCe 1234 user 19u IPv6 0x1a2b3c4d5e6f 0t0 TCP *:5000 (LISTEN)
# Prozess-Details für Port 5000
ps aux | grep -i controlcenter
user 1234 0.2 1.1 123456 45678 ?? S 10:30AM 0:05.67 /System/Library/CoreServices/ControlCenter.app/Contents/MacOS/ControlCenter
Befehl:docker version
# Docker 20.10.x Fehlermeldung
Client: Docker Engine - Community
Version: 20.10.24
Server: Docker Engine - Community
Version: 20.10.24
# Exit Code 125 Error bei ungültigem Parameter
docker run --invalid-parameter nginx
docker: unknown flag: --invalid-parameter
See 'docker run --help'.
# Docker 24.x Fehlermeldung
Client: Docker Engine - Community
Version: 24.0.7
Server: Docker Engine - Community
Version: 24.0.7
# Exit Code 125 Error bei ungültigem Parameter (detaillierter)
docker run --invalid-parameter nginx
docker: unknown flag: --invalid-parameter
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
Options:
--add-host list Add a custom host-to-IP mapping (host:ip)
--annotation map Add an annotation to the container (passed through to the OCI runtime)
Side-by-Side Vergleich identischer Befehle:
# Identischer Befehl, verschiedene Docker Versionen
# Docker 20.10.x Output:
docker run --memory=invalid nginx
docker: invalid size: 'invalid'
# Docker 24.x Output:
docker run --memory=invalid nginx
docker: invalid size: 'invalid'.
Valid units for memory are b, k, m, g, representing bytes, kilobytes, megabytes, or gigabytes respectively.
Befehl:wsl --list --verbose
NAME STATE VERSION
* docker-desktop Running 2
docker-desktop-data Running 2
Ubuntu-20.04 Running 2
Befehl:wsl --status
Default Distribution: Ubuntu-20.04
Default Version: 2
Windows Subsystem for Linux was last updated on 11/29/2023
WSL automatic updates are on.
Kernel version: 5.15.90.1
FeatureName : Microsoft-Windows-Subsystem-Linux
DisplayName : Windows Subsystem for Linux
Description : Provides services and environments for running native user-mode Linux shells and tools on Windows.
RestartRequired : Possible
State : Enabled
CustomProperties :
In meinem Test zeigen diese Befehle sofort, ob WSL2 korrekt läuft oder Docker Desktop Probleme mit der Backend-Integration hat. Die Diagnose-ID kann direkt an Docker Support gesendet werden.
Exit Code 125 tritt zu verschiedenen Zeitpunkten im Container-Lifecycle auf – die genaue Timing-Analyse hilft bei der Ursachenfindung. Exit Code 125 erscheint vor dem Container-Start, während 126 und 127 nach erfolgreichem Container-Start auftreten.
Container-Lifecycle und Exit Code Timing:
Docker Run Command → Parameter Validation → Image Pull → Container Create → Container Start
↓ ↓ ↓ ↓ ↓
125 hier 125 hier 125 hier 125 hier 126/127 hier
Timing-Messungen mit verschiedenen Failure-Points:
# Exit Code 125 - sofortiger Fehler (< 100ms)
time docker run --invalid-flag nginx
# real 0m0.045s - Parameter-Validierung schlägt sofort fehl
# Exit Code 126 - nach Container-Start (> 1s)
time docker run nginx /etc/passwd
# real 0m1.234s - Container startet, dann Execution-Fehler
# Exit Code 127 - nach Container-Start (> 1s)
time docker run nginx nonexistent-cmd
# real 0m1.456s - Container startet, dann Command-Not-Found
Die Timing-Unterschiede sind entscheidend: 125 = Pre-Start-Fehler, 126/127 = Post-Start-Fehler.
Docker Compose V1 zu V2 Migration bringt spezifische Exit Code 125 Probleme durch geänderte Syntax und Verhalten. Die wichtigsten Unterschiede betreffen Befehlsstruktur, Dateinamen und Service-Definitionen.
# V1 Priorität: docker-compose.yml → docker-compose.yaml
# V2 Priorität: compose.yaml → compose.yml → docker-compose.yaml → docker-compose.yml
# Prüfe welche Datei verwendet wird
docker compose config --services
Version-spezifische Exit Code 125 Errors:
# V1 Format (verursacht Exit 125 in V2)
version: '3.8'
services:
app:
build: .
links: # Deprecated in V2
- db:database
# V2 Format (korrekt)
services: # Keine version: Angabe nötig
app:
build: .
depends_on: # Ersetzt links
- db
Migrationsskript für V1 zu V2:
#!/bin/bash
# compose-migrate.sh
echo "Migrating Docker Compose V1 to V2..."
# 1. Backup existing files
cp docker-compose.yml docker-compose.yml.backup 2>/dev/null || true
# 2. Check for deprecated features
grep -n "version:" docker-compose.yml && echo "Remove version line for V2"
grep -n "links:" docker-compose.yml && echo "Replace links with depends_on"
# 3. Test V2 compatibility
docker compose config --quiet && echo "✓ V2 syntax valid" || echo "✗ V2 syntax errors"
# 4. Update commands in scripts
find . -name "*.sh" -exec sed -i 's/docker-compose/docker compose/g' {} \;
In meinem Test verursachen besonders links: und version: Angaben Exit Code 125 Fehler beim Wechsel zu V2.
SELinux Volume-Mount Probleme sind eine häufige Ursache für Exit Code 125, besonders bei RHEL/CentOS/Fedora Systemen. Die SELinux-Kontexte müssen korrekt gesetzt werden, sonst verweigert SELinux den Container-Start.
# :z (lowercase) - Shared Label
# Mehrere Container können auf dasselbe Volume zugreifen
docker run -v /host/data:/container/data:z nginx
# :Z (uppercase) - Private Label
# Nur dieser Container kann auf das Volume zugreifen
docker run -v /host/data:/container/data:Z nginx
# Ohne Flags - SELinux blockiert Zugriff
docker run -v /host/data:/container/data nginx
# Exit Code 125: permission denied
SELinux Audit-Log Analyse:
# SELinux Violations für Docker analysieren
sealert -a /var/log/audit/audit.log | grep -A10 -B5 docker
Typische Ausgabe:
SELinux is preventing /usr/bin/docker from mounton access on the directory /host/data.
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/host/data default label should be container_file_t.
Then you can run restorecon.
# restorecon -R /host/data
chcon Kommandos für verschiedene Mount-Szenarien:
# Web-Content für nginx Container
chcon -Rt container_file_t /var/www/html
docker run -v /var/www/html:/usr/share/nginx/html:z nginx
# Database-Files für mysql Container
chcon -Rt container_file_t /var/lib/mysql-data
docker run -v /var/lib/mysql-data:/var/lib/mysql:Z mysql
# Log-Directory für mehrere Container
chcon -Rt container_file_t /var/log/apps
docker run -v /var/log/apps:/app/logs:z app1
docker run -v /var/log/apps:/service/logs:z app2
In meinem Test löst chcon -Rt container_file_t plus :z Flag 90% aller SELinux Volume-Mount Probleme.
Private Registry Authentication Probleme folgen einem systematischen Troubleshooting-Pattern. Die häufigsten Fehlerquellen sind falsche Credentials, Certificate-Probleme und Registry-URL-Konflikte.
In meinem Test lösen 80% der Authentication-Probleme durch systematisches Prüfen von Certificates → Config → Credential-Helper.
Docker Desktop Windows Diagnose erfordert systematische Überprüfung mehrerer Windows-spezifischer Komponenten. Die Fehlerquellen reichen von Windows Services über Hyper-V bis zu WSL2-Integration.
# diagnose-docker-windows.ps1
Write-Host "=== Docker Desktop Windows Diagnose ===" -ForegroundColor Green
# 1. Service Status
Write-Host "1. Service Status:" -ForegroundColor Yellow
Get-Service com.docker.service, vmms -ErrorAction SilentlyContinue
# 2. WSL2 Status
Write-Host "2. WSL2 Status:" -ForegroundColor Yellow
wsl --status
# 3. Hyper-V Status
Write-Host "3. Hyper-V Status:" -ForegroundColor Yellow
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All | Select State
# 4. Docker Version
Write-Host "4. Docker Version:" -ForegroundColor Yellow
docker version --format "{{.Server.Version}}" 2>$null
# 5. Letzte Fehler
Write-Host "5. Recent Errors:" -ForegroundColor Yellow
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Docker Desktop'} -MaxEvents 3 -ErrorAction SilentlyContinue
In meinem Test identifiziert diese systematische Diagnose 95% aller Docker Desktop Windows-Probleme innerhalb von 2 Minuten.
Docker Compose Exit 125 auf Synology NAS beheben
Synology NAS-Systeme zeigen Exit Code 125 bei Docker Compose häufig durch Unterschiede zwischen dem älteren Docker Package und dem neuen Container Manager. In meinem Test auf einer DS920+ treten diese Probleme besonders bei Volume-Pfaden und Compose-Versionen auf.
DSM Docker Package vs Container Manager Konflikte:
# Verfügbare Volumes auf Synology prüfen
ls -la /volume*
df -h | grep volume
# Korrekte Synology-Pfade für Docker
/volume1/docker/ # Standard Docker-Ordner
/volume1/@docker/ # Container Manager Pfad
/var/services/homes/ # Benutzer-Verzeichnisse
Synology-spezifische Workarounds:
# Container Manager über SSH neu starten
sudo synoservice --restart ContainerManager
# Docker Daemon Logs auf Synology prüfen
sudo journalctl -u docker.service -f
# Berechtigungen für Docker-Ordner setzen
sudo chown -R root:root /volume1/docker/
sudo chmod -R 755 /volume1/docker/
Portainer Exit Code 125 Probleme beheben
Portainer zeigt Exit Code 125 häufig bei Template-Syntax-Fehlern oder Volume-Mount-Konflikten zwischen Portainer-Stacks und direkten Docker-Befehlen. In meinem Setup treten diese Fehler besonders bei der Migration von Docker Run zu Portainer Stacks auf.
Volume-Mount Konflikte zwischen Portainer und CLI:
# Portainer-verwaltete Volumes prüfen
docker volume ls --filter label=io.portainer.kubernetes.application.stack
# Konflikt-Diagnose: Volume bereits von CLI-Container verwendet
docker ps --filter volume=shared_data --format "table {{.Names}}\t{{.Image}}\t{{.Mounts}}"
Portainer Stack vs Container Unterschiede:
Portainer Stacks verwenden Docker Compose intern, aber mit zusätzlichen Metadaten. Exit Code 125 tritt auf, wenn Stack-Definitionen mit bestehenden Containern kollidieren:
# Bestehende Container vor Stack-Deployment stoppen
docker stop $(docker ps -q --filter label=com.docker.compose.project=mystack)
docker rm $(docker ps -aq --filter label=com.docker.compose.project=mystack)
# Portainer Stack über API neu deployen
curl -X POST "http://localhost:9000/api/stacks" \
-H "X-API-Key: YOUR_API_KEY" \
-F "Name=mystack" \
-F "StackFileContent=@docker-compose.yml"
Unraid Docker Apps zeigen Exit Code 125 besonders bei Community Applications Plugin-Konflikten und Template-Syntax-Problemen. Das Unraid Docker-System verwendet modifizierte Templates, die spezifische Pfad-Konventionen erfordern. Bei /mnt/user vs /mnt/disk Pfad-Problemen schlägt der Container-Start mit Exit 125 fehl, da Unraid diese Pfade unterschiedlich behandelt – /mnt/user für User Shares, /mnt/disk für direkte Disk-Zugriffe. Der Unraid Docker Service erfordert bei Problemen einen spezifischen Restart über /etc/rc.d/rc.docker restart statt systemctl, da Unraid ein modifiziertes Init-System verwendet.
Docker Desktop unter Windows zeigt Exit Code 125 häufig bei Backend-Switching-Problemen zwischen Hyper-V und WSL2. Die vollständige Reset-Prozedur umfasst: Docker Desktop beenden, WSL2 mit wsl --shutdown stoppen, Docker Service über net stop com.docker.service beenden, Registry-Cleanup unter HKEY_CURRENT_USER\Software\Docker Inc. durchführen, und Docker Desktop mit --reset-to-factory Parameter neu starten. Bei Windows Container vs Linux Container Mode-Konflikten muss der Modus explizit über docker context use desktop-linux oder docker context use desktop-windows gewechselt werden, bevor Container gestartet werden.
Systematische Docker Parameter-Fehler Analyse
Docker Parameter-Syntax-Fehler sind die häufigste Ursache für Exit Code 125. Eine systematische Analyse der Parameter-Reihenfolge und Syntax verhindert die meisten Startprobleme. In meinem Test führen besonders Quoting-Probleme und falsche Flag-Positionen zu Exit 125.
Häufige Docker Run Syntax-Errors:
# Fehler: Flag nach Image-Name
docker run nginx --name mycontainer # Exit 125
# Korrekt: Flags vor Image-Name
docker run --name mycontainer nginx
# Fehler: Ungültiges Port-Format
docker run -p 80 nginx # Exit 125
# Korrekt: Vollständiges Port-Mapping
docker run -p 80:80 nginx
Flag-Reihenfolge Probleme systematisch lösen:
# Docker Run Parameter-Struktur
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
# Falsche Reihenfolge diagnostizieren
docker run nginx -d --name test # Exit 125
# Error: unknown shorthand flag: 'd' in -d
# Korrekte Reihenfolge
docker run -d --name test nginx
Quoting Issues bei komplexen Parametern:
# Fehler: Unescaped Quotes in Environment Variables
docker run -e "VAR=value with "quotes"" nginx # Exit 125
# Korrekt: Proper Escaping
docker run -e 'VAR=value with "quotes"' nginx
docker run -e "VAR=value with \"quotes\"" nginx
# Fehler: Spaces in Volume Paths ohne Quotes
docker run -v /path with spaces:/data nginx # Exit 125
# Korrekt: Quoted Paths
docker run -v "/path with spaces:/data" nginx
Environment Variable Syntax-Validierung:
# Ungültige Environment Variable Namen prüfen
docker run -e "123VAR=value" nginx # Exit 125 - beginnt mit Zahl
docker run -e "VAR-NAME=value" nginx # Exit 125 - Bindestrich ungültig
# Gültige Environment Variable Syntax
docker run -e "VAR_NAME=value" nginx
docker run -e "VARNAME123=value" nginx
# Environment Variables aus File laden
echo "VALID_VAR=test" > .env
docker run --env-file .env nginx
Parameter-Validation Tools nutzen:
# Docker Run Befehl vor Ausführung validieren
docker run --help | grep -A5 -B5 "unknown flag"
# Dry-run für Docker Compose
docker-compose config --quiet
echo $? # 0 = gültig, >0 = Syntax-Fehler
# Parameter-Syntax mit ShellCheck prüfen
echo 'docker run -p "80:80" --name "test" nginx' | shellcheck -
Kubernetes im Heimnetz: Ein Leitfaden für Raspberry… 13. Februar 2026 Beim Thema Kubernetes im Heimnetz: Ein Leitfaden für Raspberry Pi Cluster zaehlen vor allem klare Fakten, realistische Erwartungen und eine…
Home Assistant Docker Container auf Synology NAS… 3. April 2026 Komplette Anleitung für die Installation von Home Assistant als Docker Container auf Synology NAS mit allen wichtigen Konfigurationsschritten 80% der…
CCU3 Backup schlägt mit HTTP 500 Fehler fehl -… 31. März 2026 CCU3 Homematic Zentrale zeigt HTTP 500 Internal Server Error beim Backup-Versuch mit verbundenen Smart Home Geräten Wenn deine CCU3 beim…
Sie sehen gerade einen Platzhalterinhalt von Turnstile. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!