ZimaOS saknar diskutrymme: Hitta lokala data som döljs under monteringspunkter för säkerhetskopiering och SMB

Disk-usage tools can be misleading on a NAS because a directory may be either ordinary local storage or the place where another filesystem is mounted. This January 2026 thread began with a 1 TB ZimaOS drive showing roughly 915 GB used even though the user believed only about 450 GB of media existed. The first assumption was Docker cache. The command output instead pointed toward /DATA/.media, där monteringspunkter för säkerhetskopiering och fjärrlagring var inblandade. Verktyg för diskanvändning kan vara missvisande på en NAS eftersom en katalog kan vara antingen vanlig lokal lagring eller platsen där ett annat filsystem är monterat. Den här tråden från januari 2026 började med en 1 TB ZimaOS-enhet som visade ungefär 915 GB använt, trots att användaren trodde att det bara fanns cirka 450 GB mediefiler. Det första antagandet var Docker-cache. Kommandots utdata pekade i stället mot

Mät innan du rensar Docker

Det första communitysvaret föreslog att de största mapparna under skulle granskas /DATA och kontrollerade Dockers egen redovisning. Det var rimligt, men användarens resultat visade bara cirka 2,1 GB under Docker-trädet och cirka 2 GB AppData.

Docker kunde därför inte förklara hundratals saknade gigabyte.

Den första användaren hittade 424 GB under /DATA/.media/UNTITLED 2

Storleksskanningen visade ungefär 419 GB vanliga mediefiler plus ytterligare 424 GB under /DATA/.media/UNTITLED 2. Användaren kände igen namnet som namnet på den SSD som tidigare använts som ZimaOS-mål för säkerhetskopiering.

Det förvirrande var att den fysiska säkerhetskopieringsenheten inte längre var ansluten.

En monteringspunkt kan bli en vanlig lokal mapp

Linux-monteringspunkter är kataloger. När en USB-enhet eller SMB-delning monteras går åtkomsten till katalogen till det externa filsystemet. Om det externa filsystemet försvinner och ett program fortsätter skriva till samma katalog kan skrivningarna hamna i det lokala filsystemet under den.

Detta skapar det klassiska felet: ”mitt säkerhetskopieringsmål är externt, så varför blev systemdisken full?”

Radera inte en .media-katalog förrän du vet om den är monterad

Den ursprungliga felsökningen föreslog destruktiva raderingskommandon efter kontroll av monteringsstatusen. Den ordningen är viktig. Om du raderar filer från ett aktivt monterat säkerhetskopieringsmål kan du radera den faktiska externa säkerhetskopian i stället för att frigöra lokalt dolt data.

Eftersom raderingskommandot var ett råd från communityn och inte en supportinstruktion från IceWhale presenteras det inte på den här sidan som en generell rensningsmetod.

En andra användare återskapade samma mönster efter ett strömavbrott

Senare i tråden förlorade en annan användare med en liten ZimaOS-HD-system-/datapartition allt återstående ledigt utrymme efter att ett strömavbrott avbrutit säkerhetskopieringen. Deras råa du utdata verkade enorm eftersom den även räknade med monterad RAID- och SMB-data under /DATA/.media.

Använd en skanning av samma filsystem för att skilja lokala data från monteringar

Communityn rekommenderade en du en skanning som håller sig till samma filsystem så att monterade nätverksdelningar utesluts. I det andra fallet visade detta ungefär 30 GB genuint lokala data under en IP-namngiven katalog inuti /DATA/.media.

Den andra användaren frigjorde 30 GB

Efter att ha bekräftat att katalogen med IP-adress som namn inte var en aktiv SMB-montering och identifierat den som lokala data som låg kvar under monteringspunkten tog användaren bort det oönskade innehållet och rapporterade att 30 GB hade frigjorts.

Det är det tydligast bekräftade resultatet i tråden.

Communityns teori var att backupen skrev medan målet inte var monterat

Skribenten trodde att backupprocessen fortsatte skriva till den förväntade SMB-sökvägen när delningen inte var korrekt monterad, vilket fick Linux att skriva till den lokala katalogen i stället.

Den bekräftade återvinningen på 30 GB stöder att lokala filer fanns under monteringspunkten, men den exakta orsaken med backupens skrivning var en diagnos från communityn och inte ett tekniskt inlägg från IceWhale i den här tråden.

Aktuell hantering av backup och lagring i ZimaOS har förändrats

I aktuell dokumentation för ZimaOS beskrivs hanterade backuptasks och bredare lagringshantering. Använd det aktuella backuparbetsflödet i ZimaOS för nya jobb och kontrollera att det avsedda målet faktiskt är monterat innan stora skrivningar påbörjas.

Ett säkrare arbetsflöde för att hitta saknat utrymme

1. Använd df för att bekräfta vilket lokalt filsystem som är fullt.
2. Skanna endast det filsystemet så att SMB-, USB- och RAID-monteringar inte blåser upp totalsummorna.
3. Kontrollera Docker och AppData separat.
4. Inspektera /DATA/.media för kataloger för monteringspunkter som innehåller riktiga lokala filer.
5. Bekräfta att målet inte är monterat innan du raderar något under en monteringspunkt.
6. Efter rensningen ska du kontrollera det lediga utrymmet och testa backupmålet igen.

Den första användarens fall med 424 GB var mer tvetydigt än det senare fallet med 30 GB

Det ursprungliga inlägget visade ungefär 424 GB under en katalog som hade fått namn efter den frånkopplade backup-SSD:n, och skribenten trodde att utrymmet var överflödigt. Diskussionen gick sedan vidare till kontroller av monteringar och föreslagen rensning, men trådens tydligaste verifierade återvinning kom från den senare användaren som frigjorde 30 GB.

Den skillnaden är viktig eftersom en katalog under /DATA/.media kan representera en aktiv montering, en inaktuell monteringspunkt eller riktiga lokala filer. Att sökvägen ser likadan ut innebär inte att samma säkra rensningsåtgärd gäller på alla system.

Använd df och du för olika frågor

df besvarar frågan ”vilket filsystem är faktiskt fullt?” medan du besvarar frågan ”vilka synliga kataloger innehåller filer?”. På en NAS med nästlade monteringar kan de två verktygen verka vara oense eftersom du kan gå in i andra filsystem om den inte instrueras att låta bli.

Tråden blev mycket tydligare först när felsökningen separerade det lokala ZimaOS-HD-filsystemet från monterat SMB- och RAID-innehåll.

Oväntade strömavbrott gör problem med monteringspunkter farligare

Det senare fallet på 30 GB började efter ett strömavbrott medan säkerhetskopieringar pågick. Om ett fjärrmål inte monteras om korrekt efter uppstart men ett säkerhetskopieringsjobb återupptas eller startas om, kan sökvägen fortfarande finnas som en vanlig lokal katalog.

För viktiga säkerhetskopieringsjobb bör du efter en omstart eller strömavbrott kontrollera att målet är monterat och skrivbart innan du antar att den gamla sökvägen fortfarande pekar på det externa målet.

Radera inte Docker overlay2 manuellt för att frigöra utrymme

Tidigt i tråden såg Docker overlay-sökvägar visuellt framträdande ut i filsystemsutdata. Communityn varnade särskilt för att radera godtyckliga filer från overlay2. Dockers lagringslager bör hanteras via Docker eller appens livscykel, inte genom att ta bort slumpmässiga lagerkataloger.

Aktuella ZimaOS visar även apparnas lagringsanvändning

Aktuella appinställningar i ZimaOS visar apparnas lagringsförbrukning och erbjuder cachestädning för appar som stöds. Det är användbart för att skilja normal tillväxt i appar från data under monteringspunkter innan du öppnar terminalen.

Förklaringen av var aktuella ZimaOS-appar lagrar data och cache ger en säkrare första överblick över filsystemet.

Vanliga frågor om saknat utrymme

Var Docker overlay2 orsaken till den första användarens hundratals saknade gigabyte?

Nej. Docker stod bara för en liten del av det använda utrymmet i det publicerade resultatet.

Varför kan du rapportera terabyte på en mycket mindre lokal disk?

Det kan räkna monterade fjärr- eller RAID-filsystem rekursivt, om genomsökningen inte begränsas till det lokala filsystemet.

Bekräftades någon återställning?

Ja. Den senare användaren återställde 30 GB från lokala data som lagrats under en SMB-monteringspunkt.