Why Does a Photo Library Show Duplicates Only After Enabling an External Library?

Duplicates that appear only after enabling an external library usually mean the same photo has entered the database through two different ingestion paths.

Do not begin by deleting cards that look identical. First determine whether the application created two records for one physical file, indexed an uploaded copy plus the external original, or found a genuinely different edited file. The repair is to remove the overlapping ingestion boundary while preserving the authoritative asset and its ownership.

Prove Whether the Duplicate Is Physical or Database-Level

Pick one duplicated photo and compare its filesystem path, size, checksum, capture timestamp, and library record ID. Two UI cards do not automatically mean two physical copies exist.

An external-library asset handling can expose files that were already uploaded through another path, creating two application records even when the household stores only one underlying image.

If both records resolve to the same physical content through different library roots, this is an ingestion-boundary problem. If two files really exist, diagnose the copy workflow instead.

Map Every Path That Can Index the Same Folder

Write down the upload directory, external-library roots, bind mounts, synchronization destinations, and any nested folder that points back into another indexed tree.

Self-hosted photo setups often separate managed uploads and watched storage; understanding those Immich library boundaries makes overlapping roots easier to spot than searching the UI for a generic deduplicate button.

Disable or narrow one overlapping source in a test library. If the second record disappears after a supported rescan while the file remains accessible, keep one authoritative ingestion path.

Separate Ownership From File Identity

Compare who owns each library record and whether one copy was uploaded by a user while the external library indexes the same file for an administrator or service account.

A typical self-hosted Immich storage path uses several services and storage locations, so identical bytes can enter the application with different ownership or lifecycle rules.

Do not merge records blindly when ownership affects albums, sharing, deletion, or face metadata. Choose the path whose lifecycle matches how the household expects that photo to be managed.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Check Exact Copies Against Edited Variants

Before deleting anything, compare checksums and pixel dimensions. A phone edit, sidecar-applied export, or metadata rewrite can look identical in the gallery while being a genuinely different file.

Storage planning for Immich emphasizes deliberate Immich external storage planning; that distinction matters when an external tree contains originals, edited exports, and already imported managed copies side by side.

Use exact-content evidence for true duplicates and keep edited derivatives when they carry intended changes. A visual similarity score alone is not a safe deletion rule.

Choose One Ingestion Boundary and Verify

After selecting the authoritative source, remove only the overlapping library definition or duplicate managed copy using supported application actions. Keep an independent backup until album and sharing behavior is verified.

The related ZimaSpace workflow for duplicate-photo migration workflow is useful here because it treats duplicate cleanup as a migration decision rather than a bulk-delete shortcut.

Retest with one new phone upload and one file added to the external folder. The repair is stable when each new asset enters exactly once and survives a rescan without producing a second record.