Docker Deployment Fails with User/Group Configuration other than 1001:1001

[nosbig]

On a Linux Docker install, without Docker Desktop, a deployment of BorgWarehouse with another UID and/or GID fails, as the container image is built with the borgwarehouse containing the user borgwarehouse (1001) and the group borgwarehouse (1001).

Apparently, Docker Desktop does rebuild the container such that it runs and adjusts the permissions somewhere (either at the host or from within the container), but the standard Docker daemon does no adjustments to permissions.

I've been trying to dabble with building my own image, which I can do by modifying the Dockerfile to add the UID and GID directly into the Dockerfile as well as adding support for changing the UID and GID from the base image at runtime:

RUN usermod --uid ${UID} borgwarehouse RUN groupmod --gid ${GID} borgwarehouse

I've not been able to get it to build with any other combination of changes to the docker-compose.yml file or .env to pass along those values dynamically to the build, much less during a standard Docker Compose deployment.

This feels like it's similar to #60.

[Ravinou]

Thank you for your issue. I manage to reproduce the problem without docker desktop. I'm looking for the right solution.

[shad-lp]

I can confirm this behaviour, I am trying to set my Synology NAS as my main Borg repo host, using that compose :

version: "2.1"
services:

   borgwarehouse:
      image: borgwarehouse/borgwarehouse
      container_name: borgwarehouse
      network_mode: bridge
      user: "1031:100"
      environment:
         - NEXTAUTH_URL=https://bwh.xxx.ovh
         - NEXTAUTH_SECRET=VKXHRqnwH2o6xEJCYD77JR4tmacLTWP2YldapIq7dyE=
         - CRONJOB_KEY=Z8Da8Ao6SwRY0JNiE9nVEh4+GZYrFMYqxJjb5nQmMGY=
         - SSH_SERVER_PORT=50022
         - FQDN=bwh.xxx.ovh
         # backup through LAN
         - SSH_SERVER_PORT_LAN=50022
         - FQDN_LAN=garrus.xxx.ovh
      ports:
         - 53000:3000/tcp
         - 50022:22/tcp
      volumes:
         # config
         - /volume1/homes/backup/borgwarehouse-data/config:/home/borgwarehouse/app/config
         - /volume1/homes/backup/borgwarehouse-data/ssh:/home/borgwarehouse/.ssh
         - /volume1/homes/backup/borgwarehouse-data/ssh_host:/etc/ssh
         - /volume1/backup/borgwarehouse-repos:/home/borgwarehouse/repos
      labels:
         # watchtower label only monitoring
         - "com.centurylinklabs.watchtower.enable=true"
      restart: unless-stopped

Logs at first deployment :

2023-11-18T08:45:55.599477410Z /etc/ssh is empty, generating SSH host keys...
2023-11-18T08:45:55.872282997Z No user exists for uid 1031
2023-11-18T08:46:10.504435157Z /etc/ssh is empty, generating SSH host keys...
2023-11-18T08:46:10.508812955Z No user exists for uid 1031
2023-11-18T08:46:21.259399199Z /etc/ssh is empty, generating SSH host keys...
2023-11-18T08:46:21.417330542Z No user exists for uid 1031

1031 is the UID of my dedicated backup user on Synology DSM 100 is the default GID every user (mandatory) belongs to.

Permissions on folders :

By the way thanks for your awesome work to improve this software since my first issue to tell you about Apprise. I'd gladly sponsor your work if you enable the feature.

[Ravinou]

Thanks for your message of support :). I've just activated the sponsoring button on the project. For the moment I only have github sponsor button. I may add another donation service in the future. A huge thank you for thinking of donate.

I'm trying to find some time to fix this user docker problem. I'm on it :)

Have good day !

[Ravinou]

Thank you very much @shad-lp , I updated the readme of the project to thank you as a sponsor of BorgWarehouse.

[dhenry123]

Hi This happens because the container is not instrumented to switch to another user. This is unfortunately common in the container world. This is why many projects cannot be installed on platforms that start containers with an arbitrary user/group (e.g. Openshift).

After a discussion with Raven, and having removed the cron service, which is useless since its software provides the secure entrypoint needed to execute the task. In business, we always prefer to control task scheduling. The container no longer has this responsibility.

The sshd constraint remains, but it's not a constraint: the user running the processes in the container can also start the sshd daemon. There's no need for a supervisor or service. A "probe" method will do the job.

Consequently, I'm going to propose a build that can swap the user. The tests will be carried out on a Kubernetes cluster, using the security context runAsUser, runAsGroup and read-only. And don't forget that a started container accesses its own volume groups, so don't give these volumes a common group (privilege separation).

Borgwarehouse has a good level of isolation and respects the BorgBackup manifest to the letter.

Thanks Raven for sharing your software

[Ravinou]

For the moment I don't have a solution to propose to avoid having to build the image yourself if another uid:gid is proposed. And not using dockerhub image. Building image is fast.

Docker Desktop seems to do the job on its own. And if not, there are tweaks to pass the uid:gid back to an already-built container, but the simplest thing to do is rebuild.

I'll wait for a functional contribution to help me with this, Docker is not my main expertise.

In the meantime, I'll improve the documentation on this subject to explain that you need to build your own image to use a different uid:gid. I'll also explain how to do this build

[Ravinou]

Full documentation is here. I test it and it run with uid:gid of your choice. All is here. Have fun with latest 2.1.0 🥳 !

[MilesTEG1]

Hello @Ravinou I'm using Portainer to deploy my containers, and I can't build the image with a set of custom uid:gid. And on my Synology NAS, I can't use user 1001:1001.

I think this way of hard setting the uid:gid isn't user friendly. Could you improve this by letting users to choose another uid:gid without needing to build an image? I would be a great improvement. Thanks in advance.