If a file disappears from Windows Explorer but ZimaOS still reports the disk as full, the first question is not “did SMB fail to delete it?” The file may have been moved into ZimaOS's Trash workflow, retained in a hidden trash directory, or affected by a version-specific trash-index/display bug.
The source thread itself did not reach a confirmed fix. A community responder said this was normal Samba behavior and suggested hidden folders such as .recycle, .Trash, or .Trash-1000. That advice was too generic for ZimaOS. Later 1.5.4 troubleshooting identified ZimaOS's own hidden trash path under /var/lib/casaos_data/.media/.../.trash, while current Files includes a first-class Trash Bin.
ZimaOS Files Has an Official Trash Bin
IceWhale added a visual Trash Bin to Files in ZimaOS 1.3.1. The release notes describe restoring deleted items and automatic cleanup after 30 days.
See the official ZimaOS Trash Bin feature before deleting hidden directories manually.
The Source's “Normal Samba Behavior” Was Not Verified
The original poster asked whether every deletion would require command-line cleanup, but no later reply confirmed which hidden directory was consuming space or whether deleting from Windows was routed through ZimaOS Trash on that version.
Therefore the source should be treated as an initial hypothesis rather than a confirmed diagnosis.
ZimaOS 1.5.4 Later Had a Documented .trash Display/Sync Bug
A separate February 2026 community thread found deleted files accumulating under:
/var/lib/casaos_data/.media/Mounted-Drive-Label/.trashwhile the Files Trash interface did not display them correctly. The workaround stopped Files/SMB, removed the affected hidden trash folder, restarted services, and synced writes—but the author later said the problem returned after reboots.
That is a version-specific community workaround, not a safe universal deletion recipe.
Check Files → Trash Before SSH Cleanup
For a current user, first open the Files Trash Bin and inspect what is being retained. If the deleted items are visible, empty the trash through the UI instead of removing internal metadata paths from the shell.
Automatic Retention Explains Why Space May Not Return Immediately
If deleted files are intentionally retained for recovery, storage usage can remain high until the trash is emptied or the retention window expires. This behavior protects users from accidental deletion but can surprise someone deleting hundreds of gigabytes over SMB.
Measure the Real Space Consumer Before Deleting Hidden Folders
If the Files Trash looks empty but disk usage remains high, inspect:
- hidden trash data;
- backup/version retention;
- Btrfs snapshots if used;
- files written beneath a missing mount point;
- open-but-deleted files held by a running process;
- application caches or Docker data.
Do not assume every unexplained gigabyte belongs to trash.
Deleting Through Explorer Should Not Require Manual SSH Every Time
A healthy current setup should let normal SMB/File workflows handle deletion without the user repeatedly removing internal trash folders. If every Explorer delete requires manual cleanup, treat that as a current Files/SMB behavior problem and capture the ZimaOS version.
Do Not Delete Internal .media Paths Blindly
Paths under /var/lib/casaos_data/.media are part of ZimaOS's internal file-service mount/trash model. Removing the wrong directory while services are active can affect indexing or mounted storage.
Use the UI first and involve support before applying an old 1.5.4 shell workaround to current ZimaOS.
Retest on Current ZimaOS Before Reproducing a 2025/1.5.4 Trash Bug
Current ZimaOS is 1.7.1 and has continued to receive file-service, memory, cut/move, and security fixes. The source is useful for understanding the trash layer, not for proving the same bug still exists today.
SMB Delete and Trash FAQ
Can deleted files continue consuming space because they are in Trash?
Yes. ZimaOS Files has an official Trash Bin and retention behavior.
Was the original 2025 thread's hidden-folder diagnosis confirmed by the user?
No. The thread ended before the user reported a successful cleanup.
Should current users delete /var/lib/casaos_data/.media/.../.trash manually?
Not as the first step. That path came from a later 1.5.4 community workaround and should be used only with version-specific evidence and care.
