Why Does Immich Recreate Missing Files With the Wrong Owner?
Immich should not silently recreate a missing source original as a generic recovery feature. If a deleted object reappears, first identify whether it is a generated thumbnail, encoded video, profile artifact, XMP sidecar, or another writable file; those can be recreated or rewritten by different processes and inherit a different owner.
Use one disposable regenerated object and its parent directory. Compare numeric UID/GID and ACLs on the host with the effective writer inside the container, then identify whether Immich, a sidecar-writing feature, a NAS protocol, or another host process actually created it. Avoid recursive chown or chmod 777 until that writer is known.
Compare the Recreated File With Its Parent and a Known-Good Neighbor
Record the owner, group, mode, ACL, extended attributes if relevant, and numeric UID/GID for the recreated file, its parent directory, and an older file that works correctly. Names can be misleading across a NAS and a container; numeric IDs reveal whether “immich” on one system maps to the same identity on another.
The ZimaSpace permission workflow for files moved to a NAS applies directly: new objects are governed by the destination ACL, container identity, protocol mapping, and creation rules. A replacement file can therefore be readable yet still acquire an owner that breaks another tool's workflow. If the recreated file matches the parent inheritance and only the display name looks unfamiliar, map the numeric ID before changing anything. If it differs from both the parent and known-good files, continue to the writer identity; the problem may be inside the container configuration rather than the filesystem ACL.
Identify the Process and Effective UID/GID That Writes the Replacement
Trigger one safe regeneration while watching the relevant logs and filesystem. Inspect the effective user and groups inside the container that performs the write. If a sidecar, metadata tool, backup process, or host script creates the file instead, inspect that service rather than changing Immich's runtime identity.
Container ownership is numeric rather than name-based. A Docker file-ownership explanation shows why the same bind-mounted file can display a different username across host and container when UID/GID mappings do not match. Use numeric IDs as the common reference.
An Immich external-library ownership discussion documented XMP sidecars being written as root in one deployment. That is case evidence for checking the effective writer and supported runtime identity, not a claim that every current Immich installation writes every regenerated file as root.
If the container is intentionally running as a non-root user, confirm the UID/GID actually exists on the host or NAS and has the required access to the mounted path. A symbolic username inside a container does not automatically match a host account with the same name.
Repair the Creation Rule Instead of Repeatedly Fixing Existing Files
Correct the smallest confirmed boundary: align the service UID/GID where supported, repair the parent directory group or ACL inheritance, set an appropriate umask, or change the NAS share mapping that supplies the wrong identity. Preserve the ability of Immich and any other legitimate reader to access originals and generated files.
Do not use world-writable permissions as the default repair. That hides the identity mismatch and expands write access unnecessarily. Likewise, do not recursively change PostgreSQL ownership, model cache, uploads, and external libraries under one command; those paths may intentionally use different service identities.
If an external library is meant to be immutable, consider making the mount read-only and keeping app-owned writable state elsewhere, but only if the features you use do not require sidecar writes there. The decision is about desired ownership and write behavior, not forcing every file in the photo archive to share one account.
Recreate One File Again and Validate After a Restart
Remove only a disposable generated object or test sidecar that can safely be recreated, then trigger the exact Immich operation again. Verify the new owner, group, ACL, and readability from both Immich and the other program that previously failed. Keep the original media untouched during this test.
Restart the container and then reboot the host once to make sure the corrected identity and mounts survive lifecycle changes. A passing repair creates the next test file with the expected ownership automatically; it does not depend on a post-startup chown script that races Immich writes.
Stop and restore from the preserved configuration if ownership changes spread into the database or originals unexpectedly, or if the service loses read/write access after restart. Escalate with numeric IDs, ACL output, mount options, effective container user, Compose fragment, and the exact file type Immich recreated.
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.
