Quando ZimaOS Files mostra Error Loading ma l’accesso SMB da Windows continua a funzionare, non presumere subito che il RAID o i dati siano scomparsi. Questo è stato lo schema osservato nella discussione di febbraio 2026: l’interfaccia Files ha smesso di funzionare dopo l’aggiornamento alla versione 1.5.4, mentre le altre app e l’accesso ai file tramite Samba continuavano a funzionare.
In seguito, il personale di IceWhale ha fornito l’informazione più importante sulla causa. raller1028 ha spiegato che, in ZimaOS 1.5.4, quando il disco di sistema è pieno, il servizio Files può smettere di funzionare correttamente. Il ripristino ufficiale consisteva nel liberare spazio sul disco di sistema e riavviare icewhale-files. Una procedura alternativa della community, basata sulla ridenominazione del database, ha aiutato diversi utenti, ma IceWhale non l’ha indicata come soluzione prioritaria.
Se SMB funziona, è una forte indicazione che dati e mount siano ancora presenti
L’autore del post originale riusciva ancora ad accedere ai file tramite una condivisione Samba di Windows. Ciò significa che lo storage dell’host e il percorso dei dati erano attivi, anche se l’applicazione web Files non riusciva a visualizzarli.
È importante distinguere tra:
- perdita di dati o dello storage;
- errore del servizio Files;
- errore del browser o dell’interfaccia.
Files non è un normale container Docker dell’App Store
Di conseguenza, è normale che docker ps non mostri un container Files. Riavviare container Docker casuali non riparerà il servizio Files nativo.
IceWhale ha identificato nello spazio di sistema esaurito la causa del problema in 1.5.4
Il 26 febbraio, raller1028 di IceWhale ha scritto che il problema “dovrebbe essere” causato dal disco di sistema pieno nella versione 1.5.4.
La procedura ufficiale di ripristino era:
- liberare spazio sul disco di sistema tramite la riga di comando;
- riavviare il servizio Files:
systemctl restart icewhale-filesAgli utenti che non conoscevano le procedure di pulizia dalla riga di comando è stato consigliato di contattare l’assistenza invece di eliminare file alla cieca.
Perché un disco di sistema pieno può bloccare Files mentre SMB continua a funzionare
I servizi nativi hanno bisogno di spazio operativo per database, stato, file temporanei, log e altre operazioni. I dati utente di grandi dimensioni possono rimanere intatti su un altro array di storage, mentre una piccola partizione di sistema raggiunge il 100% di utilizzo e causa un errore specifico del servizio.
Per questo, controllare soltanto che “il mio RAID abbia spazio libero” non è sufficiente.
Mantieni i dati delle app in crescita fuori dal disco di sistema
La documentazione attuale di ZimaOS consiglia di spostare i dati delle applicazioni in uno spazio di archiviazione reale, invece di lasciare che database Docker, miniature e cache riempiano il disco di sistema.
Consulta le indicazioni attuali di ZimaOS per lo storage delle app per prevenire un’altra fonte di pressione sul disco di sistema.
La ridenominazione di files.db proposta dalla community ha funzionato per diversi utenti
In seguito, un utente della community ha pubblicato:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesDiversi partecipanti hanno risposto che questa procedura aveva ripristinato Files.
Questa procedura dovrebbe comunque essere considerata una soluzione secondaria proposta dalla community. Il personale di IceWhale ha chiesto immediatamente quale fosse il significato della rimozione del database Files e non ha sostituito le indicazioni ufficiali “libera spazio sul sistema e riavvia il servizio” con questo comando.
Rinominare un database è più sicuro che eliminarlo, ma modifica comunque lo stato dell’applicazione
Il comando della community conserva una copia .bak invece di eliminare il database. È una scelta migliore per poter tornare indietro, ma la ricostruzione del database Files può modificare i metadati indicizzati o altri dati di stato del servizio.
Non usarlo come prima operazione quando il problema è semplicemente il disco di sistema pieno.
Non presumere che il bug della versione 1.5.4 esista ancora nelle versioni attuali di ZimaOS
La versione attuale di ZimaOS è la 1.7.x e continua a ricevere correzioni per Files, storage, memoria, sicurezza e gestione dello spazio delle applicazioni. Questo problema storico è utile perché insegna a distinguere un errore del servizio dalla perdita di dati, non perché ogni errore moderno di Files abbia la stessa causa.
Se il problema si ripresenta oggi, raccogli innanzitutto informazioni sullo spazio libero attuale del sistema, sulla versione corrente, sullo stato del servizio e sul fatto che SMB o altri metodi di accesso ai file continuino a funzionare.
Libera spazio con attenzione
Non eseguire script di pulizia generici su directory di sistema sconosciute. Individua le cache delle app, i dati Docker, i backup o i log di grandi dimensioni e, quando possibile, utilizza gli strumenti di pulizia o migrazione disponibili in ZimaOS.
Domande frequenti sull’errore Loading di Files
Nel caso descritto SMB continuava a funzionare?
Sì, il che suggeriva fortemente che i dati e i mount fossero ancora presenti.
Quale problema della versione 1.5.4 ha identificato il personale di IceWhale?
Un disco di sistema pieno che impediva al servizio Files di funzionare correttamente.
Qual era il comando ufficiale per riavviare il servizio?
systemctl restart icewhale-files.
La ridenominazione di files.db era la procedura ufficiale prioritaria?
No. Era una soluzione alternativa della community confermata da diversi utenti, mentre le indicazioni prioritarie di IceWhale consistevano nel liberare spazio e riavviare il servizio Files.
