Immich Shows Stale Data After a Storage Path Change
Stale Immich data after a storage path change has three different causes that should not be mixed together: a managed media-root move, an external-library import-path change, or a client that is still showing cached state. Modern Immich releases can reconcile a moved managed media location when the configured media location and volume mount stay consistent, while external-library moves can still be treated as new asset identities.
Preserve the old path and database before rescanning. First prove what path the running container sees, then identify whether Immich's server-side record is wrong or only one client is stale. That distinction determines whether you should repair a mount, restore a stable container-visible path, rescan a test subset, or clear only client cache.
Distinguish a Managed Media-Root Move From an External-Library Move
If you changed the host location for Immich-managed uploads, verify that the effective media-location setting and the host-to-container mount changed together. A modern managed-media move should not be diagnosed the same way as renaming an external-library import path.
The ZimaSpace Immich persistent-state map is useful here because the database and filesystem paths form one recovery boundary. The right files on the host are not enough if the container is mounted somewhere else.
If the managed media root is mismatched, correct the environment and volume mapping first and restart the service before running library jobs. If the changed path belongs to an external library, keep the database intact and test that branch separately.
Keep the External-Library Container Path Stable When Possible
For an external library, a host-side storage move is safest when the container-visible import path can remain unchanged. If the path presented to Immich changes, record a small set of asset IDs, albums, people, and old paths before a scan so you can tell whether existing assets were relinked or recreated.
An Immich external-library path-change report described relocated files being treated as new assets, with reprocessing and lost Immich-only relationships. It is a version-scoped case, but it supports the conservative rule that a changed external-library path is not automatically a transparent rename.
If a test subset appears as new assets while the old records become missing or trashed, stop the full rescan. Restore the old container-visible path if practical or use a version-appropriate migration approach; do not manually rewrite production database paths without a tested backup.
Do not confuse this branch with a Storage Template migration for Immich-managed files. The symptom may look similar in the timeline, but the ownership of the files and the supported migration path are different.
Separate Stored Server Paths From Client Cache
Inspect the same known asset from the web client and another authenticated client, then compare that with server logs or the server-visible path. If server-side jobs still name the old path, clearing a browser cache cannot repair the underlying record.
A later Immich old-path metadata issue showed processing continuing to reference a previous external-library path after a rename. That is strong evidence for checking job-side paths before blaming the mobile or web UI.
If the server path is correct but only one web view is stale, refresh or clear that client cache and retest the original file. Cached thumbnails and stale client state can make a fixed server look broken, while a cached preview can also make a broken server path look healthy.
Repair the Smallest Path Boundary and Validate a Controlled Rescan
Make one reversible correction: synchronize the managed media setting and mount, restore the prior external-library container path, correct an import path, or clear one client cache. Take a database backup before any action that can cause a large library to be rediscovered.
Run the smallest practical rescan and watch whether existing records stay associated, old-path errors stop, and duplicate old/new assets do not appear. Then open sampled originals, verify album and people relationships, run a search, and restart the stack.
Escalate if old and new path records remain active together, a large external library is unexpectedly reprocessed, or relationships disappear while originals remain readable. Preserve the exact before/after mount map, Immich version, affected asset IDs, filesystem case behavior, and database backup timestamp.
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.
