Docker belegt zu viel Platz auf dem Mac? Sicher aufräumen

Warum Docker unter macOS so groß wirkt

Docker Desktop führt Linux-Container in einer schlanken virtuellen Maschine aus. Images, die beschreibbaren Schichten der Container, Build-Cache und Volumes liegen in einer großen Disk-Image-Datei – nicht in gewöhnlichen Ordnern, die du im Finder bearbeiten solltest. Je nach Version und Konfiguration von Docker Desktop heißt diese Datei meist Docker.raw.

Die maximale Kapazität der Datei, ihre angezeigte Größe und der Platz, den Docker gerade tatsächlich nutzt, sind nicht immer dieselbe Zahl. Eine Sparse-Datei kann logisch groß sein und auf dem Mac trotzdem weniger physischen Platz belegen. Beginne mit Dockers eigener Aufstellung und dem freien Speicher in macOS, statt anzunehmen, die größte Zahl im Finder sei sofort zurückzugewinnen.

Wer Docker.raw löscht, umgeht Dockers Objektverwaltung und kann alle lokalen Images, Container und Volumes auf einen Schlag vernichten. Auch Verschieben im Finder kann Docker Desktop beschädigen. Dockers Mac-Dokumentation verweist dafür auf die Einstellungen (Settings), über die du den Speicherort des Disk-Images änderst.

Docker-Speicher erst nur lesend prüfen

Starte Docker Desktop, öffne das Terminal und führe docker system df aus. Der Befehl fasst Images, Container, lokale Volumes und Build-Cache zusammen und zeigt, wie viel Docker für rückgewinnbar hält. Mit -v bekommst du die Detailansicht: docker system df -v.

Den Wert „RECLAIMABLE“ musst du vorsichtig lesen. Ein Image kann von mehreren Containern genutzt werden; löschst du ein Tag, bekommst du also nicht unbedingt die ganze angezeigte Größe zurück. Ein Volume wirkt vielleicht ungenutzt, weil gerade kein Container daran hängt, und enthält trotzdem eine Datenbank, die du später wiederherstellen willst.

Öffne außerdem in Docker Desktop Settings > Resources und sieh dir das Speicherlimit (Disk usage limit) und den Speicherort des Disk-Images (Disk image location) an, soweit deine Version sie anbietet. Notiere die aktuellen Werte, bevor du etwas änderst. Startet Docker nicht, sichere die Docker-Datendatei nach Dockers Wiederherstellungsanleitung, bevor du einen Reset oder eine Neuinstallation versuchst.

1. Führe docker system df -v aus und speichere die Ausgabe mit Datum.
2. Liste die Container mit docker ps -a auf und bestimme gestoppte Workloads, die wirklich überholt sind.
3. Liste die Images mit docker image ls auf und ordne wichtige Tags aktuellen Projekten oder CI-Workflows zu.
4. Liste die Volumes mit docker volume ls auf und kläre für jedes Volume mit Daten, wem es gehört und ob es gesichert ist.
5. Prüfe den Build-Cache zuletzt mit docker builder du oder den Befehlen, die dein aktiver Builder unterstützt.

Dass an einem Volume kein laufender Container hängt, beweist nicht, dass seine Daten entbehrlich sind. Compose-Projekte, gestoppte Datenbanken und einmalige Wiederherstellungen lassen oft berechtigte Volumes ohne Container zurück.

Gestoppte Container und ungenutzte Images gezielt entfernen

Lösche Container, die nachweislich überholt sind, mit docker container rm und ihren Namen oder IDs. Dabei gehen die Änderungen in ihrer beschreibbaren Schicht verloren; benannte Volumes bleiben erhalten, solange du ihre Entfernung nicht ausdrücklich anforderst.

Ein Image, von dem du weißt, dass du es nicht mehr brauchst, entfernst du mit docker image rm und seinem Tag oder seiner ID. Meldet Docker, dass ein Container es noch verwendet, untersuche diesen Container, statt das Löschen zu erzwingen. Ein paar teure Basis-Images zu behalten, kann sinnvoll sein, wenn du oft neu baust und das Netz langsam ist.

Befehle für einzelne Kategorien haben einen kleineren Wirkungsradius als ein systemweites Prune. docker container prune entfernt nach einer Bestätigung alle gestoppten Container. docker image prune entfernt standardmäßig nur verwaiste („dangling“) Images; mit -a erweiterst du das auf alle Images, die kein Container verwendet. Lies jedes Mal die Zusammenfassung in der Bestätigungsabfrage.

Build-Cache bereinigen, ohne Volumes anzutasten

BuildKit hebt Schichten auf, damit wiederholte Builds unveränderte Schritte wiederverwenden können. Auf aktiv genutzten Entwicklungsrechnern kann der Build-Cache zur größten rückgewinnbaren Kategorie werden – und bleibt dabei vollständig aus Dockerfiles und Build-Kontexten reproduzierbar.

Mit docker builder prune entfernst du ungenutzten Build-Cache des Standard-Builders. Für Builder, die buildx verwaltet, nutzt du docker buildx prune und prüfst die Optionen deiner Docker-Version. Beide Befehle fragen nach einer Bestätigung, solange du kein Force-Flag angibst; lass diese Abfrage als Sicherheitsprüfung bestehen.

Rechne damit, dass der nächste Image-Build langsamer ist und Schichten erneut lädt oder neu baut. Passiert das jede Woche, verbessere lieber Dockerfile und Cache-Strategie, statt regelmäßig pauschal zu löschen: Installiere Abhängigkeiten vor häufig geänderten Quellkopien, verschärfe .dockerignore und gib persistenten CI-Buildern ein festes Cache-Budget.

docker system prune verstehen, bevor du den Befehl ausführst

docker system prune ist ein praktischer Sammelbefehl. Laut Docker-Dokumentation entfernt er standardmäßig gestoppte Container, ungenutzte Netzwerke, verwaiste (dangling) Images und ungenutzten Build-Cache. Das kann passen, nachdem du diese Kategorien geprüft hast.

Volumes entfernt der Standardbefehl nicht. Die Option --volumes weitet die Bereinigung auf anonyme Volumes aus, die echte Anwendungsdaten enthalten können. Füge sie nicht leichtfertig hinzu, und kopiere keinen Einzeiler aus einem Forum, ohne zu prüfen, was deine Docker-Version damit entfernen will.

Die Option -a weitet die Image-Bereinigung über verwaiste Images hinaus auf alle Images aus, die kein Container nutzt. Das kann hohe Download- und Neubaukosten verursachen, selbst wenn keine Daten verloren gehen. Entferne die großen Verursacher lieber gezielt, wenn du sie kennst.

1. Schließe die rein lesende Prüfung ab und sichere jedes Volume, dessen Daten wichtig sind.
2. Erklärt eine einzelne Kategorie das Problem, bereinige Build-Cache oder gestoppte Container gezielt.
3. Führe docker system prune ohne -a und --volumes nur aus, wenn du jede Kategorie in der Bestätigungsabfrage akzeptierst.
4. Führe docker system df -v erneut aus und prüfe, ob wichtige Projekte noch starten.
5. Prüfe den freien Speicher in macOS, nachdem Docker Desktop Zeit hatte, Host-Blöcke freizugeben.

Volumes und Datenbanken schützen

Volumes sind dafür gedacht, Container zu überdauern. Ein Volume für PostgreSQL, MySQL oder einen anderen Entwicklungsdienst kann die einzige lokale Kopie von Daten enthalten – auch wenn der zugehörige Container gestoppt oder gelöscht ist. Behandle Volumes wie Dokumente, nicht wie Cache, bis du weißt, wem sie gehören und ob es ein Backup gibt.

Laut Dockers Backup-Anleitung müssen Volume-Daten separat gesichert werden. Nutze nach Möglichkeit den nativen Export der Datenbank oder einen getesteten Ablauf zur Volume-Sicherung. Ein Ordner, den du aus dem Volume einer laufenden Datenbank kopierst, ist nicht automatisch ein konsistentes Backup.

Gib Volumes in Compose-Dateien Namen, damit klar ist, wozu sie gehören. Notiere, welches Projekt sie angelegt hat, wie du sie wiederherstellst und wann sie wegkönnen. So wird künftiges Aufräumen von Raterei zu einer Aufbewahrungsentscheidung.

Docker-Desktop-Speicher verkleinern, verschieben oder zurücksetzen

Löst das Bereinigen der Objekte den Platzmangel auf dem Mac nicht, verwalte das Disk-Image über die Einstellungen von Docker Desktop. Welche Regler es gibt, hängt von der Version ab, doch die unterstützte Oberfläche ist der richtige Ort, um das Speicherlimit oder den Speicherort des Disk-Images zu ändern.

Zieh Docker.raw nicht im Finder auf ein anderes Laufwerk – Docker warnt ausdrücklich davor und verweist auf die Einstellungen. Bevor du einen Factory Reset, eine Deinstallation oder eine destruktive Größenänderung ausführst, exportiere benötigte Images oder stelle sicher, dass du sie erneut laden kannst, sichere Volumes separat und bewahre die Konfiguration auf, die du brauchst.

Je nach Format des Disk-Images und Verhalten von Docker Desktop wird Platz auf dem Mac erst mit Verzögerung frei, nachdem Objekte gelöscht wurden. Laut Dockers Mac-FAQ gibt Docker.raw Host-Speicher in der Regel deutlich schneller zurück als das ältere qcow2-Format. Miss nach dem Prune erneut, statt sofort weitere Daten zu löschen.

Was AskClean tut – und bewusst nicht tut

AskClean kann den Launcher-Cache von Docker Desktop sichtbar machen und zeigen, wo von Docker verwalteter Speicher auf deinem Mac Platz belegt. Docker.raw, die Group-Container-Daten von Docker, Zugangsdaten, Images und Volumes markiert es bewusst als vom Anbieter verwaltet oder als nie vorausgewählt, statt sie wie einen gewöhnlichen App-Cache zu löschen.

Für Container-Objekte und die virtuelle Festplatte nutzt du Dockers eigene CLI und Einstellungen. AskClean macht den versteckten Platzbedarf auf der Mac-Seite sichtbar und verhindert, dass eine breite Bereinigung auf Zugangsdaten oder Volume-Daten übergreift. Der sichere Ablauf bleibt: in AskClean finden, mit docker system df -v diagnostizieren und dann genau die betroffene Docker-Kategorie bereinigen.

Löschrisiko nach Docker-Kategorie

Die virtuelle Festplatte von Docker enthält sowohl neu erzeugbare Schichten als auch dauerhafte Daten.

FAQ