Found the solution.
For reference, if you encounter the same issue, you have to go inside the immich server container and from the same folder of the package.json run the command ./server/bin/immich-admin change-media-location and follow the process:
previous value of IMMICH_MEDIA_LOCATION: upload
new value IMMICH_MEDIA_LOCATION: /data
This will migrate the db with the correct absolute path.
@lughino I racked my brains when searching for a solution. Read endless posts, but then it looked like an database issue. And then I read your post:
I just changed my deprecated storage location at the same time immich changed to versions 136&137. This prevented the database migration during a regular upgrade in some way. With your post it was fixed in 5 minutes 
Grtz
This is EXACTLY what I needed to fix my issue! After updating to the latest version of Immich (v1.137.3, TrueNAS app v1.9.12), thumbnails, pictures, and videos weren’t loading, despite the fact that I could still see the metadata of the media. I went into the container, ran the commands, and restarted the container. When it came back up, I was able to access my media once again via both the web and mobile apps.
For those that want more detailed steps, here’s exactly what I did:
Accessed the TrueNAS shell
sudo docker ps to find the container ID of the Immich server container
sudo docker exec -it <immich-server-container-id> /bin/sh to enter into the Docker container’s shell
Then, follow the steps @lughino outlined above:
./server/bin/immich-admin change-media-location
previous value of IMMICH_MEDIA_LOCATION: upload
new value IMMICH_MEDIA_LOCATION: /data
Restart the Immich app from the TrueNAS GUI.
thank you very much!!! 
Hey, after following all the instructions I am still having issues with the postgress database.
I updated immich from 134.0 to 137.3
Now immich is getting an error at startup, it is trying to update something called “vchord” but fails in doing so. It is suggesting to do it manually but I can’t figure it out how.
2025-08-04 06:51:17.208905+00:00Please run ‘ALTER EXTENSION vchord UPDATE’ manually as a superuser.
Does somebody have encountered this issue or know what should I do?
2025-08-04 06:51:13.428600+00:00Initializing Immich v1.137.3
2025-08-04 06:51:13.431419+00:00Detected CPU Cores: 4
2025-08-04 06:51:15.185387+00:00Starting api worker
2025-08-04 06:51:15.189894+00:00Starting microservices worker
2025-08-04 06:51:17.098652+00:00e[32m[Nest] 7 - e[39m08/03/2025, 11:51:17 PM e[32m LOGe[39m e[33m[Microservices:EventRepository]e[39m e[32mInitialized websocket servere[39m
2025-08-04 06:51:17.167034+00:00Postgres notice: {
2025-08-04 06:51:17.167070+00:00severity_local: 'WARNING',
2025-08-04 06:51:17.167079+00:00severity: 'WARNING',
2025-08-04 06:51:17.167086+00:00code: '42602',
2025-08-04 06:51:17.167092+00:00message: 'invalid configuration parameter name "vchordrq.prewarm_dim"',
2025-08-04 06:51:17.167098+00:00detail: '"vchordrq" is a reserved prefix.',
2025-08-04 06:51:17.167105+00:00file: 'guc.c',
2025-08-04 06:51:17.167111+00:00line: '5718',
2025-08-04 06:51:17.167118+00:00routine: 'find_option'
2025-08-04 06:51:17.167125+00:00}
2025-08-04 06:51:17.185048+00:00Postgres notice: {
2025-08-04 06:51:17.185081+00:00severity_local: 'WARNING',
2025-08-04 06:51:17.185090+00:00severity: 'WARNING',
2025-08-04 06:51:17.185097+00:00code: '42602',
2025-08-04 06:51:17.185103+00:00message: 'invalid configuration parameter name "vchordrq.prewarm_dim"',
2025-08-04 06:51:17.185109+00:00detail: '"vchordrq" is a reserved prefix.',
2025-08-04 06:51:17.185116+00:00file: 'guc.c',
2025-08-04 06:51:17.185122+00:00line: '5718',
2025-08-04 06:51:17.185128+00:00routine: 'find_option'
2025-08-04 06:51:17.185147+00:00}
2025-08-04 06:51:17.194702+00:00e[32m[Nest] 7 - e[39m08/03/2025, 11:51:17 PM e[32m LOGe[39m e[33m[Microservices:DatabaseService]e[39m e[32mUpdating VectorChord extension to 0.4.3e[39m
2025-08-04 06:51:17.203244+00:00Query failed : {
2025-08-04 06:51:17.203284+00:00durationMs: 1.7626599999998689,
2025-08-04 06:51:17.203292+00:00error: PostgresError: tuple concurrently updated
2025-08-04 06:51:17.203299+00:00at ErrorResponse (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:794:26)
2025-08-04 06:51:17.203306+00:00at handle (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:480:6)
2025-08-04 06:51:17.203312+00:00at Socket.data (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:315:9)
2025-08-04 06:51:17.203319+00:00at Socket.emit (node:events:518:28)
2025-08-04 06:51:17.203325+00:00at addChunk (node:internal/streams/readable:561:12)
2025-08-04 06:51:17.203331+00:00at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
2025-08-04 06:51:17.203338+00:00at Readable.push (node:internal/streams/readable:392:5)
2025-08-04 06:51:17.203344+00:00at TCP.onStreamRead (node:internal/stream_base_commons:189:23) {
2025-08-04 06:51:17.203350+00:00severity_local: 'ERROR',
2025-08-04 06:51:17.203357+00:00severity: 'ERROR',
2025-08-04 06:51:17.203363+00:00code: 'XX000',
2025-08-04 06:51:17.203370+00:00file: 'heapam.c',
2025-08-04 06:51:17.203376+00:00line: '4373',
2025-08-04 06:51:17.203382+00:00routine: 'simple_heap_update'
2025-08-04 06:51:17.203388+00:00},
2025-08-04 06:51:17.203394+00:00sql: "ALTER EXTENSION vchord UPDATE TO '0.4.3'",
2025-08-04 06:51:17.203401+00:00params: []
2025-08-04 06:51:17.203407+00:00}
2025-08-04 06:51:17.208873+00:00e[33m[Nest] 7 - e[39m08/03/2025, 11:51:17 PM e[33m WARNe[39m e[33m[Microservices:DatabaseService]e[39m e[33mThe VectorChord extension can be updated to 0.4.3.
2025-08-04 06:51:17.208885+00:00Immich attempted to update the extension, but failed to do so.
2025-08-04 06:51:17.208892+00:00This may be because Immich does not have the necessary permissions to update the extension.
2025-08-04 06:51:17.208899+00:002025-08-04T06:51:17.208899232Z
2025-08-04 06:51:17.208905+00:00Please run 'ALTER EXTENSION vchord UPDATE' manually as a superuser.
2025-08-04 06:51:17.208911+00:00See https://immich.app/docs/guides/database-queries for how to query the database.e[39m
2025-08-04 06:51:17.209103+00:00Postgres notice: {
2025-08-04 06:51:17.209119+00:00severity_local: 'WARNING',
2025-08-04 06:51:17.209126+00:00severity: 'WARNING',
2025-08-04 06:51:17.209132+00:00code: '42602',
2025-08-04 06:51:17.209139+00:00message: 'invalid configuration parameter name "vchordrq.prewarm_dim"',
2025-08-04 06:51:17.209145+00:00detail: '"vchordrq" is a reserved prefix.',
2025-08-04 06:51:17.209151+00:00file: 'guc.c',
2025-08-04 06:51:17.209157+00:00line: '5718',
2025-08-04 06:51:17.209163+00:00routine: 'find_option'
2025-08-04 06:51:17.209170+00:00}
2025-08-04 06:51:17.213781+00:00PostgresError: tuple concurrently updated
2025-08-04 06:51:17.214745+00:00at ErrorResponse (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:794:26)
2025-08-04 06:51:17.214765+00:00at handle (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:480:6)
2025-08-04 06:51:17.214772+00:00at Socket.data (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:315:9)
2025-08-04 06:51:17.214778+00:00at Socket.emit (node:events:518:28)
2025-08-04 06:51:17.214784+00:00at addChunk (node:internal/streams/readable:561:12)
2025-08-04 06:51:17.214791+00:00at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
2025-08-04 06:51:17.214797+00:00at Readable.push (node:internal/streams/readable:392:5)
2025-08-04 06:51:17.214803+00:00at TCP.onStreamRead (node:internal/stream_base_commons:189:23) {
2025-08-04 06:51:17.214809+00:00severity_local: 'ERROR',
2025-08-04 06:51:17.214815+00:00severity: 'ERROR',
2025-08-04 06:51:17.214821+00:00code: 'XX000',
2025-08-04 06:51:17.214827+00:00file: 'heapam.c',
2025-08-04 06:51:17.214833+00:00line: '4373',
2025-08-04 06:51:17.214840+00:00routine: 'simple_heap_update'
2025-08-04 06:51:17.214846+00:00}
2025-08-04 06:51:17.215475+00:00microservices worker error: PostgresError: tuple concurrently updated, stack: PostgresError: tuple concurrently updated
2025-08-04 06:51:17.215509+00:00at ErrorResponse (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:794:26)
2025-08-04 06:51:17.215516+00:00at handle (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:480:6)
2025-08-04 06:51:17.215523+00:00at Socket.data (/usr/src/app/server/node_modules/postgres/cjs/src/connection.js:315:9)
2025-08-04 06:51:17.215529+00:00at Socket.emit (node:events:518:28)
2025-08-04 06:51:17.215535+00:00at addChunk (node:internal/streams/readable:561:12)
2025-08-04 06:51:17.215542+00:00at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
2025-08-04 06:51:17.215548+00:00at Readable.push (node:internal/streams/readable:392:5)
2025-08-04 06:51:17.215554+00:00at TCP.onStreamRead (node:internal/stream_base_commons:189:23)
2025-08-04 06:51:17.229382+00:00microservices worker exited with code 1
2025-08-04 06:51:17.229460+00:00Killing api process
Thank you for posting the detailed instructions for fixing the broken images.
My immich broke because of the ‘IMMICH_MEDIA_LOCATION’ change after updating the image as well, before I could do the data migration. Welp.
I did both fixes at the same time then, first moving everything to data/, then running the change-media-location command.
For the record you can move the existing datasets to the level under data with zfs rename yourpool/docker/immich/library yourpool/docker/immich/data/library if you want to avoid lengthy copying, that’s what I did and I have not encountered any problem.
Hi,
First of all, thanks for the instructions, it almost worked 
I’m having an issue with what seems permissions but can’t figure out which permissons should this file have. When starting Immich server pod, I’m getting the following:
2025-08-12 09:45:37.920001+00:00Initializing Immich v1.137.3
2025-08-12 09:45:37.926499+00:00Detected CPU Cores: 4
2025-08-12 09:45:41.781107+00:00Starting api worker
2025-08-12 09:45:41.789839+00:00Starting microservices worker
2025-08-12 09:45:46.708685+00:00e[32m[Nest] 7 - e[39m08/12/2025, 10:45:46 AM e[32m LOGe[39m e[33m[Microservices:EventRepository]e[39m e[32mInitialized websocket servere[39m
2025-08-12 09:45:46.922689+00:00e[32m[Nest] 7 - e[39m08/12/2025, 10:45:46 AM e[32m LOGe[39m e[33m[Microservices:DatabaseRepository]e[39m e[32mtargetLists=1, current=1 for clip_index of 25557 rowse[39m
2025-08-12 09:45:46.931269+00:00e[32m[Nest] 7 - e[39m08/12/2025, 10:45:46 AM e[32m LOGe[39m e[33m[Microservices:DatabaseRepository]e[39m e[32mtargetLists=1, current=1 for face_index of 36981 rowse[39m
2025-08-12 09:45:47.071406+00:00e[32m[Nest] 7 - e[39m08/12/2025, 10:45:47 AM e[32m LOGe[39m e[33m[Microservices:StorageService]e[39m e[32mVerifying system mount folder checks, current state: {"mountChecks":{"thumbs":true,"upload":true,"backups":true,"library":true,"profile":true,"encoded-video":true}}e[39m
2025-08-12 09:45:47.073783+00:00e[31m[Nest] 7 - e[39m08/12/2025, 10:45:47 AM e[31m ERRORe[39m e[33m[Microservices:StorageService]e[39m e[31mFailed to write /data/encoded-video/.immich: Error: EACCES: permission denied, open '/data/encoded-video/.immich'e[39m
2025-08-12 09:45:47.079528+00:00microservices worker error: Error: Failed to write "<UPLOAD_LOCATION>/encoded-video/.immich - Please see https://immich.app/docs/administration/system-integrity#folder-checks for more information.", stack: Error: Failed to write "<UPLOAD_LOCATION>/encoded-video/.immich - Please see https://immich.app/docs/administration/system-integrity#folder-checks for more information."
I’ve tried going to the website it mentions but couldn’t understand a few things:
What’s the impact of turning off these verifications and what permissions should the file have?
Anyone with this error managed to fix it without any loss of files?
encoded-video folder permissions:
drwxr-xr-x 5 root root 6 Aug 12 10:48 .
drwxr-xr-x 8 root root 8 Aug 12 10:40 ..
-rw-r--r-- 1 root root 13 Aug 11 15:04 .immich
Found the problem. New Immich instance was running under user id 568 (apps) which caused not to have access to the old copied files. Changing permission from the app to root made everything start normally.
Hi there…
I have noticed that the Community guide is updated on Immich now…( TrueNAS [Community] | Immich )
I havent tried it out but im about to do the journey to change the storage locations and the updated guide looks good. They even explain how you should move your data if you have been lazy and used the iXvolume dataset.
For example (rsync -av /mnt/.ix-apps/app_mounts/immich/library/ /mnt/tank/immich/data/library/)
and for pgdata (rsync -av /mnt/.ix-apps/app_mounts/immich/pgData/ /mnt/tank/immich/pgData/)
Anyway… i dont know when it got updated or if i just missed it out but hopefully it will work out fine =)
Just updated my main immich and also my test immich (2 separate machines with TrueNAS).
My test immich was a mixture of iXvolume and some designated datasets so that was really a mess… but it worked out all fine with the examples from where iXvolumes are stored.
My main immich (“production”) had all 7 datasets. i dont think that you need to touch the postgres db (the guide doesnt seem to include moving db data) and only run rsync on the other 6 datasets into the new “data” dataset. But i changed the pg db anyway and it worked out fine so far…
I am very thankful for TrueNAS Scale. However, this hot mess of a situation is exactly why i am migrating all of my apps off TrueNas Scale to a separate Ubuntu Docker Portainer VM.
Does anyone know why this is required? I only ran across a warning in the TrueNas gui as i was migrating my apps off.
However, this hot mess of a situation is exactly why i am migrating all of my apps off TrueNas Scale to a separate Ubuntu Docker Portainer VM.
You don’t need to do that. This hot mess is caused by the “community apps” on TrueNAS, but you don’t need to use those. Just do what I did: install Dockge (or Portainer in your case), and then install all your apps through that. Using a separate VM has its merits, but it also means more resource consumption and lower performance since everything has to go over the network (even if it’s virtualized on the same machine).
Does anyone know why this is required?
Who knows. This happens all the time with those community apps. They absolutely never post any changelogs for their updates, even those with breaking changes; it’s all very amateurish.
I’m finally wanting to take care of this, and truly, I hope whoever thought of changing all this shit will hurt his or her balls pretty hard.
Is it possible to keep the original postgres-data set or does it need to be recreated and content moved?
The Guide covers my last questions:
pgData.Docs: TrueNAS [Community] | Immich
I create a zfs snapshot on the immich dataset to rollback in case of emergency.
At first i thought its clean but hit a couple of hurdles.
So reading the server logs in case of a failed startup will help pinpointing the issue. After all its a fairly save method to switch to the new layout
Thank you for all info Alexander …
I’m still struggling because my old dataset structure doesn’t have folders “backups”, “encoded-video”, “library”, “profile”, “thumbs” and “upload”. I had Immich installed under one gigantic dataset (not smart, I know …but it was my first time in my defense). Anyway, I can’t do rsync -a --info=progress2 /mnt/.ix-apps/app_mounts/immich/backups/ /mnt/HTPC/Alex/Immich/data/backups/ for example … and I don’t have the “from” folder. Here is what I have in my old structure:
/mnt/MainPool/Immich-OLD
├── .immich
├── 46b1c87d-1eab-4d95-8d44-afebea3e470f (this is user 1)
├── 712ed819-b051-467c-857a-99a5e9f2242a (user 2)
├── bdb0694d-a4f7-4f3b-8399-4c5d0d4234cd (user 3)
├── ce476b69-9d58-4b08-9b88-99807377736f (user 4)
├── PGData (postgres)
Now, as of the new structure, I do have:
/mnt/MainPool/Immich
├── MLData/
├── PGData/
├── UserDATA/
├─ backups/
├─ encoded-video/
├─ library/
├─ profile/
├─ thumbs/
└─ upload/
My question is: how do I move/copy from old to new structure and have immich working again? I did try a few things but didn’t work…at the end I have permission problems, images not loading, etc.
Doing the migration the way it was recommended gave me problems with starting up the container (server was constantly rebooting), so I decided to make a new set of datasets for a new installation, rsync the files to the new location (yeah, I know, a lot of juggling of data…) and setup a new container.
All was well and hunky dory and the new container with the new storage schema works perfectly fine, until I saw the part of their guide covering multiple datasets that intrigued me: TrueNAS [Community] | Immich
I intended on moving all the data except the videos and pictures over to the SSD (from the main data folder), like I had it with the old storage layout, and found a similar issue if I had thumbs stored on the SSD - the server was constantly rebooting. I think part of the error was permissions for the folder/dataset. I made the datasets with the Apps preset.
What more info should I provide regarding this topic, has anyone successfully used these multiple datasets approach, etc.?
Man, my head hurts! I have been fussing with this for 3 days. I started with “Migrating Immich Storage on TrueNAS SCALE” from affan’s blog, but on a 1.2Tb data even on a 12Tb mirrored server, it would never complete and verify even after multiple rsync separate folders. I found that I had to use a (Ai generated) modification of the script that Migrated one directory using rsync, Verifies that directory, Retries if verification fails (up to N times -used 3), and Moves to the next directory when verified. It still failed the first time and then included inplace and checksum which ran slower. AND then had to have it changed to run in a persistent session overnight to get it to complete. Did step 4 in the guide and redeployed Immich. But it was only the beginning!
Because I have two unique users on Immich (me and wife) it seems that the files are owned by the unique UUID of each user and my wife’s 338,000 assets were now only 365. And to further complicate things, opening Immich on the phones created two new user ids. I found the assets under the original UUIDs in the original locations, changed their associations to the (hopefully correct owner) and am now waiting as the files are copied over to another folder for Immich to reindex and add. I only hope it works because now the 10 bucks a month to Google is starting to look worthwhile. Here’s hoping tomorrow everything finishes and reindexes and I have our files. Of course then I have to go figure out where multiple copies of whatever went where because my pool storage went from 1.5Tb when I started to around 5Tb now and then reclaim all that space.
Have to agree with Alexanderhuzar’s comment! Infuriating exercise. There must be an easier way, but my pea brain doesn’t understand it
Here i just don’t get it working because the server is always trying to start unsucessfuly " Failed to read: /encoded-video/.immich
Don’t know what else i shall do, after tried to copy that file from the backup and older folder million times!
Any help ?