[BUG] Scheduled user removal not working on immich server #1919

Closed
opened 2026-02-05 04:26:30 +03:00 by OVERLORD · 7 comments
Owner

Originally created by @arpanghosh8453 on GitHub (Jan 1, 2024).

Originally assigned to: @jrasm91 on GitHub.

The bug

Hi Alex, thank you again for this fantastic app. It works like a charm. ALWAYS!

I thought I should notify you of one small issue, maybe a duplicate of #1616

I have removed one of my users, and it was scheduled for removal after seven days. I waited seven days to discover that the user was still with his assets. So, the scheduled removal job may have failed to run. So, I restored the user and removed him again. After seven more days, the user is still there, showing scheduled removal on an already past date.

I would like to see an option for the forced immediate removal of a user bypassing the scheduled job option. This can be CLI only if that makes it easier.

image

The OS that Immich Server is running on

Debian 12

Version of Immich Server

V1.91.4 (Latest)

Version of Immich Mobile App

Latest

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

version: "3.8"

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
      - /media/archive-read-only:/mnt/media/Pictures:ro
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    #ports:
    #  - 2283:3001
    depends_on:
      - redis
      - database
    restart: unless-stopped
    networks:
      proxy-network:

  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
      - /media/archaive-read-only:/mnt/media/Pictures:ro
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: unless-stopped
    networks:
      proxy-network:

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

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:60e49e22fa5706cd8df7d5e0bc50ee9bab7c608039fa653c4d961014237cca46
    restart: unless-stopped
    networks:
      proxy-network:

  database:
    container_name: immich_postgres
    #image: postgres:14-alpine@sha256:6a0e35296341e676fe6bd8d236c72afffe2dfe3d7eb9c2405c0f3fc04500cd07
    image: tensorchord/pgvecto-rs:pg14-v0.1.11
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopped
    networks:
      proxy-network:

volumes:
  pgdata:
  model-cache:

networks:
  proxy-network:
    external: true
    name: proxy-network

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=/media/immich-sync

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=v1.91.4
TZ=America/Toronto
LOG_LEVEL=log
# Connection secrets for postgres and typesense. You should change these to random passwords
TYPESENSE_API_KEY=[REDACTED]
DB_PASSWORD=[REDACTED]

# 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. Add a new user, upload some assets
2. Remove the user from the Administrative panel
3. Wait for seven days
4. Check if the user is actually removed on the scheduled removal date.
( You can see in the screenshot it's showing a past date as the scheduled removal date )

Additional information

I would prefer at least a CLI option to remove a user immediately from the users' section, overriding the scheduled removal ( which is failing in my case )

Originally created by @arpanghosh8453 on GitHub (Jan 1, 2024). Originally assigned to: @jrasm91 on GitHub. ### The bug Hi Alex, thank you again for this fantastic app. It works like a charm. ALWAYS! I thought I should notify you of one small issue, maybe a duplicate of #1616 I have removed one of my users, and it was scheduled for removal after seven days. I waited seven days to discover that the user was still with his assets. So, the scheduled removal job may have failed to run. So, I restored the user and removed him again. After seven more days, the user is still there, showing scheduled removal on an already past date. I would like to see an option for the forced immediate removal of a user bypassing the scheduled job option. This can be CLI only if that makes it easier. ![image](https://github.com/immich-app/immich/assets/26424944/39c19ca8-144a-4057-8633-a1401b489fcb) ### The OS that Immich Server is running on Debian 12 ### Version of Immich Server V1.91.4 (Latest) ### Version of Immich Mobile App Latest ### Platform with the issue - [X] Server - [x] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML version: "3.8" 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 - /media/archive-read-only:/mnt/media/Pictures:ro - /etc/localtime:/etc/localtime:ro env_file: - .env #ports: # - 2283:3001 depends_on: - redis - database restart: unless-stopped networks: proxy-network: 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 - /media/archaive-read-only:/mnt/media/Pictures:ro - /etc/localtime:/etc/localtime:ro env_file: - .env depends_on: - redis - database restart: unless-stopped networks: proxy-network: immich-machine-learning: container_name: immich_machine_learning image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release} volumes: - model-cache:/cache env_file: - .env restart: unless-stopped networks: proxy-network: redis: container_name: immich_redis image: redis:6.2-alpine@sha256:60e49e22fa5706cd8df7d5e0bc50ee9bab7c608039fa653c4d961014237cca46 restart: unless-stopped networks: proxy-network: database: container_name: immich_postgres #image: postgres:14-alpine@sha256:6a0e35296341e676fe6bd8d236c72afffe2dfe3d7eb9c2405c0f3fc04500cd07 image: tensorchord/pgvecto-rs:pg14-v0.1.11 env_file: - .env environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} volumes: - pgdata:/var/lib/postgresql/data restart: unless-stopped networks: proxy-network: volumes: pgdata: model-cache: networks: proxy-network: external: true name: proxy-network ``` ### 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=/media/immich-sync # The Immich version to use. You can pin this to a specific version like "v1.71.0" IMMICH_VERSION=v1.91.4 TZ=America/Toronto LOG_LEVEL=log # Connection secrets for postgres and typesense. You should change these to random passwords TYPESENSE_API_KEY=[REDACTED] DB_PASSWORD=[REDACTED] # 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. Add a new user, upload some assets 2. Remove the user from the Administrative panel 3. Wait for seven days 4. Check if the user is actually removed on the scheduled removal date. ( You can see in the screenshot it's showing a past date as the scheduled removal date ) ``` ### Additional information I would prefer at least a CLI option to remove a user immediately from the users' section, overriding the scheduled removal ( which is failing in my case )
Author
Owner

@etnoy commented on GitHub (Jan 4, 2024):

Interesting. Are there any error messages in the log saying why deletion failed?

I agree we should have a way to force immediate removal of the user, but I'd argue we should be able to do that in the web interface.

@etnoy commented on GitHub (Jan 4, 2024): Interesting. Are there any error messages in the log saying why deletion failed? I agree we should have a way to force immediate removal of the user, but I'd argue we should be able to do that in the web interface.
Author
Owner

@arpanghosh8453 commented on GitHub (Jan 4, 2024):

@etnoy No, I did not find any error. If I ask for a user list using the command line, the entry is not there ( it's showing me as the only user ). But on the interface, it appears like that ready to restore ( and in fact, it can be restored ). I am fine with both CLI or web interface way, but will be happy to see that feature in any form. Thank you for making a note of this.

@arpanghosh8453 commented on GitHub (Jan 4, 2024): @etnoy No, I did not find any error. If I ask for a user list using the command line, the entry is not there ( it's showing me as the only user ). But on the interface, it appears like that ready to restore ( and in fact, it can be restored ). I am fine with both CLI or web interface way, but will be happy to see that feature in any form. Thank you for making a note of this.
Author
Owner

@arpanghosh8453 commented on GitHub (Jan 8, 2024):

I checked back today, and it was gone. Not sure what happened earlier.

@arpanghosh8453 commented on GitHub (Jan 8, 2024): I checked back today, and it was gone. Not sure what happened earlier.
Author
Owner

@PovilasID commented on GitHub (Jan 17, 2024):

I have the same issue I tried to remove the user and it was scheduled for December 27th... nothing happened so about a week ago I said to "restore" the user that was supposed to be deleted and now it was supposed get deleted on the 15th... still here.
Is there a command line way of doing this because I have already imported google takeout and wiping the server and reestablishing both users would take a long time.

@PovilasID commented on GitHub (Jan 17, 2024): I have the same issue I tried to remove the user and it was scheduled for December 27th... nothing happened so about a week ago I said to "restore" the user that was supposed to be deleted and now it was supposed get deleted on the 15th... still here. Is there a command line way of doing this because I have already imported google takeout and wiping the server and reestablishing both users would take a long time.
Author
Owner

@salvisbh commented on GitHub (Mar 3, 2024):

The same issue here. When trying to log in again via oidc, the user marked for deletion prevents the user from being created again with the idp's data.

@salvisbh commented on GitHub (Mar 3, 2024): The same issue here. When trying to log in again via oidc, the user marked for deletion prevents the user from being created again with the idp's data.
Author
Owner

@jrasm91 commented on GitHub (Mar 22, 2024):

The same issue here. When trying to log in again via oidc, the user marked for deletion prevents the user from being created again with the idp's data.

This seems unrelated and not actually a bug but working as designed.

@jrasm91 commented on GitHub (Mar 22, 2024): > The same issue here. When trying to log in again via oidc, the user marked for deletion prevents the user from being created again with the idp's data. This seems unrelated and not actually a bug but working as designed.
Author
Owner

@jrasm91 commented on GitHub (Mar 22, 2024):

Implemented in #7681 and #7663.

@jrasm91 commented on GitHub (Mar 22, 2024): Implemented in #7681 and #7663.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1919