Wanneer ZimaOS Files Error Loading weergeeft, maar SMB-toegang vanuit Windows nog steeds werkt, moet je niet meteen aannemen dat de RAID of gegevens zijn verdwenen. Dat was het patroon in deze thread uit februari 2026: de Files-interface werkte niet meer na de update naar 1.5.4, terwijl andere apps en bestandstoegang via Samba bleven werken.
Medewerkers van IceWhale gaven later de belangrijkste afbakening van de hoofdoorzaak. raller1028 zei dat in ZimaOS 1.5.4 de Files-service niet goed meer kan werken wanneer de systeemschijf vol is. De officiële herstelprocedure was ruimte vrijmaken op de systeemschijf en icewhale-files opnieuw starten. Een aparte workaround uit de community, waarbij de database wordt hernoemd, hielp meerdere gebruikers, maar IceWhale presenteerde die niet als eerste oplossing.
Werkende SMB is sterk bewijs dat de gegevens en koppelingen nog bestaan
De oorspronkelijke melder kon nog steeds via een Windows-Samba-share bij de bestanden. Dat betekent dat de opslag en het gegevenspad van de host nog actief waren, ook al kon de Files-webapp de bestanden niet weergeven.
Dit is een belangrijk onderscheid tussen:
- verlies van opslag of gegevens;
- een defecte Files-service;
- een browser- of interfaceprobleem.
Files is geen normale Docker-container uit de App Store
Daarom is het normaal dat docker ps geen Files-container toont. Het opnieuw starten van willekeurige Docker-containers herstelt de native Files-service niet.
IceWhale wees volledige systeemopslag aan als oorzaak in 1.5.4
Op 26 februari schreef raller1028 van IceWhale dat het probleem in versie 1.5.4 “waarschijnlijk” werd veroorzaakt doordat de systeemschijf vol was.
De officiële herstelprocedure was:
- maak via de opdrachtregel wat ruimte vrij op de systeemschijf;
- start de Files-service opnieuw:
systemctl restart icewhale-filesGebruikers die niet vertrouwd waren met opruimen via de opdrachtregel kregen het advies contact op te nemen met de ondersteuning in plaats van blind bestanden te verwijderen.
Waarom een volle systeemschijf Files kan laten uitvallen terwijl SMB blijft werken
Native services hebben werkruimte nodig voor databases, statusgegevens, tijdelijke bestanden, logboeken en servicebewerkingen. De grote hoeveelheid gebruikersgegevens kan intact blijven op een andere opslagarray, terwijl een kleine systeempartitie 100% vol raakt en een specifieke service laat uitvallen.
Daarom is alleen controleren of “mijn RAID nog vrije ruimte heeft” niet voldoende.
Houd groeiende appgegevens weg van de systeemschijf
De huidige ZimaOS-documentatie adviseert om applicatiegegevens naar een echte opslagruimte te verplaatsen, in plaats van Docker-databases, miniaturen en caches de systeemschijf te laten vullen.
Gebruik de huidige richtlijnen voor app-opslag in ZimaOS om een andere oorzaak van druk op de systeemschijf te voorkomen.
Het hernoemen van files.db uit de community werkte voor meerdere gebruikers
Een gebruiker uit de community plaatste later:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesVerschillende deelnemers antwoordden dat Files daarna weer werkte.
Dit moet nog steeds worden beschouwd als een secundaire herstelmethode uit de community. Medewerkers van IceWhale vroegen direct wat het belang was van het verwijderen van de Files-database en vervingen de officiële richtlijn “maak ruimte vrij op de systeemschijf en start de service opnieuw” niet door dit commando.
Een database hernoemen is veiliger dan verwijderen, maar verandert nog steeds de applicatiestatus
Het communitycommando bewaart een kopie met de extensie .bak in plaats van de database te wissen. Dat is beter voor terugdraaien, maar het opnieuw opbouwen van de Files-database kan geïndexeerde metagegevens of een andere servicestatus wijzigen.
Gebruik dit niet als eerste actie wanneer de systeemschijf simpelweg vol is.
Ga er niet van uit dat de bug uit 1.5.4 nog aanwezig is in de huidige ZimaOS-versie
De huidige ZimaOS-versie is 1.7.x en krijgt nog steeds verbeteringen voor Files, opslag, geheugen, beveiliging en applicatieopslag. Het historische probleem is nuttig omdat het leert hoe je een servicefout onderscheidt van gegevensverlies, niet omdat elke moderne Files-fout dezelfde oorzaak heeft.
Als het probleem vandaag opnieuw optreedt, leg dan eerst de huidige vrije ruimte op het systeem, de huidige versie, de servicestatus en de vraag vast of SMB of andere bestandstoegang nog werkt.
Maak weloverwogen ruimte vrij
Voer geen algemene opruimscripts uit op onbekende systeemmappen. Zoek grote app-caches, Docker-gegevens, back-ups of logboeken op en gebruik waar mogelijk de huidige opruim- en migratieopties van ZimaOS.
Veelgestelde vragen over de foutmelding ‘Error Loading’ in Files
Werkte SMB nog in de oorspronkelijke situatie?
Ja, wat er sterk op wees dat de gegevens en koppelingen nog aanwezig waren.
Wat identificeerden medewerkers van IceWhale als het probleem in 1.5.4?
Een volle systeemschijf waardoor de Files-service niet meer goed werkte.
Wat was het officiële commando om de service opnieuw te starten?
systemctl restart icewhale-files.
Was het hernoemen van files.db de officiële eerste aanbeveling?
Nee. Het was een workaround uit de community die door meerdere gebruikers werd bevestigd, terwijl de eerste aanbeveling van IceWhale was om ruimte vrij te maken en de Files-service opnieuw te starten.
