Come risolvere "No space left on device" su Linux

La tua applicazione non riesce a caricare file, gli aggiornamenti si interrompono a metà e il sistema Linux restituisce l'errore: No space left on device.

In breve: L'errore No space left on device su Linux indica che il server non è in grado di scrivere nuovi dati nella destinazione richiesta. La causa principale è solitamente la saturazione dello spazio su disco, ma può anche essere dovuta all'esaurimento degli inode (le strutture dati con cui il sistema tiene traccia dei singoli file). Per risolvere il problema occorre identificare le risorse che occupano memoria, rimuovere in sicurezza file temporanei o log obsoleti e pianificare una gestione preventiva per evitare il ripetersi del blocco.

Cosa significa "No space left on device" su Linux?

L'archiviazione del server può essere paragonata a un magazzino logistico.

La causa più comune dell'errore è il riempimento fisico dello spazio disponibile: file di log voluminosi, backup, caricamenti utente, pacchetti di cache, file di database, vecchie build di deploy o dati accumulati da Docker possono occupare l'intero disco.

Esiste tuttavia un secondo fattore critico in ambiente Linux: gli inode. Un inode è la struttura dati che memorizza i metadati di ciascun file. Anche un file privo di contenuto richiede un inode dedicato. Qualora un'applicazione generi milioni di file di ridotte dimensioni (come cache o sessioni), il sistema può esaurire la tabella degli inode pur mantenendo ancora gigabyte di spazio fisico libero. La conseguenza sarà la medesima: l'impossibilità di scrivere dati e l'uscita dell'errore No space left on device.

Quando si riscontra questo errore, occorre verificare due scenari distinti:

• Lo spazio di archiviazione su disco è esaurito?
• È stato raggiunto il limite massimo del numero di inode (file)?

Entrambe le condizioni bloccano le operazioni di scrittura, compromettendo i caricamenti dei file, i deployment, l'installazione dei pacchetti software, le transazioni sul database e la gestione delle sessioni di autenticazione.

Come identificare l'origine della saturazione del disco

La fase diagnostica richiede una verifica strutturata dell'infrastruttura prima di procedere a qualsiasi eliminazione.

Lo strumento di analisi primario è il comando df -h, che mostra lo stato di occupazione dei filesystem montati con valori formattati per la lettura. Se il punto di montaggio principale (/) risulta al 100%, il disco di sistema è completamente saturo. Se l'esaurimento riguarda directory specifiche (come /var o /home), l'origine del problema è localizzata.

Occorre poi verificare il consumo degli inode tramite il comando df -i. Qualora l'utilizzo degli inode raggiunga il 100%, la causa risiede nell'eccessivo numero di file memorizzati anziché nella dimensione complessiva in gigabyte.

Per individuare quali directory occupino il maggior spazio, si utilizza il comando du -h --max-depth=1 /var. Questo comando permette di analizzare progressivamente le sottodirectory per isolare le cartelle critiche.

Le posizioni più soggette a saturazione includono:

• /var/log: log di sistema o applicativi non sottoposti a rotazione;
• /var/lib/docker: immagini, container non attivi o log dei container accumulati nel tempo;
• /tmp: file temporanei di sistema o applicativi non eliminati correttamente;
• Directory degli upload applicativi: file multimediali, documenti ed esportazioni;
• Directory dei backup: in particolare se salvati sullo stesso disco da proteggere;
• Directory dei database: se conservano volumi di dati elevati senza manutenzione.

Se il server evidenzia contemporaneamente un degrado delle prestazioni, la saturazione del disco potrebbe rappresentare l'elemento scatenante. Per un approfondimento diagnostico, consulta la nostra guida su perché il tuo server è lento.

Quali elementi è possibile rimuovere in sicurezza?

In fase di emergenza è fondamentale evitare la cancellazione indiscriminata di risorse per non rischiare di compromettere l'operatività del sistema.

Le prime operazioni di pulizia dovrebbero riguardare:

• Log obsoleti e compressi: i file di log archiviati possono essere rimossi se non necessari ai fini di audit o diagnosi;
• File temporanei: la cartella /tmp contiene file di sessione o di sistema eliminabili, assicurandosi di non rimuovere file legati a processi in esecuzione;
• Cache dei gestori pacchetti: gli archivi dei pacchetti scaricati (es. apt o yum) possono essere puliti in quanto ri-scaricabili all'occorrenza;
• Risorse Docker non utilizzate: immagini pendenti (dangling images), container arrestati, cache di build ed eventuali log dei container possono essere eliminati tramite i comandi dedicati di pulizia dell'ambiente Docker.

È necessario procedere con la massima cautela e non eliminare mai le seguenti risorse:

• File di database;
• File di configurazione applicativa e di sistema (directory /etc);
• Caricamenti e contenuti generati dagli utenti;
• Directory relative alle release attive dell'applicazione;
• Risorse non identificate o non documentate.

Se la saturazione del disco è causata dalla presenza dei backup locali, è opportuno rivedere la strategia di disaster recovery. I backup devono risiedere su un'infrastruttura separata per non compromettere la stabilità del server principale. Per definire una strategia adeguata, consulta la guida su come fare il backup del tuo server — e riuscire davvero a ripristinarlo.

Se il problema si ripresenta frequentemente, il server potrebbe necessitare di un upgrade delle risorse hardware. La quota di disco non è destinata al solo codice applicativo, ma deve prevedere un margine operativo per log, database, caricamenti e aggiornamenti di sistema. Per comprendere i criteri di dimensionamento, ti consigliamo di leggere che dimensione di server ti serve.

FAQ

**Perché Linux mostra No space left on device anche se è presente spazio libero?** La causa potrebbe essere l'esaurimento degli inode. È possibile verificare l'utilizzo degli inode tramite il comando df -i. La presenza di un numero elevato di file di piccole dimensioni impedisce la creazione di nuove risorse anche in presenza di megabyte o gigabyte liberi.

È consigliabile riavviare un server quando il disco è saturo? Non sempre. Il riavvio del sistema con un disco saturo può impedire il corretto avvio dei servizi o del sistema operativo, qualora i processi necessitino di scrivere file temporanei, file di lock o log durante la fase di boot.

Aumentare la dimensione del disco risolve definitivamente il problema? Espandere lo storage incrementa la capacità complessiva, ma non risolve le cause sottostanti legate a processi che generano dati in modo incontrollato. È fondamentale identificare l'origine della crescita dei dati prima di procedere a un upgrade hardware.

Quali directory non devono mai essere eliminate manualmente? Non si devono mai rimuovere manualmente i file dei database, la configurazione di sistema (/etc), i caricamenti degli utenti o i file applicativi senza aver identificato preventivamente la loro funzione e struttura.

La soluzione intermedia

Server Manager consente di mantenere una struttura dell'infrastruttura chiara e documentata, facilitando l'individuazione della distribuzione dei dati sullo storage anche a distanza di tempo.

Questo approccio previene l'insorgere di criticità tipiche, quali log non monitorati, backup locali accumulati sul disco principale, build obsolete non rimosse o conflitti di risorse tra progetti diversi ospitati sulla stessa macchina.

Server Manager preserva la tracciabilità delle configurazioni nel tempo, rendendo le operazioni di manutenzione e pulizia dell'infrastruttura veloci, sicure e prive di incertezze.

Risolta l'emergenza iniziale, è consigliabile implementare procedure preventive trasparenti: trasferire i backup su storage esterni, configurare la rotazione automatica dei file di log (logrotate) e riservare un margine adeguato di spazio su disco per l'operatività del sistema.