Wenn ZimaOS Files Loading error anzeigt, der Windows-SMB-Zugriff aber weiterhin funktioniert, sollten Sie nicht sofort davon ausgehen, dass das RAID oder die Daten verschwunden sind. Das war das Muster in diesem Thread vom Februar 2026: Die Files-Benutzeroberfläche fiel nach dem Update auf 1.5.4 aus, während andere Apps und der Samba-Dateizugriff weiterhin funktionierten.
Mitarbeiter von IceWhale nannten später die wichtigste Ursache. raller1028 erklärte, dass der Files-Dienst in ZimaOS 1.5.4 nicht mehr korrekt funktionieren kann, wenn die Systemfestplatte voll ist. Die offizielle Wiederherstellung bestand darin, Speicherplatz auf der Systemfestplatte freizugeben und icewhale-files neu zu starten. Eine separate, von der Community vorgeschlagene Umbenennung der Datenbank half mehreren Benutzern, wurde von IceWhale jedoch nicht als erste Maßnahme empfohlen.
Funktionierendes SMB ist ein starkes Indiz dafür, dass Daten und Einbindungen noch vorhanden sind
Der ursprüngliche Verfasser konnte weiterhin über eine Windows-Samba-Freigabe auf die Dateien zugreifen. Das bedeutet, dass der Host-Speicher und der Datenpfad aktiv waren, auch wenn die Files-Webanwendung die Daten nicht darstellen konnte.
Dies ist ein wichtiger Unterschied zwischen:
- Speicher- oder Datenverlust;
- einem Ausfall des Files-Dienstes;
- einem Browser- oder UI-Fehler.
Files ist kein normaler Docker-Container aus dem App Store
Daher ist es erwartungsgemäß, dass docker ps keinen Files-Container anzeigt. Das Neustarten beliebiger Docker-Container wird den nativen Files-Dienst nicht reparieren.
IceWhale identifizierte vollen Systemspeicher als Auslöser in Version 1.5.4
Am 26. Februar schrieb raller1028 von IceWhale, dass das Problem in Version 1.5.4 „durch eine volle Systemfestplatte verursacht sein sollte“.
Die offizielle Wiederherstellungssequenz lautete:
- über die Befehlszeile etwas Speicherplatz auf der Systemfestplatte freigeben;
- den Files-Dienst neu starten:
systemctl restart icewhale-filesBenutzern, die mit der Bereinigung über die Befehlszeile nicht vertraut waren, wurde geraten, den Support zu kontaktieren, anstatt wahllos Dateien zu löschen.
Warum eine volle Systemfestplatte Files beeinträchtigen kann, während SMB weiterhin funktioniert
Native Dienste benötigen freien Speicherplatz für Datenbanken, Statusdaten, temporäre Dateien, Protokolle oder Dienstvorgänge. Die großen Benutzerdaten können auf einem anderen Speicher-Array intakt bleiben, während eine kleine Systempartition 100 % Auslastung erreicht und dadurch einen dienstspezifischen Fehler verursacht.
Deshalb reicht es nicht aus, lediglich zu prüfen, ob „mein RAID noch freien Speicherplatz hat“.
Halten Sie wachsende App-Daten von der Systemfestplatte fern
Die aktuelle ZimaOS-Dokumentation empfiehlt, Anwendungsdaten in einem echten Speicherbereich abzulegen, anstatt Docker-Datenbanken, Vorschaubilder und Caches die Systemfestplatte füllen zu lassen.
Nutzen Sie die aktuelle Anleitung zur App-Speicherung von ZimaOS, um eine andere Ursache für eine hohe Auslastung der Systemfestplatte zu vermeiden.
Das Umbenennen von files.db durch die Community funktionierte bei mehreren Benutzern
Ein Benutzer aus der Community veröffentlichte später:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesMehrere Teilnehmer antworteten, dass Files dadurch wiederhergestellt wurde.
Dies sollte dennoch als sekundärer Wiederherstellungsweg aus der Community betrachtet werden. Mitarbeiter von IceWhale fragten umgehend nach der Bedeutung des Entfernens der Files-Datenbank und ersetzten die offizielle Empfehlung „Systemspeicher freigeben und Dienst neu starten“ nicht durch diesen Befehl.
Das Umbenennen einer Datenbank ist sicherer als das Löschen, verändert aber weiterhin den Anwendungsstatus
Der Befehl aus der Community behält eine .bak-Kopie, anstatt die Datenbank zu löschen. Das ist für ein Zurücksetzen sicherer, aber durch die Neuerstellung der Files-Datenbank können sich indizierte Metadaten oder andere Statusdaten des Dienstes ändern.
Verwenden Sie diesen Schritt nicht als erste Maßnahme, wenn die Systemfestplatte einfach nur voll ist.
Gehen Sie nicht davon aus, dass der Fehler aus Version 1.5.4 in aktuellen ZimaOS-Versionen weiterhin besteht
Das aktuelle ZimaOS ist Version 1.7.x und erhält weiterhin Fehlerbehebungen für Files, Speicher, Arbeitsspeicher, Sicherheit und Anwendungsspeicher. Das historische Problem ist hilfreich, weil es zeigt, wie man einen Dienstausfall von Datenverlust unterscheidet, nicht weil jeder moderne Files-Fehler dieselbe Ursache hat.
Wenn das Problem heute erneut auftritt, erfassen Sie zunächst den aktuell freien Speicherplatz des Systems, die aktuelle Version, den Dienststatus und die Information, ob SMB oder ein anderer Dateizugriff weiterhin funktioniert.
Geben Sie Speicherplatz gezielt frei
Führen Sie keine umfassenden Bereinigungsskripte für unbekannte Systemverzeichnisse aus. Ermitteln Sie große App-Caches, Docker-Daten, Sicherungen oder Protokolle und verwenden Sie nach Möglichkeit die aktuellen Bereinigungs- und Migrationsfunktionen von ZimaOS.
FAQ: Files zeigt „Loading error“ an
Funktionierte SMB im ursprünglichen Fall weiterhin?
Ja. Das deutete stark darauf hin, dass die Daten und Einbindungen weiterhin vorhanden waren.
Was identifizierten die Mitarbeiter von IceWhale als Problem in Version 1.5.4?
Eine volle Systemfestplatte, durch die der Files-Dienst nicht mehr korrekt funktionierte.
Wie lautete der offizielle Befehl zum Neustarten des Dienstes?
systemctl restart icewhale-files.
War das Umbenennen von files.db eine offizielle Empfehlung als erste Maßnahme?
Nein. Es war ein Workaround aus der Community, den mehrere Benutzer bestätigten, während IceWhale als erste Maßnahme empfahl, Speicherplatz freizugeben und den Files-Dienst neu zu starten.
