Application icons disappear after a few weeks

[svenlameir]

Describe the bug Application icons disappear after a few weeks. they still function when clicking on them

To Reproduce Normal use of authentik

Expected behavior Icons should remain visible

Screenshots

Version and Deployment (please complete the following information):

• authentik version: 2024.6.0
• Deployment: docker-compose

Additional context This has happened a few times this year even on previous versions

[Terrorwolf01]

Hi, Could it be that you use Portainer to manage your Authentik?

[svenlameir]

Hi, Could it be that you use Portainer to manage your Authentik?

Correct

[Terrorwolf01]

Could you share your stack config? (Please obfuscate passwords and such)

[svenlameir]

version: "3.4"

services:
  redis:
    deploy:
      replicas: 1
    image: docker.io/library/redis:alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - redis:/data
    logging:
      driver: "gelf"
      options:
        gelf-address: $GRAYLOG_ADDRESS
        tag: $GRAYLOG_TAG
  server:
    deploy:
      replicas: 1
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-}$AUTHENTIK_VERSION
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: $PG_ENDPOINT
      AUTHENTIK_POSTGRESQL__USER: $PG_USER
      AUTHENTIK_POSTGRESQL__NAME: $PG_NAME
      AUTHENTIK_POSTGRESQL__PASSWORD: $PG_PASS
      AUTHENTIK_SECRET_KEY: $AUTHENTIK_SECRET_KEY
      AUTHENTIK_ERROR_REPORTING__ENABLED: $ERROR_REPORTING__ENABLED
      AUTHENTIK_EMAIL__HOST: $EMAIL_HOST
      AUTHENTIK_EMAIL__PORT: $EMAIL_PORT
      AUTHENTIK_EMAIL__USERNAME: $EMAIL_USERNAME
      AUTHENTIK_EMAIL__PASSWORD: $EMAIL_PASSWORD
      AUTHENTIK_EMAIL__USE_TLS: $EMAIL_USE_TLS
      AUTHENTIK_EMAIL__USE_SSL: $EMAIL_USE_SSL
      AUTHENTIK_EMAIL__TIMEOUT: $EMAIL_TIMEOUT
      AUTHENTIK_EMAIL__FROM: $EMAIL_FROM
    volumes:
      - media:/media
      - custom-templates:/templates
    ports:
      - "${COMPOSE_PORT_HTTP:-9000}:9000"
      - "${COMPOSE_PORT_HTTPS:-9443}:9443"
    depends_on:

      - redis
    logging:
      driver: "gelf"
      options:
        gelf-address: $GRAYLOG_ADDRESS
        tag: $GRAYLOG_TAG
  worker:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-}$AUTHENTIK_VERSION
    deploy:
      replicas: 1
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: $PG_ENDPOINT
      AUTHENTIK_POSTGRESQL__USER: $PG_USER
      AUTHENTIK_POSTGRESQL__NAME: $PG_NAME
      AUTHENTIK_POSTGRESQL__PASSWORD: $PG_PASS
      AUTHENTIK_SECRET_KEY: $AUTHENTIK_SECRET_KEY
      AUTHENTIK_EMAIL__HOST: $EMAIL_HOST
      AUTHENTIK_EMAIL__PORT: $EMAIL_PORT
      AUTHENTIK_EMAIL__USERNAME: $EMAIL_USERNAME
      AUTHENTIK_EMAIL__PASSWORD: $EMAIL_PASSWORD
      AUTHENTIK_EMAIL__USE_TLS: $EMAIL_USE_TLS
      AUTHENTIK_EMAIL__USE_SSL: $EMAIL_USE_SSL
      AUTHENTIK_EMAIL__TIMEOUT: $EMAIL_TIMEOUT
      AUTHENTIK_EMAIL__FROM: $EMAIL_FROM
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - media:/media
      - certs:/certs
      - custom-templates:/templates
    depends_on:
      - redis
    logging:
      driver: "gelf"
      options:
        gelf-address: $GRAYLOG_ADDRESS
        tag: $GRAYLOG_TAG

volumes:
  database:
    driver: local
  redis:
    driver: local
  media:
    driver: local
  certs:
    driver: local
  custom-templates:
    driver: local

[Terrorwolf01]

Could you try to map the media volume to a static path? For example my media directory is mapped to /data/authentik/media.

[natoleet]

I was also hit with this bug. Haven't had a chance to look into the cause yet, I'm assuming the location in which Authentik uploads application images is not persistent?

[Terrorwolf01]

That was exactly the case at my server. As soon as I specified a fixed location in the Portainer stack, it works since then. In my case it was the Problem how Portainer works with Stacks.