starred/immich

Fork 0

mirror of https://github.com/immich-app/immich.git synced 2026-03-02 22:57:45 -05:00

[Server/Linux] Corrupted zip of album worth 2.9GB (Fail to download album) #6022

New issue

Closed

opened 2026-02-20 04:07:28 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-20 04:07:28 -05:00

Owner

Originally created by @ngdangtu-vn on GitHub (Jul 22, 2025).

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

The bug

I tried to download an album worth 2.9GiB and received a corrupted zip file. The zipping process seems to work fine on small file (around 10MB) but for 2.9GiB its size got compressed down to 2GiB and impossible to open with Ark app (zip software in Linux/KDE plasma).

This bug continues from this error #20093 (In another word, it compressed sync photos that could be failed)

The OS that Immich Server is running on

Linux hostname 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux

Version of Immich Server

v1.135.3 => v1.136.0

Version of Immich Mobile App

v1.135.3

Platform with the issue

Server
Web
Mobile

Your docker-compose.yml content

#
# WARNING: To install Immich, follow our guide: https://immich.app/docs/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}:/usr/src/app/upload
      - /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://immich.app/docs/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-bookworm@sha256:fec42f399876eb6faf9e008570597741c87ff7662a54185593e74b09ce83d177
    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
    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
    restart: always

volumes:
  model-cache:

Your .env content

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

# The location where your uploaded files are stored
UPLOAD_LOCATION=$P_DB/immich/gallery

# The location where your database files are stored. Network shares are not supported for the database
DB_DATA_LOCATION=$P_DB/immich/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=Asia/Ho_Chi_Minh

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

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

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

Reproduction steps

follow reproduction steps in issue #20093
go to web version
go to album page: :2283/albums
right click on the album
select download and wait for server compressing

=> After zipping completed, it expects to have a smaller filesize yet totally useless as unzip doesn't see as zip file (could be corrupted file or incorrect file header).

other attempt

in step 3, instead of go to album index page, I went to album content page (:2283/albums/${id}) and click on download icon => still corrupted

Relevant log output

[Nest] 16  - 07/23/2025, 5:50:57 AM   DEBUG [Api:LoggingInterceptor~t3m9lgjt] POST /api/download/info 201 24.89ms ::ffff:192.168.31.56
[Nest] 16  - 07/23/2025, 5:50:57 AM VERBOSE [Api:LoggingInterceptor~t3m9lgjt] {"albumId":"9fefec5e-36e1-4753-969a-d237e4b32e5a","archiveSize":4294967296}
[Nest] 16  - 07/23/2025, 5:50:58 AM   DEBUG [Api:LoggingInterceptor~x9ngzayu] POST /api/download/archive 200 413.87ms ::ffff:192.168.31.56
[Nest] 16  - 07/23/2025, 5:50:58 AM VERBOSE [Api:LoggingInterceptor~x9ngzayu] {"assetIds":["9c132e98-0a3e-40a8-b73c-4fcf88d23d8e","2e84e942-2b2e-4aa3-92e2-d497cd2b738d","57a8f35e-fd8e-4a54-8faf-a658008709fa","3f5b9564-122e-4398-86bc-a4c1e30e4262","9b8fa304-96cd-408f-ac94-dd0375b88fb3","5291ee37-c167-41f9-bf2b-355d29401c66","f0ae5e19-7b95-4111-baaf-18ae51f5d014","c7770977-9222-44ae-9127-0a4af3c40507","e6a6245f-d529-4a90-9dad-e14f03013cd9","999d8bf7-90fb-45d9-9c06-72b5a038efb4","d9161eea-9efd-49a7-a98e-a31351f259cb","a63ce2b7-9fe7-416e-a492-159b4d442b22","c9690d70-60f6-4682-8beb-f1fda8e54f8f","a3763d64-d9d3-4da9-87f5-d3f50abbf577","c68a71f1-a8e6-460f-a37d-c8c0584e6ade","eb9e2643-5e93-4922-b7c8-95e9cd97dc50","0c1c62a4-a6fb-4068-a555-710077020c6e","23ed562c-fb7b-47ae-86e9-92d485afb910","0bd6ba97-c387-4f1c-be98-4a0d7ff58a58","30f575e7-8ebd-479d-a3ca-6e6038ab0d01","abd0d42c-93ea-4168-95de-eaa8c3c92b26","b2c35516-cd2e-4e55-a0e2-ea8a7643ffbe","2a863327-88ec-46e1-926f-fc62ae1d1231","36be1e44-29ce-4fa4-b228-70357c38e4b3","ce2c15c7-a969-45a2-85c7-13e5b85ad004","4be294f8-403f-4c47-93e0-bd1075fe7664","66b06ee4-19be-4159-81f8-5d5852e9ed4b","f60a2d56-70ba-4f88-bb6f-305c038f7b1f","4e9e1c13-71bc-4ed5-aa3d-917dde5c6ff7","f010a2cd-27ed-4e0c-ab97-6d430944e39f","04f39ab5-e113-48a5-b96b-c79bca5f2270","883831ce-dfde-44a4-bef0-183966b01595","07698cd3-82f8-4f62-9bcc-9226941dff62","12a85e1e-e4c1-45a1-b78e-0c0b6c60cbbe","4fc2d350-37a8-4d62-81c9-1d67d7534ff1","9a56abb0-ab9b-4917-b18d-4cbdd62db2c1","be53063c-49e1-4cfd-9637-42704b49316c","c0607c70-4542-4c50-8ed2-9bba3f419f4e","e4c98098-5804-402e-b235-c79a3d8c856f","c90a0c24-e9a5-446f-b784-1d80f411ed21","89e8aeb9-2dc9-4ef8-b705-5bb3828576cb","f96c0589-b96d-445e-8dd7-a70706ccf480","769cd311-4fd1-47c5-9d65-543f1ef512e4","5eed3685-4291-4430-957e-b7a6fb119bc9","b38dab7a-a0d0-40ba-bde8-8d83c4fe53f3","45eaa9d2-b14a-4da9-8210-64c87bf605e3","f3a64dd0-0ee6-4f6f-8a65-6ca595c4cbe5","aa7588b7-8e6b-47f6-994e-845e0a848a98","69924089-dc72-4b56-9a1a-92badb21c83a","ed4d1f1f-ef14-4c10-8007-cbf95b7836d4","8201e21b-cbc4-48ed-9942-0a6f320d269f","5f5324f7-5d2a-481f-90be-6f6c5b589f56","f9a509aa-5943-49b6-b470-8f7e37b47373","c9507378-70c1-4079-9c12-2587df7e6fd1","6cb4d267-3291-4d46-8319-dbf9486e70bd","2fa60797-2b7f-4f2f-86b0-7f29ab25c8ce","b8ebfe4c-c974-4825-b1e5-ecaf72446136","9a550cad-f2db-468d-b590-5db15697f93f","d961a386-d7a1-4dc2-813d-ea6f0df22dc1","0a9d401b-dd8e-4a2e-843b-fe68718ca18f","1a4a7a36-41a8-4b60-9edf-350022648c2f","7d2874cd-bc35-442a-a3f7-f68efc441055","100e5a6d-4c89-4f8e-9582-7583b5b499e6","753e738a-a224-4436-9320-10a0bc40bf43","7b947000-df6e-425f-a6f2-82b3216229c1","2a37c093-a1a2-441e-8c15-c9455c503a2b","14cb6835-a932-430a-9d80-46014f130314","cff5bf87-2284-476f-bd6e-30b7536ebc13","9842782b-c1d1-46cd-9816-3f2c2a6d45db","58cbd89c-0a78-4ca3-a496-363b1b1ec7bd","eb52b502-a5ec-41cd-8829-a62bfc1c412c","0cefc4bc-27a9-40a2-8328-d129882b3007","2bd90bd6-9358-472c-bbd6-5a4944de97dd","95926482-c617-492f-b3ff-e320ba691bd1","9c86b90f-d847-4a96-a42c-fefff953081c","7ac3573a-68b8-41b3-90ae-cb494d764805","43a3a11c-91a2-4760-966c-a0e22c12a6e7","32475c09-ff3c-4d53-a045-46d10b999b3c","ac43c98c-3b68-4eb0-bc49-ee869feee780","b0f4d986-b70c-4670-9c2d-841a8378c471","a3bc348a-ec86-48b4-8f21-59b814b81e35","f8af9bd3-817a-4e62-8ce6-63dba812920c","32a962d5-0579-424f-a08c-a679e5de69f8","8a0dc669-f220-4a1b-8c3c-4449a9e9c128","7e1e9bd2-d076-4dcb-ae77-444e5a4c1173","563c15cb-7267-425a-8f2e-1e2d31edcc1f","7b574c7d-0979-46a7-8dba-c2c053aab1f7","63e1bde4-0ec1-41ef-865a-2fd37d3ed6dc","78182c73-c4ab-4c98-8c3e-ca3943276db3","b242ea79-9a97-4114-a441-f0e57ec55911","c0907d96-a9c4-4538-94c1-f3c17918c680","d0d18340-17c9-42b7-b8ae-f542a79654a5","6cd3868f-bf86-4c17-bb7d-7f9e634424a3","3c4434a4-43f5-4f1a-bc83-ac5b261c671f","fdbc3cd9-be5e-4336-82d1-50bdf60fe6e1","6d8dd291-b19d-4314-a4e2-53712c51ec8a","7ba670e8-4fda-4a3f-ac36-3b803db44d1d","4c146962-313a-4c90-bc21-ce3135886145","88802685-4005-42c3-a9da-8c3b0cff4de4","51c83896-7473-49fc-86a8-f051543ab2e5","...and 349 more"]}
[Nest] 16  - 07/23/2025, 5:51:11 AM   DEBUG [Api:LoggingInterceptor~s4ug2hqs] GET /api/server/ping 200 0.58ms ::ffff:127.0.0.1
[Nest] 16  - 07/23/2025, 5:51:41 AM   DEBUG [Api:LoggingInterceptor~wckf8p4x] GET /api/server/ping 200 0.71ms ::ffff:127.0.0.1
[Nest] 16  - 07/23/2025, 5:52:11 AM   DEBUG [Api:LoggingInterceptor~z95hphoe] GET /api/server/ping 200 0.62ms ::ffff:127.0.0.1

Additional information

Error from Ark

Loading the archive ‘$HOME/album-name-20250723_055057.zip’ failed with the following error:
Failed to open archive: Not a zip archive

Error from unzip

$ unzip -t album-name-20250723_055057.zip 
Archive:  album-name-20250723_055057.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of album-name-20250723_055057.zip or
        album-name-20250723_055057.zip.zip, and cannot find album-name-20250723_055057.zip.ZIP, period.

Originally created by @ngdangtu-vn on GitHub (Jul 22, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug I tried to download an album worth 2.9GiB and received a corrupted zip file. The zipping process seems to work fine on small file (around 10MB) but for 2.9GiB its size got compressed down to 2GiB and impossible to open with [Ark app](https://apps.kde.org/ark) (zip software in Linux/KDE plasma). This bug continues from this error #20093 (In another word, it compressed sync photos that could be failed) ### The OS that Immich Server is running on Linux hostname 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux ### Version of Immich Server `v1.135.3` => `v1.136.0` ### Version of Immich Mobile App v1.135.3 ### Platform with the issue - [x] Server - [x] Web - [ ] Mobile ### <details> <summary> <h3>Your docker-compose.yml content</h3> </summary> ```YAML # # WARNING: To install Immich, follow our guide: https://immich.app/docs/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}:/usr/src/app/upload - /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://immich.app/docs/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-bookworm@sha256:fec42f399876eb6faf9e008570597741c87ff7662a54185593e74b09ce83d177 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 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 restart: always volumes: model-cache: ``` </details> <details> <summary> <h3>Your .env content</h3> </summary> ```Shell # You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables # The location where your uploaded files are stored UPLOAD_LOCATION=$P_DB/immich/gallery # The location where your database files are stored. Network shares are not supported for the database DB_DATA_LOCATION=$P_DB/immich/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=Asia/Ho_Chi_Minh # The Immich version to use. You can pin this to a specific version like "v1.71.0" IMMICH_VERSION=release # 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=************************** # The values below this line do not need to be changed ################################################################################### DB_USERNAME=postgres DB_DATABASE_NAME=immich ``` ### Reproduction steps 1. follow reproduction steps in issue #20093 2. go to web version 3. go to album page: `:2283/albums` 4. right click on the album 5. select download and wait for server compressing => After zipping completed, it expects to have a smaller filesize yet totally useless as `unzip` doesn't see as zip file (could be corrupted file or incorrect file header). **other attempt** - in step 3, instead of go to album index page, I went to album content page (`:2283/albums/${id}`) and click on download icon => still corrupted ### Relevant log output ```shell [Nest] 16 - 07/23/2025, 5:50:57 AM DEBUG [Api:LoggingInterceptor~t3m9lgjt] POST /api/download/info 201 24.89ms ::ffff:192.168.31.56 [Nest] 16 - 07/23/2025, 5:50:57 AM VERBOSE [Api:LoggingInterceptor~t3m9lgjt] {"albumId":"9fefec5e-36e1-4753-969a-d237e4b32e5a","archiveSize":4294967296} [Nest] 16 - 07/23/2025, 5:50:58 AM DEBUG [Api:LoggingInterceptor~x9ngzayu] POST /api/download/archive 200 413.87ms ::ffff:192.168.31.56 [Nest] 16 - 07/23/2025, 5:50:58 AM VERBOSE [Api:LoggingInterceptor~x9ngzayu] {"assetIds":["9c132e98-0a3e-40a8-b73c-4fcf88d23d8e","2e84e942-2b2e-4aa3-92e2-d497cd2b738d","57a8f35e-fd8e-4a54-8faf-a658008709fa","3f5b9564-122e-4398-86bc-a4c1e30e4262","9b8fa304-96cd-408f-ac94-dd0375b88fb3","5291ee37-c167-41f9-bf2b-355d29401c66","f0ae5e19-7b95-4111-baaf-18ae51f5d014","c7770977-9222-44ae-9127-0a4af3c40507","e6a6245f-d529-4a90-9dad-e14f03013cd9","999d8bf7-90fb-45d9-9c06-72b5a038efb4","d9161eea-9efd-49a7-a98e-a31351f259cb","a63ce2b7-9fe7-416e-a492-159b4d442b22","c9690d70-60f6-4682-8beb-f1fda8e54f8f","a3763d64-d9d3-4da9-87f5-d3f50abbf577","c68a71f1-a8e6-460f-a37d-c8c0584e6ade","eb9e2643-5e93-4922-b7c8-95e9cd97dc50","0c1c62a4-a6fb-4068-a555-710077020c6e","23ed562c-fb7b-47ae-86e9-92d485afb910","0bd6ba97-c387-4f1c-be98-4a0d7ff58a58","30f575e7-8ebd-479d-a3ca-6e6038ab0d01","abd0d42c-93ea-4168-95de-eaa8c3c92b26","b2c35516-cd2e-4e55-a0e2-ea8a7643ffbe","2a863327-88ec-46e1-926f-fc62ae1d1231","36be1e44-29ce-4fa4-b228-70357c38e4b3","ce2c15c7-a969-45a2-85c7-13e5b85ad004","4be294f8-403f-4c47-93e0-bd1075fe7664","66b06ee4-19be-4159-81f8-5d5852e9ed4b","f60a2d56-70ba-4f88-bb6f-305c038f7b1f","4e9e1c13-71bc-4ed5-aa3d-917dde5c6ff7","f010a2cd-27ed-4e0c-ab97-6d430944e39f","04f39ab5-e113-48a5-b96b-c79bca5f2270","883831ce-dfde-44a4-bef0-183966b01595","07698cd3-82f8-4f62-9bcc-9226941dff62","12a85e1e-e4c1-45a1-b78e-0c0b6c60cbbe","4fc2d350-37a8-4d62-81c9-1d67d7534ff1","9a56abb0-ab9b-4917-b18d-4cbdd62db2c1","be53063c-49e1-4cfd-9637-42704b49316c","c0607c70-4542-4c50-8ed2-9bba3f419f4e","e4c98098-5804-402e-b235-c79a3d8c856f","c90a0c24-e9a5-446f-b784-1d80f411ed21","89e8aeb9-2dc9-4ef8-b705-5bb3828576cb","f96c0589-b96d-445e-8dd7-a70706ccf480","769cd311-4fd1-47c5-9d65-543f1ef512e4","5eed3685-4291-4430-957e-b7a6fb119bc9","b38dab7a-a0d0-40ba-bde8-8d83c4fe53f3","45eaa9d2-b14a-4da9-8210-64c87bf605e3","f3a64dd0-0ee6-4f6f-8a65-6ca595c4cbe5","aa7588b7-8e6b-47f6-994e-845e0a848a98","69924089-dc72-4b56-9a1a-92badb21c83a","ed4d1f1f-ef14-4c10-8007-cbf95b7836d4","8201e21b-cbc4-48ed-9942-0a6f320d269f","5f5324f7-5d2a-481f-90be-6f6c5b589f56","f9a509aa-5943-49b6-b470-8f7e37b47373","c9507378-70c1-4079-9c12-2587df7e6fd1","6cb4d267-3291-4d46-8319-dbf9486e70bd","2fa60797-2b7f-4f2f-86b0-7f29ab25c8ce","b8ebfe4c-c974-4825-b1e5-ecaf72446136","9a550cad-f2db-468d-b590-5db15697f93f","d961a386-d7a1-4dc2-813d-ea6f0df22dc1","0a9d401b-dd8e-4a2e-843b-fe68718ca18f","1a4a7a36-41a8-4b60-9edf-350022648c2f","7d2874cd-bc35-442a-a3f7-f68efc441055","100e5a6d-4c89-4f8e-9582-7583b5b499e6","753e738a-a224-4436-9320-10a0bc40bf43","7b947000-df6e-425f-a6f2-82b3216229c1","2a37c093-a1a2-441e-8c15-c9455c503a2b","14cb6835-a932-430a-9d80-46014f130314","cff5bf87-2284-476f-bd6e-30b7536ebc13","9842782b-c1d1-46cd-9816-3f2c2a6d45db","58cbd89c-0a78-4ca3-a496-363b1b1ec7bd","eb52b502-a5ec-41cd-8829-a62bfc1c412c","0cefc4bc-27a9-40a2-8328-d129882b3007","2bd90bd6-9358-472c-bbd6-5a4944de97dd","95926482-c617-492f-b3ff-e320ba691bd1","9c86b90f-d847-4a96-a42c-fefff953081c","7ac3573a-68b8-41b3-90ae-cb494d764805","43a3a11c-91a2-4760-966c-a0e22c12a6e7","32475c09-ff3c-4d53-a045-46d10b999b3c","ac43c98c-3b68-4eb0-bc49-ee869feee780","b0f4d986-b70c-4670-9c2d-841a8378c471","a3bc348a-ec86-48b4-8f21-59b814b81e35","f8af9bd3-817a-4e62-8ce6-63dba812920c","32a962d5-0579-424f-a08c-a679e5de69f8","8a0dc669-f220-4a1b-8c3c-4449a9e9c128","7e1e9bd2-d076-4dcb-ae77-444e5a4c1173","563c15cb-7267-425a-8f2e-1e2d31edcc1f","7b574c7d-0979-46a7-8dba-c2c053aab1f7","63e1bde4-0ec1-41ef-865a-2fd37d3ed6dc","78182c73-c4ab-4c98-8c3e-ca3943276db3","b242ea79-9a97-4114-a441-f0e57ec55911","c0907d96-a9c4-4538-94c1-f3c17918c680","d0d18340-17c9-42b7-b8ae-f542a79654a5","6cd3868f-bf86-4c17-bb7d-7f9e634424a3","3c4434a4-43f5-4f1a-bc83-ac5b261c671f","fdbc3cd9-be5e-4336-82d1-50bdf60fe6e1","6d8dd291-b19d-4314-a4e2-53712c51ec8a","7ba670e8-4fda-4a3f-ac36-3b803db44d1d","4c146962-313a-4c90-bc21-ce3135886145","88802685-4005-42c3-a9da-8c3b0cff4de4","51c83896-7473-49fc-86a8-f051543ab2e5","...and 349 more"]} [Nest] 16 - 07/23/2025, 5:51:11 AM DEBUG [Api:LoggingInterceptor~s4ug2hqs] GET /api/server/ping 200 0.58ms ::ffff:127.0.0.1 [Nest] 16 - 07/23/2025, 5:51:41 AM DEBUG [Api:LoggingInterceptor~wckf8p4x] GET /api/server/ping 200 0.71ms ::ffff:127.0.0.1 [Nest] 16 - 07/23/2025, 5:52:11 AM DEBUG [Api:LoggingInterceptor~z95hphoe] GET /api/server/ping 200 0.62ms ::ffff:127.0.0.1 ``` </details> ### Additional information Error from Ark ``` Loading the archive ‘$HOME/album-name-20250723_055057.zip’ failed with the following error: Failed to open archive: Not a zip archive ``` Error from `unzip` ```bash $ unzip -t album-name-20250723_055057.zip Archive: album-name-20250723_055057.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of album-name-20250723_055057.zip or album-name-20250723_055057.zip.zip, and cannot find album-name-20250723_055057.zip.ZIP, period. ```

deekerman closed this issue

2026-02-20 04:07:29 -05:00

deekerman commented

2026-02-20 04:07:29 -05:00

Author

Owner

@mvanleeu commented on GitHub (Jul 24, 2025):

When testing on my end with the slightly newer v 1.136.0, Immich splits the download into multiple files, using a [album_name]+[part_number]-[date]_[time].zip filename pattern, each file being not bigger than 2Gb which seems to be the limit for the "classic" zip file format. (example: My album+1+20250725_013512.zip and My album+2-20250725_013559.zip )

Maybe a solution could be to generate Zip64 files instead by modifying this part of Immich server's source code: github.com/immich-app/immich@6563fa608a/server/src/repositories/storage.repository.ts (L85) for the main branch, which would need to become:

const archive = archiver('zip', { store: true, forceZip64: true });

@ngdangtu-vn: You could, as an experiment, apply such change inside your docker image, to test if this fixes your issue, following those steps below:

# Copy the (compiled from TypeScript) javascript file from the docker image to your local folder:
docker cp immich_server:/usr/src/app/server/dist/repositories/storage.repository.js .

# Make a backup of the original file 
cp storage.repository.js storage.repository.js.original

Using your prefered editor, go modify line 63 (double check please) of the local copy of storage.repository.js, from

const archive = (0, archiver_1.default)('zip', { store: true });

to:

const archive = (0, archiver_1.default)('zip', { store: true, forceZip64: true });

and save the file.

# Copy back the modified file to docker:
docker cp storage.repository.js immich_server:/usr/src/app/server/dist/repositories/storage.repository.js

# Restart the docker container:
docker restart immich_server

Try to recreate your zipped album download of 2.9Gb and check if this time the unzip tools are happy. If not, you may want to revert the changes by copying back to docker the original file:

docker cp storage.repository.js.original immich_server:/usr/src/app/server/dist/repositories/storage.repository.js

Last but not least, would you mind including here the full output of unzip -v to ensure your version supports those Zip64 extensions?

@mvanleeu commented on GitHub (Jul 24, 2025): When testing on my end with the slightly newer v 1.136.0, Immich splits the download into multiple files, using a `[album_name]+[part_number]-[date]_[time].zip` filename pattern, each file being not bigger than 2Gb which seems to be the limit for the "classic" zip file format. (example: `My album+1+20250725_013512.zip` and `My album+2-20250725_013559.zip` ) Maybe a solution could be to generate Zip64 files instead by modifying this part of Immich server's source code: https://github.com/immich-app/immich/blob/6563fa608a5a4414f40264b847e60928916fb986/server/src/repositories/storage.repository.ts#L85 for the main branch, which would need to become: ```typescript const archive = archiver('zip', { store: true, forceZip64: true }); ``` @ngdangtu-vn: You could, as an experiment, apply such change inside your docker image, to test if this fixes your issue, following those steps below: ```shell # Copy the (compiled from TypeScript) javascript file from the docker image to your local folder: docker cp immich_server:/usr/src/app/server/dist/repositories/storage.repository.js . # Make a backup of the original file cp storage.repository.js storage.repository.js.original ``` Using your prefered editor, go modify line 63 (double check please) of the local copy of `storage.repository.js`, from ```javascript const archive = (0, archiver_1.default)('zip', { store: true }); ``` to: ```javascript const archive = (0, archiver_1.default)('zip', { store: true, forceZip64: true }); ``` and save the file. ```shell # Copy back the modified file to docker: docker cp storage.repository.js immich_server:/usr/src/app/server/dist/repositories/storage.repository.js # Restart the docker container: docker restart immich_server ``` Try to recreate your zipped album download of 2.9Gb and check if this time the unzip tools are happy. If not, you may want to revert the changes by copying back to docker the original file: ```shell docker cp storage.repository.js.original immich_server:/usr/src/app/server/dist/repositories/storage.repository.js ``` Last but not least, would you mind including here the full output of `unzip -v` to ensure your version supports those Zip64 extensions?

deekerman commented

2026-02-20 04:07:29 -05:00

Author

Owner

@mvanleeu commented on GitHub (Jul 24, 2025):

One more side note: as Immich deals with image and video files, both of which are already compressed, the .zip file is created without compression to not waste CPU time by trying (and failing) to recompress what is already compressed.

It is here rather meant to put all the album files into a "downloadable archive" using the most ubiquitous ye timperfect archiving format around: Zip.

@mvanleeu commented on GitHub (Jul 24, 2025): One more side note: as Immich deals with image and video files, both of which are already compressed, the .zip file is created without compression to not waste CPU time by trying (and failing) to recompress what is already compressed. It is here rather meant to put all the album files into a "downloadable archive" using the most ubiquitous ye timperfect archiving format around: Zip.

deekerman commented

2026-02-20 04:07:29 -05:00

Author

Owner

@ngdangtu-vn commented on GitHub (Jul 24, 2025):

Here is my unzip -v (it's the built-in version)

UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 11.4.0 for Unix (Linux ELF).

UnZip special compilation options:
        ACORN_FTYPE_NFS
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)
        VMS_TEXT_CONV
        WILD_STOP_AT_DIR
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]

Yeah, I think it supports zip64.

@ngdangtu-vn commented on GitHub (Jul 24, 2025): Here is my `unzip -v` (it's the built-in version) ``` UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP. Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ; see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites. Compiled with gcc 11.4.0 for Unix (Linux ELF). UnZip special compilation options: ACORN_FTYPE_NFS COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported) SET_DIR_ATTRIB SYMLINKS (symbolic links supported, if RTL and file system permit) TIMESTAMP UNIXBACKUP USE_EF_UT_TIME USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported) USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported) UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths) LARGE_FILE_SUPPORT (large files over 2 GiB supported) ZIP64_SUPPORT (archives using Zip64 for large files supported) USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019) VMS_TEXT_CONV WILD_STOP_AT_DIR [decryption, version 2.11 of 05 Jan 2007] UnZip and ZipInfo environment options: UNZIP: [none] UNZIPOPT: [none] ZIPINFO: [none] ZIPINFOOPT: [none] ``` Yeah, I think it supports zip64.

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@ngdangtu-vn commented on GitHub (Jul 24, 2025):

const archive = (0, archiver_1.default)('zip', { store: true, forceZip64: true });

@mvanleeu I've updated to your suggestion but the zip file still corrupted. I'll try to update to latest version for now.

@ngdangtu-vn commented on GitHub (Jul 24, 2025): > ```js > const archive = (0, archiver_1.default)('zip', { store: true, forceZip64: true }); > ``` @mvanleeu I've updated to your suggestion but the zip file still corrupted. I'll try to update to latest version for now.

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@ngdangtu-vn commented on GitHub (Jul 25, 2025):

I've update the the latest version v1.136.0 but the bug is still the same. It also didn't chunk it down into the smaller files :? Maybe it's because the file was corrupted during sync progress?

@ngdangtu-vn commented on GitHub (Jul 25, 2025): I've update the the latest version `v1.136.0` but the bug is still the same. It also didn't chunk it down into the smaller files :? Maybe it's because the file was corrupted during sync progress?

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@mvanleeu commented on GitHub (Jul 25, 2025):

What value do you have for the Download "Archive Size", in the GUI under "Account Settings" -> "Download" -> "Archive size" ?
https://your-immich-url-and-port/ user-settings?isOpen=download-settings

In case you have different values, could you try with the value "2" and "Embedded videos" disabled?

@mvanleeu commented on GitHub (Jul 25, 2025): What value do you have for the Download "Archive Size", in the GUI under "Account Settings" -> "Download" -> "Archive size" ? [https://__your-immich-url-and-port__/ user-settings?isOpen=download-settings]() In case you have different values, could you try with the value "2" and "Embedded videos" disabled?

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@ngdangtu-vn commented on GitHub (Jul 26, 2025):

@mvanleeu

~~Maybe I got zip file of 2GB because it separated the video to another zip file but it wasn't able to send the rest?~~ Sorry I thought I enabled the "Embedded videos", but I didn't.

Update

In case you have different values, could you try with the value "2" and "Embedded videos" disabled?

I tried your suggestion (which seems to be default config right?) and ~~it still return me the same result, corrupt zip file.~~ I tried it again and it separated files like you told. Funny thing is the first part is corrupted but the second part is good. The second part is a mixed of photos and videos (because "Embedded videos" is disabled right).

@ngdangtu-vn commented on GitHub (Jul 26, 2025): @mvanleeu <img width="1854" height="764" alt="Image" src="https://github.com/user-attachments/assets/79f1f02f-55a5-4e45-b7ca-f9388321022c" /> ~~Maybe I got zip file of 2GB because it separated the video to another zip file but it wasn't able to send the rest?~~ Sorry I thought I enabled the "Embedded videos", but I didn't. Update > In case you have different values, could you try with the value "2" and "Embedded videos" disabled? I tried your suggestion (which seems to be default config right?) and ~~it still return me the same result, corrupt zip file.~~ I tried it again and it separated files like you told. Funny thing is the first part is corrupted but the second part is good. The second part is a mixed of photos and videos (because "Embedded videos" is disabled right).

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@MartB commented on GitHub (Aug 25, 2025):

This is still a thing in v1.139.2

It behaves like @ngdangtu-vn states, first part is corrupt, single archives dont work.

@MartB commented on GitHub (Aug 25, 2025): This is still a thing in v1.139.2 It behaves like @ngdangtu-vn states, first part is corrupt, single archives dont work.

deekerman commented

2026-02-20 04:07:30 -05:00

Author

Owner

@jrasm91 commented on GitHub (Sep 11, 2025):

The archive tool we use already will automatically package the zip as a zip64, if it meats criteria that would make it an invalid classic zip.

github.com/archiverjs/node-compress-commons@0295b96a46/lib/archivers/zip/zip-archive-output-stream.js (L119)

Given that, at the fact you are running into issues around the 2GiB limit, this is much more likely to be a reverse proxy issue. You can test this by connecting directly to the server ip and downloading the archive. If that works, and it errors with the reverse proxy, then that should clearly show it's a user configuration issue.

@jrasm91 commented on GitHub (Sep 11, 2025): The archive tool we use already will automatically package the zip as a zip64, if it meats criteria that would make it an invalid classic zip. https://github.com/archiverjs/node-compress-commons/blob/0295b96a46e4e885264fb14a8e3cfe660d11126b/lib/archivers/zip/zip-archive-output-stream.js#L119 Given that, at the fact you are running into issues around the 2GiB limit, this is much more likely to be a reverse proxy issue. You can test this by connecting directly to the server ip and downloading the archive. If that works, and it errors with the reverse proxy, then that should clearly show it's a user configuration issue.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/immich#6022

No description provided.

Rows
Columns