Docker prune: Images, Container und Volumes löschen

Docker löscht von sich aus nichts. Alle heruntergeladenen Images, alle angehaltenen Container, alle Volumes, der Build-Cache sowie die Container-Protokolle verbleiben auf der Festplatte im Verzeichnis /var/lib/docker. Auf einem regelmäßig aktualisierten Server können sich im Laufe von Monaten mehrere Dutzend Gigabyte ansammeln, und die Festplatte eines kleineren VPS ist plötzlich voll.

Dieser Artikel zeigt Ihnen, wie Sie einsehen können, was Speicherplatz belegt, wie Sie Einträge einzeln oder mithilfe der Befehle prune in großer Zahl löschen können, wie Sie eine überfüllte Protokolldatei leeren können und was Sie nicht löschen sollten. Wir haben die Schritte im November 2026 auf Systemen mit Ubuntu 26.04, Debian 13 und AlmaLinux 10.2 sowie mit Docker Version 29.9.3 getestet. Informationen zur Installation von Docker finden Sie im Artikel Installation von Docker unter Ubuntu, Debian und AlmaLinux.

Die Beispiele sind ohne sudo angegeben; sollte Ihr Benutzer nicht zur Gruppe docker gehören, fügen Sie bitte das Wort sudo vor den Befehlen ein.

Wie viel Speicherplatz benötigt Docker?

docker system df

TOTAL / ACTIVE: wie viele vorhanden sind und wie viele davon von Containern genutzt werden.
SIZE: die Gesamtgröße.
RECLAIMABLE: So viel Speicherplatz kann durch das Löschen nicht genutzter Elemente freigegeben werden.

Der Befehl docker system df -v gibt die Größenangaben auch elementweise aus, beispielsweise wie groß ein bestimmtes Volume ist und von wie vielen Containern es genutzt wird (LINKS). Die Gesamtgröße des Docker-Datenverzeichnisses wird durch den Befehl sudo du -sh /var/lib/docker angezeigt (siehe: Der Befehl du im Detail).

„Dangling“ und „unbenutzt“: Was ist der Unterschied?

	Was bedeutet das?	Womit wird es gelöscht?
Dangling Image	Image ohne Tag (Name), beispielsweise eine alte Version, die nach einem Neuerstellen oder erneuten Herunterladen erhalten geblieben ist (`<none>`)	`docker image prune`
Nicht verwendetes Image	Es gibt keinen einzigen Container, der darauf verweist, auch nicht die stillgelegten Container.	`docker image prune -a`
Anonymes Volume	Ein Volume mit langer, zufälliger Kennung, das von Docker aufgrund der Anweisung `VOLUME` in einem Image oder des Schalters `-v /mappa` erstellt wurde	`docker volume prune`
Benanntes Volume	Mit eigenem Namen erstelltes Volume (`-v adatok:/data`, Compose-`volumes:`)	Nur `docker volume prune -a` oder `docker volume rm`

Docker 29 verwendet bei neuen Installationen den „containerd“-Image-Speicher (in der Ausgabe von docker info: Storage Driver: overlayfs). Im Test entstanden dadurch keinerlei „dangling images“: Nach dem Neuerstellen eines Images verschwand die alte Version sofort aus der Liste und wurde durch den Build-Cache ersetzt. Laut der Docker-Dokumentation behalten Installationen, die von einer älteren Version aktualisiert wurden, den bisherigen Speicher (Storage Driver: overlay2) bei; dort erscheinen die <none>-Images weiterhin. Der einfache Befehl docker image prune gibt daher oft keinen Speicherplatz frei; ungenutzte Images werden mit dem Schalter -a gelöscht.

Einzeln löschen

Container:

docker ps -a                       # alle Container, auch gestoppte
docker rm nev                      # gestoppten Container löschen
docker rm -f nev                   # laufenden Container stoppen und löschen
docker rm -v nev                   # samt seinen anonymen Volumes
docker rm $(docker ps -aq -f status=exited)   # alle gestoppten Container

Ein laufender Container kann nicht ohne das -f-Argument gelöscht werden: cannot remove container "cache": container is running: stop the container before removing or force remove.

Images:

docker images
docker rmi nginx:alpine            # ugyanaz: docker image rm nginx:alpine

Ein Image kann erst gelöscht werden, wenn kein Container (auch kein stillgelegter) mehr darauf zugreift: conflict: unable to delete redis:alpine (must be forced) - container bfa361262ba5 is using its referenced image. Löschen Sie zunächst den Container; erzwingen Sie den Vorgang nicht mit dem Schalter -f.

Volumes und Netzwerke:

docker volume ls
docker volume rm regi-adatok
docker network ls
docker network rm tesztnet

Docker lässt das Löschen eines an den Container angehängten Volumes nicht zu (volume is in use), selbst wenn der Container lediglich angehalten ist. Durch das Löschen des Volumes gehen die darin enthaltenen Daten (beispielsweise eine Datenbank) unwiderruflich verloren.

Bei einem Compose-Projekt löscht der Befehl docker compose down die Container und das Netzwerk des Projekts, behält jedoch die Volumes bei; der Befehl docker compose down -v löscht auch die benannten Volumes. Weitere Informationen hierzu finden Sie im Artikel Verwendung von Docker Compose.

Massenlöschung mit den „prune“-Befehlen

Befehl	Was wird gelöscht?
`docker container prune`	alle nicht mehr aktiven Container
`docker image prune`	die „dangling“ Images
`docker image prune -a`	alle Images, die von keinem Container verwendet werden
`docker volume prune`	die containerlosen anonymen Volumes
`docker volume prune -a`	alle containerlosen Volumes, einschließlich der benannten
`docker network prune`	die eigenen, containerlosen Netzwerke
`docker builder prune`	den „dangling“ Build-Cache (der mit keinem Image verknüpft ist)
`docker builder prune -a`	den gesamten Build-Cache
`docker system prune`	stillgelegte Container, nicht genutzte Netzwerke, „dangling“-Images, ungenutzter Build-Cache
`docker system prune -a`	Das Gleiche, jedoch mit allen nicht verwendeten Images und dem gesamten Build-Cache
`docker system prune --volumes`	ebenso, einschließlich der containerlosen anonymen Volumes

Jedes Programm fragt nach, ob Sie den Vorgang wirklich fortsetzen möchten ([y/N]), und zeigt an, was gelöscht wird. Der Schalter -f (--force) überspringt diese Abfrage; verwenden Sie diesen Schalter bitte nur in Skripten mit kontrollierten Befehlen.

Auf dem Bild ist deutlich zu erkennen, dass der einfache Befehl docker system prune oft kaum Speicherplatz freigibt (hier 53 kB): Die stillgelegten Container sind klein, der Speicherplatz wird von ungenutzten Images und Volumes belegt. Im Test auf demselben Rechner gab der Befehl docker image prune -a 492 MB frei.

Vorsicht: system prune -a und –volumes

Der Befehl docker system prune löscht zunächst die angehaltenen Container. Wenn Sie einen Container nur vorübergehend angehalten haben (docker stop, docker compose stop), wird dieser ebenfalls gelöscht, ebenso wie seine Konfiguration (Ports, Umgebungsvariablen). Bei einem Compose-Projekt ist dies kein Problem, da docker compose up -d den Container neu erstellt; bei einem manuell mit docker run gestarteten Container müssen Sie den Befehl jedoch erneut eingeben.
-a löscht alle Images, für die kein Container vorhanden ist, sodass Docker diese beim nächsten Start erneut herunterlädt. Falls Sie eine alte Version zur Wiederherstellung aufbewahrt haben, geht diese ebenfalls verloren.
Der Schalter --volumes löscht auch unbenannte Volumes im selben Durchlauf zusammen mit den beendeten Containern. Im Test wurden ein beendeter Container und das dazugehörige unbenannte Volume mit einem einzigen Befehl docker system prune --volumes gelöscht. Wenn ein Datenbank-Container (beispielsweise aus dem postgres- oder mariadb-Image) ohne Angabe eines Volumes gestartet wurde, befinden sich seine Daten in einem solchen unbenannten Volume, und eine im angehaltenen Zustand durchgeführte Bereinigung löscht diese endgültig.

Die benannten Volumes werden auch durch den Befehl system prune --volumes nicht gelöscht; hierfür ist der Befehl docker volume prune -a erforderlich, den Sie nur ausführen sollten, wenn Sie sicher sind, dass Sie keines der Volumes mehr benötigen.

Filter: „until“ und „label“

Mit dem Schalter --filter werden nur die älteren Elemente oder diejenigen mit dem angegebenen Label gelöscht:

# Unbenutzte Images, älter als 24 Stunden
docker image prune -a --filter "until=24h"
# Gestoppte Container, Netzwerke, Images und Build-Cache, älter als 7 Tage
docker system prune -a --filter "until=168h"
# Nur unbenutzte Images mit dem Label projekt=demo
docker image prune -a --filter "label=projekt=demo"

Der Wert von until kann entweder eine Zeitspanne (24h, 30m; Tage werden nicht akzeptiert, daher 7 Tage 168h) oder ein Datum (2026-11-01T00:00:00) sein. Im Test basierte until bei den Images auf dem Zeitpunkt des Herunterladens des Images und nicht auf dem Erstellungsdatum: Ein Image, das vor 7 Monaten erstellt, aber am selben Tag heruntergeladen wurde, blieb mit dem Filter until=168h erhalten. Die Bezeichnung (Label) erhalten die Images aus der Zeile LABEL im Dockerfile.

Die Volumes erkennen den Filter until nicht: Der Befehl docker volume prune --filter until=24h führt zu einer Fehlermeldung (invalid filter 'until'), und auch der Befehl docker system prune --volumes --filter until=24h wird nicht ausgeführt (The "until" filter is not supported with "--volumes"). Die Volumes können mit dem Filter label gefiltert werden.

Unkontrollierte Protokolldateien

Die Ausgabe der Container wird standardmäßig in jeweils eine JSON-Datei geschrieben, ohne Größenbeschränkung. Das Protokoll eines Containers, der viele Einträge erstellt, wächst sehr schnell: Im Test erreichte das Protokoll eines kontinuierlich schreibenden Containers innerhalb von 10 Sekunden eine Größe von 1 GB. Den Speicherort und die Größe der Protokolldatei können Sie wie folgt einsehen:

docker inspect --format '{{.LogPath}}' containername
sudo du -h $(docker inspect --format '{{.LogPath}}' containername)

Die Größe der Protokolle aller Container, wobei die größten am Ende aufgeführt sind:

sudo sh -c 'du -h /var/lib/docker/containers/*/*-json.log* | sort -h | tail'

Das Log leeren, ohne den Container anzuhalten:

sudo truncate -s 0 $(docker inspect --format '{{.LogPath}}' containername)

Löschen Sie die Protokolldatei nicht mit dem Befehl rm. Im Test hielt dockerd die gelöschte Datei weiterhin offen: Der Speicherplatz wurde nicht freigegeben, das Protokoll wuchs unsichtbar weiter an (wie durch den Befehl sudo lsof +L1 mit der Kennzeichnung (deleted) angezeigt), und docker logs gab eine Fehlermeldung aus (Error grabbing logs: ... no such file or directory). Der Speicherplatz wurde erst durch einen Neustart des Containers (docker restart) oder dessen Löschung freigegeben. Dieses Phänomen wird im Artikel Die Festplatte ist voll, aber du zeigt nichts an ausführlich beschrieben.

truncate ist lediglich eine symptomatische Maßnahme. Die endgültige Lösung besteht in der Festlegung einer Größenbeschränkung für die Protokolle in der Datei /etc/docker/daemon.json ("log-opts": {"max-size": "10m", "max-file": "3"}), wie im Installationsartikel beschrieben. Dies gilt nur für neue Container; die Einstellungen eines bestehenden Containers können Sie wie folgt überprüfen:

docker inspect --format '{{.HostConfig.LogConfig}}' containername

{json-file map[]} steht für ein Protokoll ohne Begrenzung, während {json-file map[max-file:3 max-size:10m]} ein begrenztes Protokoll bezeichnet. Sie können auch für einen einzelnen Container im Befehl docker run eine Begrenzung festlegen: --log-opt max-size=10m --log-opt max-file=3.

Regelmäßige Bereinigung mit einem systemd-Timer

Der folgende Dienst und der Timer löschen jeden Sonntag in den frühen Morgenstunden nicht genutzte Images, die älter als 7 Tage sind, inaktive Container und Netzwerke sowie den Build-Cache. Die Volumes bleiben dabei bewusst unberührt.

/etc/systemd/system/docker-prune.service:

[Unit]
Description=Unbenutzte Docker-Images, Container und Build-Cache löschen
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker system prune --all --force --filter "until=168h"

/etc/systemd/system/docker-prune.timer:

[Unit]
Description=Wöchentliche Docker-Bereinigung

[Timer]
OnCalendar=Sun 04:00
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

Aktivierung und Testlauf:

sudo systemctl daemon-reload
sudo systemctl enable --now docker-prune.timer
systemctl list-timers docker-prune.timer
sudo systemctl start docker-prune.service
journalctl -u docker-prune.service

Aufgrund der Einstellung Persistent=true wird die Bereinigung beim nächsten Systemstart ausgeführt, falls der Rechner zum angegebenen Zeitpunkt ausgeschaltet war. Falls Sie die Verwendung von Cron bevorzugen, fügen Sie dieselbe Zeile in die Root-Crontab ein (sudo crontab -e):

0 4 * * 0 /usr/bin/docker system prune --all --force --filter "until=168h" > /dev/null

Über die Cron-Syntax erfahren Sie mehr im Artikel Crontab-Syntax und geplante Aufgaben. Bitte beachten Sie: Bei dieser Bereinigung werden auch stillgelegte Container gelöscht, sofern diese älter als 7 Tage sind. Wenn Sie einen Container über einen längeren Zeitraum stillgelegt halten, ihn aber behalten möchten, sollten Sie diese Methode nicht verwenden oder den Befehl auf folgende Form einschränken: docker image prune -a --force --filter "until=168h".

Was sollten Sie nicht löschen?

Den Inhalt des Verzeichnisses /var/lib/docker manuell. Docker verwaltet in einer Datenbank, wo sich welche Layer, Volumes und Container befinden; das manuelle Löschen einzelner Verzeichnisse führt zu Unstimmigkeiten, wodurch Container oder Images unbrauchbar werden können. Verwenden Sie zum Löschen stets die docker-Befehle. Löschen Sie das gesamte Verzeichnis erst, wenn Sie Docker deinstallieren.
Benannte Volumes, solange Sie nicht wissen, was sich darin befindet. Datenbanken, hochgeladene Dateien und Anwendungseinstellungen befinden sich in der Regel in Volumes. Sie können den Inhalt eines Volumes vor dem Löschen einsehen: docker run --rm -v kotetnev:/adat alpine ls -la /adat. Erstellen Sie zuvor eine Sicherungskopie wichtiger Daten.
Deaktivierte, aber noch benötigte Container. In diesem Fall sind die Befehle docker image prune -a sowie docker builder prune zielgerichteter als system prune.
Images, die für eine Wiederherstellung vorgesehen sind. Wenn Sie nach einem Update zur alten Version zurückkehren möchten, löschen Sie das alte Image bitte nicht, solange sich die neue Version nicht als fehlerfrei erwiesen hat.

Sollte der Speicherplatz auch nach der Bereinigung von Docker knapp werden, hilft Ihnen die Überprüfung der Festplattennutzung dabei, herauszufinden, was außer Docker noch Speicherplatz belegt.