MisterSanders

I had the same problem and found this thread in a search. For others who are showing up well after like me, I wanted to make sure there's a clear answer that yes, your Immich data (user accounts, albums, etc.) will be lost. If you're okay with this, go for it. If not, then you can reset your Postgres password with these steps: In the Unraid web UI, open the Docker tab. Click on the Postgres container and select "Console" to open a shell inside the container. Enter psql -U postgres This will take you to a postgres prompt Enter \password postgres You will be prompted to enter a new password and confirm it. This updates the password for the postgres superuser account, by the way. Make sure you update (if needed) your Immich container postgres password variable to match. Troubleshooting: If you can't complete the above steps because step 3 is asking for authentication, check your pg_hba.conf file (found in your appdata/postgres.. folder). After making a copy of this file for safety, edit the file to replace `md5` with 'trust' (no quotes). This will allow passwordless login for the above steps. Restart postgres and give the above steps another go.

Thanks for your reply. In my case, it turned out to be cookies. I cleared Firefox's cookies for my server's address (Firefox: Settings > Privacy and Security), and the login worked as expected -- no looping login screen. I'm writing this message in case others find themselves in the same situation as us.

I'm having the same problem: an endless loop of entering credentials to be taken back to the login screen without any error message. I'm also using Firefox, but when I use a private session in Firefox it works fine. I've disabled all add-ons in the regular session and fiddled with privacy/security settings, but I haven't figured out what's causing this behavour. @emptyfish, did you figure out what the specific cause was for you?

I see how I was misunderstanding the file paths. Thanks for the explanations. 👍 @Squid, you were right, this was the problem that prevented the mover from moving these files off my cache. I changed the share to split at any directory, and the mover's now moving these files over. Thank you!

The shares have always been set to cache:yes, but the mover isn't moving them. Making up an example, I have the following: On my cache drive, /storage/cache/media/tv/seinfeld/season01/seinfeld.s01e04.mp4, taking up 802mb On my share, /media/tv/seinfeld/season01/seinfeld.s01e04.mp4, also taking up 802mb Deleting either seinfeld.s01e04.mp4 file deletes the other, freeing up 802mb on the share, and 802mb on the cache. This is what made me reason they were hardlinked. Looking for a way to delete the cache versions. I've attached my diagnostics log to this post. city6-diagnostics-20211209-1542.zip

[EDIT: I totally misunderstood the problem: mover wasn't moving because of Split Level. Resolution at or near the end.] My cache has filled up with files that also exist on a share (same paths). But they're hardlinked, it seems, and deleting the files on cache deletes the same file on the share. Is there a way to manually remove the cache items without affecting the share items?