Why Does Immich Stop Returning Searchable Private Photos After a Restart?
Immich usually stops returning searchable private photos after a restart because Smart Search lost its machine-learning path, has not finished warming its model, or cannot complete the jobs and storage reads that build search embeddings.
If the timeline still shows the originals, the photos are probably not missing; the search layer is incomplete. Treat an empty result as a service-path problem first, preserve the database and upload library, then distinguish an unavailable machine-learning container from delayed jobs, a mismatched endpoint, or a persistent-path permission failure before rebuilding anything.
Separate Missing Search Results From Missing Photos
Open several known assets directly from the timeline, albums, and a private library before testing search. Pass means the database can locate the records and Immich can read the files; fail means this is a broader library or storage incident, so stop search-specific changes and protect the affected paths.
Run three repeatable searches: a term that worked before, a visually obvious term, and a recently uploaded asset after its background work should have completed. Record whether results are empty, stale, or limited to older photos. Those outcomes separate total endpoint failure from an indexing backlog.
A community troubleshooting thread collects restart-related Smart Search checks, including endpoint reachability and re-running jobs. Use its search-layer diagnostic sequence as case evidence, not as a reason to delete the database or regenerate every asset.
Check the Machine-Learning Path After Restart
Inspect the server and machine-learning container health, then test the configured machine-learning URL from the network namespace that calls it. A reachable endpoint with successful model requests passes this branch; connection refusal, name-resolution failure, or an unhealthy container identifies the service path to repair.
Compare the deployed service name, port, environment value, image version, and network membership with the last known-good Compose definition. Recreate only the affected container after correcting a mismatch. A mere restart does not replace stale container environment, so confirm the effective value in the recreated workload.
A reported Immich v2.6.1 case tied failed Smart Search to an unhealthy machine-learning container. The version-scoped failure report supports checking health and logs; it does not prove that every post-restart failure is that regression.
Check Model Readiness, Jobs, and Persistent Paths
Watch machine-learning logs while sending one known search. A first request may load or download a model and temporarily use more memory; progress followed by a successful response passes. Repeated eviction, out-of-memory termination, or download failure maps to memory, cache persistence, or network repair.
Inspect Smart Search job counts and recent failures without clearing them. If the endpoint is healthy but jobs remain failed or queued, retry a small controlled batch and observe whether counts fall. If one asset succeeds, repair worker concurrency or the failed dependency before scheduling a full re-index.
Confirm the database, upload library, and model cache mount the intended persistent paths with the expected identity. The related ZimaSpace guide to Immich recognition behavior helps distinguish access and indexing scope from a missing original.
Apply the Matched Fix and Retest Two Restarts
Correct only the confirmed cause: restore the endpoint name, recreate the container with the right environment, persist the model cache, reduce measured concurrency, repair ownership, or retry failed Smart Search jobs. Keep the previous Compose file and database backup ready; do not delete embeddings as a first response.
Retest the same three queries, one old asset, and one new upload. Pass requires useful results, falling job queues, readable originals, and stable machine-learning health. Restart the stack in its normal dependency order and repeat, then restart the host once to prove mounts and name resolution survive boot.
Roll back if results shrink, originals become unreadable, or the database reports consistency errors. Escalate with Immich version, effective endpoint, container health, relevant logs, job counts, model name, and mount mappings if the same failure returns after two restarts; keep the old searchable instance isolated but recoverable.
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.
