How to Prevent Permission Drift in Immich Data Folders
Preventing permission drift in Immich means making file ownership and access rules predictable before different containers, NAS protocols, updates, or maintenance jobs create new files with different identities.
The durable fix is not a periodic recursive permission reset. Record the numeric UID/GID and access each workflow actually needs, keep mount ownership and ACL inheritance deliberate, separate read-only from writable paths, and test the creation path after every change. Permission drift is prevented when tomorrowโs new file is created correctly without an emergency `chown`, not when todayโs library happens to be readable.
Record the Identities That Read and Write Each Immich Path
List the host paths mounted into Immich and identify which processes are expected to read, create, rename, or delete files in each one. For every writer, record its numeric UID and GID on the host and inside the container. Numeric IDs matter more than matching usernames because files store ownership as numbers.
Include non-Immich writers in the inventory. SMB uploads, NFS clients, backup tools, import scripts, media-management containers, and an administrator shell can all create files under the same tree. If they do so as different identities, the library can slowly accumulate owners and modes that work for one path but fail for another.
Keep this identity map with the Compose configuration. A future image update, server migration, or restored NAS account can then be compared against a known-good baseline instead of discovering the mismatch only after new uploads start failing.
Use a Deliberate Owner, Shared Group, and Minimum Access Model
Decide which identity should own application-managed data and which shared group, if any, needs access. Give each workflow only the read or write rights it requires. Avoid making the entire Immich tree world-writable simply because one container cannot create a thumbnail or move an imported file.
UID/GID mismatches and over-broad modes are common causes of shared-volume failures. The safer pattern is to align container and volume permissions rather than granting unrestricted access. That matters on a home server where several services may touch the same storage pool.
If multiple services need write access, use a shared group and consistent group permissions or ACLs rather than alternating recursive ownership between applications. Verify one representative directory first. Broad recursive changes across the whole photo library should be a last resort with a current backup, not routine maintenance.
Make New-File Permissions Predictable
Existing files can look perfect while new files drift immediately because the creation rules are wrong. Check the parent-directory ACL, default ACL entries, umask, service identity, and any SMB or NFS creation settings that apply to the path. The prevention target is inheritance, not cleanup.
Before changing modes recursively, compare numeric ownership on the host with the UID/GID actually running inside the container. This UID/GID bind-mount check quickly separates identity mismatch from a genuinely missing permission. Fix the owner/group relationship instead of masking it with permissive modes.
Create a small test file through every normal write path: Immich upload, import workflow, SMB/NFS transfer if used, and backup restore. Inspect owner, group, mode, and ACL after each test. If two creation paths produce incompatible results, resolve that policy conflict before importing more data.
Keep Mount and Update Changes From Rewriting Ownership
Treat a Compose edit, image update, NAS remount, or migration as a permission-sensitive change. Before applying it, record the current mount source and destination, whether the path is read-only or read-write, the effective container user, and a sample of numeric ownership from each important directory.
Transfers and network storage can introduce different SMB/NFS identities, numeric IDs, ACL inheritance, and umask behavior. Use NAS permission-change failure points as a pre-change checklist whenever Immich data moves between filesystems or access methods.
After the change, compare the same samples before running bulk jobs. If ownership suddenly changes on startup, stop the stack and identify which entrypoint, maintenance task, or remapped identity caused it. Do not allow an unexplained recursive ownership rewrite to continue across a large library.
Audit for Drift With Small, Repeatable Tests
Run a lightweight permission audit on a schedule or after upgrades: check a few stable originals, a recent upload, a newly generated derivative, and any external-library mount. Look for unexpected owners, missing group access, read-only mounts that became writable, or ACLs that no longer inherit as expected.
Then perform an end-to-end write test. Upload a disposable asset through the normal client, let Immich process it, open it, and remove it through the application. If external-library or import paths are part of your setup, add one representative file through those paths and confirm Immich can read it without changing ownership unexpectedly.
The prevention loop is complete only when new files continue receiving the intended identity and access after an Immich restart and a host reboot. If permissions require a manual repair after either event, the system is still drifting; fix the creation rule or identity mapping before expanding access.
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.
