tried to install immich. asks for database password on setup. is there a pre created password somewhere?
41 replies
tomspark wrote:
That's the admin sign-up, not a database password — Immich just words that first screen a bit confusingly. There's nothing pre-made to hunt for: the first account you create on the Immich web page automatically becomes your admin. So put in your own email and a password you'll remember, and that's your Immich login from then on. (SparkBox already generated the real, internal database password behind the scenes — you never type that one in anywhere.)
jackhammer57 wrote:
I was wondering because I get IMMICHDBPASSWORD error when I put my admin password
tomspark wrote:
Ah — my earlier answer missed the real cause, sorry. That error means Immich's database password never got generated on your setup (a gap when Immich is turned on after an upgrade rather than a fresh install), so its database can't start and registration fails. It's nothing to do with the admin password you typed. Finish your SparkBox upgrade first (the "sparkbox up" from your other thread), then run this to give Immich a fresh, working database — you've no photos in it yet, so nothing is lost: sudo sed -i '/^IMMICHDBPASSWORD=/d' /opt/sparkbox/.env echo "IMMICHDBPASSWORD=$(openssl rand -hex 16)" | sudo tee -a /opt/sparkbox/.env sudo docker rm -f sb-immich-db 2/dev/null sudo rm -rf /opt/sparkbox/modules/immich/config/db sudo sparkbox restart immich Give it a minute, reload the Immich page, and register your admin — it'll go through this time. I'm flagging the missing-password gap to Tom so installs handle it automatically.
jackhammer57 wrote:
Still getting the following error
tomspark wrote:
Ah — that "not allowed" message is the dashboard doing its job: IMMICHDBPASSWORD is an internal key, so the Settings page deliberately won't let you set it there. It has to be set on the box itself. Run these in your NAS terminal (the same place you ran the update), not in the dashboard: sudo sed -i '/^IMMICHDBPASSWORD=/d' /opt/sparkbox/.env echo "IMMICHDBPASSWORD=$(openssl rand -hex 16)" | sudo tee -a /opt/sparkbox/.env sudo docker rm -f sb-immich-db 2/dev/null sudo rm -rf /opt/sparkbox/modules/immich/config/db sudo sparkbox restart immich Then reload Immich and register your admin. Give me a shout if the terminal throws anything.
jackhammer57 wrote:
Joe@DXP4800PRO-868A:~$ sudo sed -i '/^IMMICHDBPASSWORD=/d' /opt/sparkbox/.env echo "IMMICHDBPASSWORD=$(openssl rand -hex 16)" | sudo tee -a /opt/sparkbox/.env sudo docker rm -f sb-immich-db 2/dev/null sudo rm -rf /opt/sparkbox/modules/immich/config/db sudo sparkbox restart immich IMMICHDBPASSWORD=c9def3088829f638fe2bb8d1eb85e436 [INFO] Restarting module: immich (recreating to pick up .env changes) Joe@DXP4800PRO-868A:~$ still get password error just to be clear this is happening right off the app install page of the dashboard
jackhammer57 wrote:
I also tried with the password generated IMMICHDBPASSWORD=c9def3088829f638fe2bb8d1eb85e436 that did not work either
tomspark wrote:
No worries — the bit that catches everyone here is that the database keeps its OLD password baked in unless you also wipe its data folder. Just changing the password in .env isn't enough on its own. Run ALL of this as one paste (safe — no photos in there yet): sudo sed -i '/^IMMICHDBPASSWORD=/d' /opt/sparkbox/.env echo "IMMICHDBPASSWORD=$(openssl rand -hex 16)" | sudo tee -a /opt/sparkbox/.env sudo docker rm -f sb-immich-db 2/dev/null sudo rm -rf /opt/sparkbox/modules/immich/config/db sudo sparkbox restart immich Give it ~30 seconds, reload Immich, and register. If it STILL won't go, paste me the output of: sudo docker logs sb-immich-db --tail 30 and I'll pin down the exact reason.
jackhammer57 wrote:
Error response from daemon: No such container: sb-immich-db
tomspark wrote:
Ah, that's actually the real clue — "no such container" means immich's database isn't running at all, so the restart didn't bring it back up. Let me see what happens when it tries to start. Run this and paste the whole output: sudo sparkbox restart immich then this so I can see the container states: sudo docker ps -a | grep immich That'll show me whether Immich is even switched on and why the database isn't coming up — then I can give you the exact fix instead of another guess.
jackhammer57 wrote:
here's output Joe@DXP4800PRO-868A:~$ sudo sparkbox restart immich [INFO] Restarting module: immich (recreating to pick up .env changes) Joe@DXP4800PRO-868A:~$ Joe@DXP4800PRO-868A:~$ sudo docker ps -a | grep immich Joe@DXP4800PRO-868A:~$
tomspark wrote:
That's the smoking gun — it says it's recreating but zero containers come up, which means the start is erroring out and the error is getting hidden. Let's catch it. Run this exactly (the 2&1 forces the hidden error to show): sudo sparkbox restart immich 2&1 | tail -30 Paste the whole output. Whatever error comes back is what's stopping Immich's containers from starting — once I see it, the fix should be quick.
jackhammer57 wrote:
Joe@DXP4800PRO-868A:~$ sudo sparkbox restart immich 2&1 | tail -30 [INFO] Restarting module: immich (recreating to pick up .env changes) Joe@DXP4800PRO-868A:~$
tomspark wrote:
Genuinely odd — even with the error-catch it's completely silent, which means the start command itself isn't producing anything (it should always print at least the container names). Let's run the exact thing SparkBox runs under the hood, directly, so nothing can hide the result: cd /opt/sparkbox && sudo SBROOT=/opt/sparkbox docker compose --env-file .env -p sparkbox -f modules/immich/docker-compose.yml up -d 2&1 | tail -30 Paste whatever it prints. This'll either start the containers or finally show the real error — and that tells me exactly what to fix.
jackhammer57 wrote:
Joe@DXP4800PRO-868A:~$ cd /opt/sparkbox && sudo SBROOT=/opt/sparkbox docker compose --env-file .env -p sparkbox -f modules/immich/docker-compose.yml up -d 2&1 | tail -30 6bb2b863ef46 Extracting 11.15kB/11.15kB 6bb2b863ef46 Extracting 11.15kB/11.15kB 6bb2b863ef46 Pull complete 3b981c3bfd83 Extracting 11.1kB/11.1kB 3b981c3bfd83 Extracting 11.1kB/11.1kB 3b981c3bfd83 Pull complete immich-server Pulled Network sparkboxsbimmich Creating Network sparkboxsbimmich Created time="2026-06-03T12:58:59-07:00" level=warning msg="Found orphan containers ([sb-sabnzbd sb-dashboard sb-npm sb-homepage sb-portainer sb-seerr sb-sonarr sb-qbittorrent sb-prowlarr sb-flaresolverr sb-radarr sb-gluetun sb-jellyfin-media sb-bazarr sb-deunhealth]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up." Container sb-immich-db Creating Container sb-immich-redis Creating Container sb-immich-ml Creating Container sb-immich-ml Created Container sb-immich-redis Created Container sb-immich-db Created Container sb-immich-server Creating Container sb-immich-server Created Container sb-immich-db Starting Container sb-immich-ml Starting Container sb-immich-redis Starting Container sb-immich-db Started Container sb-immich-redis Started Container sb-immich-db Waiting Container sb-immich-redis Waiting Container sb-immich-ml Started Container sb-immich-db Healthy Container sb-immich-redis Healthy Container sb-immich-server Starting Container sb-immich-server Started Joe@DXP4800PRO-868A:/opt/sparkbox$
tomspark wrote:
That's the one! It pulled the Immich images (they hadn't actually downloaded yet, which is why the earlier attempts came up empty) and it's creating the containers now. That orphan-containers line is just a harmless warning — ignore it. Give it ~30 seconds, then confirm all four are up: sudo docker ps | grep immich You want to see sb-immich-server, sb-immich-db, sb-immich-ml and sb-immich-redis. Once they're running, reload the Immich page and register your admin — with the fresh database password now in place, it should finally go through. Let me know if any of the four are missing.
jackhammer57 wrote:
Joe@DXP4800PRO-868A:/opt/sparkbox$ sudo docker ps | grep immich 6a63b51a2c2c ghcr.io/immich-app/immich-server:v2.7.5 "tini -- /bin/bash -…" 7 minutes ago Up 7 minutes (healthy) 0.0.0.0:2283-2283/tcp, :::2283-2283/tcp sb-immich-server bd74c5fc6512 ghcr.io/immich-app/immich-machine-learning:v2.7.5 "tini -- python -m i…" 7 minutes ago Up 7 minutes (healthy) sb-immich-ml 83e17da62bff redis:7-alpine "docker-entrypoint.s…" 7 minutes ago Up 7 minutes (healthy) 6379/tcp sb-immich-redis a301552efc94 ghcr.io/immich-app/postgres:16-vectorchord0.4.3-pgvectors0.2.1 "/usr/local/bin/immi…" 7 minutes ago Up 7 minutes (healthy) 5432/tcp sb-immich-db Joe@DXP4800PRO-868A:/opt/sparkbox$ I then tried to install through dashboard got the password error so then I tried again: Joe@DXP4800PRO-868A:/opt/sparkbox$ sudo sed -i '/^IMMICHDBPASSWORD=/d' /opt/sparkbox/.env echo "IMMICHDBPASSWORD=$(openssl rand -hex 16)" | sudo tee -a /opt/sparkbox/.env sudo docker rm -f sb-immich-db 2/dev/null sudo rm -rf /opt/sparkbox/modules/immich/config/db sudo sparkbox restart immich IMMICHDBPASSWORD=2fdf533bc6ec6dd924d0e5c8d071336f sb-immich-db [INFO] Restarting module: immich (recreating to pick up .env changes) Joe@DXP4800PRO-868A:/opt/sparkbox$ back to install, still won't let me past the password input screen
tomspark wrote:
Found the mix-up — and it's an easy one! That password screen you're stuck on is in the SparkBox dashboard, but Immich isn't set up there. Immich has its OWN web page, and THAT'S where you make your account. The dashboard's "password not allowed" is an internal thing — ignore it completely. Two steps: 1) You actually had it working (all 4 containers were healthy!) but re-running the reset block removed the database again. Bring it back once more — and don't run the reset block after this, your password's already set: cd /opt/sparkbox && sudo SBROOT=/opt/sparkbox docker compose --env-file .env -p sparkbox -f modules/immich/docker-compose.yml up -d 2) Then open Immich's own page directly — either the Open/Launch button on the Immich tile, or in a new browser tab go to: http://YOUR-NAS-IP:2283 (same IP as your dashboard, just port 2283). The first account you create on THAT page becomes your admin. That's it — no dashboard needed.
jackhammer57 wrote:
Excellent. Is there an easy way to set up folder location for uploads?
tomspark wrote:
You're in — nice work sticking with it through all that! Two things: 1) To make sure Immich survives future updates, run: sudo sparkbox enable immich 2) On the upload folder — honest answer: right now Immich stores uploads inside the SparkBox install folder (/opt/sparkbox/...) and there's no built-in setting to move it yet. SparkBox actually sets up a photos folder on your data drive for exactly this, but Immich isn't wired to use it — that's a gap, and I'm flagging it to Tom so photos land on your big storage by default. If you'd rather put it on a specific drive right now (best while the library's still empty), tell me the drive/path and I'll give you the steps.
jackhammer57 wrote:
I want to set the folder as /volume2/data/photos
tomspark wrote:
Can do — and since your library's empty, it's totally clean. Honest heads-up first: there's no built-in setting for this yet (the gap I flagged to Tom), so it's a manual symlink, and a big SparkBox update could reset it. With no photos in there, waiting a few days for the proper auto-fix is the no-hassle route — but if you want it now, here you go: sudo docker stop sb-immich-server sudo mkdir -p /volume2/data/photos sudo rm -rf /opt/sparkbox/modules/immich/config/upload sudo ln -s /volume2/data/photos /opt/sparkbox/modules/immich/config/upload sudo SBROOT=/opt/sparkbox docker compose --env-file /opt/sparkbox/.env -p sparkbox -f /opt/sparkbox/modules/immich/docker-compose.yml up -d --force-recreate Uploads then live in /volume2/data/photos. If a future update ever makes your photos look gone, just re-run the symlink line — the files themselves stay safe in /volume2.
jackhammer57 wrote:
applied patch and now immich-server keeps crashing here is the log. Connecting... 52026-06-03T21:43:02.547039331Z Detected CPU Cores: 2 z2026-06-03T21:43:04.052687367Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:04.052721152Z (Use node --trace-warnings ... to show where the warning was created) 32026-06-03T21:43:05.095831212Z Starting api worker =2026-06-03T21:43:05.103138352Z Starting microservices worker z2026-06-03T21:43:07.360456209Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:07.360485809Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-03T21:43:07.545834365Z [32m[Nest] 7 - [39m06/03/2026, 2:43:07 PM [32m LOG[39m [33m[Microservices:WebsocketRepository][39m [32mInitialized websocket server[39m {2026-06-03T21:43:07.655886954Z (node:24) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:07.655916165Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-03T21:43:07.928934100Z [32m[Nest] 7 - [39m06/03/2026, 2:43:07 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for clipindex of 0 rows[39m �2026-06-03T21:43:07.930826130Z [32m[Nest] 7 - [39m06/03/2026, 2:43:07 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for faceindex of 0 rows[39m �2026-06-03T21:43:07.936648163Z [32m[Nest] 7 - [39m06/03/2026, 2:43:07 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mRunning migrations[39m �2026-06-03T21:43:08.001517815Z [32m[Nest] 7 - [39m06/03/2026, 2:43:08 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mFinished running migrations[39m �2026-06-03T21:43:08.039099008Z [32m[Nest] 7 - [39m06/03/2026, 2:43:08 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mChecking for schema drift[39m �2026-06-03T21:43:08.133668838Z [32m[Nest] 24 - [39m06/03/2026, 2:43:08 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mInitialized websocket server[39m �2026-06-03T21:43:08.167138508Z [32m[Nest] 7 - [39m06/03/2026, 2:43:08 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mNo schema drift detected[39m 62026-06-03T21:43:08.172994791Z [32m[Nest] 7 - [39m06/03/2026, 2:43:08 PM [32m LOG[39m [33m[Microservices:StorageService][39m [32mVerifying system mount folder checks, current state: {"mountChecks":{"thumbs":true,"upload":true,"backups":true,"library":true,"profile":true,"encoded-video":true}}[39m (2026-06-03T21:43:08.173622997Z [31m[Nest] 7 - [39m06/03/2026, 2:43:08 PM [31m ERROR[39m [33m[Microservices:StorageService][39m [31mFailed to read (/usr/src/app/upload/encoded-video/.immich): Error: ENOENT: no such file or directory, open '/usr/src/app/upload/encoded-video/.immich'[39m �2026-06-03T21:43:08.176532556Z microservices worker error: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information.", stack: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information." �2026-06-03T21:43:08.176563093Z at StorageService.verifyReadAccess (/usr/src/app/server/dist/services/storage.service.js:130:19) g2026-06-03T21:43:08.176569685Z at async /usr/src/app/server/dist/services/storage.service.js:57:21 p2026-06-03T21:43:08.176574396Z at async /usr/src/app/server/dist/repositories/database.repository.js:392:27 �2026-06-03T21:43:08.176578658Z at async /usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/kysely.js:541:20 �2026-06-03T21:43:08.176582939Z at async DefaultConnectionProvider.provideConnection (/usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/driver/default-connection-provider.js:12:20) p2026-06-03T21:43:08.176587727Z at async /usr/src/app/server/dist/repositories/database.repository.js:389:13 G2026-06-03T21:43:08.183300567Z microservices worker exited with code 1 32026-06-03T21:43:08.183329483Z Killing api process :2026-06-03T21:43:09.673707415Z Initializing Immich v2.7.5 52026-06-03T21:43:09.682135855Z Detected CPU Cores: 2 z2026-06-03T21:43:11.235198217Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:11.235222448Z (Use node --trace-warnings ... to show where the warning was created) 32026-06-03T21:43:12.286676985Z Starting api worker =2026-06-03T21:43:12.292687686Z Starting microservices worker z2026-06-03T21:43:14.448032476Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:14.448076751Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-03T21:43:14.695241998Z [32m[Nest] 7 - [39m06/03/2026, 2:43:14 PM [32m LOG[39m [33m[Microservices:WebsocketRepository][39m [32mInitialized websocket server[39m {2026-06-03T21:43:14.805906720Z (node:24) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:14.805932996Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-03T21:43:14.814941711Z [32m[Nest] 7 - [39m06/03/2026, 2:43:14 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for clipindex of 0 rows[39m �2026-06-03T21:43:14.815564806Z [32m[Nest] 7 - [39m06/03/2026, 2:43:14 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for faceindex of 0 rows[39m �2026-06-03T21:43:14.820609147Z [32m[Nest] 7 - [39m06/03/2026, 2:43:14 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mRunning migrations[39m �2026-06-03T21:43:15.018693933Z [32m[Nest] 7 - [39m06/03/2026, 2:43:15 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mFinished running migrations[39m �2026-06-03T21:43:15.035320737Z [32m[Nest] 7 - [39m06/03/2026, 2:43:15 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mChecking for schema drift[39m �2026-06-03T21:43:15.210864908Z [32m[Nest] 7 - [39m06/03/2026, 2:43:15 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mNo schema drift detected[39m 62026-06-03T21:43:15.218133827Z [32m[Nest] 7 - [39m06/03/2026, 2:43:15 PM [32m LOG[39m [33m[Microservices:StorageService][39m [32mVerifying system mount folder checks, current state: {"mountChecks":{"thumbs":true,"upload":true,"backups":true,"library":true,"profile":true,"encoded-video":true}}[39m (2026-06-03T21:43:15.218988152Z [31m[Nest] 7 - [39m06/03/2026, 2:43:15 PM [31m ERROR[39m [33m[Microservices:StorageService][39m [31mFailed to read (/usr/src/app/upload/encoded-video/.immich): Error: ENOENT: no such file or directory, open '/usr/src/app/upload/encoded-video/.immich'[39m �2026-06-03T21:43:15.223306793Z microservices worker error: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information.", stack: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information." �2026-06-03T21:43:15.223341875Z at StorageService.verifyReadAccess (/usr/src/app/server/dist/services/storage.service.js:130:19) g2026-06-03T21:43:15.223348699Z at async /usr/src/app/server/dist/services/storage.service.js:57:21 p2026-06-03T21:43:15.223353139Z at async /usr/src/app/server/dist/repositories/database.repository.js:392:27 �2026-06-03T21:43:15.223378061Z at async /usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/kysely.js:541:20 �2026-06-03T21:43:15.223385541Z at async DefaultConnectionProvider.provideConnection (/usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/driver/default-connection-provider.js:12:20) p2026-06-03T21:43:15.223390817Z at async /usr/src/app/server/dist/repositories/database.repository.js:389:13 G2026-06-03T21:43:15.231261452Z microservices worker exited with code 1 32026-06-03T21:43:15.231311834Z Killing api process :2026-06-03T21:43:17.408591745Z Initializing Immich v2.7.5 52026-06-03T21:43:17.418812993Z Detected CPU Cores: 2 z2026-06-03T21:43:18.923980041Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:18.924008372Z (Use node --trace-warnings ... to show where the warning was created) 32026-06-03T21:43:19.973967376Z Starting api worker =2026-06-03T21:43:19.979830597Z Starting microservices worker {2026-06-03T21:43:22.244957609Z (node:24) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:22.244988129Z (Use node --trace-warnings ... to show where the warning was created) z2026-06-03T21:43:22.494419498Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-03T21:43:22.494469948Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-03T21:43:22.739906954Z [32m[Nest] 7 - [39m06/03/2026, 2:43:22 PM [32m LOG[39m [33m[Microservices:WebsocketRepository][39m [32mInitialized websocket server[39m �2026-06-03T21:43:23.115544092Z [32m[Nest] 7 - [39m06/03/2026, 2:43:23 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for clipindex of 0 rows[39m �2026-06-03T21:43:23.116541148Z [32m[Nest] 7
tomspark wrote:
Ah — that's my relocate that broke it, sorry! Easiest fix is to put it back on the original folder and you're working again in 10 seconds (your admin account is safe — it lives in the database, not the photo folder): sudo rm -f /opt/sparkbox/modules/immich/config/upload sudo mkdir -p /opt/sparkbox/modules/immich/config/upload sudo SBROOT=/opt/sparkbox docker compose --env-file /opt/sparkbox/.env -p sparkbox -f /opt/sparkbox/modules/immich/docker-compose.yml up -d --force-recreate Honestly I'd leave it there for now and let the proper /volume2 fix come through an update — it's not worth the hassle on an empty library. But if you DO still want /volume2 now, paste the LAST ~15 lines of that crash log (the actual error at the very bottom) and I'll fix the specific cause — almost certainly just a permissions thing on /volume2/data/photos.
jackhammer57 wrote:
Tried the fix to revert back and still have immich-server crashing here’s the last few lines of the log. �2026-06-03T22:51:18.585180550Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for clipindex of 0 rows[39m �2026-06-03T22:51:18.585851984Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mtargetLists=1, current=1 for faceindex of 0 rows[39m �2026-06-03T22:51:18.588452716Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mRunning migrations[39m �2026-06-03T22:51:18.648862494Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseRepository][39m [32mFinished running migrations[39m �2026-06-03T22:51:18.659333432Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mChecking for schema drift[39m �2026-06-03T22:51:18.773363716Z [32m[Nest] 24 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mInitialized websocket server[39m �2026-06-03T22:51:18.788676294Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:DatabaseService][39m [32mNo schema drift detected[39m 62026-06-03T22:51:18.794539316Z [32m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [32m LOG[39m [33m[Microservices:StorageService][39m [32mVerifying system mount folder checks, current state: {"mountChecks":{"thumbs":true,"upload":true,"backups":true,"library":true,"profile":true,"encoded-video":true}}[39m (2026-06-03T22:51:18.795420858Z [31m[Nest] 7 - [39m06/03/2026, 3:51:18 PM [31m ERROR[39m [33m[Microservices:StorageService][39m [31mFailed to read (/usr/src/app/upload/encoded-video/.immich): Error: ENOENT: no such file or directory, open '/usr/src/app/upload/encoded-video/.immich'[39m �2026-06-03T22:51:18.798394759Z microservices worker error: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information.", stack: Error: Failed to read: "<UPLOADLOCATION/encoded-video/.immich (/usr/src/app/upload/encoded-video/.immich) - Please see https://docs.immich.app/administration/system-integrityfolder-checks for more information." �2026-06-03T22:51:18.798423386Z at StorageService.verifyReadAccess (/usr/src/app/server/dist/services/storage.service.js:130:19) g2026-06-03T22:51:18.798429764Z at async /usr/src/app/server/dist/services/storage.service.js:57:21 p2026-06-03T22:51:18.798434128Z at async /usr/src/app/server/dist/repositories/database.repository.js:392:27 �2026-06-03T22:51:18.798438342Z at async /usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/kysely.js:541:20 �2026-06-03T22:51:18.798442587Z at async DefaultConnectionProvider.provideConnection (/usr/src/app/server/nodemodules/.pnpm/kysely@0.28.14/nodemodules/kysely/dist/cjs/driver/default-connection-provider.js:12:20) p2026-06-03T22:51:18.798447084Z at async /usr/src/app/server/dist/repositories/database.repository.js:389:13 G2026-06-03T22:51:18.803745248Z microservices worker exited with code 1 32026-06-03T22:51:18.803769291Z Killing api process
tomspark wrote:
Got the exact cause this time (and it's the last hurdle) — Immich writes tiny marker files (.immich) in each storage folder, and my earlier folder-swap wiped them, so Immich refuses to start to protect your data. The official fix is just to put those markers back. Run: sudo docker stop sb-immich-server for d in upload library thumbs encoded-video profile backups; do sudo mkdir -p /opt/sparkbox/modules/immich/config/upload/$d && sudo touch /opt/sparkbox/modules/immich/config/upload/$d/.immich; done sudo docker start sb-immich-server That recreates exactly what Immich's looking for and it'll start right up — your account is untouched (it's in the database, not those folders). Sorry for the runaround on the folder move; lesson learned that the manual relocate isn't safe until the proper fix ships.
jackhammer57 wrote:
Tried the last update. And it looks even more messed up. Might be easier with a fresh install of immich. Here’s the log. G2026-06-04T20:26:44.425427353Z at Socket.emit (node:events:508:28) W2026-06-04T20:26:44.425431057Z at addChunk (node:internal/streams/readable:563:12) j2026-06-04T20:26:44.425434790Z at readableAddChunkPushByteMode (node:internal/streams/readable:514:3) [2026-06-04T20:26:44.425438599Z at Readable.push (node:internal/streams/readable:394:5) d2026-06-04T20:26:44.425442309Z at TCP.onStreamRead (node:internal/streambasecommons:189:23) { :2026-06-04T20:26:44.425446220Z severitylocal: 'FATAL', 42026-06-04T20:26:44.425449933Z severity: 'FATAL', 02026-06-04T20:26:44.425453494Z code: '28P01', 12026-06-04T20:26:44.425457125Z file: 'auth.c', .2026-06-04T20:26:44.425460694Z line: '331', 82026-06-04T20:26:44.425464288Z routine: 'authfailed' !2026-06-04T20:26:44.425467865Z } 2026-06-04T20:26:44.425471342Z 02026-06-04T20:26:44.425474970Z Node.js v24.14.1 :2026-06-04T20:27:44.801955296Z Initializing Immich v2.7.5 52026-06-04T20:27:44.810783365Z Detected CPU Cores: 2 z2026-06-04T20:27:46.302520277Z (node:7) ExperimentalWarning: WASI is an experimental feature and might change at any time g2026-06-04T20:27:46.302571630Z (Use node --trace-warnings ... to show where the warning was created) �2026-06-04T20:27:46.356332069Z file:///usr/src/app/server/nodemodules/.pnpm/postgres@3.4.8/nodemodules/postgres/src/connection.js:817 M2026-06-04T20:27:46.356370587Z errored(Errors.postgres(parseError(x))) 62026-06-04T20:27:46.356377854Z ^ 2026-06-04T20:27:46.356383146Z 2026-06-04T20:27:46.356387664Z PostgresError: password authentication failed for user "immich" �2026-06-04T20:27:46.356392673Z at ErrorResponse (file:///usr/src/app/server/nodemodules/.pnpm/postgres@3.4.8/nodemodules/postgres/src/connection.js:817:22) �2026-06-04T20:27:46.356397589Z at handle (file:///usr/src/app/server/nodemodules/.pnpm/postgres@3.4.8/nodemodules/postgres/src/connection.js:489:6) �2026-06-04T20:27:46.356402302Z at Socket.data (file:///usr/src/app/server/nodemodules/.pnpm/postgres@3.4.8/nodemodules/postgres/src/connection.js:324:9) G2026-06-04T20:27:46.356407126Z at Socket.emit (node:events:508:28) W2026-06-04T20:27:46.356411740Z at addChunk (node:internal/streams/readable:563:12) j2026-06-04T20:27:46.356416506Z at readableAddChunkPushByteMode (node:internal/streams/readable:514:3) [2026-06-04T20:27:46.356421158Z at Readable.push (node:internal/streams/readable:394:5) d2026-06-04T20:27:46.356425714Z at TCP.onStreamRead (node:internal/streambasecommons:189:23) { :2026-06-04T20:27:46.356430250Z severitylocal: 'FATAL', 42026-06-04T20:27:46.356434630Z severity: 'FATAL', 02026-06-04T20:27:46.356439011Z code: '28P01', 12026-06-04T20:27:46.356443417Z file: 'auth.c', .2026-06-04T20:27:46.356447755Z line: '331', 82026-06-04T20:27:46.356452149Z routine: 'authfailed' !2026-06-04T20:27:46.356456592Z } 2026-06-04T20:27:46.356460937Z 02026-06-04T20:27:46.356465282Z Node.js v24.14.1
tomspark wrote:
Honestly, yes — that's the right call now, and I'm sorry for the runaround getting here. Since your library's empty, a clean slate is the fastest way out and you lose nothing. One quick check first so we don't wipe into the dark — this is the exact thing that started it all (immich needs a database password). SSH in and run: grep IMMICHDBPASSWORD /opt/sparkbox/.env If that shows a line with a real value after the = sign, you're set — run these three to reset immich clean: sudo docker rm -f sb-immich-server sb-immich-ml sb-immich-db sb-immich-redis sudo rm -rf /opt/sparkbox/modules/immich/config sudo sparkbox up Give it a minute, then open immich at :2283 and register a fresh admin — done. ⚠️ That middle line erases immich's database and config (its login + anything stored in it). Your library's empty so this loses nothing — just don't run it if you've added photos since we started. If instead the grep shows nothing (or just a blank after the =), THAT missing password is the whole root cause — paste me what it shows and I'll give you the one line to set it before we wipe. Either way, we'll get you sorted.
jackhammer57 wrote:
The information I found searching online is to shut down containers, edit the .env file UPLOADLOCATION to new location, open docker-compose.yaml to confirm then restart container To move your Immich upload folder to a separate volume or drive, update your Docker configuration to point to the new location, transfer your existing files, and remount the new storage.Follow these steps to safely change your directory: 1. Stop the Immich Containers Ensure no new uploads are being processed during the transfer: bash docker compose down 2. Copy the Existing Files Copy all current files from your old upload location to the new destination (your separate volume/drive) while preserving permissions :bash rsync -avz /old/path/to/upload/ /new/path/to/upload/ 3. Update the Environment File Edit your .env file (located in the same directory as your docker-compose.yml). Update the UPLOADLOCATION variable to your new drive path: env UPLOADLOCATION=/new/path/to/upload 4. Verify Docker Volumes Open your docker-compose.yml file and ensure the immich-server container volume points to ${UPLOADLOCATION}: yaml services: immich-server: volumes: - ${UPLOADLOCATION}:/usr/src/app/upload Or if mounting the drive directly in the compose file: - /new/path/to/upload:/usr/src/app/upload 5. Restart ContainersStart the Immich services with the updated paths: bash docker compose up -d I wouldn’t need step 2 above as I haven’t uploaded any files yet
tomspark wrote:
Hold off on the UPLOADLOCATION route — that guide is for the standard Immich setup, and SparkBox's version doesn't use that variable, so editing it won't do anything here. It also wouldn't touch what's actually broken. And the great news: your earlier log handed us the exact cause. That line 'password authentication failed for user immich' means Immich's database has an OLD password baked into it that no longer matches the current one — a database mismatch, not a photo/upload problem at all. The clean reset I sent earlier is exactly the fix: wiping the old database lets it rebuild with the right password. Since you've uploaded nothing, it's totally safe — and you can even skip the grep now, because that log already proves the password is there, just mismatched. Run these three: sudo docker rm -f sb-immich-server sb-immich-ml sb-immich-db sb-immich-redis sudo rm -rf /opt/sparkbox/modules/immich/config sudo sparkbox up Give it a minute, open immich at :2283, register your admin — and that's the saga finally done. Shout if anything's off after.
jackhammer57 wrote:
Got immich reinstalled. Got through the onboarding process. But it keeps kicking me out. Here’s the log: ice][39m [32mFeature Flags: { 62026-06-04T21:26:34.417967567Z "smartSearch": true, <2026-06-04T21:26:34.417973359Z "facialRecognition": true, =2026-06-04T21:26:34.417995119Z "duplicateDetection": true, .2026-06-04T21:26:34.418001481Z "map": true, ;2026-06-04T21:26:34.418005673Z "reverseGeocoding": true, 72026-06-04T21:26:34.418009513Z "importFaces": false, 22026-06-04T21:26:34.418013277Z "sidecar": true, 12026-06-04T21:26:34.418016943Z "search": true, 02026-06-04T21:26:34.418020557Z "trash": true, 12026-06-04T21:26:34.418024382Z "oauth": false, ;2026-06-04T21:26:34.418028148Z "oauthAutoLaunch": false, .2026-06-04T21:26:34.418031866Z "ocr": true, 82026-06-04T21:26:34.418035484Z "passwordLogin": true, 62026-06-04T21:26:34.418039195Z "configFile": false, 02026-06-04T21:26:34.418042925Z "email": false &2026-06-04T21:26:34.418046548Z }[39m �2026-06-04T21:26:34.594140928Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:SystemConfigService][39m [32mLogLevel=log (set via system config)[39m �2026-06-04T21:26:34.602738323Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:MachineLearningRepository][39m [32mMachine learning server became healthy (http://sb-immich-ml:3003).[39m �2026-06-04T21:26:34.619900562Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:NestFactory][39m [32mStarting Nest application...[39m �2026-06-04T21:26:34.620963197Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mBullModule dependencies initialized[39m �2026-06-04T21:26:34.620991890Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mClsModule dependencies initialized[39m �2026-06-04T21:26:34.621000051Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mClsCommonModule dependencies initialized[39m �2026-06-04T21:26:34.621006113Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mKyselyModule$1 dependencies initialized[39m �2026-06-04T21:26:34.621011383Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mOpenTelemetryModule dependencies initialized[39m �2026-06-04T21:26:34.621016661Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mKyselyCoreModule$1 dependencies initialized[39m �2026-06-04T21:26:34.621021815Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mDiscoveryModule dependencies initialized[39m �2026-06-04T21:26:34.621030165Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mOpenTelemetryCoreModule dependencies initialized[39m �2026-06-04T21:26:34.621056445Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mClsRootModule dependencies initialized[39m �2026-06-04T21:26:34.621064294Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mBullModule dependencies initialized[39m �2026-06-04T21:26:34.621070138Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mBullModule dependencies initialized[39m �2026-06-04T21:26:34.621075496Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:InstanceLoader][39m [32mMicroservicesModule dependencies initialized[39m �2026-06-04T21:26:34.621080631Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:NestApplication][39m [32mNest application successfully started[39m �2026-06-04T21:26:34.621087073Z [32m[Nest] 7 - [39m06/04/2026, 2:26:34 PM [32m LOG[39m [33m[Microservices:Bootstrap][39m [32mImmich Microservices is running [v2.7.5] [production] [39m �2026-06-04T21:28:46.423297506Z [32m[Nest] 24 - [39m06/04/2026, 2:28:46 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Connect: eOFNnlZehGvlL9QAAAB[39m �2026-06-04T21:29:13.932516258Z [32m[Nest] 24 - [39m06/04/2026, 2:29:13 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Disconnect: eOFNnlZehGvlL9QAAAB[39m �2026-06-04T21:30:01.073915366Z [32m[Nest] 24 - [39m06/04/2026, 2:30:01 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Connect: lA7NQc60yGC8oy5AAAD[39m �2026-06-04T21:30:21.611020170Z [32m[Nest] 24 - [39m06/04/2026, 2:30:21 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Disconnect: lA7NQc60yGC8oy5AAAD[39m �2026-06-04T21:32:28.448493620Z [32m[Nest] 24 - [39m06/04/2026, 2:32:28 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Connect: 8e6bSWA6pd1Uq8VAAAF[39m �2026-06-04T21:34:25.066891317Z [32m[Nest] 24 - [39m06/04/2026, 2:34:25 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Disconnect: 8e6bSWA6pd1Uq8VAAAF[39m �2026-06-04T21:37:09.205388624Z [32m[Nest] 24 - [39m06/04/2026, 2:37:09 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Connect: PiG6qWT9Fwd68mSLAAAH[39m �2026-06-04T21:37:09.206540780Z [32m[Nest] 24 - [39m06/04/2026, 2:37:09 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Disconnect: PiG6qWT9Fwd68mSLAAAH[39m �2026-06-04T21:37:10.249459643Z [32m[Nest] 24 - [39m06/04/2026, 2:37:10 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Connect: CDJdcEYdyfGDgkbAAAJ[39m �2026-06-04T21:37:14.735076483Z [32m[Nest] 24 - [39m06/04/2026, 2:37:14 PM [32m LOG[39m [33m[Api:WebsocketRepository][39m [32mWebsocket Disconnect: CDJdcEYdyfGDgkbAAAJ[39m
tomspark wrote:
First off — big progress! That reset fixed the database, so immich actually starts now and you got all the way through setup. The login part is a separate, much smaller thing. In your log I can see immich connecting and then dropping its live connection every ~30 seconds (the 'Websocket Connect / Websocket Disconnect' lines) — that's what's bouncing you out. It almost always comes down to HOW you're opening immich. Quick question so I give you the right fix: are you opening it straight at the NAS address (http://your-nas-ip:2283), or through Tailscale / a domain / a reverse proxy? If it's direct at :2283, we'll check the cookie/HTTPS angle. If it's through Tailscale or a proxy, that's almost certainly it — those have to be told to pass 'websocket' connections through, and immich leans on them hard. Tell me which and I'll hand you the exact setting.
jackhammer57 wrote:
Im connecting directly through the nas port 2283
tomspark wrote:
Perfect — direct on :2283 rules out the proxy/Tailscale cause (those are the usual websocket killers), so it's something more local. The most common cause on direct access is the browser itself — an ad-blocker or privacy extension quietly killing immich's live connection, or a stale cookie. Quick test: open immich in an incognito/private window (or a totally different browser) and use it for a few minutes. If it behaves there → it's an extension or cookie in your normal browser; disable extensions for the immich tab, or clear its cookies for that address. If it STILL boots you in incognito → it's not the browser. Grab the server log right after it kicks you (docker logs sb-immich-server --tail 30) and paste it — that shows whether immich-server is dropping the connection on its end. We'll pin it from there.
jackhammer57 wrote:
Cleared cookies and it has fixed the problem.
jackhammer57 wrote:
I shall leave it like that for the time being and hopefully Tom is able to come up with a work around.
tomspark wrote:
You've been a trooper through this whole thing — and the hard part is genuinely done, immich is running now. The logout is the last little gremlin and I don't want to leave you hanging on it. One 30-second check before you park it: open immich in a private/incognito window (or a totally different browser) and use it for a couple of minutes. If it stays logged in there, it's just a browser extension — ad-blockers are the usual immich culprit — and the fix is one toggle. If it STILL logs you out in incognito, then it's on our side and I'll dig in properly with you. No pressure either way, but that one test tells us instantly which it is. I'm not going anywhere on it.
jackhammer57 wrote:
Opened in private window and it stayed open.
tomspark wrote:
That's the answer right there — if it stays logged in in the private window, it's a browser extension in your normal browser killing immich's live connection (an ad-blocker or privacy extension is the usual culprit), or a stale cookie. Two quick fixes in your normal browser: 1. Allowlist your immich address (http://your-nas-ip:2283) in your ad-blocker / privacy extension, or just pause it for that tab. 2. If that doesn't do it, clear cookies for that address and log in fresh. Either one should make it stick. And with that, your whole immich saga is finally done — genuinely nice work sticking it out through all of that.
tomspark wrote:
Good news, Joe — this is sorted properly now, and you don't need the UPLOADLOCATION route (SparkBox doesn't use that variable, so editing it wouldn't have done anything). Update with sudo sparkbox upgrade and Immich will keep your whole photo library on your storage pool instead of the small system disk. If you've already added photos, the update moves them across for you automatically — it copies and verifies everything first and keeps the originals tucked aside until you're happy, so nothing's at risk. Since you'd reset to an empty library, it'll just start clean on the pool. Thanks for sticking through the whole saga — you found a genuine bug, and it's fixed for everyone now.