Can Immich Use an External Library Without Taking Ownership of the Files?

Yes. Immich can index an external library while the original files remain managed outside Immich; mount it read-only when Immich must not rename or delete the source.

This becomes a real compatibility question when family photos already live in a curated NAS tree and Immich should add search and browsing without becoming the file-of-record manager. Start with a disposable path or account, keep the previous working state available, and judge the design by the original workload rather than by a one-time connection test.

Separate the Supported Architecture From the Risky One

The supported branch is a read-only external library with separate writable uploads and application state. The competing branch is a writable source mount confused with Immich-managed upload storage. Record versions, identities, addresses, mount paths, permissions, and the current observable state before changing either branch.

The relevant Immich external libraries defines the first compatibility boundary. Use it to constrain the claim, then verify the same behavior on this exact home server instead of treating a documented feature as proof that the full design works.

Write the decision rule before testing: success must produce assets index and display while originals keep their paths, hashes, ownership, and delete protection; failure includes the scan misses permissions, edits imply source writes, or an action can remove or rename the original. This prevents a partial connection or clean command exit from being misread as end-to-end compatibility.

Reproduce the Exact Storage and Network Path

Use one controlled discriminator: mount a small representative folder read-only, create the external library, scan, edit metadata in Immich, and attempt delete plus filesystem rename tests. Hold the client, workload, file set, account, and timing constant so the changed component is the only plausible explanation.

Use read-only volume mounts to choose the second observation that matters for this path. Capture both sides of the transaction: resolver or route, negotiated protocol, process identity, exit status, latency, transferred bytes, and any recovery event.

Repeat the test after the lifecycle event named in the title—recreation, reconnect, remount, restart, failover, or client change. A design that works only while old sockets, caches, or credentials remain warm has not passed.

mount /photos:/external:ro -> scan pilot folder -> compare hashes -> test metadata edit and delete behavior

Interpret Durability, Timeout, and Recovery Results

PASS: assets index and display while originals keep their paths, hashes, ownership, and delete protection. Save the exact versions and topology that produced this state, because the conclusion applies to those conditions rather than every implementation of the protocol.

FAIL: the scan misses permissions, edits imply source writes, or an action can remove or rename the original. Check shared dependencies such as DNS, MTU, identity, firewall state, storage latency, and cached sessions before declaring either primary branch responsible.

EXCEPTION: remove the library definition without deleting files, restore the prior mount, and correct read-only path plus identity mapping. Do not widen privileges, delete source data, weaken transport security, or replace working storage until a repeatable observation identifies which boundary failed.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Keep the Design Only After a Restore-Grade Check

Apply only the action matched to the observed branch, then rerun the original workload. Keep the design only when assets index and display while originals keep their paths, hashes, ownership, and delete protection across two relevant lifecycle cycles and under the expected concurrent load.

Use the Immich read-only sources to verify the closest dependent workflow. Its access, timing, and recovery behavior must remain unchanged while the new design is active.

Stop and return to the saved state if the scan misses permissions, edits imply source writes, or an action can remove or rename the original. Escalate with timestamps, exact versions, route or mount evidence, and the smallest reproduction rather than adding another workaround.

Cross-check the result against the separate photo accounts so risk is not merely moved into another network, identity, backup, or storage layer.

For Immich external-library ownership, the qualified answer is therefore the opening judgment—not an unconditional yes. The observable pass state is the acceptance line; the fail state is the rollback line.

FAQ

Does removing an external library delete originals?

It should remove indexed records rather than source files, but verify current behavior on a disposable folder first.

Where do Immich-generated thumbnails live?

In Immich-managed writable storage, not in the read-only external library.

Can uploads and external assets appear together?

Yes, provided their lifecycle and backup policies stay distinct and paths do not overlap.