immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 12 Packages Projects Releases 10 Wiki Activity

Error reading input from user Error [ERR_USE_AFTER_CLOSE]: readline was closed #1047

New Issue
Closed
opened 2026-02-05 00:11:21 +03:00 by OVERLORD · 6 comments
OVERLORD commented 2026-02-05 00:11:21 +03:00
Owner
Copy Link

Originally created by @marviins87 on GitHub (Jul 2, 2023).

The bug

A few days ago I've successfully imported 50k+ photos to immich. They were all located in my existing library
/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo
Today I've created a new subdirectory with new photo's
/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01 - party

I'm trying to import this new directory in my account the same way like before but get the error below.

My user is configured with the following external path:
/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/

$ immich upload --key <MYAPIKEY> --server http://192.168.2.14:2283/api /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party --recursive --import
Checking connectivity with Immich instance...
Server status: OK
Checking credentials...
Login status: OK
Successful authentication for user ***@***.**
Indexing local assets...
Indexing complete, found 256 local assets
Comparing local assets with those on the Immich instance...
A total of 256 assets will be uploaded to the server
Error reading input from user  Error [ERR_USE_AFTER_CLOSE]: readline was closed
    at new NodeError (node:internal/errors:399:5)
    at Interface.question (node:internal/readline/interface:403:13)
    at Interface.question (node:readline:159:5)
    at answer (/usr/local/lib/node_modules/immich/bin/index.js:221:24)
    at new Promise (<anonymous>)
    at /usr/local/lib/node_modules/immich/bin/index.js:220:25
    at Generator.next (<anonymous>)
    at fulfilled (/usr/local/lib/node_modules/immich/bin/index.js:29:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_USE_AFTER_CLOSE'
}

What could cause this error? The importer is able to see the 256 new photo's but unable to upload them?

The OS that Immich Server is running on

OMV

Version of Immich Server

v1.65.0

Version of Immich Mobile App

v1.65.0 build.105

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

immich-server:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-server.sh"]
    volumes:
      - $UPLOAD_LOCATION:/usr/src/app/upload
      - /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo:/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo
    env_file:
      - stack.env
    environment:
      - NODE_ENV=production
    depends_on:
      - redis
      - database
      - typesense
    restart: always

  immich-microservices:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-microservices.sh"]
    volumes:
      - $UPLOAD_LOCATION:/usr/src/app/upload
      - /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo:/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo
    env_file:
      - stack.env
    environment:
      - NODE_ENV=production
    depends_on:
      - redis
      - database
      - typesense
    restart: always

Your .env content

-

Reproduction steps

1. Install immich inside container (npm i -g immich)
2. try to import the new directory with the following command:
immich upload --key <MYAPIKEY> --server http://192.168.2.14:2283/api /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party --recursive --import

Additional information

I'm not sure but it looks like the error only occurs when importing a subdirectory.
I didn't see this error when importing the root directory /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo the first time.

I've tried multiple subdirectory notations but all give the same error (the importer is always able to detect the 256 new photo's so it's probably not related to the notation):

  • /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party
  • "/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01 - party"
Originally created by @marviins87 on GitHub (Jul 2, 2023). ### The bug A few days ago I've successfully imported 50k+ photos to immich. They were all located in my existing library `/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo` Today I've created a new subdirectory with new photo's `/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01 - party` I'm trying to import this new directory in my account the same way like before but get the error below. My user is configured with the following external path: `/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/` ``` $ immich upload --key <MYAPIKEY> --server http://192.168.2.14:2283/api /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party --recursive --import Checking connectivity with Immich instance... Server status: OK Checking credentials... Login status: OK Successful authentication for user ***@***.** Indexing local assets... Indexing complete, found 256 local assets Comparing local assets with those on the Immich instance... A total of 256 assets will be uploaded to the server Error reading input from user Error [ERR_USE_AFTER_CLOSE]: readline was closed at new NodeError (node:internal/errors:399:5) at Interface.question (node:internal/readline/interface:403:13) at Interface.question (node:readline:159:5) at answer (/usr/local/lib/node_modules/immich/bin/index.js:221:24) at new Promise (<anonymous>) at /usr/local/lib/node_modules/immich/bin/index.js:220:25 at Generator.next (<anonymous>) at fulfilled (/usr/local/lib/node_modules/immich/bin/index.js:29:58) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) { code: 'ERR_USE_AFTER_CLOSE' } ``` What could cause this error? The importer is able to see the 256 new photo's but unable to upload them? ### The OS that Immich Server is running on OMV ### Version of Immich Server v1.65.0 ### Version of Immich Mobile App v1.65.0 build.105 ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML immich-server: image: altran1502/immich-server:release entrypoint: ["/bin/sh", "./start-server.sh"] volumes: - $UPLOAD_LOCATION:/usr/src/app/upload - /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo:/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo env_file: - stack.env environment: - NODE_ENV=production depends_on: - redis - database - typesense restart: always immich-microservices: image: altran1502/immich-server:release entrypoint: ["/bin/sh", "./start-microservices.sh"] volumes: - $UPLOAD_LOCATION:/usr/src/app/upload - /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo:/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo env_file: - stack.env environment: - NODE_ENV=production depends_on: - redis - database - typesense restart: always ``` ### Your .env content ```Shell - ``` ### Reproduction steps ```bash 1. Install immich inside container (npm i -g immich) 2. try to import the new directory with the following command: immich upload --key <MYAPIKEY> --server http://192.168.2.14:2283/api /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party --recursive --import ``` ### Additional information I'm not sure but it looks like the error only occurs when importing a subdirectory. I didn't see this error when importing the root directory /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo the first time. I've tried multiple subdirectory notations but all give the same error (the importer is always able to detect the 256 new photo's so it's probably not related to the notation): - /srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01\ -\ party - "/srv/dev-disk-by-uuid-6cd40146-725c-430e-90b2-83be61f23b38/photo/archive/2023-07-01 - party"
OVERLORD commented 2026-02-05 00:11:27 +03:00
Author
Owner
Copy Link

@LordVaderXIII commented on GitHub (Jul 6, 2023):

Im having the same issue.

@LordVaderXIII commented on GitHub (Jul 6, 2023): Im having the same issue.
OVERLORD commented 2026-02-05 00:11:29 +03:00
Author
Owner
Copy Link

@ghzgod commented on GitHub (Jul 8, 2023):

Same issue

@ghzgod commented on GitHub (Jul 8, 2023): Same issue
OVERLORD commented 2026-02-05 00:11:32 +03:00
Author
Owner
Copy Link

@apigban commented on GitHub (Jul 10, 2023):

Experiencing the same error on my setup, found weird behaviour:

  • Running the immich command inside the container doesn't give an error

  • using crontab to run the upload/import command outside the container produces the issue like

    docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y produces the issue.

@apigban commented on GitHub (Jul 10, 2023): Experiencing the same error on my setup, found weird behaviour: - Running the immich command inside the container doesn't give an error - using crontab to run the upload/import command outside the container produces the issue like `docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y` produces the issue.
OVERLORD commented 2026-02-05 00:11:38 +03:00
Author
Owner
Copy Link

@marviins87 commented on GitHub (Jul 10, 2023):

  • Running the immich command inside the container doesn't give an error
  • using crontab to run the upload/import command outside the container produces the issue like
    docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import produces the issue.

That's a very good find! I've just tested this and can confirm that the import is succesfull when running the command from inside the container (portainer console) .

@marviins87 commented on GitHub (Jul 10, 2023): > * Running the immich command inside the container doesn't give an error > * using crontab to run the upload/import command outside the container produces the issue like > `docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import` produces the issue. That's a very good find! I've just tested this and can confirm that the import is succesfull when running the command from inside the container (portainer console) .
OVERLORD commented 2026-02-05 00:11:44 +03:00
Author
Owner
Copy Link

@apigban commented on GitHub (Jul 10, 2023):

My cronjobs (outside the container) was successful when I use the -i option for docker:

docker exec -i immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y.

@apigban commented on GitHub (Jul 10, 2023): My cronjobs (outside the container) was successful when I use the `-i` option for docker: `docker exec -i immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y`.
OVERLORD commented 2026-02-05 00:11:52 +03:00
Author
Owner
Copy Link

@exil0867 commented on GitHub (Jul 11, 2023):

Experiencing the same error on my setup, found weird behaviour:

* Running the immich command inside the container doesn't give an error

* using crontab to run the upload/import command outside the container produces the issue like
  `docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y` produces the issue.

Adding -y flag to my command fixed the issue, thanks!

@exil0867 commented on GitHub (Jul 11, 2023): > Experiencing the same error on my setup, found weird behaviour: > > * Running the immich command inside the container doesn't give an error > > * using crontab to run the upload/import command outside the container produces the issue like > `docker exec immich_server /bin/sh /usr/local/bin/immich upload --key <KEY> --server http://<IP>:<PORT>/api /mnt/<PATH>/<TO>/<MNT> --recursive --import -y` produces the issue. Adding `-y` flag to my command fixed the issue, thanks!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1047
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?