Permission denied when using external mounts

[joerg]

Disclaimer: This is a copy of https://github.com/bitwarden/server/issues/2989, since the Docker part moved to this repo

Steps To Reproduce

1. Install according to official documentation
2. Use an external storage mount for the data directory /etc/bitwarden. Examples: i. Official Docker docs for NFS: https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume ii. EFS Volume on AWS Fargate: https://docs.aws.amazon.com/AmazonECS/latest/userguide/efs-volumes.html Expected Result Regular working Service with a highly available and easy to backup storage solution in the background.

Actual Result

The logs show a "permission denied" error when trying to set the permissions for /etc/bitwarden. This happens in the unified and the regular containers. The exact line of code producing the error is for the regular installation this https://github.com/bitwarden/server/blob/master/src/Admin/entrypoint.sh#L33 and for the unified this https://github.com/bitwarden/server/blob/master/docker-unified/entrypoint.sh#L97.

After some investiagation the underlying problem seems to be that the application user is created in the entrypoint.sh script and thus the /etc/bitwarden directory is owned by root:root during the container creation when the mount is happening. Changing permissions to a mounted directory is not possible afterwards, thus the application does not have permissions to /etc/bitwarden during runtime and does not work.

Screenshots or Videos

No response

Additional Context

Best practice by Docker seems to be to create the user with an explicit UID/GID during the image creation and not during container startup. Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user A change of this explicit UID/GID should then not be done in the entrypoint script but utilizing a remap as suggested by Docker: https://docs.docker.com/engine/security/userns-remap/

Build Version

https://github.com/bitwarden/server/commit/8d9ca424a1ec2079cc2508be5c23a4883987ea69-dirty and 2023.4.3

Environment

Self-Hosted

Environment Details

Tested on various Setups including:

• Server installation on Ubuntu LTS 22.04 and 20.04 using an external NFS storage mount.
• AWS ECS Fargate installation with and EFS share

Issue Tracking Info

• [x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[Krychaz]

Hello there,

I am passing this to engineering team based on the previous issue that was opened.

[joerg]

Just as a heads up: The same problem/error exists for all other docker images, especially the key-connector which is not included in the unified build and also the separate images.

[yggdrasil-tynor]

Same here when hosting on Azure App Service with external mount (Storage --> File Share)