Come risolvere l’errore Docker "No Space Left on Device": guida completa

L’errore Docker "no space left on device" di solito colpisce nel momento peggiore: a metà di un deployment, durante una build critica o mentre stai scaricando un’immagine essenziale. Mi è capitato diverse volte e posso dirti che mettersi a cancellare file alla cieca, senza una diagnosi corretta, è la ricetta perfetta per perdere dati.

Ciò che rende questo errore particolarmente insidioso è che raramente ha una sola causa. Potresti avere a che fare con immagini Docker accumulate, log dei container fuori controllo, inode esauriti a causa di milioni di file piccoli o persino spazio "fantasma" occupato da file eliminati ma ancora aperti da processi in esecuzione. Ogni scenario richiede una soluzione diversa.

Ecco perché insisto sempre sulla diagnosi prima dell’azione. Capire la causa alla radice ti permette di applicare soluzioni mirate in modo efficiente ed evitare interruzioni nell’ambiente di produzione. In questa guida ti mostrerò un approccio sistematico per diagnosticare, risolvere e prevenire questo problema frustrante.

Se sei alle prime armi con Docker, ti consiglio il nostro corso Introduction to Docker con esercitazioni pratiche: copre tutto ciò che ti serve per iniziare con la containerizzazione.

Che cos’è l’errore Docker "No Space Left on Device"?

Quando Docker segnala questo errore, sta indicando uno di due problemi fondamentali con l’archiviazione del tuo sistema:

• Esaurimento dei blocchi fisici del disco
• Esaurimento degli inode

Capire la differenza tra queste cause è cruciale per applicare la soluzione corretta.

Cause alla radice dell’errore “no space left on device”

La prima e più immediata causa è l’esaurimento dei blocchi fisici del disco. Il filesystem ha esaurito lo spazio reale per scrivere dati. È lo scenario più intuitivo: hai semplicemente riempito il disco con immagini, container, log o altri file Docker.

La seconda causa, meno ovvia, è l’esaurimento degli inode. Anche con gigabyte di spazio libero, il filesystem può rimanere senza inode (strutture di metadati usate per tracciare file e directory). Ogni file e directory consuma un inode, quindi applicazioni che creano milioni di piccoli file (pensa ai file di sessione PHP o alle directory node_modules di npm) possono esaurire gli inode lasciando spazio disco inutilizzato.

Capire il driver di storage overlay2

Docker usa in genere il driver di storage overlay2, basato su OverlayFS di Linux. OverlayFS stratifica più directory su un singolo host e le presenta come un filesystem unificato. I layer dell’immagine sono montati come directory inferiori in sola lettura, mentre ogni container in esecuzione aggiunge un sottile layer superiore scrivibile. La vista unificata è esposta al container come un’unica directory.

Il driver overlay2 supporta nativamente fino a 128 layer inferiori di OverlayFS in teoria, ma l’archivio dei layer di Docker impone un limite pratico di 125 layer base per immagine. Consente una composizione efficiente delle immagini e prestazioni migliori per operazioni come docker build e docker commit. 

Sebbene overlay2 sia progettato per consumare meno inode rispetto ai driver precedenti, ambienti Docker che costruiscono spesso immagini, scaricano layer o creano container possono comunque esercitare nel tempo una notevole pressione sia sui blocchi disco che sugli inode, soprattutto quando le immagini o i layer applicativi contengono molti file piccoli.

Come si manifesta l’errore dipende dall’ambiente di deployment:

• Su sistemi Linux nativi, interessa il filesystem che supporta /var/lib/docker. 

• Su Docker Desktop per Windows o macOS, il limite esiste all’interno dell’immagine del disco della macchina virtuale di Docker (come un file .raw o .vhdx), il che introduce considerazioni aggiuntive quando si recupera o si ridimensiona lo storage.

Passo 1: Diagnostica della causa alla radice

Prima di rimuovere qualsiasi cosa, inizio sempre con una diagnosi accurata. Pochi minuti investiti qui possono farti risparmiare ore di troubleshooting ed evitare perdite accidentali di dati.

Verifica la capacità a livello di sistema

Inizia esaminando l’utilizzo del disco dell’host con df -H (df sta per disk free):

df -HOfferto da

Verifica dello spazio libero su WSL

Questo comando mostra l’uso del disco in formato leggibile. Cerca filesystem alla capacità del 100% o prossimi a essa. 

Su installazioni Linux native, presta particolare attenzione alla partizione dove risiede /var/lib/docker. In genere è la partizione di root (/) o una partizione Docker dedicata. 

Su Docker Desktop (Windows/Mac), cerca il mount principale del filesystem (di solito /dev/sdf o simile), che contiene i dati della VM di Docker, non riferimenti specifici a /var/lib/docker, poiché Docker gira dentro una macchina virtuale.

Poi, controlla l’esaurimento degli inode usando df -i:

df -iOfferto da

Verifica dell’esaurimento degli inode

Se vedi uso inode al 100% (IUse%) su un filesystem, hai trovato il problema. Questo scenario è sorprendentemente comune su server di build e ambienti CI/CD, dove Docker crea e distrugge ripetutamente container con molti file piccoli.

Analizza l’uso specifico di Docker

Ora che abbiamo stabilito se il problema riguarda lo spazio disco o gli inode, andiamo più a fondo ed esaminiamo il consumo di risorse specifico di Docker. Il comando docker system df fornisce un riepilogo di alto livello valido in tutte le installazioni Docker:

docker system dfOfferto da

L’output suddivide l’uso dello spazio in quattro categorie: immagini, container, volumi locali e build cache.

La colonna RECLAIMABLE è particolarmente utile. Mostra quanto spazio puoi recuperare senza influire sui container in esecuzione. È fondamentale capire la differenza tra questi due valori: lo spazio "attivo" è attualmente in uso da container in esecuzione, mentre lo spazio "recuperabile" può essere liberato in sicurezza.

Per dettagli più granulari, aggiungi il flag verbose:

docker system df -vOfferto da

Analisi dell’utilizzo Docker

Questo output dettagliato elenca singolarmente ogni immagine, container e volume con le relative dimensioni, fornendoti la scomposizione granulare necessaria per individuare i maggiori consumatori di spazio. Ecco cosa osservare in ciascuna sezione:

• Images: Mostra la dimensione di ogni immagine e se è attualmente in uso. Cerca immagini grandi non utilizzate o duplicate con tag diversi. Le immagini contrassegnate come "unused" possono essere rimosse in sicurezza senza influire sui container in esecuzione.

• Containers: Visualizza la dimensione del layer scrivibile per ogni container. Se un container arrestato mostra una SIZE significativa, ha scritto dati sul proprio filesystem. La colonna CREATED aiuta a identificare container vecchi che potresti aver dimenticato.

• Volumes: Elenca le dimensioni dei volumi e se sono in uso. I volumi indicati come non in uso sono candidati alla rimozione, ma verifica sempre che non contengano dati importanti prima del pruning.

• Build Cache: Spesso il maggiore consumatore e frequentemente trascurato. Si tratta di layer intermedi delle operazioni docker build che Docker conserva per velocizzare le build successive.

Comandi specifici per OS

Per chi usa Linux nativamente e vuole approfondire ulteriormente il filesystem, puoi facoltativamente esaminare direttamente le sottodirectory per mostrare quali sottodirectory (overlay2, containers, volumes) consumano più spazio:

sudo du -h --max-depth=1 /var/lib/docker | sort -hOfferto da

Tuttavia, per gli utenti Docker Desktop, /var/lib/docker si trova all’interno della VM nascosta di Docker e non è direttamente accessibile. La buona notizia è che docker system df -v fornisce tutte le informazioni operative necessarie, indipendentemente dalla piattaforma, rendendolo l’approccio diagnostico più affidabile.

Passo 2: Pulisci il sistema con Docker Prune 

Dopo aver identificato dove viene consumato lo spazio, posso recuperarlo in sicurezza usando i comandi di pruning integrati in Docker. Queste operazioni sono progettate per rimuovere solo le risorse non utilizzate, riducendo al minimo il rischio di interrompere i servizi in esecuzione.

Elimina le risorse dangling

Docker distingue tra risorse "dangling" e "unused". Un’immagine dangling non ha tag né riferimenti da container. Tipicamente è un layer intermedio di una build fallita o superata. Queste sono sempre sicure da rimuovere.

Inizia con il comando prune di base:

docker system pruneOfferto da

Questo rimuove tutti i container inutilizzati, le reti e le immagini dangling. Non tocca le immagini con tag o i volumi a meno che non sia specificato esplicitamente. Docker chiederà conferma prima di procedere.

Per essere più aggressivo e rimuovere tutte le immagini non utilizzate (non solo quelle dangling), aggiungi il flag --all:

docker system prune --allOfferto da

Docker system prune

Questo comando rimuove qualsiasi immagine non attualmente associata a un container. Fai attenzione: i deployment successivi dovranno riscaricare le immagini rimosse.

Se vuoi includere i volumi nella pulizia (che contengono dati persistenti), aggiungi il flag --volumes:

docker system prune --all --volumesOfferto da

Attenzione: Questo elimina definitivamente i dati nei volumi non utilizzati. Verifica sempre che i volumi non contengano dati importanti prima di usare questo flag.

Gestisci la build cache

Qui le cose si fanno interessanti. La build cache, che memorizza i layer intermedi delle operazioni di build di Docker, è spesso il maggiore consumatore di spazio, eppure docker system prune la esclude deliberatamente per preservare le prestazioni delle build.

Per colpire specificamente la build cache:

docker builder pruneOfferto da

Se vuoi essere selettivo e conservare i layer recenti, usa filtri basati sul tempo:

docker builder prune --filter "until=24h"Offerto da

Questo rimuove solo i layer di cache più vecchi di 24 ore, mantenendo intatto il lavoro recente.

Pulisci i volumi in sicurezza

I volumi richiedono particolare cautela perché contengono dati persistenti, come database, file caricati e stato dell’applicazione. Rimuovere il volume sbagliato significa perdita permanente dei dati.

Per prima cosa, identifica i volumi dangling (non collegati ad alcun container):

docker volume ls -f dangling=trueOfferto da

Esamina attentamente l’elenco. Se sei certo che questi volumi non servano, eliminali:

docker volume pruneOfferto da

Docker chiederà conferma prima di procedere. In caso di dubbio, esegui un backup dei volumi prima del pruning.

Passo 3: Gestisci l’esaurimento dei file di log Docker

I log dei container possono consumare silenziosamente enormi quantità di spazio su disco, talvolta superando i 50 GB per container.

Identifica i file di log gonfiati

Il logging driver predefinito json-file di Docker cattura tutto lo stdout e lo stderr dei container in file JSON. Senza un’impostazione di dimensione massima (il default è -1, illimitato), questi file crescono senza controllo.

Controlla le dimensioni dei container in tutti gli ambienti:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"Offerto da

Per controllare la dimensione del file di log di un container specifico:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)Offerto da

Solo per Linux nativo, trova direttamente i file di log più grandi:

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

Se docker logs diventa lento o i container non si avviano, è probabile che la causa siano log troppo grandi. Per risolvere, puoi troncarli.

Tronca i log in sicurezza

Troncare i log libera spazio. Tuttavia, non eliminare mai i file di log con rm mentre i container sono in esecuzione. Il demone Docker mantiene aperti gli handle verso questi log e, eliminandoli, si creano file "eliminati ma aperti" che continuano a occupare spazio finché il demone non viene riavviato.

L’approccio sicuro è troncarli a zero:

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

Questo libera spazio immediatamente senza interrompere gli handle. Il container continua a scrivere sullo stesso file.

Passo 4: Troubleshooting avanzato e problemi nascosti

Quando la pulizia standard non basta, è probabile che tu stia affrontando uno di questi problemi meno comuni ma altrettanto impattanti:

• Esaurimento degli inode: Il filesystem ha esaurito le strutture di metadati dei file nonostante lo spazio disco libero

• File eliminati ma aperti: Processi che mantengono handle su file eliminati, creando un uso di spazio "fantasma"

• Gonfiore del disco virtuale di Docker Desktop: Il file .raw o .vhdx dell’host non si riduce dopo che hai eliminato dati all’interno della VM

Affrontiamo ognuno di questi scenari in modo sistematico.

Risolvi l’esaurimento degli inode

Può essere causato da applicazioni che creano milioni di piccoli file, come sessioni PHP, node_modules di npm o artefatti di build che consumano inode a ritmi allarmanti.

Per prima cosa, verifica l’esaurimento degli inode:

df -iOfferto da

Usando i comandi Docker (tutti gli ambienti):

docker ps -a | wc -l             # Conta i container
docker images | wc -l         # Conta le immagini
docker image prune -a      # Rimuovi le immagini inutilizzate per liberare inodeOfferto da

Per installazioni Linux, identifica le directory ricche di inode:

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

Rimuovere le immagini non utilizzate con docker rmi libera anche inode. Per problemi a livello applicativo, implementa la pulizia all’interno dei container o usa mount di volumi per i file temporanei.

Gestisci i file eliminati ma aperti (solo Linux)

Quando un file viene eliminato mentre un processo lo ha ancora aperto, il filesystem non rilascia lo spazio finché il processo non chiude l’handle (uso di spazio "fantasma").

Su Linux puoi verificare se sta accadendo cercando voci "deleted" nell’elenco dei file aperti.

Per prima cosa, identifica questi file:

sudo lsof | grep deleted Offerto da

File Docker eliminati

Quindi, per rilasciare spazio, riavvia il processo specifico (usando il PID da lsof) o riavvia Docker. Dopo averlo fatto, rieseguendo il comando i file non compariranno più, segno che sono stati rimossi correttamente.

Vediamo ora l’ultima strategia avanzata di troubleshooting, applicabile solo a Docker Desktop: la gestione dei dischi virtuali.

Gestione dei dischi virtuali di Docker Desktop

Docker Desktop memorizza i dati in un file disco virtuale (.raw su Mac, .vhdx su Windows) che cresce dinamicamente ma non si riduce automaticamente quando elimini dati. Pulisci immagini e container, vedi lo spazio libero crescere dentro la VM, ma il disco dell’host resta pieno.

Per gestirlo, l’approccio più sicuro è usare fstrim per compattare il disco senza perdere dati:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /Offerto da

Questo comando esegue il trim del filesystem della VM di Docker Desktop, rilasciando i blocchi inutilizzati al sistema host. Le tue immagini, i container e i volumi restano intatti.

In alternativa, se vuoi ripartire da zero (questo elimina tutti i dati), usa Docker Desktop Settings → Troubleshoot → Reset to factory defaults. 

Attenzione: Questa operazione è distruttiva e rimuove tutte le immagini, i container, i volumi e le impostazioni. Dovrebbe essere l’ultima opzione, solo se tutto il resto fallisce.

Ripristina impostazioni predefinite

Passo 5: Previeni l’errore Docker “No Space Left on Device”

Ora che abbiamo risolto l’emergenza, implementiamo cambiamenti strutturali per prevenirne la ricomparsa. Queste configurazioni richiedono pianificazione ma ripagano ampiamente in termini di stabilità del sistema.

Sposta la directory root di Docker (solo Linux)

Gli utenti di Docker Desktop non possono cambiare facilmente la posizione della data root. In alternativa puoi:

• Aumentare lo spazio su disco: Usare i metodi di compattazione del disco descritti nel Passo 4

• Per backend WSL2: Gestire i limiti tramite un file .wslconfig come mostrato in Docker Desktop Settings → Resources

Tuttavia, se sei su Linux e la partizione di root è limitata ma hai a disposizione una partizione più grande (magari un disco dati dedicato), spostare la directory dei dati di Docker è una soluzione definitiva.

Per prima cosa, arresta Docker:

sudo systemctl stop dockerOfferto da

Modifica /etc/docker/daemon.json per specificare la nuova posizione:

{
  "data-root": "/mnt/docker-data"
}Offerto da

Migra i dati esistenti per conservare immagini e container:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/Offerto da

Infine, riavvia Docker:

sudo systemctl start dockerOfferto da

Docker ora memorizza tutti i dati nella nuova posizione. Verifica con docker info | grep "Docker Root Dir" per confermare il percorso della nuova directory.

Configura la rotazione globale dei log

La rotazione dei log è la singola strategia preventiva più efficace che ho implementato. Di default, il driver json-file di Docker ha max-size: -1 (illimitato), una bomba a orologeria in produzione.

Per installazioni Linux native, modifica /etc/docker/daemon.json per imporre limiti globali:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Offerto da

Dopo aver modificato il file, riavvia Docker.

Per gli utenti Docker Desktop, non modificare direttamente /etc/docker/daemon.json. Invece:

1. Apri Docker Desktop
2. Vai su Settings → Docker Engine
3. Vedrai un editor JSON con la configurazione del demone
4. Aggiungi le impostazioni di rotazione dei log al JSON esistente:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Offerto da

Infine, fai clic su Apply & Restart.

Questa configurazione limita ciascun container a tre file di log da 10 MB ciascuno (30 MB totali per container).

Nota critica: queste impostazioni si applicano solo ai container creati dopo la modifica. I container esistenti mantengono la loro configurazione di log originale. Devi ricrearli per applicare i nuovi limiti.

Per una compressione e prestazioni ancora migliori, valuta il logging driver local:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}Offerto da

Inoltre, puoi anche sovrascrivere le impostazioni di log per servizio in docker-compose.yml:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"Offerto da

Automatizza la manutenzione

Un’altra buona pratica è automatizzare alcuni processi. Prevenire è spesso meglio che gestire le emergenze. Perciò ti consiglio di automatizzare la pulizia con un cron job da eseguire durante le finestre di manutenzione:

# Create a cleanup script
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

# Add to crontab to run weekly on Sundays at 2 AM
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -Offerto da

Questo script crea un’attività pianificata che rimuove automaticamente ogni domenica alle 2:00 i container arrestati e i dati non utilizzati. Inoltre, pulisce in sicurezza i layer della build cache più vecchi di una settimana (168 ore) per evitare che l’uso del disco cresca indefinitamente.

In aggiunta, ottimizza i tuoi Dockerfile usando le build multi-stage per ridurre al minimo le dimensioni delle immagini. Le build multi-stage ti permettono di usare uno stage per compilare e costruire (con tutti gli strumenti di sviluppo pesanti) e poi copiare solo gli artefatti finali in uno stage di produzione pulito e minimale. 

Questo elimina dipendenze di build, codice sorgente e file intermedi dall’immagine finale, riducendone sensibilmente dimensioni e superficie d’attacco.

# 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"]Offerto da

Questo pattern riduce la dimensione dell’immagine di produzione escludendo strumenti di build e codice sorgente.

Conclusione

La risoluzione dell’errore "no space left on device" segue uno schema prevedibile: prima diagnostica per capire se stai affrontando blocchi disco o inode, poi effettua pruning in sicurezza per recuperare spazio senza perdita di dati, quindi ottimizza la configurazione per prevenire ricorrenze.

Negli anni passati a gestire ambienti Docker, ho imparato che la rotazione dei log è la singola strategia preventiva più efficace. Una semplice configurazione di daemon.json può evitare la maggior parte degli incidenti di esaurimento dello spazio.

Ti invito a controllare ora la configurazione di daemon.json. Se non hai impostato max-size e max-file per il logging driver, aggiungili subito. Mi ringrazierai quando eviterai la prossima crisi di spazio.

Pronto a diventare un pro di Docker? Il passo successivo è iscriverti al nostro skill track Containerization and Virtualization with Docker and Kubernetes, che consiglio vivamente.