Repository navigation
constantly failing on the reupload/metadata update with io: read/write on closed pipe during the later stages of file #1271
Description
I tried to upload google takeout zip file and it was failing due to missing metadata for some of the files. It only uploaded partial set of files from the zip. So I reset the immich server and used the from-folder option was able to upload all files. I was able to upload over 1TB of data successfully.
However later I realized that there is an option for -u in the from-google-photos as well. So I tried using that and reupload the existing zip file so it can populate the missing metadata without uploading all files again. It works up to some extend, however it fails later in the stage after processing some random set of files.
I am running immich-go version 0.31.0 on MacOS Darwin Arm64 platform. My immich-server is running 2.4.1. I have set the concurrent-tasks = 1 to avoid any server side issue but it still fails.
Following is the example of failure. This only fails after having many successful API completed. eg.
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1203.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1203.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1205.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1205.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1206.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1206.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1207.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1207.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1208.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1208.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1211.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1211.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1212.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1212.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1213.HEIC
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1213.HEIC
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1225.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_1225.JPG
2025-12-31 22:09:02 WRN discarded local duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_0988.JPG reason=already present in input as
unknown
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_3081.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_3081.JPG
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5141.HEIC
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5141.HEIC
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5186.HEIC
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5186.HEIC
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5256.HEIC
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5256.HEIC
2025-12-31 22:09:02 INF server has duplicate file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5268.JPG
2025-12-31 22:09:02 INF metadata updated file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_5268.JPG
2025-12-31 22:09:02 ERR server error file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_0542.JPG error=io: read/write on closed pipe
2025-12-31 22:09:02 ERR Error err=io: read/write on closed pipe
2025-12-31 22:09:02 ERR server error file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_0989.JPG error=AssetUpload, POST, https://immich-server/api/assets
Post "https://immich-server/api/assets": io: read/write on closed pipe
2025-12-31 22:09:02 ERR server error file=takeout-20251222T185233Z-3-002:Takeout/Google Photos/Art /IMG_0479.JPG error=AssetUpload, POST, https://immich-server/api/assets
Post "https://immich-server/api/assets": io: read/write on closed pipe
I also enabled api-trace to get more details.
Method: POST, URL: https://immich-server/api/assets
Timestamp: 2025-12-31T22:09:01.795-08:00
Headers:
Content-Type: multipart/form-data; boundary=93c8f5b3cade130883901fc6cbaf64d16d4ab4518ddfbe712dce6e539999
X-Api-Key: *********
Accept: application/json
X-Immich-Checksum: 1wvlp3hi0NirDiT+ukaeuuJFQT8=
Body:
[Multipart]
--- Part 1 ---
Content-Disposition: form-data; name="fileCreatedAt"
Content:
2024-04-25T16:48:43.000Z
--- Part 2 ---
Content-Disposition: form-data; name="fileModifiedAt"
Content:
2026-01-01T06:09:01.794Z
--- Part 3 ---
Content-Disposition: form-data; name="isReadOnly"
Content:
false
--- Part 4 ---
Content-Disposition: form-data; name="deviceAssetId"
Content:
IMG_0542.JPG-1076161
--- Part 5 ---
Content-Disposition: form-data; name="deviceId"
Content:
MacStudio-M1-Max.local
--- Part 6 ---
Content-Disposition: form-data; name="assetType"
Content:
image
--- Part 7 ---
Content-Disposition: form-data; name="isFavorite"
Content:
false
--- Part 8 ---
Content-Disposition: form-data; name="fileExtension"
Content:
.JPG
--- Part 9 ---
Content-Disposition: form-data; name="duration"
Content:
00:00:00.000000
--- Part 10 ---
Content-Disposition: form-data; name="visibility"
Content:
timeline
--- Part 11 ---
Content-Disposition: form-data; name="assetData"; filename="IMG_0542.JPG"
Content-Type: application/octet-stream
Error reading part data: unexpected EOF
Error reading part 11: multipart: NextPart: EOF
+---- response ---------------------------------------------------
Timestamp: 2025-12-31T22:09:02.794-08:00
Duration: 999ms
Status: 200 OK: 200
Headers:
Etag: "42-UWN2RfeaDCYSXBMijLlIGFAG59Q"
Vary: Accept-Encoding
X-Immich-Cid: osjqytbm
X-Powered-By: Express
Content-Length: 66
Content-Type: application/json; charset=utf-8
Date: Thu, 01 Jan 2026 06:09:02 GMT
Body:
[JSON]
{"status":"duplicate","id":"9d440e44-5722-4453-a045-2bc7a75119da"}
Failed API request/response log
/---- client #1 request #119 ---------------------------------------------------
Method: POST, URL: https://immich-server/api/assets
Timestamp: 2025-12-31T22:09:01.82-08:00
Headers:
X-Api-Key: *******
Accept: application/json
X-Immich-Checksum: QLb7bHUA82PceLGMFvrRE9Qfhi0=
Content-Type: multipart/form-data; boundary=02ee280d50ec344a2292f8aaabea7c4e933e14e0a2e13c0813e4b01752fd
Body:
[Multipart]
--- Part 1 ---
Content-Disposition: form-data; name="deviceAssetId"
Content:
IMG_0400.JPG-912826
--- Part 2 ---
Content-Disposition: form-data; name="fileCreatedAt"
Content:
2026-01-01T06:09:01.820Z
--- Part 3 ---
Content-Disposition: form-data; name="fileModifiedAt"
Content:
2026-01-01T06:09:01.820Z
--- Part 4 ---
Content-Disposition: form-data; name="isFavorite"
Content:
false
--- Part 5 ---
Content-Disposition: form-data; name="fileExtension"
Content:
.JPG
--- Part 6 ---
Content-Disposition: form-data; name="isReadOnly"
Content:
false
--- Part 7 ---
Content-Disposition: form-data; name="visibility"
Content:
timeline
--- Part 8 ---
Content-Disposition: form-data; name="deviceId"
Content:
MacStudio-M1-Max.local
--- Part 9 ---
Content-Disposition: form-data; name="assetType"
Content:
image
--- Part 10 ---
Content-Disposition: form-data; name="duration"
Content:
00:00:00.000000
--- Part 11 ---
Content-Disposition: form-data; name="assetData"; filename="IMG_0400.JPG"
Content-Type: application/octet-stream
Error reading part data: unexpected EOF
Error reading part 11: multipart: NextPart: EOF
+---- response ---------------------------------------------------
Timestamp: 2025-12-31T22:09:02.797-08:00
Duration: 978ms
Error: io: read/write on closed pipe
\---- client #1 request #119 ---------------------------------------------------
Why does it fail after some files? Is there a way to import metadata only?
I am running immich-server behing traefik proxy. I don't see any logs on the immich-server side or treafik side.
Activity
[-]constantly failing on the reupload[/-][+]constantly failing on the reupload/metadata update with `io: read/write on closed pipe` during the later stages of file[/+]simulot commentedon Jan 1, 2026
The error just says that the source is closed, but without the root cause.
Proxies are well known to interfere with immich-go.
But anything else can cause the problem:
Can you simplify your setup in order to let immich-go talking directly to the immich server?
jspatel commentedon Jan 1, 2026
Here is my setup
immich-go -----> Internet ----> VPS Hosting Immich. So there is no other network level proxy involved here. I am using traefik via docker compose to setup immich-server. With this setup I was able to upload over 1TB of data (withfrom-folderoption) few days back and now I am trying to update metadata (usingfrom-google-photos) and it is failing.I have over 500 google takeout files sized ~2GB each. During the
from-folderbased options, when I triedimmich-go upload from-folder takeout*.zipThis failed after 3-4 files and started to give errors because server was overwhelmed. So I wrote a script to upload one file at a time and delay of 30 seconds in between. That worked fine and uploaded over 1TB of data.Now I am trying to run
from-google-photosfor a single file and it is still failing.Keep in mind all files are already uploaded earlier when I performed
from-folderoperation.I have set the
concurrent-tasks = 1for simplicity and see if it still fails and it did. Does immich-go make too many metadata calls etc.. causing the failure?jspatel commentedon Jan 1, 2026
I was able to solve the problem using following middleware in traefik for the immich-server
And for the docker compose file
However I still don't get on what is that immich-go is doing which cause it to fail at traefik layer. Is it too many request, or too large of a request etc.. I didn't see this issue while doing the upload.
I haven't look at the immich-go source code, but I think there should be an option to have a retry mechanism with time based backoff for the failure scenario as such.
I also noticed that it makes lot of calls to
POST /api/search/metadatato process files. I have over 70K+ images/photos. I noticed that it makes the same API call with different page index with size of 1000 each.{"page":12,"size":1000,"withExif":true,"visibility":"timeline","order":"asc"}. I honestly don't know if this is the most efficient way of querying and updating the metadata for maybe 100 files in a zip.This has to be repeated for each file I process and it takes about 90 seconds to get all 70 APIs done for the metadata. The actual processing is very limited at that point as this is just metadata only update.
jspatel commentedon Jan 2, 2026
As an update, I tried with the above settings and uploaded more files on the server and still got intermittent failures. I have to retry the same file again to finish the upload for the remaining file.
Most of my takeout folders have larger portion is occupied by videos over images. However I noticed when I have lots of images in a single takeout file, it fails more often. So if I have 2GB takeout with all images, it is bound to fail again and again.
I have to keep retry it few times to complete the upload. For each retry
Server errorcounter would go down as well as counter for theWARNING: XXX assets did not reach a final stage!message.dartmoordunbar commentedon Jan 15, 2026
Similar issue, this is an upload from local google docs folder. Immich-Go is running in a container on the same machine as immich and the files are mapped to a local disk.
speters commentedon Jan 17, 2026
I have run into - what I think is - the same problem on current
mainbranch immich-go.The problem does not occur on a version built from current
developbranch.thrillhouse2342 commentedon Jan 17, 2026
I believe I am experiencing the same issue. I tried to move from main to develop however unfortunately it's still crashing.
Details:
1.) Using Immich-Go to move images from one folder (old inactive immich) to a new immich installation on the same local HDD drive
2.) Attempted changing concurrent tasks all the way down to 1 and it still crashed
3.) Attempted using admin API key so Immich jobs could be paused just in case.
4.) Attempted using develop branch instead of main branch like previously suggested however I'm still experiencing the same issues with the develop branch.
Antoine1983 commentedon Jan 18, 2026
Using these parmeters is clearly helping:
https://github.com/simulot/immich-go/blob/main/docs/examples.md#conservative-upload-slow-network
Jakeler commentedon Jan 30, 2026
Just got the error using from-folder with the (source) folder on a network share, especially if it's 100% busy (Gbit Ethernet).
If I understand correctly the problem is reading from the file system, not the connection to immich for upload. With folders on local SSD storage or ramdisk I never get the error.
Tested it countless times with main/v0.31.0, develop and branches with my changes and can't detect a correlation. Seems to be external factors/load related, sometimes it fails repeatably unless I wait a few seconds.
emelendez89 commentedon Feb 27, 2026
Well... we gather here friends together with the same issue :(
All immich services, immich-go and takeout-*.zip folders in the same Debian WSL2 VM. I believe it's choking on resources.
Reducing the
--concurrent-tasksor stopping the MLdocker compose stop immich-machine-learningdoesn't help. It's something else, need to check the logs of the Redis and Database containers. If I find the culprit I'll share some details. I'm also pending create aC:\Users\<you>\.wslconfigfile to define my WSL2 resources.leonbohn commentedon Mar 1, 2026
I had a similar problem when importing to an instance on a VPS. Reducing the number of concurrent tasks did not fix the problems on its own. But combined with a longer duration before a timeout is triggered led to a successful, albeit painfully slow import. Did you already try setting
--client-timeoutto 60m or even higher?alternativesurfer commentedon Mar 16, 2026
Similar issue:
│2026-03-16 11:22:09 ERR server error file=20250725-Google Photos:07112024- Mission San Luis Rey/IMG_7408.HEIC error=AssetUpload, POST, http://10.60.1.4:2283/api/assets │
│Post "http://10.60.1.4:2283/api/assets": write tcp 192.168.50.201:48130->10.60.1.4:2283: write: connection timed out │
│ │
│io: read/write on closed pipe │
│2026-03-16 11:22:09 DBG upload asset file.OriginalFileName=IMG_7408.HEIC file.FileName=20250725-Google Photos:07112024- Mission San Luis Rey/IMG_7408.HEIC file.ID= │
│file.FileDate=2025-07-24 09:30:28 file.Description= file.FileSize=1588540 file.CaptureDate=2024-07-11 18:57:50 file.Trashed=false file.Archived=false file.FromPartner=false │
│file.Favorite=false file.Stars=0 file.Latitude=33.xxxxx file.Longitude=-117.xxxxx │
│2026-03-16 11:22:09 ERR Error err=AssetUpload, POST, http://10.60.1.4:2283/api/assets │
│Post "http://10.60.1.4:2283/api/assets": write tcp 192.168.50.201:48130->10.60.1.4:2283: write: connection timed out │
│ │
│io: read/write on closed pipe
All local to rule out any funny stuff with proxies/etc
Source is a mounted disk.
import:
immich-go upload from-google-photos --server=http://10.60.1.4:2283 --manage-burst=Stack --concurrent-tasks=1 --client-timeout=120m --on-errors=continue --session-tag --tag="2025-05-20 phone dump" --pause-immich-jobs=true --log-file=/mnt/import/import.log --log-level=DEBUG --admin-api-key=ANAPIKEY --api-key=ANOTHERAPIKEY "/mnt/import/20250725-Google Photos"
logs show nothing more than what is listed above
sztupy commentedon May 16, 2026
Having the same issue importing video files from a local SSD to an immich running locally, also on a (different) SSD, so there should be neither a problem of network, nor disk speed at all.
However mp4 video files still fail occasionally, even after multiple retries, even if I select the failing files to be uploaded one-by-one, and even if the file was already uploaded and is therefore a duplicate.
Size of the videos are around 200-300MB so I would assume nothing major.
Trying with something like
-concurrent-tasks=1 --client-timeout=120malso doesn't work.Uploading the files manually through the web interface works fine, but then I have to manually fix the album metadata.
Repair windowed index misses with a per-file checksum fallback
7robertodantas commentedon Jun 25, 2026
One thing that helped me was not trusting
--pause-immich-jobs=true. Instead, I manually triggered each job and paused before starting the import. That generally made it work. I also set the concurrent tasks to 1.bakelite105 commentedon Jul 6, 2026
This works. Processing speed is much slower but still acceptable. However, there's still Some errors occurred (the amount is much less than before, in my case, it's 1). According to the logs, the file that has caused the error is an iPhone screen recording video, which named RPReplay_Final1626707824.mp4 and sized 457.1 MBit.
The logs say,
ERR Error err=io: read/write on closed pipe
│2026-07-06 22:15:29 ERR server error file=HaveEXIF:202107/RPReplay_Final1626707824.mp4 error=AssetUpload, POST, http://localhost:2283/api/assets
│Post "http://localhost:2283/api/assets": io: read/write on closed pipe
│io: read/write on closed pipe
│2026-07-06 22:15:29 ERR Error err=AssetUpload, POST, http://localhost:2283/api/assets
│Post "http://localhost:2283/api/assets": io: read/write on closed pipe
│io: read/write on closed pipe
...
│2026-07-06 22:15:29 INF Asset Tracking Report:⚠️ WARNING: 1 assets did not reach a final state!
│2026-07-06 22:15:29 INF =====================
│2026-07-06 22:15:29 INF Total Assets: 3406 (21.5 GB)
│2026-07-06 22:15:29 INF Processed: 3403 (20.9 GB)
│2026-07-06 22:15:29 INF Discarded: 0 (0 B)
│2026-07-06 22:15:29 INF Errors: 2 (457.1 MB)
│2026-07-06 22:15:29 INF Pending: 1 (152.2 MB)
│2026-07-06 22:15:29 INF
│2026-07-06 22:15:29 INF
And worth noticing, even I upload this file individually, still fail. I eventually found this file has existed on the server, but there's another server-existed file process successfully (skipped, cause no error). Strange.
BTW, I upload from local SSD to local server.
fix(upload): ignore duplicate closed-pipe writer errors
fix(upload): ignore duplicate closed-pipe writer errors
smurfmckenzie commentedon Sep 13, 2026
This did it for me! Thanks!
fix(upload): ignore duplicate closed-pipe writer errors (#1391)