L’errore 507 Insufficient Storage indica che il server non dispone dello spazio o della capacità necessaria per memorizzare la rappresentazione richiesta e completare l’operazione. È nato in ambito WebDAV, ma alcune applicazioni lo usano anche per quota, inode o storage temporaneo.
Questa guida approfondisce errore 507 Insufficient Storage con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
Il valore Disk Usage del pannello non è l’unico indicatore: inode, filesystem temporanei, quota database, backup in esecuzione e directory cache possono impedire nuove scritture.
Un 507 non deve essere risolto cancellando file casuali. Prima occorre identificare il filesystem e il percorso che non può crescere.
Come riconoscere il problema
- Upload e salvataggi falliscono.
- Backup o archivi si interrompono.
- Il log mostra no space left on device.
- La quota appare vicina al limite.
- Il problema riguarda WebDAV o una API di storage.
Cause più frequenti
1. Quota disco esaurita
L’account ha raggiunto lo spazio assegnato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. Inode esauriti
Esiste spazio in byte ma non è possibile creare nuovi file. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. Temporanei pieni
Upload, PHP o database non possono usare la directory temporanea. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Backup e cache
Copie locali e file cache occupano gran parte dello storage. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Database o log in crescita
Tabelle, log e sessioni aumentano senza rotazione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Storage remoto o WebDAV
La destinazione applica una quota propria. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Controlla Disk Usage e inode. Registra valori e percorsi principali. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Individua file recenti e grandi. Usa strumenti in sola lettura. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla backup locali. Verifica copie duplicate e incomplete. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Esamina cache e log. Distingui dati rigenerabili da dati necessari. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla directory temporanee. Cerca errori durante upload o estrazione. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Verifica database. Misura tabelle e file di log applicativi. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Conferma chi genera il 507. Applicazione, WebDAV, proxy o server. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Libera spazio identificato. Rimuovi soltanto file confermati e dopo backup. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riduci inode. Elimina cache o sessioni obsolete con procedure supportate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Sposta backup fuori account. Conserva copie su storage dedicato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Configura rotazione log. Mantieni una cronologia proporzionata. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ottimizza cache. Definisci scadenza e pulizia automatica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aumenta il piano se il consumo è strutturale. Non usare pulizie continue come unica strategia. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ritesta l’operazione. Verifica che spazio e inode restino disponibili durante il picco. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- Scritture e upload completano.
- Spazio e inode hanno margine.
- Backup non duplicati.
- Log ruotati.
- Nessun nuovo no space left on device.
Prevenzione
- Monitoraggio quota.
- Backup esterni.
- Rotazione log.
- Pulizia cache.
- Piano dimensionato.
Errori da evitare
- Non cancellare database o uploads casualmente.
- Non rimuovere backup unici.
- Non ignorare inode.
- Non lasciare archivi in public_html.
- Non aumentare la quota senza capire la crescita.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- dominio o servizio
- orario
- quota e inode
- percorso o operazione
- errore completo
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su errore 507 Insufficient Storage
Posso avere spazio libero ma ricevere 507?
Sì, se sono esauriti inode o una directory temporanea.
Il 507 è uguale al 413?
No. Il 413 riguarda una richiesta troppo grande; il 507 la capacità di memorizzarla.
La cache può causarlo?
Sì, se cresce senza limiti.
Devo cancellare i backup?
Solo dopo aver verificato che esistano copie valide altrove.
Quando serve un upgrade del piano?
Quando il consumo normale e necessario supera stabilmente la capacità disponibile.