Docker frisst Speicher auf dem Mac: was prune wirklich löscht

Auf einem Mac mit Docker Desktop ist der größte einzelne Klumpen Speicher fast immer dieselbe Datei: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw. Sie wird 40, 60, manchmal 100 GB groß, und ein Aufräum-Programm sieht darin genau eine Zahl.

Diese Zahl ist die Summe von vier getrennten Konten, und sie zu addieren ist der Fehler.

Was Docker über sich selbst sagt

Die Antwort steht nicht im Dateisystem, sondern im Werkzeug:

docker system df -v

Der Aufruf ist read-only und liefert vier Zeilen — Images, Containers, Local Volumes, Build Cache — jeweils mit SIZE und RECLAIMABLE. Genau diese Aufteilung entscheidet, was ein Aufräumen kostet:

Die Befehle, in der Reihenfolge, in der sie weh tun

docker builder prune            # nur Build-Cache. Kostet Zeit, sonst nichts.
docker image prune              # nur unbenutzte, unbenannte Images (dangling).
docker system prune             # + gestoppte Container, ungenutzte Netzwerke.
docker system prune -a          # + JEDES Image ohne laufenden Container.
docker volume prune             # anonyme Volumes.
docker volume prune -a          # auch die benannten. Das sind meistens Daten.

Der Sprung von Zeile drei auf Zeile vier ist ein Flag. Er ist auch der Unterschied zwischen „ich warte beim nächsten Build zwei Minuten“ und „das Image, das ich vor drei Monaten gebaut habe und dessen Dockerfile es nicht mehr gibt, ist weg“.

Der Sprung von Zeile fünf auf Zeile sechs ist ebenfalls ein Flag — und dahinter liegen Postgres-Volumes.

Warum wir den pauschalen Befehl nie vorschlagen

Docker unterscheidet nicht zwischen einem Image, das aus einer Registry kam, und einem, das hier gebaut wurde. Für den Daemon sehen beide gleich aus. Ein Werkzeug, das von außen zuschaut, kann diesen Unterschied also nicht kennen — und darf ihn folglich nicht behaupten.

BalaneDisk zeigt deshalb die vier Konten getrennt, mit drei Urteilen:

• gefahrlos — Build-Cache, dangling Images
• vorher hinsehen — Images, Container-Schichten
• enthält Daten — benannte Volumes

und liefert zu jedem den passenden Befehl statt eines Knopfes. Ausgeführt wird er von dir, im Terminal, mit dem Wissen, was er mitnimmt.

Der Rest der Wahrheit über Docker.raw

Drei Größen gehören zu dieser einen Datei, und sie sind alle drei richtig:

1. 01Zugewiesene Größe — die Obergrenze, die Docker Desktop in den Einstellungen bekommen hat.
2. 02Tatsächlich belegt — was macOS an Blöcken wirklich vergeben hat (Sparse-Datei).
3. 03Innen genutzt — was die Linux-VM davon benutzt.

Nach einem prune sinkt (3) sofort, (2) erst, wenn Docker den freien Platz an macOS zurückgibt. Wer nur auf den Finder schaut, hält das für einen fehlgeschlagenen Aufräumvorgang. Es ist nur ein Abbild, das noch nicht geschrumpft ist.

Wie der Platz zurück an macOS geht

Platz innerhalb der VM freizugeben und Platz auf deiner Platte freizugeben sind zwei Ereignisse, und sie fallen nicht zusammen. Genau das bringt Leute dazu, einen Prune dreimal zu wiederholen.

Docker.raw ist eine Sparse-Datei: Sie belegt, was hineingeschrieben wurde, und schrumpft nicht von allein, wenn Daten darin gelöscht werden. Der Platz muss ausdrücklich zurückgegeben werden, indem die ungenutzten Blöcke getrimmt werden.

Neuere Docker-Desktop-Versionen führen dieses TRIM automatisch aus, meist kurz nach einem Prune oder beim nächsten Start. Ist die Datei eine Stunde später immer noch groß:

1. 01Docker Desktop beenden und neu öffnen. Das Billigste, und oft genug.
2. 02Docker Desktop → Settings → Resources → Advanced, wo die Obergrenze des virtuellen Laufwerks steht. Sie zu senken verkleinert die Datei nicht; es deckelt künftiges Wachstum.
3. 03„Clean / Purge data" unter Troubleshoot. Die grobe Fassung: Sie verwirft alles, benannte Volumes eingeschlossen. Lies vorher die Kontentabelle oben noch einmal.

Bis eines davon passiert, meldet der Finder eine Datei, die noch nicht nachgezogen hat — keinen misslungenen Prune.

Unter Windows ist die Datei anders und das Problem identisch

Docker Desktop läuft unter Windows auf WSL 2, das Gegenstück liegt also in einem virtuellen Laufwerk:

%LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx

Gleiches Verhalten: Es wächst mit dem Geschriebenen und behält seine Größe, nachdem die Daten weg sind. Dieselben vier Konten darin, dieselben Befehle, dieselbe Reihenfolge der Gefährlichkeit.

Zurückholen geht in zwei Schritten. Erst alles herunterfahren:

wsl --shutdown

Dann komprimieren — mit verfügbarem Hyper-V:

Optimize-VHD -Path "$env:LOCALAPPDATA\Docker\wsl\disk\docker_data.vhdx" -Mode Full

oder ohne, über diskpart:

diskpart
select vdisk file="C:\Users\<du>\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
compact vdisk
exit

Wo das zwischen allem anderen auf einem Windows-Rechner einzuordnen ist: Windows-Speicher voll: wo der Platz wirklich hingeht.

Damit es nicht wiederkommt

Prune ist die Heilung. Diese drei Dinge verhindern, dass es ein monatliches Ritual wird:

Den Build-Cache nach Zeit prunen, nicht nach Impuls.

docker builder prune --filter until=168h

Das wirft Cache-Einträge weg, die älter als eine Woche sind, und behält die jüngeren, die dir tatsächlich Zeit sparen.

Den Build-Cache deckeln. Docker Desktop → Settings → Builders lässt eine Maximalgröße für den Build-Cache setzen, ab der er selbst die ältesten Einträge verdrängt. Eine Obergrenze, die du einmal setzt, schlägt einen Befehl, an den du dich erinnern musst.

Eine .dockerignore schreiben. Ein Build-Kontext, der node_modules, .git und einen dist-Ordner bei jedem Build an den Daemon schickt, verschwendet Cache-Platz und Build-Zeit in einer Bewegung. Das ist die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung, und sie ist eine Datei.

Kurzfassung

• Nie mit -a anfangen. docker builder prune zuerst, es kostet nichts außer Zeit.
• Benannte Volumes einzeln ansehen, nie im Rudel löschen.
• Docker.raw schrumpft verzögert — das ist kein Fehler.
• Und der Ordner im Finder ist der falsche Hebel: für einen Cache, den sein Werkzeug verwaltet, ist der Befehl der richtige.

Weiter: Mac-Speicher voll: wo die Gigabyte wirklich stecken · Was dein Mac wirklich tut · Eine DaisyDisk-Alternative, die sagt, was der Ordner ist