Setting PUID and PGID to root

The unifi tag is just one I picked as example as I have more of an overall question.

A bit of background here, TLDR question at the bottom:
I’m currently trying to run Linuxserver containers rootless in podman. I know this is not officially supported, and I have no question that directly asks for support of this. Through trial and error and reading this forum I found out that the containers first seem to run init scripts as root to set the permissions and other things correctly, and afterwards it runs as the user provided by the PUID and GUID (correct me if I am wrong here).

My approach now is that podman allows me to run the container as a root user inside the container, but outside the container the root ID maps to whatever ID I started the container as (for example, 1000). As Linuxserver first needs to run as root, and then switch to whatever user was provided via the env. vars, I would need 2 users, which both have access to the files that I mount. But with podman I can afaik only map the user I ran the container as consistently.

TL:DR:
My solution would have now have been that I set the PUID/GUID via the env vars to 0 so the container just runs as root user internally all the time. Could this cause any problems for the container, or should it mostly act as usual ?

your assumptions above are correct at a high level of how our stuff works.

we can’t possibly tell you an answer to this as we do not test, use, or support podman in any way, shape, or form. I would say just give it a try and see what happens.

Isn’t this something that would also be possible in a normal docker setup though ? It’s not strictly podman specific (just would be unsecure in docker)

I will probably try it out and report back how it went (if I don’t forget to post here)

we have users who do this successfully, yes. We also get many users who do this and encounter weird issues, we tell them to use a non-root uid/gid, and things will be fixed. Since we dont support using root, it’s not something we’ve ever dug into.

I use podman, there is no need to do any of this. Podman from a container runner perspective is only different in that it is deamonless and runs in userspace. What happens inside the container should be 1:1 with docker unless you are trying to bind mount in root owned filesystems or devices.
Simply run the container as we recommend, our s6 init will run as root and when services are actually executed in the container they will run as the PUID and PGID you pass to the container as env variables. There are very few corner cases where we run anything as root in the container outside of init or need to have root privs to manipulate something like a device or docker socket etc…

1 Like

I can’t say I have made the same experience.
This is the compose I used for docker:

version: "3.7"
services:
  unifi-controller:
    image: docker.io/linuxserver/unifi-controller:version-6.5.55
    container_name: unifi-controller
    environment:
      - PUID=1000
      - PGID=1000
      - MEM_LIMIT=1024M #optional
    volumes:
      - /opt/Unifi:/config
    network_mode: host

Running this compose via podman-compose with the command

podman-compose -f ./docker-compose.yml up -d

results in these kinds of errors

chown: changing ownership of '/config/data/backup/6.0.23.unf': Operation not permitted

(There is more of these, just didn’t wanna fill the entire page with them)
If I exec into the container the mounted files appear as the following permissions:

root@container:/usr/lib/unifi# ls /config -la
total 20
drwxr-xr-x  5 root root 4096 Dec 23 14:07 .
dr-xr-xr-x 21 root root 4096 Dec 23 14:04 ..
drwxr-xr-x  5 root root 4096 Dec 23 14:03 data
drwxr-xr-x  3 root root 4096 Oct  3  2020 logs
drwxr-xr-x  3 root root 4096 Dec 23 14:04 run

On the host these files have the owner of the user I run the container with, which makes sense that they then would be mapped to root:root inside the container.

I’m not sure why this problem occurs, as the container should run as root initially, but changing the PUID/GUID to 0 seems to fix the issue.

Are you by chance running podman with sudo or root in your setup ? Because that would work for podman to access these files and run pretty much just like docker, but I don’t think that counts as rootless.

it’s likely because your path /opt/Unifi was preexisting and already owned by root. We typically suggest letting docker create the bind mount folders which will ensure it has proper permissions from the start.

/opt/Unifi was preexisting, but owned by the user I ran the container with, which isn’t root. In the container it just gets shown as root:root because podman handles it like that.

ahh we’ll have to wait on thelamer to chime in then

I had some permission error too when trying qbittorrent container, however after following tutorial here Media Server Setup with Podman. How to setup Radarr / Sonarr / NZBGet /… | by Pooch | Medium

it works if I add :z to my volume config. ( of course turning selinux off also works)