Deleting of a (single) External Library does nothing

[Shurov]

trafficstars

The bug

I have a single External Library configured, which I tried to delete via ... -> Delete libray. But nothing happens - I still can see the entry in the list. Page refresh (including force/hard refresh of browser cache) doesn't help either.

Some background: I misconfigured my external library in a way - that the root path contains /immich/ folder with Thumbs. So that thumb generation goes in a loop. So I stopped the container, split the folders, updated volume mapping docker-compose.yml, started the container, cleared offline images (which didn't help much), manually removed /immich/thumbs/ folder and decided to recreate External Library.

The OS that Immich Server is running on

Unraid 6.12.10

Version of Immich Server

v1.106.4

Version of Immich Mobile App

v1.106.3

Platform with the issue

• [X] Server
• [X] Web
• [ ] Mobile

Your docker-compose.yml content

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /mnt/user/photos/visuals:/mnt/media/photos:ro
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/dri:/dev/dri
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always

  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: always

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:d6c2911ac51b289db208767581a5d154544f2b2fe4914ea5056443f62dc6e900
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
	  POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: pg_isready --dbname='${DB_DATABASE_NAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo ">
    command: ["postgres", "-c" ,"shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", "-c", "wal_compression=on"]
    restart: always

volumes:
  model-cache:

Your .env content

UPLOAD_LOCATION=/mnt/user/photos/immich/
DB_DATA_LOCATION=./postgres
TZ=Etc/<xxx>
IMMICH_VERSION=release
DB_PASSWORD=immich
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

Possible short route:
1. Create a single External Library
2. Let it generate thumbs
3. Try to Delete library
4. Nothing happens - the entry is still visible on the UI.

My real route:
1. Create a single External Library
2. Let it generate thumbs
3. Remove Offline Files (and wait till job ends)
4. Remove .../immich/thumbs/ folder (possibly it was done when containers were down - can't recall)
5. Try to Delete library
6. Nothing happens - the entry is still visible on the UI.

Relevant log output

No response

Additional information

No response

[Southpaw1496]

I also had this issue, and I was able to work around it by using the API. I used an http client called Paw (also known as RapidAPI for Mac), but you could also accomplish it using cURL. The abstract steps are as follows:

1. Obtain an API Key
2. GET /api/libraries to find the ID of the library you want to delete (use the header x-api-key: <KEY> to authenticate)
3. DELETE /api/libraries/<id> (where <id> is the ID of the library you want to delete).

Once you have your API key, I think this would be the way to do it in cURL (but I haven't tested it).

1. export IMMICH_API_KEY=<API KEY>
2. curl "<YOUR IMMICH IP/DOMAIN>/api/libraries" -H "x-api-key: $IMMICH_API_KEY"
3. Find the id of the library that has the name you want in the JSON you get back.
4. curl -X "DELETE" "<IMMICH IP/DOMAIN>/api/libraries/<LIBRARY ID>" -H "x-api-key: $IMMICH_API_KEY"

[Shurov]

I was able to work around it by using the API

Thanks for the workaround! Your detailed instructions helped me as well - first set (with 3 steps) worked perfectly via Postman.

Still would keep this ticket open for the bug fix with non-working deletion from UI.

[alextran1502]

This issue has been fixed and will be available in the next release

[Shurov]

This issue has been fixed and will be available in the next release

Thanks for this! I'm thinking, as an additional idiot-proof (like me) protection - thinking of the root cause, if the main photo dir included everything: photo sources themselves as well as Immich technical folder (with uploads) that caused a circle reference.... Maybe it's possible somehow to check this in a dir structure (compare dir pathes) and exclude immich folder with thumbs from the search/fetch/etc?

[danieldietzler]

@Shurov can you verify that it's fixed now? :)

[jrasm91]

I could not reproduce this. Let me know if this is still an issue or not.

[porjo]

I'm using server v1.107.1 and just hit this issue using web UI. Deleting via API worked for me.

[jrasm91]

I'm using server v1.107.1 and just hit this issue using web UI. Deleting via API worked for me.

It will be fixed in the next release