The most important thing this source does not prove is that ZimaOS independently scanned the NAS and deleted a normal photo library. The user reported that their Immich files disappeared after uninstall/reinstall activity and suspected the “Delete configs” option, but the exact deletion event was never reproduced or diagnosed by IceWhale.
The posted configuration later showed a custom Docker Compose deployment, not the ZimaOS Store Immich package. Its database, machine-learning cache, and library were bind-mounted under /mnt/bigdrive/data/immich/.... Zima-Giorgio explicitly noticed the app was not from the ZimaOS Store. That makes it unsafe to claim the Store's normal uninstall behavior caused the loss. The durable lesson is to keep irreplaceable photo assets and database backups outside any cleanup path you do not fully understand.
The User Reported Irreplaceable Photos Missing After Uninstall/Reinstall
The source user believed they may have checked an option to delete configuration while removing Immich. They also described crash loops, poor access to logs during the failure, and eventually left ZimaOS after being unable to recover the images.
This is a serious data-loss report, but the forum never produced a reproducible sequence showing which action actually removed which files.
The First Explanation Was a Community Theory
A community reply suggested originals may have lived under an app folder that the uninstall cleanup considered configuration/user data. That is a reasonable hazard to warn about, especially if users mix config/database/original media in one AppData tree.
It was not confirmed as the cause of this specific incident.
The Posted Compose Mapped Data Outside the Normal Store AppData Example
The user later posted a Compose definition with host paths such as:
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryThe Immich server mapped the library folder to /data. This is important evidence because it does not match the simple “all originals were under /DATA/AppData/immich” theory proposed earlier.
IceWhale Confirmed It Was Not the ZimaOS Store Immich Package
Zima-Giorgio asked where the app came from after inspecting the configuration. The user answered that it came from the Immich Docker Compose file. Giorgio then recommended installing apps from the ZimaOS Store.
That recommendation does not identify what deleted the files, but it clearly establishes the app-management boundary.
Current ZimaOS Treats Container and Mapped Data as Different Things
Current IceWhale documentation explains that the container itself is disposable while important application data lives in mapped host folders. It explicitly recommends backing up those host folders and keeping AppData on appropriate storage.
Use the current ZimaOS app-data model before removing a stateful app.
Immich Needs Both Asset and Database Protection
Photos/videos on disk are only one half of an Immich recovery. Albums, users, metadata, file records, and application state live in PostgreSQL. A safe plan protects both the asset tree and a compatible database backup.
Do not rely on an app-uninstall checkbox as your backup strategy.
Before Uninstalling a Photo Manager
- record every host-side volume mapping;
- verify the real photo/video asset path;
- create and test an independent database backup;
- copy irreplaceable assets to another device/storage;
- understand exactly what any “delete user data/config” option targets;
- only then remove/recreate the app.
If Files Suddenly Disappear, Minimize Further Writes
Stop the application and avoid installing/recreating containers or copying new data onto the affected filesystem until you understand the state. Restore from verified backups first. If there is no backup and the files are truly gone, preserve the media and seek filesystem-specific recovery help rather than repeatedly writing to it.
The source community mentioned recovery tools, but those were not IceWhale procedures and are not guaranteed safe for every RAID/filesystem.
Immich Data-Loss FAQ
Did IceWhale confirm that the ZimaOS Store uninstall deleted the source user's photos?
No. The app was a custom Compose deployment and the exact deletion mechanism was never established.
Did the posted Compose show the library under /DATA/AppData/immich?
No. It showed library/database/cache bind mounts under /mnt/bigdrive/data/immich.
What is the safest prevention?
Back up both the original photo/video assets and the Immich database independently before uninstalling, resetting, or remapping the stack.
