Die 10 häufigsten Docker-Fehler – Ursachen und Lösungen

Von / / Schreibe einen Kommentar

Docker-Fehler treten fast immer an denselben Stellen auf: falsche Image-Namen, belegte Ports, fehlende Berechtigungen oder Netzwerk- und Volume-Probleme. Dieser Guide zeigt dir die 10 häufigsten Docker-Fehler, die typische Fehlermeldung dazu und – wichtiger – die konkrete Lösung samt Befehl. Am Ende findest du eine Diagnose-Checkliste, mit der du praktisch jeden Container-Fehler eingrenzen kannst. Neu bei Containern? Starte mit Was ist Docker?.

Die 10 häufigsten Docker-Fehler auf einen Blick

  1. Image nicht gefunden (pull access denied)
  2. Port bereits belegt (port is already allocated)
  3. Container beendet sich sofort (Exited (1))
  4. Permission denied (EACCES)
  5. Keine Verbindung zum Docker-Daemon
  6. Netzwerkprobleme (Could not resolve host)
  7. Volume-Mount-Fehler (bind source path does not exist)
  8. Out of Memory (OOMKilled)
  9. Fehlkonfiguration des Docker-Daemons
  10. Namens-Konflikt (name is already in use)

1. Image nicht gefunden – „pull access denied“

Ursache: Der Image-Name oder das Tag ist falsch geschrieben oder existiert nicht in der Registry. Bei privaten Images fehlt außerdem oft die Anmeldung.

Error response from daemon: pull access denied for <image>,
repository does not exist or may require 'docker login'

Lösung: Prüfe Name und Tag (z. B. nginx:latest). Bei privaten Registries zuerst anmelden:

docker login registry.example.com
docker pull nginx:1.27

Tipp: Vermeide :latest in der Produktion – pinne eine feste Version, damit Deployments reproduzierbar bleiben.

2. Port bereits belegt – „port is already allocated“

Ursache: Der Host-Port ist bereits durch einen anderen Prozess oder Container belegt.

Error response from daemon: driver failed programming external
connectivity on endpoint <name>: Bind for 0.0.0.0:<port> failed:
port is already allocated

Lösung: Finde den belegenden Prozess und wähle einen freien Port oder stoppe den Konflikt-Container:

sudo lsof -i :8080        # oder: sudo ss -ltnp | grep 8080
docker ps                 # belegt ihn ein Container?
# neuen Host-Port mappen, z. B. 8081 statt 8080:
docker run -p 8081:80 nginx

3. Container beendet sich sofort – „Exited (1)“

Ursache: Der Hauptprozess des Containers bricht sofort ab – meist wegen fehlender Umgebungsvariable, falschem CMD/ENTRYPOINT oder einer nicht erfüllten Abhängigkeit.

# Ursache im Log finden:
docker logs <container>
# Container interaktiv zum Debuggen starten:
docker run -it --entrypoint sh <image>

Lösung: Log auswerten, fehlende ENV-Variablen ergänzen und CMD/ENTRYPOINT im Dockerfile prüfen. Exited (0) bedeutet übrigens: der Prozess lief korrekt durch und hat sich beendet – bei kurzlebigen Tasks ist das normal.

Siehe auch  Portainer installieren: Docker per Weboberfläche verwalten

4. Permission denied

Ursache: Der Container oder der Host hat nicht die nötigen Rechte – häufig bei gemounteten Volumes mit abweichender User-/Group-ID.

permission denied
EACCES: permission denied, mkdir '/data'

Lösung: Besitzer/Rechte des Host-Verzeichnisses setzen oder die passende UID/GID an den Container übergeben:

sudo chown -R 1000:1000 /pfad/zum/volume
docker run --user 1000:1000 -v /pfad/zum/volume:/data <image>

Tipp: --privileged ist selten die richtige Lösung – es hebelt die Isolierung aus. Nutze gezielt --user oder --cap-add.

5. Keine Verbindung zum Docker-Daemon

Ursache: Der Docker-Daemon läuft nicht, oder dein Benutzer darf nicht auf den Docker-Socket zugreifen.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?
sudo systemctl status docker
sudo systemctl start docker
# ohne sudo arbeiten? Benutzer der docker-Gruppe hinzufügen:
sudo usermod -aG docker $USER   # danach neu anmelden

6. Netzwerkprobleme – „Could not resolve host“

Ursache: Der Container erreicht kein externes Netz oder findet ein Compose-Netzwerk nicht.

docker network ls
docker network inspect <netzwerk>
# DNS im Container testen:
docker run --rm busybox nslookup google.com

Lösung: In docker-compose.yml das Netzwerk sauber definieren, DNS prüfen (--dns 1.1.1.1) und bei Firewalls sicherstellen, dass docker0 bzw. die Bridge nicht blockiert wird.

7. Volume-Mount-Fehler – „bind source path does not exist“

Ursache: Der als Bind-Mount angegebene Host-Pfad existiert nicht oder ist relativ statt absolut angegeben.

Error response from daemon: invalid mount config for type "bind":
bind source path does not exist

Lösung: Host-Pfad anlegen und absolut angeben (mit / beginnend). Ein verwandter, häufiger Compose-Fehler ist service refers to undefined volume – hier fehlt der Eintrag im Top-Level-volumes:-Block. Mehr dazu: Docker-Compose: undefined volume – Lösung.

Siehe auch  Apache2 Logrotate ohne Restart: Der Guide zu copytruncate

8. Out of Memory – „OOMKilled“

Ursache: Der Container überschreitet sein Speicherlimit und wird vom Kernel beendet.

docker inspect <container> --format '{{.State.OOMKilled}}'
free -m
# Speicher gezielt limitieren:
docker run --memory=1g --memory-swap=1g <image>

Lösung: Limit erhöhen oder die Anwendung optimieren. Setze bewusst --memory, damit ein Container nicht den ganzen Host mitreißt.

9. Fehlkonfiguration des Docker-Daemons

Ursache: Ein Syntaxfehler in /etc/docker/daemon.json verhindert den Start des Daemons.

sudo dockerd --validate            # Config prüfen (neuere Versionen)
sudo journalctl -u docker -e       # Startfehler ansehen
sudo systemctl restart docker

Tipp: Validiere die JSON-Datei vor dem Neustart – ein fehlendes Komma legt den kompletten Daemon lahm.

10. Namens-Konflikt – „name is already in use“

Conflict. The container name "/<name>" is already in use by
container "<id>"

Lösung: Alten Container entfernen oder neu benennen:

docker rm <name>          # oder: docker rm -f <name>
docker run --name mein-app-v2 <image>

Docker-Fehler systematisch diagnostizieren

Die meisten Fehler lassen sich mit vier Befehlen eingrenzen. Diese Reihenfolge hat sich bewährt:

docker logs -f <container>     # Was sagt die Anwendung?
docker inspect <container>      # Config, Mounts, Netzwerk, Exit-Code
docker events                   # Live-Ereignisse des Daemons
docker system df                # Platz-/Ressourcenübersicht

So vermeidest du Docker-Fehler von vornherein

  • Feste Image-Tags statt :latest verwenden.
  • Volumes und Netzwerke in docker-compose.yml explizit definieren.
  • Healthchecks setzen, damit abhängige Services erst starten, wenn die Datenbank bereit ist.
  • Ressourcenlimits (--memory, --cpus) vergeben.
  • Regelmäßig aufräumen: docker system prune entfernt ungenutzte Layer und Netzwerke.
Siehe auch  Docker Logs anzeigen und verwalten – Anleitung

Verwandte Anleitungen

Häufige Fragen zu Docker-Fehlern

Wie sehe ich, warum ein Container abgestürzt ist?

Mit docker logs <container> siehst du die Ausgabe der Anwendung, mit docker inspect <container> den Exit-Code und die Konfiguration. Beides zusammen zeigt fast immer die Ursache.

Was bedeutet „Exited (0)“ gegenüber „Exited (1)“?

Exited (0) heißt: erfolgreich beendet. Exited (1) (oder ein anderer Wert > 0) signalisiert einen Fehler – dann lohnt der Blick ins Log.

Wie gebe ich einen belegten Port wieder frei?

Ermittle mit sudo lsof -i :<port> den Prozess. Ist es ein Container, stoppe ihn mit docker stop <name>; sonst beende den Host-Prozess oder wähle einen anderen Host-Port.

Fazit

Die meisten Docker-Fehler sind Konfigurations- statt Software-Probleme – und mit docker logs und docker inspect schnell gefunden. Wer feste Tags, saubere Volumes und Ressourcenlimits nutzt, vermeidet die häufigsten Stolperfallen von vornherein.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen