Immich server fails to start on Debian Trixie host - ncrypto::CSPRNG assertion failure #8017

Open
opened 2026-02-05 13:28:21 +03:00 by OVERLORD · 11 comments
Owner

Originally created by @phoh on GitHub (Dec 8, 2025).

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

  • Yes

The bug

Immich server container fails to start with a Node.js CSPRNG assertion failure on
a Debian Trixie (13) host. The error occurs during Node.js initialization before
the application even starts.

Environment

  • Host OS: Debian GNU/Linux 13 (trixie)
  • Kernel: 6.12.57+deb13-amd64
  • Docker: Running via systemd
  • Immich Version: v2.3.1 (also tested v2.2.3 - same issue)
  • OpenSSL (host): 3.5.4

Error Message

Initializing Immich v2.3.1
Detected CPU Cores: 8

#  node[7]: std::shared_ptr<node::InitializationResultImpl>

node::InitializeOncePerProcessInternal(...) at ../src/node.cc:1235
# Assertion failed: ncrypto::CSPRNG(nullptr, 0)

----- Native stack trace -----

1: 0xf716e7 node::Assert(node::AssertionInfo const&) [node]
2: 0xf1e346 [node]
3: 0xf1f44c node::Start(int, char**) [node]
4: 0x7f...ca8 [/lib/x86_64-linux-gnu/libc.so.6]
5: 0x7f...d65 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
6: 0xe5cede _start [node]

The OS that Immich Server is running on

  • Host OS: Debian GNU/Linux 13 (trixie) - Kernel: 6.12.57+deb13-amd64 - Docker: Running via systemd

Version of Immich Server

v2.3.1 (also tested v2.2.3 - same issue)

Version of Immich Mobile App

2.3.0 build 2.3.6

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
      env_file:
        - .env
      ports:
        - '2283:2283'
      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:8@sha256:81db6d39e1bba3b3ff32bd3a1b19a6d69690f9
  4a3954ec131277b9a26b95b3aa
      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:b
  cf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
      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:

  This is the standard Immich docker-compose.yml - you can add this to the bug
  report under a "docker-compose.yml" section.

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=GB

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

  # 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=<REDACTED>

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

Reproduction steps

  1. Run Debian Trixie as Docker host
  2. Deploy Immich using standard docker-compose.yml
  3. Start or restart the immich-server container
  4. Container enters crash loop with exit code 134

Relevant log output


Additional information

The issue is specific to Immich's bundled Node.js binary.

Testing inside the same container environment:

  • Immich's bundled Node.js crashes immediately
  • Debian-packaged Node.js 20.19.2 works perfectly
  • node:22-slim Docker image works perfectly
  • /dev/urandom is accessible and produces random data

This fails (Immich's Node.js):

docker run --rm ghcr.io/immich-app/immich-server:v2 node -e "console.log('test')"

This works (Debian's Node.js inside same container):

docker run --rm --entrypoint /bin/sh ghcr.io/immich-app/immich-server:v2 -c
"apt-get update && apt-get install -y nodejs && /usr/bin/node -e
'console.log(require("crypto").randomBytes(8).toString("hex"))'"

Output: fd877f5b278967f5

Additional Notes

  • Issue persists with --privileged, --security-opt seccomp=unconfined, and
    --security-opt apparmor=unconfined
  • Issue affects both v2.3.1 and v2.2.3 images
  • Other containers (postgres, redis, machine-learning) work fine
  • The container was previously running for 2 days before a restart triggered this
    issue

Suggested Fix

The Node.js binary bundled in the Immich Docker image may need to be rebuilt with
compatibility for newer glibc/OpenSSL versions found in Debian Trixie, or replaced
with the distribution's Node.js package.

Originally created by @phoh on GitHub (Dec 8, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug Immich server container fails to start with a Node.js CSPRNG assertion failure on a Debian Trixie (13) host. The error occurs during Node.js initialization before the application even starts. Environment - Host OS: Debian GNU/Linux 13 (trixie) - Kernel: 6.12.57+deb13-amd64 - Docker: Running via systemd - Immich Version: v2.3.1 (also tested v2.2.3 - same issue) - OpenSSL (host): 3.5.4 Error Message Initializing Immich v2.3.1 Detected CPU Cores: 8 # node[7]: std::shared_ptr<node::InitializationResultImpl> node::InitializeOncePerProcessInternal(...) at ../src/node.cc:1235 # Assertion failed: ncrypto::CSPRNG(nullptr, 0) ----- Native stack trace ----- 1: 0xf716e7 node::Assert(node::AssertionInfo const&) [node] 2: 0xf1e346 [node] 3: 0xf1f44c node::Start(int, char**) [node] 4: 0x7f...ca8 [/lib/x86_64-linux-gnu/libc.so.6] 5: 0x7f...d65 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6] 6: 0xe5cede _start [node] ### The OS that Immich Server is running on - Host OS: Debian GNU/Linux 13 (trixie) - Kernel: 6.12.57+deb13-amd64 - Docker: Running via systemd ### Version of Immich Server v2.3.1 (also tested v2.2.3 - same issue) ### Version of Immich Mobile App 2.3.0 build 2.3.6 ### Platform with the issue - [x] Server - [ ] Web - [ ] Mobile ### Device make and model _No response_ ### Your docker-compose.yml content ```YAML # # 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 env_file: - .env ports: - '2283:2283' 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:8@sha256:81db6d39e1bba3b3ff32bd3a1b19a6d69690f9 4a3954ec131277b9a26b95b3aa 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:b cf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23 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: This is the standard Immich docker-compose.yml - you can add this to the bug report under a "docker-compose.yml" section. ``` ### Your .env content ```Shell # 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=GB # The Immich version to use. You can pin this to a specific version like "v2.1.0" IMMICH_VERSION=v2 # 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=<REDACTED> # The values below this line do not need to be changed ################################################################################## # DB_USERNAME=postgres DB_DATABASE_NAME=immich ``` ### Reproduction steps 1. Run Debian Trixie as Docker host 2. Deploy Immich using standard docker-compose.yml 3. Start or restart the immich-server container 4. Container enters crash loop with exit code 134 ### Relevant log output ```shell ``` ### Additional information The issue is specific to Immich's bundled Node.js binary. Testing inside the same container environment: - ❌ Immich's bundled Node.js crashes immediately - ✅ Debian-packaged Node.js 20.19.2 works perfectly - ✅ node:22-slim Docker image works perfectly - ✅ /dev/urandom is accessible and produces random data # This fails (Immich's Node.js): docker run --rm ghcr.io/immich-app/immich-server:v2 node -e "console.log('test')" # This works (Debian's Node.js inside same container): docker run --rm --entrypoint /bin/sh ghcr.io/immich-app/immich-server:v2 -c \ "apt-get update && apt-get install -y nodejs && /usr/bin/node -e 'console.log(require(\"crypto\").randomBytes(8).toString(\"hex\"))'" # Output: fd877f5b278967f5 Additional Notes - Issue persists with --privileged, --security-opt seccomp=unconfined, and --security-opt apparmor=unconfined - Issue affects both v2.3.1 and v2.2.3 images - Other containers (postgres, redis, machine-learning) work fine - The container was previously running for 2 days before a restart triggered this issue Suggested Fix The Node.js binary bundled in the Immich Docker image may need to be rebuilt with compatibility for newer glibc/OpenSSL versions found in Debian Trixie, or replaced with the distribution's Node.js package.
Author
Owner

@github-actions[bot] commented on GitHub (Dec 8, 2025):

This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

@github-actions[bot] commented on GitHub (Dec 8, 2025): This issue has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.
Author
Owner

@bo0tzz commented on GitHub (Dec 8, 2025):

Can you try removing and re-pulling the container image to ensure it isn't corrupted in some way?

@bo0tzz commented on GitHub (Dec 8, 2025): Can you try removing and re-pulling the container image to ensure it isn't corrupted in some way?
Author
Owner

@phoh commented on GitHub (Dec 8, 2025):

Re-pulling didn't fix the issue. Same error after complete image removal and fresh
pull:

Initializing Immich v2.3.1
Detected CPU Cores: 8

#  node[7]: ...node::InitializeOncePerProcessInternal(...) at

../src/node.cc:1235
# Assertion failed: ncrypto::CSPRNG(nullptr, 0)

Key finding: Debian's packaged Node.js 20.19.2 works perfectly inside the same
container:

docker run --rm --entrypoint /bin/sh ghcr.io/immich-app/immich-server:v2 -c
"apt-get update -qq && apt-get install -y -qq nodejs >/dev/null &&
/usr/bin/node -e
'console.log(require("crypto").randomBytes(8).toString("hex"))'"

Output: fd877f5b278967f5 ✓

@phoh commented on GitHub (Dec 8, 2025): Re-pulling didn't fix the issue. Same error after complete image removal and fresh pull: Initializing Immich v2.3.1 Detected CPU Cores: 8 # node[7]: ...node::InitializeOncePerProcessInternal(...) at ../src/node.cc:1235 # Assertion failed: ncrypto::CSPRNG(nullptr, 0) Key finding: Debian's packaged Node.js 20.19.2 works perfectly inside the same container: docker run --rm --entrypoint /bin/sh ghcr.io/immich-app/immich-server:v2 -c \ "apt-get update -qq && apt-get install -y -qq nodejs >/dev/null && \ /usr/bin/node -e 'console.log(require(\"crypto\").randomBytes(8).toString(\"hex\"))'" # Output: fd877f5b278967f5 ✓
Author
Owner

@bo0tzz commented on GitHub (Dec 9, 2025):

Are you running your kernel in FIPS mode?

@bo0tzz commented on GitHub (Dec 9, 2025): Are you running your kernel in FIPS mode?
Author
Owner

@YarosMallorca commented on GitHub (Dec 9, 2025):

I can run latest Immich successfully in a Debian 13 (trixie) VM without issue.

@YarosMallorca commented on GitHub (Dec 9, 2025): I can run latest Immich successfully in a Debian 13 (trixie) VM without issue.
Author
Owner

@pseudoseed commented on GitHub (Dec 9, 2025):

I'm experiencing the same issue. Here's my env::

Container OS: Debian GNU/Linux 13 (trixie)
glibc: 2.41-12
Node.js: v22.18.0 (Immich's bundled)
Image: ghcr.io/immich-app/immich-server:release (sha256:f8d06a32b1b2a81053d78e40bf8e35236b9faefb5c3903ce9ca8712c9ed78445)

Crash Details:

  • Exit code: 139 (Segmentation fault)
  • Crashes after: "Initializing Immich v2.3.1" and "Detected CPU Cores: 6"
  • Crashes when: Loading @nestjs/core or executing node dist/main.js
  • Versions affected: v2.2.2, v2.3.1 (both tested)

What works: Simple Node.js commands, crypto.randomBytes(), individual modules
What fails: App startup, NestJS module loading

Running on Kubernetes (k3s) with containerd runtime.

I am not running in FIPS mode fwiw.

@pseudoseed commented on GitHub (Dec 9, 2025): I'm experiencing the same issue. Here's my env:: **Container OS**: Debian GNU/Linux 13 (trixie) **glibc**: 2.41-12 **Node.js**: v22.18.0 (Immich's bundled) **Image**: `ghcr.io/immich-app/immich-server:release` (sha256:f8d06a32b1b2a81053d78e40bf8e35236b9faefb5c3903ce9ca8712c9ed78445) **Crash Details**: - Exit code: 139 (Segmentation fault) - Crashes after: "Initializing Immich v2.3.1" and "Detected CPU Cores: 6" - Crashes when: Loading `@nestjs/core` or executing `node dist/main.js` - Versions affected: v2.2.2, v2.3.1 (both tested) **What works**: Simple Node.js commands, `crypto.randomBytes()`, individual modules **What fails**: App startup, NestJS module loading Running on Kubernetes (k3s) with containerd runtime. I am not running in FIPS mode fwiw.
Author
Owner

@bo0tzz commented on GitHub (Dec 9, 2025):

@pseudoseed are you seeing the same ncrypto::CSPRNG assertion failure?

@bo0tzz commented on GitHub (Dec 9, 2025): @pseudoseed are you seeing the same ncrypto::CSPRNG assertion failure?
Author
Owner

@phoh commented on GitHub (Dec 11, 2025):

Are you running your kernel in FIPS mode?

no. FIPS mode is disabled.

@phoh commented on GitHub (Dec 11, 2025): > Are you running your kernel in FIPS mode? no. FIPS mode is disabled.
Author
Owner

@pseudoseed commented on GitHub (Dec 11, 2025):

are you seeing the same ncrypto::CSPRNG assertion failure?

I don't see the exact ncrypto::CSPRNG assertion failure message in my Kubernetes pod logs. The crash happens right after "Initializing Immich v2.3.1" and "Detected CPU Cores: 6", before that error gets logged. I see exit code 139 (segmentation fault). When I run node dist/main.js manually in the container, it crashes with the same exit code. But I haven't witnessed the exact log "ncrypto::CSPRNG" as the crash happens so early in the build.

@pseudoseed commented on GitHub (Dec 11, 2025): > are you seeing the same ncrypto::CSPRNG assertion failure? I don't see the exact ncrypto::CSPRNG assertion failure message in my Kubernetes pod logs. The crash happens right after "Initializing Immich v2.3.1" and "Detected CPU Cores: 6", before that error gets logged. I see exit code 139 (segmentation fault). When I run `node dist/main.js` manually in the container, it crashes with the same exit code. But I haven't witnessed the exact log "ncrypto::CSPRNG" as the crash happens so early in the build.
Author
Owner

@pseudoseed commented on GitHub (Dec 11, 2025):

This is super weird... I just redeployed my stack with ansible and terraform. Fresh new nodes and now everything is working again (with the persistent storage I setup). So I'm really confused at what the issue is... I've spent hours debugging lol

@pseudoseed commented on GitHub (Dec 11, 2025): This is super weird... I just redeployed my stack with ansible and terraform. Fresh new nodes and now everything is working again (with the persistent storage I setup). So I'm really confused at what the issue is... I've spent hours debugging lol
Author
Owner

@bo0tzz commented on GitHub (Dec 11, 2025):

Hmm. Any other nonstandard configuration? Can you reproduce this on a completely fresh VM?

@bo0tzz commented on GitHub (Dec 11, 2025): Hmm. Any other nonstandard configuration? Can you reproduce this on a completely fresh VM?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#8017