Bottom Line: If Trash Will Not Open, Preserve the Deleted Files Before Trying to Repair the UI
The important part of the 1.5.0 case is not that the Trash button broke; it is that the deleted files were still recoverable underneath the Files interface. The user found hidden trash directories under ZimaOS data paths and copied the needed files out before reinstalling. That is the right priority: recover first, repair the interface second.

ZimaOS Trash Is Designed as a Recoverable Deletion Layer
ZimaOS introduced Trash so Files deletions could be restored and automatically cleared after a retention period instead of disappearing immediately. The historical ZimaOS Trash behavior documents restore and 30-day cleanup behavior.
Check Whether Deleted Data Still Exists
du -sh /var/lib/casaos_data/.trash/* 2>/dev/null
du -sh /var/lib/casaos_data/.media/*/.trash 2>/dev/null
find /var/lib/casaos_data -maxdepth 4 -type d -name ".trash" 2>/dev/null
Those internal paths come from real historical cases and can help locate data when the UI is broken. Treat them as recovery locations, not stable public APIs. ZimaOS storage internals can change between releases.
When locating recovery folders manually, use read-only inspection first. GNU's GNU find tools provide a safer discovery method than creating, renaming or deleting hidden directories while mount state is still uncertain.
Copy Needed Files Out Before Deleting or Rebuilding Anything
If you find the missing files, copy them to a normal folder on another storage space or external disk and verify they open. Do not move or delete the trash directory while investigating. The ZimaOS backup gives a safer second copy.
Confirm the Real Mount State
Later 1.6-era reports showed similar symptoms when storage paths and mount records no longer matched. Check:
df -h
mount
ls -lah /media
findmnt
If the UI says Trash exists but the underlying storage path is missing or points to a stale mount, manually creating a new .trash folder can make recovery harder.
Do Not Assume Files, SMB and Media Apps Delete Identically
A file deleted from the ZimaOS Files interface may go through the platform Trash workflow, while deletion from SMB, Plex or Jellyfin can behave differently depending on the service and mount configuration. If free space does not return after deletion, inspect trash directories and open-file state rather than assuming the filesystem failed.
Linux's open file inspection helps when disk space remains consumed by an open deleted file.
A Broken Trash UI Does Not Require an Immediate OS Reinstall
The original user decided to reinstall after another GPU-transcoding problem appeared, but reinstalling is not the first recovery step for a Trash-only issue. Recover deleted data, test the current stable release, clear browser state, and inspect storage mounts first. The ZimaOS recovery is the appropriate escalation boundary.
Keep App Data and User Data on Planned Storage
When storage paths drift after upgrades, Trash, app mounts and shortcuts can all appear broken at once. Current ZimaOS now documents app storage paths and data migration more clearly. The ZimaOS data migration reduces future path ambiguity.
Test Trash After Recovery
Create a disposable text file, delete it through Files, confirm it appears in Trash, restore it, then delete it again and verify capacity behavior. Use expendable test data so you can confirm the current release without risking the recovered files.
FAQ
Where are ZimaOS deleted files stored?
Historical releases used hidden .trash directories under ZimaOS data and mounted-media paths, but internal paths are not guaranteed as a stable public interface.
Why does Trash appear but not open?
It can be a Files UI regression, stale storage path or mount inconsistency. Recover data and inspect mounts before recreating folders.
Will reinstalling ZimaOS restore Trash?
It may replace system components, but it is too destructive as a first fix and does not replace recovering the deleted files first.
Why is disk space not freed after deletion?
Files may still be in Trash or held open by a running process. Check both before blaming the filesystem.
How should I test the fix?
Use a disposable file: delete, confirm it appears in Trash, restore it and verify storage usage.
