USER_ID default (1000) causes issues with docker rootless (and possibly podman)

[Fran314]

I've found that running this container with docker rootless (and possibly podman, though I haven't tested it) generates some weird behaviours and bugs which need USER_ID=0 (and GROUP_ID=0) to resolve.

I want to document this issue so that possibly this fix gets mentioned in the documentation, hoping to save this headache to other users.

Note

There will be some confusion between the host user running docker, the user inside the container and the root-user inside the container. To try and avoid this confusion, I'll use the following notation:

• I'll call "host-user" the user on the host that is running docker. This user has ID 1000 on the host
• I'll call "container-user" the user with ID 1000 inside the container
• I'll call "container-root" the root user inside the container

Note that docker translates the container ids to host ids according to the rules in /etc/subuid. In a typical case, since the host-user running docker has ID 1000, then:

• container-id-0 gets mapped to host-id-1000 (and viceversa)
• container-id-1000 gets mapped to host-id-100999 (and viceversa)

Setup to reproduce

The setup to reproduce the issues is the following:

Start with the following directory structure

.
├── compose.yaml
├── config/
└── trash/

where ./config/ and ./trash/ empty directories owned by host-user (with permissions 1000:1000) and the content of compose.yaml is the following:

services:
    handbrake:
        image: jlesage/handbrake:latest
        container_name: handbrake
        devices:
            - /dev/dri:/dev/dri
        ports:
            - 5800:5800
        volumes:
            - ./config:/config
            - ./trash:/trash
        # environment:
        #     - AUTOMATED_CONVERSION_USE_TRASH=1
        restart: unless-stopped

First issue

Let the host-user start the container (with docker rootless) with

docker compose up

you will notice that the permissions of the directory ./config have changed from the original 1000:1000 to 100999:100999. I believe this is because this container chowns the config directory to the container-user which has id specified by the environment variable USER_ID (by default 1000), which as discussed gets mapped outside of the container to the value 100999.

This isn't an issue on itself, as the container runs without a problem, but it becomes an issue when the host-user wants to backup the content of the ./config directory

Second issue

Uncomment the environment variable inside of compose.yaml, with the following result:

services:
    handbrake:
        image: jlesage/handbrake:latest
        container_name: handbrake
        devices:
            - /dev/dri:/dev/dri
        ports:
            - 5800:5800
        volumes:
            - ./config:/config
            - ./trash:/trash
        environment:
            - AUTOMATED_CONVERSION_USE_TRASH=1
        restart: unless-stopped

Now let the host-user (try to) run the container with

docker compose up

You will see that the container fails to start, giving the following error

handbrake  | [cont-init   ] 54-check-trash-dir.sh: executing...
handbrake  | [cont-init   ] 54-check-trash-dir.sh: mktemp: failed to create file via template ‘/trash/.test_XXXXXX’: Permission denied
handbrake  | [cont-init   ] 54-check-trash-dir.sh: ERROR: Trash usage is enabled, but no write permission on it.
handbrake  | [cont-init   ] 54-check-trash-dir.sh: terminated with error 1.

This is because the ./trash directory, which has permissions 1000:1000 outside of the container, gets mounted with the mapped permissions of 0:0 inside the container and is owned by the container-root, so the container-user fails to use it. This causes the container to get stuck in a startup-loop and not start at all, which is of course problematic.

Fix

Both of this issues are resolved with the following compose.yaml:

services:
    handbrake:
        image: jlesage/handbrake:latest
        container_name: handbrake
        devices:
            - /dev/dri:/dev/dri
        ports:
            - 5800:5800
        volumes:
            - ./config:/config
            - ./trash:/trash
        environment:
            - USER_ID=0
            - GROUP_ID=0
            - AUTOMATED_CONVERSION_USE_TRASH=1
        restart: unless-stopped

that is, by specifying USER_ID=0 and GROUP_ID=0 in the container environment variables. This tells the container to run as container-root instead of container-host, and since container-root gets mapped to host-user, this results in the intended behaviour.

Conclusion

I don't really think that this counts as a bug neither in docker-rootles nor in this container, because:

• the id mapping host-1000 <-> container-0 and host-100999 <-> container-1000 is intended behaviour
• it (probably) makes sense to have the default value of USER_ID to be 1000, because most people usually run docker not in rootless mode and by having this default, it makes it easy to have the correct permissions in and out of the container

I do think though that this was a bit of a headache to figure out, and it might be useful to other user to add a small note under the chapter User/Group IDs of the README along the lines of:

If you're running this container with docker rootless (or podman) you might want to set USER_ID=0 and GROUP_ID=0 to get the container to run and obtain the permissions you would expect

Note: I keep mentioning podman because as far as I can tell, it behaves similarly to docker rootless and I guess it would result in the same bug, though I haven't tested it. If someone wants to test it I'd be interested in the results they get!

[jlesage]

You should not have to use USER_ID=0 and GROUP_ID=0.

I verified with podman: the following options can be used: --userns=keep-id --user 0:0. In this scenario:

• The container runs on the host as the "host-user" (i.e. user id 1000).
• Inside the container, the default user is "container-root" (0 inside the container, mapped to something else on the host).
• Inside the container, the "container-user" 1000 is mapped to the "host-user" 1000.

With docker, I think the same thing can be achieved with --userns=host --user 0:0 (for the docker run command).

[Fran314]

I've tested it, and I can confirm that it runs succesfully with podman, but I get the same error as the second issue when running with docker run with the flags you suggested.

For completeness, the (succesfull) podman command I used is the following:

podman run --rm --name handbrake-podman --device /dev/dri:/dev/dri --userns=keep-id --user 0:0 -p 5801:5800 -v ./config:/config -v ./trash:/trash -e AUTOMATED_CONVERSION_USE_TRASH=1 jlesage/handbrake:latest

and the (unsuccesfull) docker command I used is the following (this is being run by host-user-1000 and with docker rootless):

docker run --rm --name handbrake-podman --device /dev/dri:/dev/dri --userns=host --user 0:0 -p 5801:5800 -v ./config:/config -v ./trash:/trash -e AUTOMATED_CONVERSION_USE_TRASH=1 jlesage/handbrake:latest

(don't mind the unusual port and name, it was just to make it not collide with the already running instance)

As I mentioned, the error for the docker run is the same as the second issue in the first post, that is issues with the permissions of the trash, but if needed I can provide the full log.

Can I ask in practice what is the difference between using --user 0:0 and setting USER_ID and GROUP_ID to 0? I thought they meant basically the same thing, but apparently not (and I can confirm that they're not doing the same thing because I'm getting some weird permission issues with podman, caused by my default group being 100 instead of 1000 (thanks NixOS I guess) which means that I have to use BOTH --user 0:0 and GROUP_ID=100 to get the proper permissions on the host).

I'm not 100% sure that --userns=host on docker does the same thing as --userns=keep-id does on podman, but it's the first time using docker-rootless for me and I have never used podman so don't quote me on this.

(Anyway, I can at least make it run as intended on podman, thank you for the help!)