External Library Scan Doesn't Import Medias

[alexNMD]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

When scanning an external library, Immich successfully crawls and detects all files (11,388 files in my case), but then immediately marks the library as empty and doesn't process any imports. The files remain invisible in the UI, and no import jobs are executed.

• Files are accessible from both containers (ls -la works)
• Permissions allow reading files
• File formats are supported by Immich

The OS that Immich Server is running on

Debian GNU/Linux 13 (trixie)

Version of Immich Server

v2.4.1

Version of Immich Mobile App

v2.5.0

Platform with the issue

• Server
• Web
• Mobile

Device make and model

No response

Your docker-compose.yml content

#
# WARNING: To install Immich, follow our guide: https://docs.immich.app/install/docker-compose
#
# Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
#      - /media/Armoire/Images_Voyages:/media/Armoire/Images_Voyages
      - /media/Armoire/Images/iCloud:/media/Armoire/Images/iCloud
      - ./stream:/media/stream
    env_file:
      - .env
    environment:
      IMMICH_WORKERS_INCLUDE: 'api'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
#      - /media/Armoire/Images_Voyages:/media/Armoire/Images_Voyages
      - /media/Armoire/Images/iCloud:/media/Armoire/Images/iCloud
      - ./stream:/media/stream
    env_file:
      - .env
    environment:
      IMMICH_WORKERS_EXCLUDE: 'api'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://docs.immich.app/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:fb8d272e529ea567b9bf1302245796f21a2672b8368ca3fcb938ac334e613c8f
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
      # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
      # DB_STORAGE_TYPE: 'HDD'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always

volumes:
  model-cache:


networks:
  default:
    name: traefik
    external: true

Your .env content

# You can find documentation for all the supported env variables at https://docs.immich.app/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=./library

# The location where your database files are stored. Network shares are not supported for the database
DB_DATA_LOCATION=./postgres

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
# TZ=Etc/UTC

# The Immich version to use. You can pin this to a specific version like "v2.1.0"
IMMICH_VERSION=v2.4.1

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=postgres

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

volumes:
  - /media/Armoire/Images/iCloud:/media/Armoire/Images/iCloud

1. Create an external library in the UI pointing to /media/Armoire/Images/iCloud (from admin panel)
2. Trigger a library scan from the UI

Actual Behavior

What happens:

1. Crawl succeeds - immich-microservices logs show:

[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Starting disk crawl of 1 import path(s) for library 21b8d080-a504-41e7-8ee0-ea0491409155...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Crawled 10000 file(s) so far: 10000 of current batch of 10000 will be imported...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Crawled 11388 file(s) so far: 1388 of current batch of 1388 will be imported...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Finished disk crawl, 11388 file(s) found on disk and queued 11388 file(s) for import into 21b8d080-a504-41e7-8ee0-ea0491409155

2. Immediately marked as empty - Very next line:

[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Library 21b8d080-a504-41e7-8ee0-ea0491409155 is empty, no need to check assets

3. No further processing - After 24+ hours:
   • No files appear in the library folder view
   • immich-microservices logs show no import activity when triggering scan
   • immich-server logs only show the scan request:

[Nest] 31  - 02/05/2026, 7:35:20 PM   DEBUG [Api:LoggingInterceptor] PUT /api/jobs/library 200 27.61ms
[Nest] 31  - 02/05/2026, 7:35:20 PM VERBOSE [Api:LoggingInterceptor] {"command":"start"}

Relevant log output

[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Starting disk crawl of 1 import path(s) for library 21b8d080-a504-41e7-8ee0-ea0491409155...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Crawled 10000 file(s) so far: 10000 of current batch of 10000 will be imported...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Crawled 11388 file(s) so far: 1388 of current batch of 1388 will be imported...
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Finished disk crawl, 11388 file(s) found on disk and queued 11388 file(s) for import into 21b8d080-a504-41e7-8ee0-ea0491409155
[Nest] 7  - 02/05/2026, 7:15:37 PM     LOG [Microservices:LibraryService] Library 21b8d080-a504-41e7-8ee0-ea0491409155 is empty, no need to check assets

Additional information

No response

[LeLunZ]

@alexNMD just saw your path is /media/Armoire/Images/iCloud
Is that an actual icloud folder, where images can get synced to your phone?

---

if it works similar to mac os/windows etc. these images aren't automatically downloaded, which would mean immich cant see them

[alexNMD]

@LeLunZ No isn't a sync path, it's just my iCloud photos on lambda directory.

And i tried with multiple directory and i'm facing the same issue...

[LeLunZ]

What exactly do you mean with lambda directory? Thats not a normal directory, by howit sounds :)

[alexNMD]

It's just a directory with photos inside.

No link with cloud or something like that.

[alexNMD]

Additional informations :

Task seems to be stucked :

And when i click on "Delete tasks on error" all tasks is deleted
Nothings showed on the logs...

[ronbeernink-byte]

I hit this same behavior on Immich v3.0.3 and was able to isolate the root cause in my case. On the advice from Cloude AI, I did the following:

My External Library scan repeatedly crawled correctly (13,584+ files found) but consistently reported "0 file(s) queued for import" on every fresh scan attempt — including with refreshAllFiles: true via the API.

Digging into the server logs, I found the actual trigger:

ERROR [Microservices:LibraryService] Error processing /path/to/file.JPG for library : Error: ENOENT: no such file or directory, stat '/path/to/file.JPG'

immediately followed by:

PostgresError: syntax error at or near ")"
sql: 'insert into "asset" () values returning "id"'

Root cause: two files in my library had stale/phantom directory entries on the NAS side (a WD My Book Live) — ls listed them (with a trailing ? on the permission bits, e.g. -rwxrwxrwx?), but stat()/md5sum confirmed they didn't actually exist. This is NAS-side directory corruption, not an Immich-caused issue.

However, when Immich's LibrarySyncFiles job hit these ENOENT errors mid-batch, it appears the failed file(s) were excluded from the batch's data but not from the SQL parameter list, resulting in a malformed insert into "asset" () values with zero columns — which Postgres correctly rejects, but the failure kills the entire batch job, not just the offending file(s). This meant the other ~9,998 valid files in that batch of 10,000 also failed to import, and the same batch would be retried identically on every subsequent scan (since the same phantom entries kept getting hit), producing the "always finds files but never imports" symptom described in this issue.

Workaround: rebooting the NAS cleared its stale directory cache, which removed the phantom entries and allowed a clean scan to complete.

Suggested fix: the batch insert logic should skip/log individual file failures without invalidating the whole batch's SQL insert — a single bad stat() shouldn't be able to take down 9,999 valid imports alongside it.