Why Does Immich Lose Access to Persistent Data After Stack Recreation?
When Immich looks empty or cannot read its library after stack recreation, assume the old persistent data is disconnected or unreadable before assuming it was deleted.
Recreating containers can change the Compose project identity, bind-mount source, named-volume attachment, network-share timing, or the UID/GID that reads the data. Stop the fresh-looking instance before it writes much new state, locate the old database and media paths on the host, and compare the recreated stack with the last known-good mapping. The goal is to reconnect existing state first; restore from backup only after you have proved that state is actually missing or damaged.
Stop the Fresh Instance and Prove the Old Data Still Exists
A setup wizard, empty timeline, or missing external library immediately after recreation is a persistence warning. Stop Immich and inspect the host-side database and media locations before uploading new files or accepting a new empty configuration. New writes can make later path comparisons harder.
Check the old directories for expected file counts, modification dates, database files or dumps, and representative original images. If the data is present on the host, the problem is access or mapping rather than disappearance. Make a read-only snapshot or backup of that state before changing ownership or moving directories.
If the old data cannot be found at the expected paths, search the storage pool and Docker volume inventory before deleting anything. The decision exit is binary: existing state is located and protected, or it is genuinely unavailable and the recovery path moves to a known-good backup instead of mount repair.
Compare the Recreated Mounts With the Previous Stack
Inspect the effective mounts on the recreated Immich server and database containers, not just the Compose text you remember editing. A relative bind path can resolve from a different project directory, and a renamed Compose project can attach a new named volume while leaving the old one intact but unused.
A failed, changed, or missing mount can present an empty directory inside a container even while the expected data still exists elsewhere on the host. Use Docker volume mount checks to compare Source, Destination, mount type, and named-volume identity for every persistent Immich path. A mismatch here directly explains a fresh-looking instance.
Correct only the wrong mount mapping, then create or start the container without removing volumes. If the expected files appear at the same container path after the change, leave the data in place. If the mount list is correct but access still fails, preserve the mapping and move to host-storage availability and permissions rather than creating another volume.
Verify External Storage Was Mounted Before Immich Started
If Immich data lives on an HDD pool, NAS share, merger layer, or other external mount, confirm that storage is actually mounted on the host before Docker starts the stack. A path such as /mnt/photos may still exist as an ordinary local directory when the real device is absent.
Persistent Docker data survives container replacement only when the intended volume or bind mount is reattached correctly. The underlying Docker volume persistence model does not make a missing host disk or network share appear automatically, so verify the storage device and a known file on the host before testing the same path inside Immich.
If you discover fallback files written into the bare mountpoint while the real storage was absent, stop Immich before mounting the device over them. Reconcile those files separately, add a startup dependency or health check for the storage mount, and only then restart the stack. If the host storage is stable and the container path is still unreadable, continue to the permission branch.
Check UID, GID, and Directory Permissions Without Rewriting Everything
A recreated stack can run a service with a different numeric identity, user namespace, or security context than the old one. The result looks different from a missing mount: the path exists and files are visible from the host, but Immich logs show permission errors or cannot create expected files.
Compare numeric ownership and mode bits on the affected host directories with the user identity inside the recreated container. Test a harmless read first, then a reversible write in a disposable location under the same mount. Avoid a recursive ownership change across the entire photo archive until you know which service needs write access and which original files should remain untouched.
Fix the smallest directory or identity mismatch that explains the failure, restart once, and recheck logs. If access still fails with matching mounts and permissions, stop making filesystem changes and inspect the database connection, environment substitution, or security layer that changed with recreation.
Reconnect the Original State and Validate Another Recreation
Once the old database and media paths are attached and readable, start Immich and look for the old users, albums, people, and representative assets. Do not call the repair complete because the homepage loads; verify that the application is reading the original state rather than a newly initialized database beside it.
The useful boundary is that containers can be disposable while application state must remain on stable storage outside the container lifecycle. Keep the corrected mount names and host paths documented, and use persistent file-server storage roles to keep the next stack recreation attached to the same data.
Finally, recreate the stack one more time under controlled conditions and repeat the original checks. The fix is proven only if the same database and media reappear after recreation and after a host reboot. If the old state vanishes again, or if the database reports corruption rather than access errors, roll back to the protected copy and switch to database/backup recovery instead of continuing mount experiments.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
