När ZimaOS Files visar Loading error men SMB-åtkomst från Windows fortfarande fungerar ska du inte omedelbart anta att RAID-enheten eller data har försvunnit. Det var mönstret i den här tråden från februari 2026: Files-gränssnittet slutade fungera efter uppdateringen till 1.5.4, medan andra appar och Samba-filåtkomst fortfarande fungerade.
IceWhale-personal angav senare den viktigaste avgränsningen för grundorsaken. raller1028 sade att Files-tjänsten i ZimaOS 1.5.4 kan sluta fungera korrekt när systemdisken är full. Den officiella återställningen var att frigöra utrymme på systemdisken och starta om icewhale-files. En separat lösning från communityn, där databasen byttes namn, hjälpte flera användare, men IceWhale presenterade inte detta som den första åtgärden.
Fungerande SMB är starka bevis på att data och monteringar fortfarande finns
Den ursprungliga skribenten kunde fortfarande komma åt filerna via en Windows-Samba-delning. Det innebär att värdlagringen och datasökvägen fortfarande fungerade, även om Files-webbappen inte kunde visa dem.
Detta är en viktig skillnad mellan:
- förlust av lagring/data;
- fel i Files-tjänsten;
- fel i webbläsaren/gränssnittet.
Files är inte en vanlig Docker-container i App Store
Därför är det förväntat att docker ps inte visar någon Files-container. Att starta om slumpmässiga Docker-containrar kommer inte att reparera den inbyggda Files-tjänsten.
IceWhale identifierade fullt systemlagringsutrymme som utlösaren i 1.5.4
Den 26 februari skrev raller1028 från IceWhale att problemet i version 1.5.4 “bör” bero på att systemdisken är full.
Den officiella återställningssekvensen var:
- frigör utrymme på systemdisken via kommandoraden;
- starta om Files-tjänsten:
systemctl restart icewhale-filesAnvändare som inte var vana vid rensning via kommandoraden uppmanades att kontakta supporten i stället för att radera filer på måfå.
Varför en full systemdisk kan få Files att sluta fungera medan SMB fortfarande fungerar
Inbyggda tjänster behöver fungerande utrymme för databaser, tillstånd, temporära filer, loggar och tjänsteåtgärder. Stora mängder användardata kan vara intakta på en annan lagringsarray samtidigt som en liten systempartition når 100 procents användning och orsakar ett tjänstespecifikt fel.
Därför räcker det inte att bara kontrollera att “min RAID-enhet har ledigt utrymme”.
Håll växande appdata borta från systemdisken
Aktuell dokumentation för ZimaOS rekommenderar att appdata flyttas till ett riktigt lagringsutrymme i stället för att Docker-databaser, miniatyrbilder och cachefiler får fylla systemdisken.
Använd den aktuella vägledningen för applagring i ZimaOS för att förebygga en annan källa till belastning på systemdisken.
Communityns namnbyte av files.db fungerade för flera användare
En användare i communityn publicerade senare:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesFlera deltagare svarade att detta återställde Files.
Det bör ändå betraktas som en sekundär återställningsmetod från communityn. IceWhale-personal frågade direkt vad syftet med att ta bort Files-databasen var och ersatte inte den officiella vägledningen “frigör systemutrymme + starta om tjänsten” med detta kommando.
Att byta namn på en databas är säkrare än att radera den, men ändrar fortfarande appens tillstånd
Community-kommandot behåller en .bak-kopia i stället för att radera databasen. Det är bättre för återställning, men en ombyggnad av Files-databasen kan ändra indexerade metadata eller annat tillstånd för tjänsten.
Använd inte detta som första åtgärd när systemdisken helt enkelt är full.
Anta inte att felet i 1.5.4 finns kvar i aktuell version av ZimaOS
Aktuell version av ZimaOS är 1.7.x och har fortsatt att få korrigeringar för Files, lagring, minne, säkerhet och applagring. Det historiska problemet är användbart eftersom det visar hur man skiljer ett tjänstefel från dataförlust, inte för att alla moderna Files-fel har samma orsak.
Om problemet uppstår igen i dag bör du först samla in information om aktuellt ledigt systemutrymme, aktuell version, tjänstens status och om SMB eller annan filåtkomst fortfarande fungerar.
Frigör utrymme med eftertanke
Kör inte breda rensningsskript mot okända systemkataloger. Identifiera stora appcachefiler, Docker-data, säkerhetskopior eller loggar och använd aktuella rensnings- och migreringskontroller i ZimaOS när det är möjligt.
Vanliga frågor om felet Loading error i Files
Fungerade SMB fortfarande i det ursprungliga fallet?
Ja, vilket starkt tydde på att data och monteringar fortfarande fanns.
Vad identifierade IceWhale-personalen som problemet i 1.5.4?
En full systemdisk som gjorde att Files-tjänsten slutade fungera korrekt.
Vilket kommando för att starta om tjänsten var officiellt?
systemctl restart icewhale-files.
Var namnbytet av files.db den officiella första åtgärden?
Nej. Det var en lösning från communityn som flera användare bekräftade, medan IceWhales första rekommendation var att frigöra utrymme och starta om Files-tjänsten.
