Docker-fout "No Space Left on Device" verhelpen: een complete gids

De Docker-fout "no space left on device" slaat meestal toe op het slechtst mogelijke moment: tijdens een deployment, bij een cruciale build of wanneer je een essentiële image pulled. Ik ben deze fout vaker tegengekomen en kan je vertellen dat overhaast bestanden verwijderen zonder goede diagnose een recept is voor dataverlies.

Wat deze fout extra lastig maakt, is dat er zelden één enkele oorzaak is. Je kunt te maken hebben met opgestapelde Docker-images, ontspoorde containerlogs, uitgeputte inodes door miljoenen kleine bestanden of zelfs "fantoom"-ruimte die wordt ingenomen door verwijderde bestanden die nog openstaan bij draaiende processen. Elk scenario vraagt om een andere oplossing.

Daarom benadruk ik altijd: eerst diagnosticeren, dan pas handelen. Als je de onderliggende oorzaak snapt, kun je gericht ingrijpen zonder je productieomgeving te verstoren. In deze gids laat ik je een systematische aanpak zien om dit probleem te diagnosticeren, op te lossen en te voorkomen.

Als je nieuw bent met Docker, raad ik je onze praktische Introduction to Docker-cursus aan, die alles behandelt wat je nodig hebt om met containerisatie te starten.

Wat is de Docker-fout "No Space Left on Device"?

Wanneer Docker deze fout geeft, wijst dat op één van twee fundamentele opslagproblemen op je systeem:

• Uitputting van fysieke schijfblokken
• Inode-uitputting

Het onderscheid tussen deze oorzaken begrijpen is cruciaal om de juiste oplossing toe te passen.

Oorzaken achter de fout “no space left on device”

De eerste en meest voor de hand liggende oorzaak is uitputting van fysieke schijfblokken. Je bestandssysteem heeft geen echte opslagruimte meer om data weg te schrijven. Dit is het intuïtieve scenario: je hebt je schijf simpelweg volgeschreven met Docker-images, containers, logs of andere bestanden.

De tweede, minder voor de hand liggende oorzaak is inode-uitputting. Zelfs met gigabytes aan vrije ruimte kan je bestandssysteem zonder inodes komen te zitten (metadata-structuren die bestanden en mappen bijhouden). Elk bestand en elke map gebruikt één inode, dus applicaties die miljoenen kleine bestanden aanmaken (denk aan PHP-sessiebestanden of npm’s node_modules-mappen) kunnen inodes uitputten terwijl er nog schijfruimte over is.

De overlay2 storage driver begrijpen

Docker gebruikt doorgaans de overlay2 storage driver, gebaseerd op Linux-OverlayFS. OverlayFS legt meerdere mappen op één host over elkaar en presenteert ze als één bestandssysteem. Imagelagen worden als read-only onderste onderste mappen gemount, terwijl elke draaiende container een dunne schrijfbare bovenlaag toevoegt. De samengevoegde weergave wordt als één map aan de container getoond.

De overlay2-driver ondersteunt theoretisch tot 128 onderste OverlayFS-lagen, maar de layer store van Docker hanteert een praktische limiet van 125 baselagen per image. Dit maakt efficiënte image-compositie mogelijk en verbetert prestaties bij operaties zoals docker build en docker commit. 

Hoewel overlay2 is ontworpen om minder inodes te gebruiken dan eerdere drivers, kunnen Docker-omgevingen die herhaaldelijk images bouwen, lagen pullen of containers aanmaken na verloop van tijd toch flinke druk zetten op zowel schijfblokken als inodes, zeker wanneer images of applicatielagen veel kleine bestanden bevatten.

Hoe deze fout zich uit, hangt af van de deployment-omgeving:

• Op native Linux-systemen raakt het het bestandssysteem achter /var/lib/docker. 

• Op Docker Desktop voor Windows of macOS zit de beperking in Docker’s virtuele schijfimage (zoals een .raw of .vhdx-bestand), wat extra aandachtspunten geeft bij het terugwinnen of vergroten van opslag.

Stap 1: Diagnoseer de oorzaak

Voordat ik iets verwijder, begin ik altijd met grondige diagnostiek. Deze investering van een paar minuten kan uren troubleshooting besparen en voorkomt per ongeluk dataverlies.

Controleer capaciteit op systeemniveau

Begin met het bekijken van de schijfgebruik van je host met df -H (df staat voor disk free):

df -HMogelijk gemaakt door

Vrije schijfcontrole in WSL

Deze opdracht toont schijfgebruik in een leesbaar formaat. Let op bestandssystemen die op of nabij 100% zitten. 

Op native Linux-installaties is vooral de partitie waar /var/lib/docker staat van belang. Dit is meestal je rootpartitie (/) of een aparte Docker-partitie. 

Op Docker Desktop (Windows/Mac) kijk je naar de hoofdmount van het bestandssysteem (meestal /dev/sdf of iets dergelijks), die de data van de Docker-VM bevat, in plaats van naar specifieke verwijzingen naar /var/lib/docker, omdat Docker in een virtuele machine draait.

Controleer vervolgens op inode-uitputting met df -i:

df -iMogelijk gemaakt door

Controle op inode-uitputting

Als je 100% inodegebruik (IUse%) ziet op een bestandssysteem, heb je het probleem gevonden. Dit komt verrassend vaak voor op buildservers en in CI/CD-omgevingen, waar Docker herhaaldelijk containers met veel kleine bestanden maakt en verwijdert.

Analyseer Docker-specifiek gebruik

Nu we weten of schijfruimte of inodes de boosdoener zijn, duiken we dieper in Docker’s specifieke verbruik. Het commando docker system df geeft een hoog-overoverzicht dat overal werkt:

docker system dfMogelijk gemaakt door

De output verdeelt ruimtegebruik in vier categorieën: images, containers, lokale volumes en buildcache.

De kolom RECLAIMABLE is bijzonder waardevol. Die toont hoeveel ruimte je kunt terugwinnen zonder draaiende containers te beïnvloeden. Het verschil begrijpen is key: "active" ruimte is in gebruik door draaiende containers, terwijl "reclaimable" ruimte veilig kan worden vrijgegeven.

Voor meer details voeg je de verbose-vlag toe:

docker system df -vMogelijk gemaakt door

Analyse van Docker-gebruik

Deze uitgebreide output toont elke image, container en volume afzonderlijk met hun grootte, zodat je de grootste verbruikers kunt identificeren. Hierop let je per sectie:

• Images: Toont de grootte per image en of die in gebruik is. Let op grote, ongebruikte images of duplicaten met verschillende tags. Images gemarkeerd als "unused" kun je veilig verwijderen zonder draaiende containers te raken.

• Containers: Geeft de grootte van de schrijfbare laag per container. Als een gestopte container hier een aanzienlijke SIZE heeft, schrijft die data naar zijn filesystem. De kolom CREATED helpt oude, vergeten containers opsporen.

• Volumes: Lijst de volumegroottes en of ze in gebruik zijn. Volumes die niet in gebruik zijn, zijn veilige kandidaten om te verwijderen, maar controleer wel of ze geen belangrijke data bevatten voordat je prune’t.

• Buildcache: Vaak de grootste verbruiker en makkelijk over het hoofd gezien. Dit zijn tussenlagen van docker build die Docker bewaart om volgende builds te versnellen.

OS-specifieke commando’s

Voor native Linux-gebruikers die nog dieper in het bestandssysteem willen kijken, kun je optioneel submappen onderzoeken om te zien welke (overlay2, containers, volumes) het meest gebruiken:

sudo du -h --max-depth=1 /var/lib/docker | sort -hMogelijk gemaakt door

Voor Docker Desktop-gebruikers geldt dat /var/lib/docker binnen de verborgen VM staat en niet direct toegankelijk is. Gelukkig geeft docker system df -v alle bruikbare info die je nodig hebt, ongeacht je platform, en is het de meest betrouwbare diagnosemethode.

Stap 2: Maak het systeem schoon met Docker prune 

Na het identificeren waar de ruimte wordt verbruikt, kun je die veilig terugwinnen met Docker’s ingebouwde prune-commando’s. Deze acties verwijderen alleen ongebruikte resources, waardoor de kans op verstoring van diensten klein is.

Prune dangling resources

Docker maakt onderscheid tussen "dangling" en "unused" resources. Een dangling image heeft geen tag en geen containerreferenties. Vaak is dit een tussenlaag van een mislukte of vervangen build. Deze kun je altijd veilig verwijderen.

Begin met het basis-prune-commando:

docker system pruneMogelijk gemaakt door

Dit verwijdert alle ongebruikte containers, netwerken en dangling images. Het raakt geen getagde images of volumes, tenzij je dat expliciet aangeeft. Docker vraagt om bevestiging voordat het doorgaat.

Wees grondiger en verwijder alle ongebruikte images (niet alleen dangling) met de vlag --all:

docker system prune --allMogelijk gemaakt door

Docker system prune

Dit commando verwijdert elke image die niet aan een container is gekoppeld. Wees voorzichtig: latere deployments moeten de verwijderde images opnieuw pullen.

Wil je ook volumes meenemen (die persistente data bevatten), voeg dan de vlag --volumes toe:

docker system prune --all --volumesMogelijk gemaakt door

Waarschuwing: Dit verwijdert data in ongebruikte volumes permanent. Controleer altijd of volumes geen belangrijke data bevatten voordat je deze vlag gebruikt.

Beheer de buildcache

Hier wordt het interessant. De buildcache, die tussenlagen van Docker-builds bewaart, is vaak de grootste ruimteverbruiker, maar docker system prune sluit deze bewust uit om buildprestaties te behouden.

Richt je specifiek op de buildcache met:

docker builder pruneMogelijk gemaakt door

Wil je selectiever zijn en recente cachelagen bewaren, gebruik dan tijdsfilters:

docker builder prune --filter "until=24h"Mogelijk gemaakt door

Dit verwijdert alleen cachelagen ouder dan 24 uur en houdt je recente werk intact.

Ruim volumes veilig op

Met volumes moet je extra voorzichtig zijn, omdat ze persistente data bevatten, zoals databases, uploads en applicatiestatus. Het verkeerde volume verwijderen betekent permanent dataverlies.

Identificeer eerst dangling volumes (niet gekoppeld aan een container):

docker volume ls -f dangling=trueMogelijk gemaakt door

Bekijk deze lijst zorgvuldig. Als je zeker weet dat ze niet nodig zijn, kun je ze prune’n:

docker volume pruneMogelijk gemaakt door

Docker vraagt om bevestiging voordat het doorgaat. Twijfel je, maak dan eerst een back-up van volumes.

Stap 3: Ga om met uitputting door Docker-logbestanden

Containerlogs kunnen stiekem enorme hoeveelheden schijfruimte innemen, soms meer dan 50 GB per container.

Identificeer opgeblazen logbestanden

Docker’s standaard json-file-loggingdriver vangt alle stdout en stderr van containers op in JSON-bestanden. Zonder max-size-instelling (standaard -1, onbeperkt) groeien deze bestanden ongeremd.

Controleer containergroottes in alle omgevingen:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"Mogelijk gemaakt door

De grootte van het logbestand van een specifieke container check je zo:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)Mogelijk gemaakt door

Alleen voor native Linux: vind de grootste logbestanden direct:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10Mogelijk gemaakt door

Als docker logs traag wordt of containers niet meer starten, zijn te grote logs waarschijnlijk de oorzaak. Om dit op te lossen, kun je de logs trunceren.

Truncate logs veilig

Logs trunceren levert direct meer ruimte op. Verwijder echter nooit logbestanden met rm terwijl containers draaien. De Docker-daemon houdt open bestandskoppelingen naar deze logs; verwijderen creëert dan "verwijderd maar open"-bestanden die ruimte blijven innemen tot de daemon herstart.

De veilige aanpak is logs op nul te trunceren:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)Mogelijk gemaakt door

Dit geeft meteen ruimte vrij zonder bestandskoppelingen te breken. De container blijft naar hetzelfde bestand loggen.

Stap 4: Geavanceerde troubleshooting en verborgen issues

Als standaardopruiming niet helpt, heb je waarschijnlijk te maken met een van deze minder voorkomende maar even impactvolle problemen:

• Inode-uitputting: Je bestandssysteem is door de metadata-structuren heen, ondanks vrije schijfruimte

• Verwijderde maar open bestanden: Processen houden bestandskoppelingen vast naar verwijderde bestanden, wat "fantoom"-ruimtegebruik creëert

• Opgeblazen virtuele schijf in Docker Desktop: Het .raw- of .vhdx-bestand op de host krimpt niet nadat je data binnen de VM hebt verwijderd

Laten we elk scenario systematisch aanpakken.

Los inode-uitputting op

Dit kan worden veroorzaakt door applicaties die miljoenen kleine bestanden aanmaken, zoals PHP-sessies, npm-node_modules of buildartefacten die in alarmerend tempo inodes verbruiken.

Bevestig eerst de inode-uitputting:

df -iMogelijk gemaakt door

Met Docker-commando’s (alle omgevingen):

docker ps -a | wc -l             # Aantal containers controleren
docker images | wc -l         # Aantal images controleren
docker image prune -a      # Ongebruikte images verwijderen om inodes vrij te makenMogelijk gemaakt door

Voor Linux-installaties: identificeer inode-zware mappen:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
doneMogelijk gemaakt door

Ongebruikte images verwijderen met docker rmi maakt ook inodes vrij. Los applicatieniveau-issues op door cleanup in containers te implementeren of volume mounts te gebruiken voor tijdelijke bestanden.

Ga om met verwijderde maar open bestanden (alleen Linux)

Als een bestand wordt verwijderd terwijl een proces het nog open heeft, wordt de ruimte niet vrijgegeven totdat het proces de koppeling sluit ("fantoom"-ruimtegebruik).

Linux-gebruikers kunnen controleren of dit gebeurt door in de lijst met open bestanden op "deleted" te zoeken.

Identificeer eerst deze bestanden:

sudo lsof | grep deleted Mogelijk gemaakt door

Verwijderde Docker-bestanden

Herstart vervolgens het specifieke proces (gebruik de PID uit lsof) of herstart Docker om ruimte vrij te maken. Als je daarna het commando opnieuw uitvoert, zouden de bestanden niet meer verschijnen: dan zijn ze correct verwijderd.

Laten we nu de laatste geavanceerde strategie bekijken, die alleen geldt voor Docker Desktop: virtuele schijven beheren.

Virtuele schijven in Docker Desktop beheren

Docker Desktop slaat data op in een virtueel schijfbestand (.raw op Mac, .vhdx op Windows) dat dynamisch groeit maar niet automatisch krimpt als je data verwijdert. Je prune’t images en containers, ziet vrije ruimte in de VM toenemen, maar je hostschijf blijft vol.

Om dit te beheren, is de veiligste aanpak fstrim gebruiken om de schijf te compacten zonder data te verliezen:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /Mogelijk gemaakt door

Dit trimt het bestandssysteem van de Docker Desktop-VM en geeft ongebruikte blokken terug aan je host. Je images, containers en volumes blijven intact.

Wil je daarentegen helemaal schoon beginnen (dit verwijdert alle data), gebruik dan Docker Desktop Settings → Troubleshoot → Reset to factory defaults. 

Waarschuwing: Dit is destructief en verwijdert alle images, containers, volumes en instellingen. Alleen als laatste redmiddel gebruiken.

Reset naar fabrieksinstellingen

Stap 5: Voorkom de Docker-fout “No Space Left on Device”

Nu we de directe crisis hebben opgelost, voeren we structurele wijzigingen door om herhaling te voorkomen. Deze configuraties vergen wat planning, maar leveren veel op in systeemstabiliteit.

Verplaats de Docker-rootmap (alleen Linux)

Docker Desktop-gebruikers kunnen de data root-locatie niet eenvoudig wijzigen. In plaats daarvan kun je:

• Schijfruimte vergroten: Gebruik de methoden voor het compacteren van virtuele schijven zoals beschreven in stap 4

• Voor WSL2-backend: Beheer limieten via een .wslconfig-bestand zoals te zien in Docker Desktop Settings → Resources

Maar als je Linux gebruikt en je rootpartitie is krap terwijl je een grotere partitie beschikbaar hebt (bijvoorbeeld een aparte datadisk), dan is het verplaatsen van Docker’s datamap een permanente oplossing.

Stop eerst Docker:

sudo systemctl stop dockerMogelijk gemaakt door

Bewerk /etc/docker/daemon.json om de nieuwe locatie op te geven:

{
  "data-root": "/mnt/docker-data"
}Mogelijk gemaakt door

Migreer bestaande data om je images en containers te behouden:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/Mogelijk gemaakt door

Start tot slot Docker opnieuw:

sudo systemctl start dockerMogelijk gemaakt door

Docker slaat nu alle data op de nieuwe locatie op. Controleer met docker info | grep "Docker Root Dir" of het pad is bijgewerkt.

Configureer globale logrotatie

Logrotatie is de effectiefste preventiestrategie die ik heb toegepast. Standaard heeft Docker’s json-file-driver max-size: -1 (onbeperkt), wat in productie een rampscenario is.

Voor native Linux-installaties: bewerk /etc/docker/daemon.json om limieten globaal af te dwingen:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Mogelijk gemaakt door

Start Docker opnieuw nadat je het bestand hebt aangepast.

Voor Docker Desktop bewerk je /etc/docker/daemon.json niet direct. In plaats daarvan:

1. Open Docker Desktop
2. Ga naar Settings → Docker Engine
3. Je ziet een JSON-editor met de daemonconfiguratie
4. Voeg de instellingen voor logrotatie toe aan de bestaande JSON:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Mogelijk gemaakt door

Klik tot slot op Apply & Restart.

Deze configuratie beperkt elke container tot drie logbestanden van 10 MB (samen 30 MB per container).

Belangrijk: Deze instellingen gelden alleen voor nieuw aangemaakte containers. Bestaande containers behouden hun oorspronkelijke logconfiguratie. Je moet containers opnieuw aanmaken om de nieuwe limieten toe te passen.

Voor nog betere compressie en performance kun je de local-loggingdriver overwegen:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}Mogelijk gemaakt door

Daarnaast kun je loginstellingen per service overschrijven in docker-compose.yml:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"Mogelijk gemaakt door

Automatiseer onderhoud

Een andere goede gewoonte is om bepaalde processen te automatiseren. Voorkomen is beter dan genezen. Daarom raad ik aan om cleanup te automatiseren met een cronjob die tijdens onderhoudsvensters draait:

# Maak een cleanupscript
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Voeg toe aan crontab om wekelijks op zondag om 02:00 te draaien
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -Mogelijk gemaakt door

Dit script plant een taak in die elke zondag om 02:00 automatisch gestopte containers en ongebruikte data verwijdert. Het wist ook veilig buildcachelagen ouder dan een week (168 uur) om ongebreidelde groei van schijfgebruik te voorkomen.

Optimaliseer bovendien je Dockerfiles met multi-stage builds om images te verkleinen. Multi-stage builds laten je één stage gebruiken voor compilatie en build (met alle zware devtools) en vervolgens alleen de eindartefacten kopiëren naar een schone, minimale productiestage. 

Dit verwijdert buildafhankelijkheden, broncode en tussenbestanden uit je uiteindelijke image, wat de grootte en het aanvalsoppervlak fors reduceert.

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]Mogelijk gemaakt door

Dit patroon verkleint de productieimage door buildtools en broncode uit te sluiten.

Conclusie

Het oplossen van de fout "no space left on device" volgt een voorspelbaar patroon: diagnoseer eerst of het om schijfblokken of inodes gaat, prune vervolgens veilig om ruimte terug te winnen zonder dataverlies, en optimaliseer daarna de configuratie om herhaling te voorkomen.

In mijn jaren met het beheren van Docker-omgevingen heb ik geleerd dat logrotatie de effectiefste preventiestrategie is. Een eenvoudige daemon.json-configuratie voorkomt de meeste incidenten met ruimte-uitputting.

Ik raad je aan om je daemon.json-configuratie nu te controleren. Als je geen max-size en max-file hebt ingesteld voor je loggingdriver, voeg die dan meteen toe. Je toekomstige zelf zal je dankbaar zijn wanneer je de volgende ruimtecrisis voorkomt.

Klaar om een Docker-pro te worden? Zet dan de volgende stap en schrijf je in voor onze Containerization and Virtualization with Docker and Kubernetes skill track, die ik van harte aanbeveel.