I am sorry that I’m a complete nooB. I have a 1 TB drive that is nearly full and I assume it’s from the backup bug? There is basically 450GB of media data on the disc but suddenly it tells me it’s almost full
I assume there is a cache file that basically doubled my hard drive usage but I don’t know how to find it or delete it. Handholding would be much appreciated.
No need to apologise at all. This is a really common situation, and you’re asking the right question.
From your screenshot, the important part is this:
/DATA/docker/overlay2/...)Even if you only have ~450GB of media, your drive can still fill up because:
So yes — it can absolutely look like your drive “randomly doubled” even though your media didn’t.
Please run these commands in Terminal:
sudo du -h -d 2 /DATA | sort -h | tail -30
That will show the biggest folders.
docker system df
This will tell us how much space is used by:
This is safe and will NOT delete your installed apps.
docker image prune -a
docker builder prune
If you want to be more aggressive (still usually safe, but removes more unused leftovers):
docker system prune
Plex often stores huge amounts of preview thumbnails.
If Plex is installed, check:
sudo du -h -d 2 /DATA/AppData | sort -h | tail -30
If you see something like:
/DATA/AppData/plexPlease do NOT delete random folders inside overlay2 manually — it can break containers.
If you paste the output of these 2 commands:
sudo du -h -d 2 /DATA | sort -h | tail -30
docker system df
I can tell you exactly what is consuming the space and what to clean up safely.
Thank you so much for your tolerance and assistance.
8.3M /DATA/AppData/emby
9.2M /DATA/.docker/containers
11M /DATA/AppData/plex
12M /DATA/.casaos/appstore
14M /DATA/Documents/Jim’s Accounts.qdfm
42M /DATA/Documents/car
46M /DATA/Documents/Taxes
49M /DATA/.log/journal
52M /DATA/.log
53M /DATA/.casaos
246M /DATA/Documents/Manuals
301M /DATA/Documents/Personal
507M /DATA/Documents/Professional
928M /DATA/Documents/Calibre
1.9G /DATA/Documents/Paperless Library.paperless
2.0G /DATA/AppData
2.0G /DATA/AppData/jellyfin
2.1G /DATA/.docker
2.1G /DATA/.docker/overlay2
4.0G /DATA/Documents
6.5G /DATA/Media/TV Shows
15G /DATA/Media/Workout
49G /DATA/Media/Movies
66G /DATA/Media/DVD Backups
66G /DATA/Media/Photos
217G /DATA/Media/Music
419G /DATA/Media
424G /DATA/.media
424G /DATA/.media/UNTITLED 2
853G /DATA
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 4 4 1.057GB 0B (0%)
Containers 5 4 181.2kB 45.48kB (25%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
What I see here is the 424G .media/UNTITLED 2 - this was the backup file (using the ZIMA backup program) that did go to “UNTITLED 2” which was the backup SSD drive. Unless I am misreading this, this is redundant.
I am using Jellyfin and not Plex. When I ran the pruning commands there was very little gain.
Assuming this is correct, can I just delete the /DATA/.media/UNTITLED 2 folder and how do I do so?
Thanks again…will this keep happening if I try to use the builtin back up program?
You’ve done everything right here, and your output is actually very clear (nice job).
You are not losing space to Docker at all.
Your Docker usage is tiny:
So pruning Docker won’t help much — and that matches what you saw.
The real space is here:
That is enormous, and it lines up perfectly with what you’re describing: a backup being written/stored there.
/DATA/.media/...?On ZimaOS, when you plug in an external drive, the system mounts it under:
/DATA/.media/<DriveName>
So:
/DATA/.media/UNTITLED 2
is very likely your backup SSD being mounted there.
This folder might be showing the contents of your external SSD through the mount.
So you have 2 possibilities:
That folder is your external SSD contents (normal mount).
Deleting it would delete the backup from the SSD, not from your internal disk.
The backup bug duplicated content into that folder on your internal drive (less likely, but possible).
We can confirm which case it is with one quick check.
Run:
df -h | grep -i media
and also:
mount | grep -i "/DATA/.media"
If you see /DATA/.media/UNTITLED 2 listed there, it means:
It is a mounted external drive
and it is not “duplicating” storage inside your internal disk.
If that backup is redundant and you want to remove it, yes you can delete it — but do it carefully.
sudo ls -lah "/DATA/.media/UNTITLED 2"
Example (replace BACKUP_FOLDER_NAME with the actual folder shown):
sudo rm -rf "/DATA/.media/UNTITLED 2/BACKUP_FOLDER_NAME"
Only do this if you are 100% sure you don’t need it:
sudo rm -rf "/DATA/.media/UNTITLED 2"/*
That will wipe the contents of the external SSD.
Based on your output: no, not in a “runaway cache” way.
What likely happened is:
So it’s not “mysteriously duplicating” — it’s just storing the backup.
If you paste the output of:
df -h | grep -i "UNTITLED\|media"
mount | grep -i "UNTITLED"
I can tell you with certainty whether it’s a mounted external SSD (safe) or accidentally written into internal DATA (rare but possible).
I get what you mean, but the back up drive, “Untitle 2” is not actually attached at this time.
In response to your process, I got this:
plex@ZimaOS:/media ➜ $ df -h | grep -i “UNTITLED|media”
plex@ZimaOS:/media ➜ $ df -h | grep -i media
plex@ZimaOS:/media ➜ $ df -h | grep -i media
plex@ZimaOS:/media ➜ $ mount | grep -i “/DATA/.media”
plex@ZimaOS:/media ➜ $ sudo ls -lah “/DATA/.media/UNTITLED 2”
total 12K
drwx------ 3 root usb 4.0K Jan 15 11:03 .
drwxr-xr-x 3 root root 4.0K Jan 11 17:36 ..
drwxr-xr-x 8 root root 4.0K Jan 15 11:17 ZimaOS-HD
If I just look at what’s on the hard drive, I get this:
plex@ZimaOS:/media ➜ $ ls
‘UNTITLED 2’ ZimaOS-HD
not sure what to do next…the whole UNTITLED 2 thing seems unnecessary.
Thanks for confirming that. That actually makes things simpler.
Since the backup drive (“UNTITLED 2”) is not connected, and both:
df -h | grep -i media shows nothingmount | grep -i "/DATA/.media" shows nothing…I believe UNTITLED 2 is not a real mounted drive right now, it’s just an empty leftover folder on your internal disk.
You already cleared it with:
sudo rm -rf "/DATA/.media/UNTITLED 2"/*
So I suggest removing the now-empty folder:
sudo rmdir "/DATA/.media/UNTITLED 2"
Then confirm it’s gone:
ls -lah /DATA/.media
I believe this folder was created by the backup tool when it expected the external drive to be mounted, but the drive wasn’t available at the time.
Thank you - I am in the process now (it’s taking a while). I totally finally gave in and cheated. I work in Mac OS for the most part so mounted the ZimaOS drive in OSX and used the show invisible files command to reveal the .media folder in Finder and deleted it from there. Clunkier and slow (running ZimaOS on an old MacMini), but it seems to have gotten the job done.
Thank you for your kindness, tolerance, and help. Slowly and gradually understanding Linux-y commands. Likely just enough to be dangerous but these are relatively low stakes.
Yipee indeed! That’s an excellent result.
And honestly, your workaround was totally valid: I believe using macOS Finder + “show hidden files” is a perfectly reasonable way to clean up when you’re more comfortable there (especially on a MacMini setup). The important part is you removed the correct folder and the storage is now back to normal.
I suggest just one small habit going forward: before running the built-in backup, quickly confirm the backup drive is actually mounted (so it doesn’t write into /DATA/.media again). If you ever see /DATA/.media/<DriveName> growing while the drive isn’t plugged in, that’s the warning sign.
Really well done and you’re learning the Linux commands exactly the right way: slowly, safely, and with low-stakes testing.
Thank you. I will aim for better backup manners next time. When I did the original back up it didn’t unmount cleanly. I may choose a different back up strategy next time.
Hello @gelbuilding ,
Sorry for bothering you, but I followed your procedure as you described below but when I run the command sudo du -h -d 2 /DATA | sort -h | tail -30, this is what I have, I don’t understand what’s taking space. The only thing that takes a lot of space are my mounted smb drives, but I don’t find anything on them relevant. Zima-Storage is my RAID 5 stored on an other volume, my ZimaOS-HD is only 60 GB but until now I had 12 GB free and since my electricty broke when I turned it on again, I saw that all space was taken, there were backups running at that moment so I stopped them but I didn’t freed the space. Would you know how I can find what’s taking space?
Thank you in advance.
I would definitely wait on the pro, but to me it looks like the 2 T .media/Zima-Storage is the same redundant file I had when I didn’t have a clean unmount (is Zima Storage still attached?).
I called it a buffer which is probably incorrect but for some reason the backup program seems to write to the parent disc before completing.
gelbuilding was a huge help.
Good luck!
Hi @blop, no bother at all, happy to help.
From your screenshot, I believe the reason it looks confusing is because the du command is counting mounted network shares under:
/DATA/.media/192.168.x.x/DATA/.media/Zima-StorageSo it’s showing huge numbers (580G / 2.0T etc.), but that is not your ZimaOS system disk filling up — that’s just the size of the SMB mounts being “visible” in the folder tree.
If your ZimaOS-HD is only 60GB, the thing we need to check is what is taking space on the local system disk, not the mounts.
I suggest running this:
df -h
Then look for the line that shows / or ZimaOS-HD (something around 60GB).
That will confirm which partition is full.
I suggest running:
sudo du -xhd 2 /DATA | sort -h | tail -30
Important: -x tells Linux “stay on this disk only” (don’t count SMB / RAID mounts).
This will show only what is actually consuming space locally.
After an unexpected shutdown, I believe the most common causes are:
You can check logs quickly like this:
sudo du -sh /DATA/.log
sudo du -sh /var/log
If those are huge, that’s likely your answer.
If you paste the output of:
df -h
sudo du -xhd 2 /DATA | sort -h | tail -30
I can point out exactly what folder is filling the disk and what’s safe to clean.
Hello @whalesnot , @gelbuilding
Thank you for your answers, I’ve been digging yesterday after my post but so far no luck, here are the results of the commands:
df -h
sudo du -xhd 2 /DATA | sort -h | tail -30
With the command
sudo du -xhd 2 /DATA | sort -h | tail -30
It looks like there is a mounting point of one my smb shares but locally from what I’m understanding, could you confirm that and how could I delete all this?
Thank you again 
Thank you for the screenshots, they make it very clear.
Yes, I believe you’re correct: /DATA (your 47GB ZimaOS-HD data partition) is full, and the biggest clue is this:
/DATA/.media/192.168.x.x ≈ 30GBNormally /DATA/.media/192.168.x.x should only be a mount point (it shouldn’t consume local storage).
So I believe after the power outage / backup, real data was written locally into that folder while the SMB share was not mounted correctly.
Run:
mount | grep -i "192.168.x.x"
If nothing shows, it confirms it’s not a live SMB mount right now.
Run:
sudo du -sh /DATA/.media/*
This will show which folder under /DATA/.media/ is taking the space.
Once you confirm which folder is huge, I suggest clearing its contents like this:
sudo rm -rf "/DATA/.media/192.168.x.x"/*
(Replace 192.168.x.x with the exact folder name shown on your system.)
Then check space recovered:
df -h /DATA
I believe the backup process continued writing to the SMB path, but because the share wasn’t mounted, Linux wrote to the local folder instead, which fills /DATA very quickly.
You’re the best! It worked perfectly, I recovered 30gb. This drove me crazy looking where was my space.
Thank you so much and sorry @whalesnot for hijacking your post but since it was related, I tought it would be better.
Have a good day!