Can't start unifi container as non-root user

[cinergi2]

Hello,

I'm trying to start the unifi-docker container ("latest" tag) on a Raspberry Pi 4 running Bullseye Arm64. It starts fine as the root user, but not as a custom non-root user that I've created:

docker run -d --restart=unless-stopped --net=host --name unifi --user="1001:1001" -e TZ='America/Toronto' -v /home/pi/docker/unifi:/unifi jacobalberty/unifi:latest

This results in the following error message in the mongodb.log file:
ERROR: Cannot write pid file to /usr/lib/unifi/run/mongod.pid: Permission denied

And a similar error in the Docker log:
rm: cannot remove '/var/run/unifi/unifi.pid': Permission denied

The issue is that the above system folders require root privileges for write access. How can I fix this without running unifi as root?

I'm a novice with Docker, so if I'm missing something obvious my apologies.

Thanks!

[cinergi2]

Hmm... If I set the environment variables RUNAS_UID0=false, UNIFI_UID=1001 and UNIFI_GID=1001 instead of the --user statement, it works fine. I thought --user would be equivalent since I understand the environment variable method is being deprecated (according to some of the other topics on here) but I guess not.

[jacobalberty]

The solution is to chown your unifi volume to be owned by the unifi uid. Yes the environment variable option is being deprecated but it functions quite differently from --user. The environment variable option launches as root, chowns the folder then drops permissions. I'm working on a solution to handle chowing the volume via a setuid binary. It will probably show up in the beta tag soon.

…

On Sun, Feb 13, 2022, 5:51 PM cinergi2 ***@***.***> wrote: Hmm... If I set the environment variables RUNAS_UID0=false, UNIFI_UID=1001 and UNIFI_GID=1001 instead of the --user statement, it works fine. I thought --user would be equivalent since I understand the environment variable method is being deprecated (according to some of the other topics on here) but I guess not. — Reply to this email directly, view it on GitHub <#525 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPDNAWIBI7X7EDXEGV7JDDU3A7YNANCNFSM5OJ2GU3Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cinergi2]

The solution is to chown your unifi volume to be owned by the unifi uid.

Thanks! I'm not sure I understand. I did chown my unifi folder (the one with the data and log subfolders that's mapped using -v) to the unifi uid and gid 1001. Unifi is able to write to those folders - for example the system properties, mongodb.log, server.log, etc. all get written properly. It was complaining about /var/run/unifi and /usr/lib/unifi, which are not within that folder structure.

[jacobalberty]

Those folders are symlinked to /unifi/run and /unifi/data respectively

…

On Sun, Feb 13, 2022, 6:12 PM cinergi2 ***@***.***> wrote: The solution is to chown your unifi volume to be owned by the unifi uid. Thanks! I'm not sure I understand. I did chown my unifi folder (the one with the data and log subfolders that's mapped using -v) to the unifi uid and gid 1001. Unifi is able to write to those folders - for example the system properties, mongodb.log, server.log, etc. all get written properly. It was complaining about /var/run/unifi and /usr/lib/unifi, which are not within that folder structure. — Reply to this email directly, view it on GitHub <#525 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPDNARKKXFDR2H4HTVTBJTU3BCG3ANCNFSM5OJ2GU3Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[cinergi2]

I think I must be looking in the wrong place. I've mapped /home/pi/docker/unifi in my host file system to /unifi in the Docker container using the -v /home/pi/docker/unifi:/unifi option. Everything under this folder hierarchy is owned by the unifi user and unifi group, with a uid/gid of 1001/1001 respectively. Unifi is able to write properly into this folder.

I don't see any /unifi/run subfolder - just data and log. There are no .pid files anywhere in this folder hierarchy.

[jacobalberty]

It looks like the /unifi/run mappings didn't get moved from the old volume structure, it's just owned by 999:999, the default unifi uid so it's not an issue with the default --user unifi setting I use, that'll need to be cleaned up with the move to the setuid binary

[cinergi2]

Thanks. I would have used --user unifi myself, but on my system there's already another unrelated user with uid 999 (pihole). I guess I'll just keep using the environment variable method until the move to setuid, as there doesn't seem to be a better option if there's already an existing 999 user.

[cinergi2]

Just wanted to add that I found another way to do it without using the environment variables. I added a mapping using -v for /var/run/unifi in addition to the existing mapping for /unifi. I made sure to chown the mapped folder to the unifi user and group (1001 in my case). Then, I ran the docker container using --user="1001:1001" without the environment variables. This enabled Unifi and mongodb to successfully write their PID files.

[jacobalberty]

the run directory should now properly be placed into /unifi working on getting permset shoehorned in now

[jacobalberty]

I have the fixes for permissions on the latest tag right now, they should work how you expect it to wrt to --user if you want to give it a try and tell me if it works how you expect it to that would be great. Just be careful about lingering on latest too long right now as 7.0.x should be out of RC hopefully sometime next week. I will test this a bit in my own environment and if I don't see any issues I'll try to get it merged into v6.5.55 before 7.0.x makes stable.

[cinergi2]

Thank you! At this point, since 7.0.xx will be out of RC soon as you mentioned, I think I'll wait for that. It's been working fine for me with the manual mapping I added for /var/run/unifi.

By the way, the mongodb version is currently 3.4. Since Ubiquiti supports 3.6, any plans to upgrade it in an upcoming release?

[jacobalberty]

So it looks like mongo db 3.6 can install on ubuntu 18.04 so that's possible.

I'm hesitant to touch much with mongodb because it's super fragile right now due to supporting armhf (32 bit arm). Right now that's what has us stuck on ubuntu 18.04, the 32 bit arm version is even stuck on mongo db 3.2 too.

Long term by the end of 2028 I have to drop armhf support ideally I would prefer to drop it by the end of 2023 (coinciding with standard updates or extended updates for ubuntu 18.04) that would make bumping up to 3.6 a lot less scary.

What I am considering doing is picking an arbitrary release of Unifi and saying it will be the last one to support 32 bit arm (i've kind of been hoping Ubiquiti would do this for me) and use that point to bump up both mongodb to 3.6 (or newer if ubiquiti starts supporting a newer version by then) and ubuntu to 22.04 at the same time.

What would be another good trigger for doing that break would also be if Ubiquiti started supporting a newer version of java, knock the trio of updates all out at once.

Edit: https://github.com/jacobalberty/unifi-docker/projects/2 Here's a project to track the issues related to that. I'll add an issue for mongodb update to that.

[cinergi2]

Thanks for the explanation. Yes, there are indeed many variables involved. Personally, I'd be OK if you drop armhf support but of course I understand that you may have users who still rely on it. Given that many people run the Unifi controller on Raspberry Pis, and that Raspberry Pi OS has recently started supporting arm64 on the Pi 3 and 4, armhf should become less relevant I guess.

[mag1024]

I think this problem might be back with 7.0.25 on x86 amd64.
7.0.23 works fine (run directory gets created under /unifi, which is mounted as a volume), but with 7.0.25 I get endless
ERROR: Cannot write pid file to /usr/lib/unifi/run/mongod.pid: Permission denied errors in the mongodb log. I tried both starting a with a clean volume owned by user unifi, and upgrading from a previously-working 7.0.23.

[wittypluck]

Hello,
I had the same error when running as non root, non unifi user (--user 1001:1001):
ERROR: Cannot write pid file to /usr/lib/unifi/run/mongod.pid: Permission denied
I had to add the following mapping:
-v ~/unifi/run:/usr/lib/unifi/run

This is with version 7.2.95

[gctwnl]

I am trying to setup a fresh new controller as docker container using docker compose and :lastest. I run into probably the same problem. It seems that even if the controller is given a user:group setting, mongodb is still creating everything as root.

  unifi-controller:
    image: jacobalberty/unifi:latest
    container_name: unifi-controller
    user: 118:123
    environment:
      - TZ=Europe/Amsterdam
    volumes:
      - /srv/docker/unificontroller/unifi:/unifi
      - /usr/lib/unifi/run/mongod.pid:/unifi/mongodb.pid

Starting and stopping the container results in:

./unifi:
total 24
drwxr-xr-x 6 unificontroller unificontroller 4096 Nov 22 14:15 .
drwxr-xr-x 4 root            root            4096 Nov 22 14:42 ..
drwxr-xr-x 4 unificontroller unificontroller 4096 Nov 22 14:42 data
drwxr-xr-x 2 unificontroller unificontroller 4096 Nov 22 14:42 log
drwxr-xr-x 2 root            root            4096 Nov 22 14:15 mongodb.pid
drwxr-xr-x 2 root            root            4096 Nov 22 13:57 run

./unifi/data:
total 28
drwxr-xr-x 4 unificontroller unificontroller 4096 Nov 22 14:42 .
drwxr-xr-x 6 unificontroller unificontroller 4096 Nov 22 14:15 ..
drwxr-xr-x 2 unificontroller unificontroller 4096 Nov 22 14:42 backup
drwxr-xr-x 2 unificontroller unificontroller 4096 Nov 22 14:42 db
-rw-r--r-- 1 unificontroller unificontroller 2248 Nov 22 14:42 keystore
-rw-r--r-- 1 unificontroller unificontroller 1352 Nov 22 14:42 system.properties
-rw-r--r-- 1 unificontroller unificontroller 1352 Nov 22 14:42 system.properties.bk

and in the mongodb log:

2022-11-22T15:42:42.306+0100 I CONTROL  [main] ERROR: Cannot write pid file to /usr/lib/unifi/run/mongod.pid: Permission denied

[gctwnl]

Answering myself, this one does launch:

version: "2.1"
services:
 unifi-controller:
  image: jacobalberty/unifi:latest
  container_name: unifi-controller
  environment:
   - TZ=Europe/Amsterdam
   - RUNAS_UID0=false
   - UNIFI_UID=118
   - UNIFI_GID=123
  volumes:
   - /srv/docker/unificontroller/unifi:/unifi
  ports: 
   - 8443:8443
   - 3478:3478/udp
   - 10001:10001/udp
   - 8080:8080

Before docker compose up -d you need to create unifi/log unifi/data and unifi/run and chown them to (in this example) 118:123. And you have to be patient, it takes a while for the controller to launch.

[ptr727]

I am currently running the old lsio version, trying this instead of the new mongo+lsio version.

I run all my containers with a custom non root user, when I run this container using user: ${USER_NONROOT_ID}:${USERS_GROUP_ID} it fails to start with access error in logs.

Per readme it seems that it is either root or unifi user, not a custom user, is that accurate?

I see mention of UNIFI_UID and UNIFI_GID in this issue, but not documented, is there a supported way of running as an arbitrary non-root user?

[gctwnl]

I am currently running the old lsio version, trying this instead of the new mongo+lsio version.

I run all my containers with a custom non root user, when I run this container using user: ${USER_NONROOT_ID}:${USERS_GROUP_ID} it fails to start with access error in logs.

Per readme it seems that it is either root or unifi user, not a custom user, is that accurate?

I see mention of UNIFI_UID and UNIFI_GID in this issue, but not documented, is there a supported way of running as an arbitrary non-root user?

My docker-compose.yml says:

    environment:
      - TZ=Europe/Amsterdam
      - RUNAS_UID0=false
      # Sadly, we cannot run this as non-root as the container itself wants to do setuid to a non-root uid
      - UNIFI_UID=118
      - UNIFI_GID=123

This was created a while ago, but apparently my comment is to remind me that the container does a setuid so it needs to run as root, but the resulting process can be non-root.

[ptr727]

Looks like the dockerfile does:

 && groupadd -r unifi -g $UNIFI_GID \
 && useradd --no-log-init -r -u $UNIFI_UID -g $UNIFI_GID unifi \

Where the values are hardcoded in ENV to 999 at build time, so it looks as if the actual user and group cannot be changed.

I may just stick with the LSIO version, at least until --user with any numerics are supported.