Docker Community Forums

Share and learn in the Docker community.

Urbackup-server doesn't install/start on ROOTLESS docker

Hi All,

I am trying to install uroni/urbackup-server [Docker Hub] on my local rootless docker environment without success.

Can uroni/urbackup-server be installed in a rootless docker environment/container? Do I need to follow a different install procedure to?

I am getting some errors regarding what I understand are privilege issues and as a result it doesn’t start.

As per the instructions [UrBackup - Download UrBackup for Windows, GNU/Linux or FreeBSD] I installed with:
docker run -d --name urbackup --restart unless-stopped -v /media/backups:/backups -v /media/database:/var/urbackup -p 55413-55415:55413-55415 -p 35623:35623/udp uroni/urbackup-server

The first time I installed, the installer gave me these errors and it didn’t finish.

docker: Error response from daemon: error while creating mount source path ‘/media/backups’: mkdir /media/backups: permission denied.
docker: Error response from daemon: error while creating mount source path ‘/media/database’: mkdir /media/database: permission denied.

I went on and created:

sudo mkdir /media/backups
sudo mkdir /media/database

After that the installation completed without errors, but the containers fails to start. In the log I see this error only:

“/usr/bin/entrypoint.sh: line 6: /var/urbackup/backupfolder: Permission denied”

Any ideas?

FYI:
Host details

Hostname ubuntu-server-1
OS Information linux x86_64 Ubuntu 20.04.3 LTS
Kernel Version 5.4.0-89-generic
Total CPU 4
Total memory 2.1 GB

Docker engine details

Version 20.10.10 (API: 1.41)
Root directory /home/xxxxxx/.local/share/docker
Storage Driver overlay2
Logging Driver json-file
Volume Plugins local
Network Plugins bridge, host, ipvlan, macvlan, null, overlay

creating the folders is not enough. The user inside the container must have permission to write it. You just created two folders using sudo which means you had to have root user to create. I don’t think you can expect those folders to be writable by a non-root user.

Hm…should I try giving write access rights to the non-root user I also use with the docker containers?

To whatever user which want to access it. If that user inside the container is root, then give access to your non-root user on the host. In case the user inside the container is something like “daemon” then give access to

231071 + UID of daemon

If it does not work try to run a container, bind mount a test folder from your home dir and use chown to change the owner of a file or folder, exit the container and check the owner of the file on your host.

What I did is created the 2 folders under the home directory of the user (“dockerUser”) that runs docker and starts the (rootless) daemon:

mkdir /home/dockerUser/backups
mkdir/home/dockerUser/database

Then I executed this, and it worked!:
docker run -d --name urbackup --restart unless-stopped -e PUID=1000 -e PGID=1000 -v /home/dockerUser/urbackup:/backups -v /home/dockerUser/urdb:/var/urbackup -p 55413-55415:55413-55415 -p 35623:35623/udp uroni/urbackup-server

After the server finished installing, I checked the directories I created with user “dockerUser” and noticed that the owner changed to “100999”.

drwxrwxr-x 4 100999 100999 4096 Nov 6 18:16 urbackup
drwxrwxr-x 3 100999 100999 4096 Nov 6 18:09 urdb

There is no user with this name or id. How can I find out exactly to which user they relate to?

The container has its own user namespace. In my environment the id outside the container was 231071 + uid inside. To tell the truth I tried rootless docker container the first time today and I am not sure what is the smallest ID on which system. This is why I recommended you to try it with a known user so you can find out the difference between the ID inside and outside. When you know the difference, you can try id USERIDINSIDE command from the container to see the username

This is the first time I use docker and set up a rootless container. It starts being a little bit confusing to me now.

Since it works the way it is now, I have to ask: why is it good to know what is the user behind the id that is now the owner of those folders on the host filesystem?

You wanted to know :slight_smile: If you didn’t, then it was a misunderstanding. The only reason I wrote about looking for the username is that you needed to know which user (or ID) had to own the created folders. If you could find out the id without knowing the user inside the container, that’s fine.

I appreciate your responses because they put me in the right path, read and learnt a lot and made it work!

After some testing I can see that the container user “root” (0:0) maps to the host user “dockerUser” (1000:1000), which is the user running the docker daemon and the container. In the container, there is another user “urbackup” (1000:1000), which after some testing found out that it is the one that maps to the “100999” user in the host, that took ownership of the 2 directories I created in the beginning and then created additional sub-directories and files.

However, I am not sure why the “100999” user took that name. I would have expected that it would have been something like 101000. Is there a way to see these namepsace mappings created by docker?

Would namespace remapping with " userns-remap" help to get a better user mapping? eg as per link [Jujens' blog – Use Linux user namespaces to fix permissions in docker volumes]

I forgot to respond to your last question. I got the notification that you accepted my answer as a solution but I respond the last question now.

That is an ID not a name. Docker has an ID on the host to assign that to the root user inside the container, however, you see that ID from the container’s point of view as “0”. Obviously SMALLEST_ID + 0 is SMALLEST_ID. “daemon” inside the container has “2” as user id but only from the container’s point of view. You can see that from the host as SMALLEST_ID + 2. There is no

HOST_ID_1 - CONTAINER_ID_1
HOST_ID_2 - CONTAINER_ID_2

mapping.

I don’t know where that smallest ID comes from but I had an LXD configuration which a could find while I was searching for the ID I had for the root user and LXD had the same ID for the root user. For Docker I could not find anything yet.

I can’t say that my settings is better than yours. It does not matter which ID was set for your environment. For security reason the smallest ID used by the user namespace should be larger then your biggest and actually used ID on the host. Maybe this is the difference between our environments.