Permission error during Bitwarden startup in docker rootless

[WojTecH94]

Steps To Reproduce

1. Install docker in rootless mode (dockerd-rootless-setuptool.sh)
2. Install Bitwarden
3. Start instance using ./bitwarden.sh start

Expected Result

Bitwarden is up and running

Actual Result

Startup fails with the message:

bitwarden.sh version 1.45.2
Docker version 20.10.12, build e91ed57
Docker Compose version v2.2.3

./bitwarden.sh: line 118: /opt/bitwarden/bwdata/scripts/run.sh: Permission denied

Screenshots or Videos

No response

Additional Context

If I manually change ownership of bwdata to my bitwarden user and group before startup (using root) then instance is starting properly, but owner of the files changes during that process and next time I will try to restart bitwarden I will receive permission error again.

Build Version

1.45.2

Environment

Self-Hosted

Environment Details

-Operationg system: Oracle Linux 8.5 up to date -bitwarden.sh version 1.45.2 -Docker version 20.10.12, build e91ed57 -Docker Compose version v2.2.3 -Selinux in permissive mode

[Hinton]

Hi @WojTecH94,

Have you tried making run.sh executable? chmod +x run.sh.

The bash scripts are supposed to be executed using a regular user, it sounds like you are attempting to use root?

[WojTecH94]

I am logged in to "bitwarden" user. The whole idea of rootless docker is to not use accounts that have sudo permissions. Like I mentioned in Additional Context section I can always log in to root, change ownership (or permissions) of bwdata directory, then log back to bitwarden account and It will work, but only until next restart, because during the run the permissions are restored.

[gitwittidbit]

Same issue here.

I actually managed to get it up running once by changing the permissions on bwdata. It then told me that I needed to update.

But the update functionality apparently also changes the permissions back and does so before it actually creates the docker-compose.yml file which sits somewhere in bwdata so that I get to see this error message:

ERROR: .PermissionError: [Errno 13] Permission denied: '/home/bituser/bitwarden/bwdata/docker/docker-compose.yml'

I tried changing the permissions again but the update breaks it again. So I am stuck there now.

[gitwittidbit]

Or, asking more generally, is it possible to run Bitwarden in a rootless docker or not? I don't want to spend too much time fighting wind mills...

[Hinton]

Hi folks,

Unfortunately I don't believe we currently support rootless docker. But it's something we are looking into but at this point I can't provide an ETA.

[github-actions[bot]]

We use GitHub issues as a place to track bugs and other development related issues. The Bitwarden Community Forums has a Feature Requests section for submitting, voting for, and discussing requests like this one.

Please sign up on our forums and search to see if this request already exists. If so, you can vote for it and contribute to any discussions about it. If not, you can re-create the request there so that it can be properly tracked.

This issue will now be closed. Thanks!

[LudoPL]

Hi ! I did not have exactly the same issue but maybe my message may help others that will come here. I have an old bitwarden self hosted installation and my bitwarden.sh script was launched as root. I tried to change that but running the update was restoring "nobody" permission on bwdata directory and so it was not working as the bitwarden user was then unable to access those file. I investigated a bit and I saw that there is an file "env/uid.env". This file is used to restore permission during the update. So in my case, deleting the file after changing directory permission and before launching bitwarden was the solution (it is recreated when launching the script with the right user). No need to say that I'm no bitwarden expert so no guarantee on the exact consequences, do a backup before trying.

[sstidl]

I investigated a bit and I saw that there is an file "env/uid.env".

this should go to documentation. when switching from root docker to rootless I ran into the same issue.