s6-overlay-preinit: fatal: unable to chown /var/run/s6: Operation not permitted

[jinnko]

---

Expected Behavior

When starting the container I expect it to start.

Current Behavior

The container fails to start, emitting only the following error:

s6-overlay-preinit: fatal: unable to chown /var/run/s6: Operation not permitted

This appears to have started in the past week following a newly published image on docker hub.

Steps to Reproduce

1. Pull the latest image with docker-compose pull
2. Start the image with docker-compose up
3. See the error message emitted and the container exits.

Environment

OS: Debian 10
CPU architecture: amd64 (Ryzen)
How docker service was installed: docker-ce 5:19.03.133-0debian-buster amd64

Command used to create docker container (run/create/compose/screenshot)

$ cat-clean docker-compose.yml    
version: "2.4"
services:
  main:
    image: linuxserver/unifi-controller:latest
    userns_mode: host
    network_mode: host
    volumes:
      - ./config:/config
    restart: unless-stopped

$ docker-compose up -d

Docker logs

linuxserver/unifi-controller:latest_unifi-contro[5838]: s6-overlay-preinit: fatal: unable to chown /var/run/s6: Operation not permitted

[github-actions]

Thanks for opening your first issue here! Be sure to follow the issue template!

[j0nnymoe]

You're missing PUID/PGID values

[jinnko]

Unfortunately that doesn't change anything.

Added to docker-compose.yml, to match ownership of the mounted config/ path, with no effect.

...
    environment:
      - PUID=911
      - PGID=911
...

[j0nnymoe]

You need to be using a UID/PGID that's on your system, 911 is just a value the container defaults to.

Did you use the official docker repo to install docker or just the binaries supplied by debian?

Use full system path for your /config too

[jinnko]

Okay, so I've done this:

1. created a user unifi belonging to group unifi
2. chown unifi: config
3. changed the docker-compose path to my config/ to a fully qualified path
4. Updated the docker-compose to reference the new unifi group and user.

No change. Still have exactly the same error.

I'd like to point out that the error has nothing to do with the config/ path, but it's about /var/run/s6.

I strongly believe this has absolutely nothing to do with the PUID/GUID settings due to the above observations and no change, and based on the fact I've been using this set up for at least 6 months with automated regular updates to the running image, without issue.

UPDATE: And the docker version installed is the official upstream Docker CE version from the official docker repositories.

[j0nnymoe]

Can't do any testing myself right now but our smoke tests show the container is booting correctly: https://ci-tests.linuxserver.io/linuxserver/unifi-controller/6.0.28-ls85/index.html

[aptalca]

Remove userns_mode: host

[jinnko]

In order to remove userns_mode: host I also had to remove network_mode: host. In order to avoid file ownership headaches I also created a docker volume for the config. All together this seems to have resolved the issue. I'm wondering if a kernel update may have introduced a change in cgroups behaviour because nothing else has changed besides a recent update to the unifi-controller container and the kernel. The system is running 5.8.18 on Debian 10.

I had added the network_mode: host in the past because I had problems with device discovery and adoption when the controller wasn't on the same network. It's not trivial to test that again now with the changes.

Thanks both for taking a look at this. Much appreciated.

[jinnko]

I have confirmed that it's not possible to adopt devices when the container is run behind the standard docker NAT, even with all the ports forwarded. Moving it to the host network namespace resolves the issue. I'll be submitting a PR to s6-overlay to hopefully get this issue resolved so it's once again possible to use the network namespace when userns-remap is turned on.