[Bug]: Logging doesn't work #882

New Issue

OVERLORD · 2026-02-04T21:32:40+03:00

OVERLORD commented

2026-02-04 21:32:40 +03:00

Originally created by @k7deubo4 on GitHub (Dec 15, 2025).

Where is the problem occurring?

I encountered the problem while interacting with the server (Backend)

What browsers are you seeing the problem on?

Chrome, Firefox, Brave, Microsoft Edge

Current behavior

I followed the all necessary steps described here https://docs.planka.cloud/docs/configuration/logging/
to enable Logging on my Planka enviroment, but without success.

When running docker compose logs 'container_name' I got again no logs.

Here is my docker-compose.yaml file:

services:
planka:
image: ghcr.io/plankanban/planka:2.0.0-rc.4
restart: on-failure
volumes:
- favicons:/app/public/favicons
- user-avatars:/app/public/user-avatars
- background-images:/app/public/background-images
- attachments:/app/private/attachments
- ./logs/:/app/logs/
# Optionally override this to your user/group
# user: 1000:1000
# tmpfs:
# - /app/.tmp:mode=770,uid=1000,gid=1000
ports:
- 3000:1337
environment:
# - BASE_URL=******
- BASE_URL=*******
- DATABASE_URL=postgresql://postgres@postgres/planka
# Optionally store the database password in secrets:
# - DATABASE_URL=postgresql://postgres:$${DATABASE_PASSWORD}@postgres/planka
# - DATABASE_PASSWORD__FILE=/run/secrets/database_password
# And add the following to the service:
# secrets:
# - database_password

    - SECRET_KEY=******
  # Optionally store in secrets - then SECRET_KEY should not be set
  # - SECRET_KEY__FILE=/run/secrets/secret_key

  # - LOG_LEVEL=warn

  # - TRUST_PROXY=true
  # - MAX_UPLOAD_FILE_SIZE=
  # - TOKEN_EXPIRES_IN=365 # In days

  # related: https://github.com/knex/knex/issues/2354
  # As knex does not pass query parameters from the connection string,
  # we have to use environment variables in order to pass the desired values, e.g.
  # - PGSSLMODE=<value>

  # Configure knex to accept SSL certificates
  # - KNEX_REJECT_UNAUTHORIZED_SSL_CERTIFICATE=false

  # The default application language used as a fallback when a user's language is not set.
  # This language is also used for per-board notifications.
  # - DEFAULT_LANGUAGE=en-US

  # Do not comment out DEFAULT_ADMIN_EMAIL if you want to prevent this user from being edited/deleted
  # - DEFAULT_ADMIN_EMAIL=demo@demo.demo
  # - DEFAULT_ADMIN_PASSWORD=demo
  # Optionally store in secrets - then DEFAULT_ADMIN_PASSWORD should not be set
  # - DEFAULT_ADMIN_PASSWORD__FILE=/run/secrets/default_admin_password
  # - DEFAULT_ADMIN_NAME=Demo Demo
  # - DEFAULT_ADMIN_USERNAME=demo

  # - INTERNAL_ACCESS_TOKEN=
  # - STORAGE_LIMIT=
  # - ACTIVE_USERS_LIMIT=
  # - CUSTOMER_PANEL_URL=

  # Set to true to show more detailed authentication error messages.
  # It should not be enabled without a rate limiter for security reasons.
  # - SHOW_DETAILED_AUTH_ERRORS=false

  # - S3_ENDPOINT=
  # - S3_REGION=
  # - S3_ACCESS_KEY_ID=
  # - S3_SECRET_ACCESS_KEY=
  # Optionally store in secrets - then S3_SECRET_ACCESS_KEY should not be set
  # - S3_SECRET_ACCESS_KEY__FILE=/run/secrets/s3_secret_access_key
  # - S3_BUCKET=
  # - S3_FORCE_PATH_STYLE=true

  # - OIDC_ISSUER=
  # - OIDC_CLIENT_ID=
  # - OIDC_CLIENT_SECRET=
  # Optionally store in secrets - then OIDC_CLIENT_SECRET should not be set
  # - OIDC_CLIENT_SECRET__FILE=/run/secrets/oidc_client_secret
  # - OIDC_USE_OAUTH_CALLBACK=true
  # - OIDC_ID_TOKEN_SIGNED_RESPONSE_ALG=
  # - OIDC_USERINFO_SIGNED_RESPONSE_ALG=
  # - OIDC_SCOPES=openid email profile
  # - OIDC_RESPONSE_MODE=fragment
  # - OIDC_USE_DEFAULT_RESPONSE_MODE=true
  # - OIDC_ADMIN_ROLES=admin
  # - OIDC_PROJECT_OWNER_ROLES=project_owner
  # - OIDC_BOARD_USER_ROLES=board_user
  # - OIDC_CLAIMS_SOURCE=userinfo
  # - OIDC_EMAIL_ATTRIBUTE=email
  # - OIDC_NAME_ATTRIBUTE=name
  # - OIDC_USERNAME_ATTRIBUTE=preferred_username
  # - OIDC_ROLES_ATTRIBUTE=groups
  # - OIDC_IGNORE_USERNAME=true
  # - OIDC_IGNORE_ROLES=true
  # - OIDC_ENFORCED=true

  # Using Gravatar directly exposes user IPs and hashed emails to a third party (GDPR risk).
  # Use a proxy you control for privacy, or leave commented out or empty to disable.
  # - GRAVATAR_BASE_URL=https://www.gravatar.com/avatar/
depends_on:
  postgres:
    condition: service_healthy

postgres:
image: postgres:16-alpine
restart: on-failure
volumes:
- db-data:/var/lib/postgresql/data
environment:
- POSTGRES_DB=planka
- POSTGRES_HOST_AUTH_METHOD=trust
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
interval: 10s
timeout: 5s
retries: 5

volumes:
logs:
favicons:
user-avatars:
background-images:
attachments:
db-data:

Desired behavior

I would like to see any logs from my system.

Steps to reproduce

I followed the all necessary steps described here https://docs.planka.cloud/docs/configuration/logging/
to enable Logging on my Planka enviroment, but without success.

When running docker compose logs 'container_name' I got again no logs.

I've already change the permissions for writing and tested inside the container too, but without success again.

Other information

No response

Originally created by @k7deubo4 on GitHub (Dec 15, 2025). ### Where is the problem occurring? I encountered the problem while interacting with the server (Backend) ### What browsers are you seeing the problem on? Chrome, Firefox, Brave, Microsoft Edge ### Current behavior I followed the all necessary steps described here https://docs.planka.cloud/docs/configuration/logging/ to enable Logging on my Planka enviroment, but without success. When running docker compose logs 'container_name' I got again no logs. Here is my docker-compose.yaml file: services: planka: image: ghcr.io/plankanban/planka:2.0.0-rc.4 restart: on-failure volumes: - favicons:/app/public/favicons - user-avatars:/app/public/user-avatars - background-images:/app/public/background-images - attachments:/app/private/attachments - ./logs/:/app/logs/ # Optionally override this to your user/group # user: 1000:1000 # tmpfs: # - /app/.tmp:mode=770,uid=1000,gid=1000 ports: - 3000:1337 environment: # - BASE_URL=****** - BASE_URL=******* - DATABASE_URL=postgresql://postgres@postgres/planka # Optionally store the database password in secrets: # - DATABASE_URL=postgresql://postgres:$${DATABASE_PASSWORD}@postgres/planka # - DATABASE_PASSWORD__FILE=/run/secrets/database_password # And add the following to the service: # secrets: # - database_password - SECRET_KEY=****** # Optionally store in secrets - then SECRET_KEY should not be set # - SECRET_KEY__FILE=/run/secrets/secret_key # - LOG_LEVEL=warn # - TRUST_PROXY=true # - MAX_UPLOAD_FILE_SIZE= # - TOKEN_EXPIRES_IN=365 # In days # related: https://github.com/knex/knex/issues/2354 # As knex does not pass query parameters from the connection string, # we have to use environment variables in order to pass the desired values, e.g. # - PGSSLMODE=<value> # Configure knex to accept SSL certificates # - KNEX_REJECT_UNAUTHORIZED_SSL_CERTIFICATE=false # The default application language used as a fallback when a user's language is not set. # This language is also used for per-board notifications. # - DEFAULT_LANGUAGE=en-US # Do not comment out DEFAULT_ADMIN_EMAIL if you want to prevent this user from being edited/deleted # - DEFAULT_ADMIN_EMAIL=demo@demo.demo # - DEFAULT_ADMIN_PASSWORD=demo # Optionally store in secrets - then DEFAULT_ADMIN_PASSWORD should not be set # - DEFAULT_ADMIN_PASSWORD__FILE=/run/secrets/default_admin_password # - DEFAULT_ADMIN_NAME=Demo Demo # - DEFAULT_ADMIN_USERNAME=demo # - INTERNAL_ACCESS_TOKEN= # - STORAGE_LIMIT= # - ACTIVE_USERS_LIMIT= # - CUSTOMER_PANEL_URL= # Set to true to show more detailed authentication error messages. # It should not be enabled without a rate limiter for security reasons. # - SHOW_DETAILED_AUTH_ERRORS=false # - S3_ENDPOINT= # - S3_REGION= # - S3_ACCESS_KEY_ID= # - S3_SECRET_ACCESS_KEY= # Optionally store in secrets - then S3_SECRET_ACCESS_KEY should not be set # - S3_SECRET_ACCESS_KEY__FILE=/run/secrets/s3_secret_access_key # - S3_BUCKET= # - S3_FORCE_PATH_STYLE=true # - OIDC_ISSUER= # - OIDC_CLIENT_ID= # - OIDC_CLIENT_SECRET= # Optionally store in secrets - then OIDC_CLIENT_SECRET should not be set # - OIDC_CLIENT_SECRET__FILE=/run/secrets/oidc_client_secret # - OIDC_USE_OAUTH_CALLBACK=true # - OIDC_ID_TOKEN_SIGNED_RESPONSE_ALG= # - OIDC_USERINFO_SIGNED_RESPONSE_ALG= # - OIDC_SCOPES=openid email profile # - OIDC_RESPONSE_MODE=fragment # - OIDC_USE_DEFAULT_RESPONSE_MODE=true # - OIDC_ADMIN_ROLES=admin # - OIDC_PROJECT_OWNER_ROLES=project_owner # - OIDC_BOARD_USER_ROLES=board_user # - OIDC_CLAIMS_SOURCE=userinfo # - OIDC_EMAIL_ATTRIBUTE=email # - OIDC_NAME_ATTRIBUTE=name # - OIDC_USERNAME_ATTRIBUTE=preferred_username # - OIDC_ROLES_ATTRIBUTE=groups # - OIDC_IGNORE_USERNAME=true # - OIDC_IGNORE_ROLES=true # - OIDC_ENFORCED=true # Using Gravatar directly exposes user IPs and hashed emails to a third party (GDPR risk). # Use a proxy you control for privacy, or leave commented out or empty to disable. # - GRAVATAR_BASE_URL=https://www.gravatar.com/avatar/ depends_on: postgres: condition: service_healthy postgres: image: postgres:16-alpine restart: on-failure volumes: - db-data:/var/lib/postgresql/data environment: - POSTGRES_DB=planka - POSTGRES_HOST_AUTH_METHOD=trust healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d planka"] interval: 10s timeout: 5s retries: 5 volumes: logs: favicons: user-avatars: background-images: attachments: db-data: ### Desired behavior I would like to see any logs from my system. ### Steps to reproduce I followed the all necessary steps described here https://docs.planka.cloud/docs/configuration/logging/ to enable Logging on my Planka enviroment, but without success. When running docker compose logs 'container_name' I got again no logs. I've already change the permissions for writing and tested inside the container too, but without success again. ### Other information _No response_

OVERLORD commented

2026-02-04 21:32:47 +03:00

@vaibhav0320 commented on GitHub (Dec 30, 2025):

I faced similar issue and it's being due to diffrent user id in on host and container. Check the user id of logs directory on system and inside docker and make sure they are same or can do chmod 777 and test ( not recommended though )

@vaibhav0320 commented on GitHub (Dec 30, 2025): I faced similar issue and it's being due to diffrent user id in on host and container. Check the user id of logs directory on system and inside docker and make sure they are same or can do `chmod 777 ` and test ( not recommended though )

OVERLORD commented

2026-02-04 21:32:54 +03:00

@Signum commented on GitHub (Jan 6, 2026):

I found that even without setting up a volume like ./logs/:/app/logs/ even LOG_LEVEL=trace does not change the log output. I would suspect that somehow the ENV variable is not obeyed.

@Signum commented on GitHub (Jan 6, 2026): I found that even without setting up a volume like `./logs/:/app/logs/` even LOG_LEVEL=trace does not change the log output. I would suspect that somehow the ENV variable is not obeyed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#882