Who Can Edit an Immich External Library?

An Immich account owning an external library does not automatically have permission to change its files. The account assignment controls ownership inside the application; the filesystem mount controls what the server can write. For a photo archive already curated in desktop software, decide which application should make lasting metadata changes before granting write access.

Choose an editor, not just a viewer

An external library lets a self-hosted Immich server index photographs where they already live. It is a useful way to browse a NAS archive without turning that archive into an upload destination. According to the external-library documentation, each library belongs to one selected user, and the owner cannot be changed later through library creation settings.

That account choice is separate from the storage permission. A Docker mount ending in :ro gives the container read-only access to that mounted path. Immich can read the pictures, but that route cannot be used to write sidecars or delete the original files. Other programs with their own writable access to the host directory are not restricted by this container setting.

For a household archive, the useful question is therefore not simply whether Immich displays the pictures. It is whether Immich should join the desktop editor as a writer.

A sidecar write needs permission on disk

XMP sidecars are companion files containing metadata rather than another copy of the photograph. Immich documents reading selected fields from these files and writing supported changes back to them. In an external library, write-back targets the sidecar beside the original media, provided the mount is writable.

The current XMP documentation warns that metadata edits on a read-only external mount can fail silently, without updating either the sidecar or the database. A description or rating appearing editable in the interface is consequently not evidence that the change has been saved. This limitation is particularly important when a reader expects read-only storage to mean that edits will simply become private database annotations.

Making the mount writable is not a harmless display fix. It expands the server's authority over that archive, including the ability to delete files. A failed metadata edit should prompt an ownership decision, not an automatic removal of the read-only boundary.

Supported fields do not make every editor interchangeable

Immich's documented XMP support covers specific description, rating, date, location and tag fields. The documentation says writes merge with existing sidecar fields rather than replacing the entire file, but it also lists fields that remain in the sidecar without becoming searchable in Immich. Lightroom editing instructions, for example, should not be mistaken for an Immich search feature.

Sidecar discovery also depends on naming. For a photograph named garden.jpg, the preferred companion name is garden.jpg.xmp; garden.xmp is the fallback. When both exist, Immich prefers the extension-qualified file. Two applications looking at different companions can therefore appear to disagree even before permissions enter the picture.

The documented jobs have different purposes: DISCOVER associates new sidecars, while SYNC rereads already associated sidecars after external changes. Neither job grants write permission. A home server needs both an intentional file layout and an intentional refresh policy.

Pick a policy the household can explain

There are two reasonable starting positions, with different responsibilities:

• Desktop editor owns metadata: retain a read-only mount for Immich, make supported changes in the archive's existing editor, and refresh Immich's view through the documented scan and sidecar jobs. Do not promise that Immich-side metadata editing will persist.
• Immich may write metadata: allow write access only after accepting its wider file authority, backing up the archive and sidecars, and checking the exact fields that matter with disposable copies. Avoid simultaneous editing of the same sidecar by competing applications.

Neither policy requires a new home-server platform. The prerequisites are administrative control of the Immich library, knowledge of the container's actual mount permissions, and access to the archive's existing editing and backup workflow. Desktop software and NAS permissions may impose additional limits even when a Docker mount is writable.

Protect the catalogue as well as the photographs

External folders should not be reorganised casually after indexing. Immich's library documentation warns that moving an external asset can cause it to be treated as a new asset on rescan, losing associated application metadata. A folder tidy-up is therefore a catalogue change, not merely a cosmetic filesystem operation.

Likewise, XMP support does not turn the sidecar into a complete export of the service. Immich's backup guidance requires database and file protection together; a database backup does not contain the photographs. Include external originals and their sidecars in the backup scope rather than assuming that an automatic database dump covers the mounted archive.

The decision is complete when the household knows where to make an edit, where that edit must persist, and which backup would recover it. A protected archive that remains browseable is a valid result even when its metadata must be edited somewhere other than Immich.