Community Solution

ZimaOS Trash Won't Open: Recover Deleted Files First

After upgrading to ZimaOS 1.5.0, a user could no longer open Trash in Files but found the deleted data in hidden trash directories and recovered it manually.

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 Files sidebar showing the Trash entry after an update where clicking it did nothing
The source screenshot shows the Trash item still present in Files even though the user could not open it after updating to ZimaOS 1.5.0.

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.