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

could not open database file: open /db/vikunja.db: permission denied #496

New Issue
Closed
opened 2025-11-01 20:57:07 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2025-11-01 20:57:07 -05:00
Owner
Copy Link

Originally created by @axelsimon on GitHub (Apr 25, 2025).

Description

Hello,
Trying to run vikunja with podman run -p 3456:3456 -v $PWD/containers/volumes/vikunja/files:/app/vikunja/files -v $PWD/containers/volumes/vikunja/db/:/db vikunja/vikunja I get the following error:

Could not connect to db: could not open database file [uid=1000, gid=0]: open /db/vikunja.db: permission denied

This is on Fedora Silverblue 42 (same on 41).

Running with the :z option on the volume mount (to enable SELinux relabelling) makes no difference,
Lastly, the directories exist and have the right permissions:

ls -lAhnZ ~/containers/volumes/vikunja/
total 0
drwxr-xr-x. 1 1000 1000 system_u:object_r:container_file_t:s0 0 Apr 24 14:41 db
drwxr-xr-x. 1 1000 1000 system_u:object_r:container_file_t:s0 0 Apr 24 14:24 files

podman image ls tells me the container image version is docker.io/vikunja/vikunja latest cec159e222f5 4 months ago which docker hub helpfully tells me is vikunja/vikunja:0.24.6

Vikunja Version

0.24.6

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @axelsimon on GitHub (Apr 25, 2025). ### Description Hello, Trying to run vikunja with `podman run -p 3456:3456 -v $PWD/containers/volumes/vikunja/files:/app/vikunja/files -v $PWD/containers/volumes/vikunja/db/:/db vikunja/vikunja` I get the following error: ``` Could not connect to db: could not open database file [uid=1000, gid=0]: open /db/vikunja.db: permission denied ``` This is on Fedora Silverblue 42 (same on 41). Running with the `:z` option on the volume mount (to enable SELinux relabelling) makes no difference, Lastly, the directories exist and have the right permissions: ``` ls -lAhnZ ~/containers/volumes/vikunja/ total 0 drwxr-xr-x. 1 1000 1000 system_u:object_r:container_file_t:s0 0 Apr 24 14:41 db drwxr-xr-x. 1 1000 1000 system_u:object_r:container_file_t:s0 0 Apr 24 14:24 files ``` `podman image ls` tells me the container image version is `docker.io/vikunja/vikunja latest cec159e222f5 4 months ago` which docker hub helpfully tells me is vikunja/vikunja:0.24.6 ### Vikunja Version 0.24.6 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2025-11-01 20:57:08 -05:00
Author
Owner
Copy Link

@foegra commented on GitHub (Apr 28, 2025):

Didn't you forget?

chown 1000 $PWD/files $PWD/db

https://vikunja.io/docs/installing/#docker

Not sure whether this apply to podman though

@foegra commented on GitHub (Apr 28, 2025): Didn't you forget? `chown 1000 $PWD/files $PWD/db` https://vikunja.io/docs/installing/#docker Not sure whether this apply to podman though
GiteaMirror commented 2025-11-01 20:57:09 -05:00
Author
Owner
Copy Link

@axelsimon commented on GitHub (Apr 28, 2025):

Hi @foegra, as you can see from the ls command i shared, the files and db directory are both owned by uid 1000.

@axelsimon commented on GitHub (Apr 28, 2025): Hi @foegra, as you can see from the `ls` command i shared, the `files` and `db` directory are both owned by uid 1000.
GiteaMirror commented 2025-11-01 20:57:09 -05:00
Author
Owner
Copy Link

@axelsimon commented on GitHub (Apr 28, 2025):

Found the issue: user id mapping.
User 1000 on my host maps to 0 (root) in the container.
So one needs to do either of two things.

  1. chown the vikunja container files to the subuid that corresponds to user 1000 inside the container (in my case, 524288+999=525287, following the map in /etc/subuid of user:524288:65536). Or,
  2. Tell podman to remap as it runs. Given that my user ID is already 1000, the one Vikunja wants to run under inside the container, one can simply use: podman run --userns=keep-id
    So the complete command becomes:
    podman run --userns=keep-id -p 3456:3456 -v $PWD/containers/volumes/vikunja/files:/app/vikunja/files -v $PWD/containers/volumes/vikunja/db/:/db vikunja/vikunja
@axelsimon commented on GitHub (Apr 28, 2025): Found the issue: user id mapping. User 1000 on my host maps to 0 (root) in the container. So one needs to do either of two things. 1. `chown` the vikunja container files to the subuid that corresponds to user 1000 _inside_ the container (in my case, 524288+999=525287, following the map in `/etc/subuid` of `user:524288:65536`). Or, 2. Tell podman to remap as it runs. Given that my user ID is already 1000, the one Vikunja wants to run under _inside_ the container, one can simply use: `podman run --userns=keep-id` So the complete command becomes: `podman run --userns=keep-id -p 3456:3456 -v $PWD/containers/volumes/vikunja/files:/app/vikunja/files -v $PWD/containers/volumes/vikunja/db/:/db vikunja/vikunja`
GiteaMirror commented 2025-11-01 20:57:09 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Apr 28, 2025):

Glad you figured it out! Do you want to send a PR to the docs about this?

https://github.com/go-vikunja/website/blob/main/src/content/docs/setup/install.mdoc

@kolaente commented on GitHub (Apr 28, 2025): Glad you figured it out! Do you want to send a PR to the docs about this? https://github.com/go-vikunja/website/blob/main/src/content/docs/setup/install.mdoc
GiteaMirror commented 2025-11-01 20:57:09 -05:00
Author
Owner
Copy Link

@foegra commented on GitHub (Apr 28, 2025):

Hi @foegra, as you can see from the ls command i shared, the files and db directory are both owned by uid 1000.

right, my apologies. Glad You figured it out!

@foegra commented on GitHub (Apr 28, 2025): > Hi [@foegra](https://github.com/foegra), as you can see from the `ls` command i shared, the `files` and `db` directory are both owned by uid 1000. right, my apologies. Glad You figured it out!
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#496
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?