github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-21 18:53:07 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

Docker - use user: xxxx:xxxx in compose does not work #1923

New Issue
Closed
opened 2026-03-22 13:46:29 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-03-22 13:46:29 -05:00
Owner
Copy Link

Originally created by @O491dogan on GitHub (Feb 28, 2024).

Description

Deploying the docker container with the provided examples works well.

But I would like to have vikunja run not as user "1000". Here the documentation (https://vikunja.io/docs/full-docker-example/) states, that one should use the --user-flag to accomplish this.

If I do so, vikunja won't start with the following messages:
info: creating the new user vikunja with 1000:1000
groupmod /etc/group.8: Permission denied
groupmod: cannot lock /etc/group; try again later.

On my docker host machine, I have some directories, that are owned by the user 1001 that are mapped to the container (please see the following compose - for testing purposes):

version: "3"
services:
  vikunja:
    image: vikunja/vikunja
    environment:
      VIKUNJA_SERVICE_PUBLICURL: http://192.168.178.59
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: vikunjapw
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: vikunjapwsecret
    ports:
      - 3456:3456
    volumes:
      - /home/dockerApps/vikunja/files:/app/vikunja/files
    user: 1001:1001
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
  db:
    image: mariadb:10
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    environment:
      MYSQL_ROOT_PASSWORD: vikunjadbroot
      MYSQL_USER: vikunja
      MYSQL_PASSWORD: vikunjapw
      MYSQL_DATABASE: vikunja
    volumes:
      - /home/dockerApps/vikunja/database:/var/lib/mysql
    user: 1001:1001
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -u $$MYSQL_USER --password=$$MYSQL_PASSWORD"]
      interval: 2s
      start_period: 30s

What I see happening on the host is, that the directory /home/dockerApps/vikunja/files/, previously owned by 1001:1001 is owned by 1000:1000 after the start of the container.

It seems like the user: 1001:1001 statement is ignored and vikunja tries to run as the default 1000.

Does anyone ever have this issue, too and can provide some help or solution?

Thank you very much!

Vikunja Version

sha256:25544141064373ce2f1c56aa88a77b5346651e2d0708f8c0cda6fc54c1893f53

Browser and version

not relevant

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

Not necessary.

Originally created by @O491dogan on GitHub (Feb 28, 2024). ### Description Deploying the docker container with the provided examples works well. But I would like to have vikunja run not as user "1000". Here the documentation (https://vikunja.io/docs/full-docker-example/) states, that one should use the **--user**-flag to accomplish this. If I do so, vikunja won't start with the following messages: `info: creating the new user vikunja with 1000:1000` `groupmod /etc/group.8: Permission denied` `groupmod: cannot lock /etc/group; try again later.` On my docker host machine, I have some directories, that are owned by the user 1001 that are mapped to the container (please see the following compose - for testing purposes): ``` version: "3" services: vikunja: image: vikunja/vikunja environment: VIKUNJA_SERVICE_PUBLICURL: http://192.168.178.59 VIKUNJA_DATABASE_HOST: db VIKUNJA_DATABASE_PASSWORD: vikunjapw VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: vikunja VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_JWTSECRET: vikunjapwsecret ports: - 3456:3456 volumes: - /home/dockerApps/vikunja/files:/app/vikunja/files user: 1001:1001 depends_on: db: condition: service_healthy restart: unless-stopped db: image: mariadb:10 command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: vikunjadbroot MYSQL_USER: vikunja MYSQL_PASSWORD: vikunjapw MYSQL_DATABASE: vikunja volumes: - /home/dockerApps/vikunja/database:/var/lib/mysql user: 1001:1001 restart: unless-stopped healthcheck: test: ["CMD-SHELL", "mysqladmin ping -h localhost -u $$MYSQL_USER --password=$$MYSQL_PASSWORD"] interval: 2s start_period: 30s ``` What I see happening on the host is, that the directory **/home/dockerApps/vikunja/files/**, previously owned by 1001:1001 is owned by 1000:1000 after the start of the container. It seems like the **user: 1001:1001** statement is ignored and vikunja tries to run as the default 1000. Does anyone ever have this issue, too and can provide some help or solution? Thank you very much! ### Vikunja Version sha256:25544141064373ce2f1c56aa88a77b5346651e2d0708f8c0cda6fc54c1893f53 ### Browser and version not relevant ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots Not necessary.
GiteaMirror commented 2026-03-22 13:46:29 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 28, 2024):

This has been changed lately but not yet released as a stable version. Does it work with an unstable build? (add the :unstable tag to the docker image).

@kolaente commented on GitHub (Feb 28, 2024): This has been changed lately but not yet released as a stable version. Does it work with an unstable build? (add the `:unstable` tag to the docker image).
GiteaMirror commented 2026-03-22 13:46:30 -05:00
Author
Owner
Copy Link

@O491dogan commented on GitHub (Feb 28, 2024):

Hi there!
Thank you for taking the time for a response.

I have tried the current :unstable build and what should I say: It works as expected!

Thank you again - I'm looking forward to the next stable version :-)

@O491dogan commented on GitHub (Feb 28, 2024): Hi there! Thank you for taking the time for a response. I have tried the current `:unstable` build and what should I say: **It works as expected!** Thank you again - I'm looking forward to the next stable version :-)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#1923
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?