immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 08:41:28 +03:00
Code Issues 26 Packages Projects Releases 10 Wiki Activity

[BUG] Suddenly incorrect email or password #1860

New Issue
Closed
opened 2026-02-05 04:13:14 +03:00 by OVERLORD · 29 comments
OVERLORD commented 2026-02-05 04:13:14 +03:00
Owner
Copy Link

Originally created by @jwefers on GitHub (Dec 21, 2023).

The bug

After updating from 1.91.0 to 1.91.4, i cannot log in with admin user and my personal user anymore (web). Second household user account still works. My android app with my personal user still seems to work (still active session?)

Bonus: Setting the admin password with immich-admin reset-admin-password does not fix it - still cannot use the just-set admin pw to log in

Note: I replaced the docker volumes with bind mounts - did the internal user for any component change? I did that because it allows me to boot immich on my beefy desktop pc accessing my data mounted via sshfs and churn through re-MLing all photos quite fast.

The OS that Immich Server is running on

Debian Bookworm

Version of Immich Server

1.91.4

Version of Immich Mobile App

1.91.4 build.116

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

version: "3.8"

#
# WARNING: 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}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: unless-stopped

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    extends:
      file: hwaccel.yml
      service: hwaccel
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: unless-stopped

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - ${MACHINE_LEARNING_LOCATION}:/cache
    env_file:
      - .env
    restart: unless-stopped

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:b6124ab2e45cc332e16398022a411d7e37181f21ff7874835e0180f56a09e82a
    restart: unless-stopped

  database:
    container_name: immich_postgres
    image: tensorchord/pgvecto-rs:pg14-v0.1.11@sha256:0335a1a22f8c5dd1b697f14f079934f5152eaaa216c09b61e293be285491f8ee
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - ${DATABASE_LOCATION}:/var/lib/postgresql/data
    restart: unless-stopped

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=/ssdraid/immich/data
DATABASE_LOCATION=/ssdraid/immich/postgres
MACHINE_LEARNING_LOCATION=/ssdraid/immich/machine-learning

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

# Connection secrets for postgres and typesense. You should change these to random passwords
TYPESENSE_API_KEY=xxx
DB_PASSWORD=xxx

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

REDIS_HOSTNAME=immich_redis

Reproduction steps

1. Try to log in on web
2. "Incorrect email or password" for 2 out of 3 accounts
3.
...

Additional information

No response

Originally created by @jwefers on GitHub (Dec 21, 2023). ### The bug After updating from 1.91.0 to 1.91.4, i cannot log in with admin user and my personal user anymore (web). Second household user account still works. My android app with my personal user still seems to work (still active session?) Bonus: Setting the admin password with `immich-admin reset-admin-password` does not fix it - still cannot use the just-set admin pw to log in **Note: I replaced the docker volumes with bind mounts** - did the internal user for any component change? I did that because it allows me to boot immich on my beefy desktop pc accessing my data mounted via sshfs and churn through re-MLing all photos quite fast. ### The OS that Immich Server is running on Debian Bookworm ### Version of Immich Server 1.91.4 ### Version of Immich Mobile App 1.91.4 build.116 ### Platform with the issue - [ ] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML version: "3.8" # # WARNING: 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} command: [ "start.sh", "immich" ] volumes: - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - 2283:3001 depends_on: - redis - database restart: unless-stopped immich-microservices: container_name: immich_microservices image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} extends: file: hwaccel.yml service: hwaccel command: [ "start.sh", "microservices" ] volumes: - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro env_file: - .env depends_on: - redis - database restart: unless-stopped immich-machine-learning: container_name: immich_machine_learning image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} volumes: - ${MACHINE_LEARNING_LOCATION}:/cache env_file: - .env restart: unless-stopped redis: container_name: immich_redis image: redis:6.2-alpine@sha256:b6124ab2e45cc332e16398022a411d7e37181f21ff7874835e0180f56a09e82a restart: unless-stopped database: container_name: immich_postgres image: tensorchord/pgvecto-rs:pg14-v0.1.11@sha256:0335a1a22f8c5dd1b697f14f079934f5152eaaa216c09b61e293be285491f8ee env_file: - .env environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} volumes: - ${DATABASE_LOCATION}:/var/lib/postgresql/data restart: unless-stopped ``` ### Your .env content ```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=/ssdraid/immich/data DATABASE_LOCATION=/ssdraid/immich/postgres MACHINE_LEARNING_LOCATION=/ssdraid/immich/machine-learning # The Immich version to use. You can pin this to a specific version like "v1.71.0" IMMICH_VERSION=release # Connection secrets for postgres and typesense. You should change these to random passwords TYPESENSE_API_KEY=xxx DB_PASSWORD=xxx # The values below this line do not need to be changed ################################################################################### DB_HOSTNAME=immich_postgres DB_USERNAME=postgres DB_DATABASE_NAME=immich REDIS_HOSTNAME=immich_redis ``` ### Reproduction steps ```bash 1. Try to log in on web 2. "Incorrect email or password" for 2 out of 3 accounts 3. ... ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 04:13:21 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Dec 21, 2023):

Hey, we have had a couple of issues similar to this reported recently, would you be able to provide a dump of your database, specifically the users table? I'm hoping we can replicate this ourselves with that data and figure out exactly what is going on.

@zackpollard commented on GitHub (Dec 21, 2023): Hey, we have had a couple of issues similar to this reported recently, would you be able to provide a dump of your database, specifically the users table? I'm hoping we can replicate this ourselves with that data and figure out exactly what is going on.
OVERLORD commented 2026-02-05 04:13:29 +03:00
Author
Owner
Copy Link

@danieldietzler commented on GitHub (Dec 21, 2023):

The easiest way to do that would probably be to join the Discord. Then you could DM us the dump

@danieldietzler commented on GitHub (Dec 21, 2023): The easiest way to do that would probably be to join the [Discord](https://discord.gg/D8JsnBEuKb). Then you could DM us the dump
OVERLORD commented 2026-02-05 04:13:32 +03:00
Author
Owner
Copy Link

@jwefers commented on GitHub (Dec 21, 2023):

sure, in a few hours i'll provide it, thanks

@jwefers commented on GitHub (Dec 21, 2023): sure, in a few hours i'll provide it, thanks
OVERLORD commented 2026-02-05 04:13:34 +03:00
Author
Owner
Copy Link

@TwoD commented on GitHub (Dec 21, 2023):

I'm having the same issue. Only have one user. Resetting the admin password does not help. Attempting to reset via the GUI in a browser which is still logged in just says "Unauthrorized".

Attaching my users table contents.

users.txt

@TwoD commented on GitHub (Dec 21, 2023): I'm having the same issue. Only have one user. Resetting the admin password does not help. Attempting to reset via the GUI in a browser which is still logged in just says "Unauthrorized". Attaching my users table contents. [users.txt](https://github.com/immich-app/immich/files/13745009/users.txt)
OVERLORD commented 2026-02-05 04:13:43 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Dec 21, 2023):

You guys can follow the conversation here for a fix.

https://discord.com/channels/979116623879368755/1185315110395322528

We currently don't understand why this issue happen yet

@alextran1502 commented on GitHub (Dec 21, 2023): You guys can follow the conversation here for a fix. https://discord.com/channels/979116623879368755/1185315110395322528 We currently don't understand why this issue happen yet
OVERLORD commented 2026-02-05 04:13:50 +03:00
Author
Owner
Copy Link

@TwoD commented on GitHub (Dec 21, 2023):

Thanks, but I'd rather stick to using an actual issue tracker for issues, not an unorganized chat client.

@TwoD commented on GitHub (Dec 21, 2023): Thanks, but I'd rather stick to using an actual issue tracker for issues, not an unorganized chat client.
OVERLORD commented 2026-02-05 04:13:58 +03:00
Author
Owner
Copy Link

@jwefers commented on GitHub (Dec 22, 2023):

After some back and forth with Zack, the index is corrupted. After running psql REINDEX users, all works again.

I identified this by doing some EXPLAIN ANALYZE on the queries for a user with a working and non-working user. It shows that the non-working users were not contained in the index on the email field.

@jwefers commented on GitHub (Dec 22, 2023): After some back and forth with Zack, the index is corrupted. After running psql `REINDEX users`, all works again. I identified this by doing some `EXPLAIN ANALYZE` on the queries for a user with a working and non-working user. It shows that the non-working users were not contained in the index on the email field.
OVERLORD commented 2026-02-05 04:14:02 +03:00
Author
Owner
Copy Link

@jwefers commented on GitHub (Dec 22, 2023):

so the question would be if on a recent update, scheme changed in areas around this and there is unexpected postgres behaviour?

@jwefers commented on GitHub (Dec 22, 2023): so the question would be if on a recent update, scheme changed in areas around this and there is unexpected postgres behaviour?
OVERLORD commented 2026-02-05 04:14:08 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Dec 22, 2023):

Hey @VoVAllen, we just wanted to loop you in on this issue to understand if pgvecto.rs could in any way cause something like this. Here's what we know so far:

  • The index of our users (login) table somehow becomes corrupt, specifically the email field
  • This happened during the upgrade to the new version
  • We have had multiple reports of this issue since the latest upgrade which includes the change to use pgvecto.rs
  • We haven't made any changes or run any SQL migrations around the users table
  • We are not sure if this is isolated to the users index, because it would be much harder to spot elsewhere
  • The image that this use specifically migrated from was postgres:14-alpine@sha256:6a0e35296341e676fe6bd8d236c72afffe2dfe3d7eb9c2405c0f3fc04500cd07
  • The specific image they migrated to was tensorchord/pgvecto-rs:pg14-v0.1.11@sha256:0335a1a22f8c5dd1b697f14f079934f5152eaaa216c09b61e293be285491f8ee

We are essentially just wondering if, from your knowledge of the pgvecto.rs codebase, is there any way that it could somehow cause corrupted indexes elsewhere in postgres? We've never had reports of this kind of thing prior to this upgrade but we have now had 4 seperate reports of the issue. If you could shed any light on this, it would be appreciated. Thanks!

@zackpollard commented on GitHub (Dec 22, 2023): Hey @VoVAllen, we just wanted to loop you in on this issue to understand if pgvecto.rs could in any way cause something like this. Here's what we know so far: - The index of our users (login) table somehow becomes corrupt, specifically the email field - This happened during the upgrade to the new version - We have had multiple reports of this issue since the latest upgrade which includes the change to use pgvecto.rs - We haven't made any changes or run any SQL migrations around the users table - We are not sure if this is isolated to the users index, because it would be much harder to spot elsewhere - The image that this use specifically migrated from was `postgres:14-alpine@sha256:6a0e35296341e676fe6bd8d236c72afffe2dfe3d7eb9c2405c0f3fc04500cd07` - The specific image they migrated to was `tensorchord/pgvecto-rs:pg14-v0.1.11@sha256:0335a1a22f8c5dd1b697f14f079934f5152eaaa216c09b61e293be285491f8ee` We are essentially just wondering if, from your knowledge of the pgvecto.rs codebase, is there any way that it could somehow cause corrupted indexes elsewhere in postgres? We've never had reports of this kind of thing prior to this upgrade but we have now had 4 seperate reports of the issue. If you could shed any light on this, it would be appreciated. Thanks!
OVERLORD commented 2026-02-05 04:14:17 +03:00
Author
Owner
Copy Link

@VoVAllen commented on GitHub (Dec 22, 2023):

@zackpollard We're aware of some edge device with low kernel version may have errors, like https://github.com/tensorchord/pgvecto.rs/issues/202, and we're fixing it. For the corrupted index, we have only encountered this issue during plugin upgrades. However, we have only tested it on the cloud and our own computer, so it's possible to have edge cases on other devices.

To reset the pgvecto.rs:

  • Delete all files under pgdata/pg_vectors
  • Restart postgres

This would not affect any of your data (including embedding) inside the postgres. Only the index part is dropped. Then I would expect everything at least works.

The pgvecto.rs index itself is isolated from other indexes. It's totally independent

@VoVAllen commented on GitHub (Dec 22, 2023): @zackpollard We're aware of some edge device with low kernel version may have errors, like https://github.com/tensorchord/pgvecto.rs/issues/202, and we're fixing it. For the corrupted index, we have only encountered this issue during plugin upgrades. However, we have only tested it on the cloud and our own computer, so it's possible to have edge cases on other devices. To reset the pgvecto.rs: - Delete all files under pgdata/pg_vectors - Restart postgres This would not affect any of your data (including embedding) inside the postgres. Only the index part is dropped. Then I would expect everything at least works. The pgvecto.rs index itself is isolated from other indexes. It's totally independent
OVERLORD commented 2026-02-05 04:14:23 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Dec 22, 2023):

@zackpollard We're aware of some edge device with low kernel version may have errors, like tensorchord/pgvecto.rs#202, and we're fixing it. For the corrupted index, we have only encountered this issue during plugin upgrades. However, we have only tested it on the cloud and our own computer, so it's possible to have edge cases on other devices.

To reset the pgvecto.rs:

* Delete all files under pgdata/pg_vectors

* Restart postgres

This would not affect any of your data (including embedding) inside the postgres. Only the index part is dropped. Then I would expect everything at least works.

The pgvecto.rs index itself is isolated from other indexes. It's totally independent

Yea, this is the weird thing. This is not a pgvecto.rs index, it's completely unrelated to that, however it's only started showing up after we started to move users to the pgvecto.rs image.

@zackpollard commented on GitHub (Dec 22, 2023): > @zackpollard We're aware of some edge device with low kernel version may have errors, like [tensorchord/pgvecto.rs#202](https://github.com/tensorchord/pgvecto.rs/issues/202), and we're fixing it. For the corrupted index, we have only encountered this issue during plugin upgrades. However, we have only tested it on the cloud and our own computer, so it's possible to have edge cases on other devices. > > To reset the pgvecto.rs: > > * Delete all files under pgdata/pg_vectors > > * Restart postgres > > > This would not affect any of your data (including embedding) inside the postgres. Only the index part is dropped. Then I would expect everything at least works. > > The pgvecto.rs index itself is isolated from other indexes. It's totally independent Yea, this is the weird thing. This is not a pgvecto.rs index, it's completely unrelated to that, however it's only started showing up after we started to move users to the pgvecto.rs image.
OVERLORD commented 2026-02-05 04:14:26 +03:00
Author
Owner
Copy Link

@VoVAllen commented on GitHub (Dec 22, 2023):

@zackpollard I read the thread in Discord. Does it happen only on the admin account? Or some data is broken here? pgvecto.rs is just an index, that won't modify anything inside postgres. It just receive the change inside postgres, and applies it on its own index. And when query happens, it returns the related rows. Nothing inside postgres would be affected. Even for the embedding, pgvecto.rs would just store another copy. No modification happens for postgres

@VoVAllen commented on GitHub (Dec 22, 2023): @zackpollard I read the thread in Discord. Does it happen only on the admin account? Or some data is broken here? pgvecto.rs is just an index, that won't modify anything inside postgres. It just receive the change inside postgres, and applies it on its own index. And when query happens, it returns the related rows. Nothing inside postgres would be affected. Even for the embedding, pgvecto.rs would just store another copy. No modification happens for postgres
OVERLORD commented 2026-02-05 04:14:30 +03:00
Author
Owner
Copy Link

@jwefers commented on GitHub (Dec 22, 2023):

not just admin accounts. 2/3 users for me. And yes, the email column is a btree index.

@jwefers commented on GitHub (Dec 22, 2023): not just admin accounts. 2/3 users for me. And yes, the email column is a btree index.
OVERLORD commented 2026-02-05 04:14:32 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Dec 22, 2023):

@zackpollard I read the thread in Discord. Does it happen only on the admin account? Or some data is broken here? pgvecto.rs is just an index, that won't modify anything inside postgres. It just receive the change inside postgres, and applies it on its own index. And when query happens, it returns the related rows. Nothing inside postgres would be affected. Even for the embedding, pgvecto.rs would just store another copy. No modification happens for postgres

The data itself appears to be fine, it's the btree index that has been corrupted somehow. A REINDEX on the table fixes the problem, but we are wondering how that index got corrupted in the first place.

@zackpollard commented on GitHub (Dec 22, 2023): > @zackpollard I read the thread in Discord. Does it happen only on the admin account? Or some data is broken here? pgvecto.rs is just an index, that won't modify anything inside postgres. It just receive the change inside postgres, and applies it on its own index. And when query happens, it returns the related rows. Nothing inside postgres would be affected. Even for the embedding, pgvecto.rs would just store another copy. No modification happens for postgres The data itself appears to be fine, it's the btree index that has been corrupted somehow. A REINDEX on the table fixes the problem, but we are wondering how that index got corrupted in the first place.
OVERLORD commented 2026-02-05 04:14:35 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Dec 22, 2023):

Note that we're not being suspicious of pgvecto.rs, it's just the only potential lead we have so we thought we'd ask :) From your explanation it sounds very unlikely to me that pgvecto.rs is involved here.

@bo0tzz commented on GitHub (Dec 22, 2023): Note that we're not being suspicious of pgvecto.rs, it's just the only potential lead we have so we thought we'd ask :) From your explanation it sounds very unlikely to me that pgvecto.rs is involved here.
OVERLORD commented 2026-02-05 04:14:36 +03:00
Author
Owner
Copy Link

@VoVAllen commented on GitHub (Dec 22, 2023):

One possibility might be pg14's minor version? The image of pgvecto.rs is built on a different minor version than pervious one? Thus some incompatibility might be introduced here. However minor version update should not affect index, just a guess

@VoVAllen commented on GitHub (Dec 22, 2023): One possibility might be pg14's minor version? The image of pgvecto.rs is built on a different minor version than pervious one? Thus some incompatibility might be introduced here. However minor version update should not affect index, just a guess
OVERLORD commented 2026-02-05 04:14:39 +03:00
Author
Owner
Copy Link

@VoVAllen commented on GitHub (Dec 22, 2023):

https://www.migops.com/blog/important-postgresql-14-update-to-avoid-silent-corruption-of-indexes/
@zackpollard @bo0tzz Found some pg14 blogs saying that btree might be silently corrupted in early version

@VoVAllen commented on GitHub (Dec 22, 2023): https://www.migops.com/blog/important-postgresql-14-update-to-avoid-silent-corruption-of-indexes/ @zackpollard @bo0tzz Found some pg14 blogs saying that btree might be silently corrupted in early version
OVERLORD commented 2026-02-05 04:14:43 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Dec 23, 2023):

https://www.migops.com/blog/important-postgresql-14-update-to-avoid-silent-corruption-of-indexes/ @zackpollard @bo0tzz Found some pg14 blogs saying that btree might be silently corrupted in early version

Thanks for looking into it, however I don't believe we have previously had Immich on 14.4, if we have it hasn't been for a long time. The version most people should be upgrading from would've been 14.8 we believe.

@zackpollard commented on GitHub (Dec 23, 2023): > https://www.migops.com/blog/important-postgresql-14-update-to-avoid-silent-corruption-of-indexes/ @zackpollard @bo0tzz Found some pg14 blogs saying that btree might be silently corrupted in early version Thanks for looking into it, however I don't believe we have previously had Immich on 14.4, if we have it hasn't been for a long time. The version most people should be upgrading from would've been 14.8 we believe.
OVERLORD commented 2026-02-05 04:14:46 +03:00
Author
Owner
Copy Link

@TwoD commented on GitHub (Dec 23, 2023):

Thanks, that did work for me, but the command was REINDEX TABLE users.

@TwoD commented on GitHub (Dec 23, 2023): Thanks, that did work for me, but the command was `REINDEX TABLE users`.
OVERLORD commented 2026-02-05 04:14:47 +03:00
Author
Owner
Copy Link

@bengelnatz commented on GitHub (Dec 23, 2023):

without reading everything: I fixed this issue for me by setting a new email for my user directly in the DB. My old username had an underscore ('_') in it address but not sure if that was the cause

@bengelnatz commented on GitHub (Dec 23, 2023): without reading everything: I fixed this issue for me by setting a new email for my user directly in the DB. My old username had an underscore ('_') in it address but not sure if that was the cause
OVERLORD commented 2026-02-05 04:14:51 +03:00
Author
Owner
Copy Link

@mertalev commented on GitHub (Dec 24, 2023):

This seems very relevant. I think the default collation in the old and new docker image may be different. The old image is Alpine-based and uses musl, while the new image is Debian-based and uses glibc. A change in collation can silently corrupt B-tree indices.

@mertalev commented on GitHub (Dec 24, 2023): [This](https://www.citusdata.com/blog/2020/12/12/dont-let-collation-versions-corrupt-your-postgresql-indexes/) seems very relevant. I think the default collation in the old and new docker image may be different. The old image is Alpine-based and uses musl, while the new image is Debian-based and uses glibc. A change in collation can silently corrupt B-tree indices.
OVERLORD commented 2026-02-05 04:14:53 +03:00
Author
Owner
Copy Link

@VoVAllen commented on GitHub (Dec 24, 2023):

@mertalev The breaking change in glibc 2.28 mentioned in this slide might be the cause.

image

@VoVAllen commented on GitHub (Dec 24, 2023): @mertalev The breaking change in glibc 2.28 mentioned in this [slide](https://www.postgresql.eu/events/pgconfeu2022/sessions/session/4040/slides/337/Collations%20in%20PostgreSQL%20-%20The%20good,%20the%20bad%20and%20the%20ugly%20-%20Tobias%20Bussmann.pdf) might be the cause. ![image](https://github.com/immich-app/immich/assets/8686776/66a0536f-36b5-437c-8492-e3ec4f9cbd9b)
OVERLORD commented 2026-02-05 04:14:59 +03:00
Author
Owner
Copy Link

@ausshir commented on GitHub (Dec 24, 2023):

Unless I was doing something wrong, running REINDEX TABLE users and even deleting pgdata/pg_vectors/* did not resolve the issue for me.

Luckily I was still authed in another session and could change the 'email' of the admin account. That allowed me to log in again.

@ausshir commented on GitHub (Dec 24, 2023): Unless I was doing something wrong, running `REINDEX TABLE users` and even deleting `pgdata/pg_vectors/*` did not resolve the issue for me. Luckily I was still authed in another session and could change the 'email' of the admin account. That allowed me to log in again.
OVERLORD commented 2026-02-05 04:15:01 +03:00
Author
Owner
Copy Link

@mertalev commented on GitHub (Dec 25, 2023):

@mertalev The breaking change in glibc 2.28 mentioned in this slide might be the cause.

image

That seems likely. I think it'd be good to set the collation ourselves to make sure it's consistent.

@mertalev commented on GitHub (Dec 25, 2023): > @mertalev The breaking change in glibc 2.28 mentioned in this [slide](https://www.postgresql.eu/events/pgconfeu2022/sessions/session/4040/slides/337/Collations%20in%20PostgreSQL%20-%20The%20good,%20the%20bad%20and%20the%20ugly%20-%20Tobias%20Bussmann.pdf) might be the cause. > > > > ![image](https://github.com/immich-app/immich/assets/8686776/66a0536f-36b5-437c-8492-e3ec4f9cbd9b) > > That seems likely. I think it'd be good to set the collation ourselves to make sure it's consistent.
OVERLORD commented 2026-02-05 04:15:07 +03:00
Author
Owner
Copy Link

@Igor01-Tech commented on GitHub (Jan 2, 2024):

eidt: not relevant anymore. See my post below.

After some back and forth with Zack, the index is corrupted. After running psql REINDEX users, all works again.

I identified this by doing some EXPLAIN ANALYZE on the queries for a user with a working and non-working user. It shows that the non-working users were not contained in the index on the email field.

Can you explain how to reindex users step by step? Tried to lo into running postgres container and doing

root@9fbc397237eb:/# REINDEX users
bash: REINDEX: command not found
root@9fbc397237eb:/# postgres REINDEX users
"root" execution of the PostgreSQL server is not permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromise. See the documentation for
more information on how to properly start the server.

How can I reindex the users? I cant login with any of my two accounts anymore..

@Igor01-Tech commented on GitHub (Jan 2, 2024): eidt: not relevant anymore. See my post below. > After some back and forth with Zack, the index is corrupted. After running psql `REINDEX users`, all works again. > > I identified this by doing some `EXPLAIN ANALYZE` on the queries for a user with a working and non-working user. It shows that the non-working users were not contained in the index on the email field. Can you explain how to reindex users step by step? Tried to lo into running postgres container and doing root@9fbc397237eb:/# REINDEX users bash: REINDEX: command not found root@9fbc397237eb:/# postgres REINDEX users "root" execution of the PostgreSQL server is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromise. See the documentation for more information on how to properly start the server. How can I reindex the users? I cant login with any of my two accounts anymore..
OVERLORD commented 2026-02-05 04:15:13 +03:00
Author
Owner
Copy Link

@Igor01-Tech commented on GitHub (Jan 2, 2024):

Unless I was doing something wrong, running REINDEX TABLE users and even deleting pgdata/pg_vectors/* did not resolve the issue for me.

Luckily I was still authed in another session and could change the 'email' of the admin account. That allowed me to log in again.

Wow, that did the trick for all my users (1 admin, 1 user) Thanks!

@Igor01-Tech commented on GitHub (Jan 2, 2024): > Unless I was doing something wrong, running `REINDEX TABLE users` and even deleting `pgdata/pg_vectors/*` did not resolve the issue for me. > > Luckily I was still authed in another session and could change the 'email' of the admin account. That allowed me to log in again. Wow, that did the trick for all my users (1 admin, 1 user) Thanks!
OVERLORD commented 2026-02-05 04:15:15 +03:00
Author
Owner
Copy Link

@JoePassanante commented on GitHub (Jan 3, 2024):

For folks looking for a quick command, this fixed the issue for me on my Rasp Pi 4s.

Docker:
docker exec -it immich_postgres psql -U postgres -d immich -c "REINDEX TABLE users;"

Specifically
docker exec -it immich_postgres psql -U <postgres user name used in .env>-d <postgres database for immich> -c "REINDEX TABLE users;"

@JoePassanante commented on GitHub (Jan 3, 2024): For folks looking for a quick command, this fixed the issue for me on my Rasp Pi 4s. Docker: `docker exec -it immich_postgres psql -U postgres -d immich -c "REINDEX TABLE users;"` Specifically `docker exec -it immich_postgres psql -U <postgres user name used in .env>-d <postgres database for immich> -c "REINDEX TABLE users;"`
OVERLORD commented 2026-02-05 04:15:18 +03:00
Author
Owner
Copy Link

@raudette commented on GitHub (Jan 20, 2024):

If it helps at all, this issue impacted 2/2 users for me, and REINDEX TABLE USERS; on the DB solved the issue.

@raudette commented on GitHub (Jan 20, 2024): If it helps at all, this issue impacted 2/2 users for me, and REINDEX TABLE USERS; on the DB solved the issue.
OVERLORD commented 2026-02-05 04:15:22 +03:00
Author
Owner
Copy Link

@psilantropy commented on GitHub (Feb 22, 2024):

Completed a 1.93.3 to 1.95.1 update and only admin user locked out.
Command above didn't fix, but I may have jumped the gun;
immich-admin reset-admin-password resolved it

@psilantropy commented on GitHub (Feb 22, 2024): Completed a 1.93.3 to 1.95.1 update and only admin user locked out. Command above didn't fix, but I may have jumped the gun; `immich-admin reset-admin-password` resolved it
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1860
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?