Openhab user groups not added anymore

[TheNetStriker]

Summary

In the latest image (4.2.3) the openhab user is not added to the additional groups anymore. This prevents the process from accessing the Zwave serial port.

Expected Behavior

Openhab user should receive additional groups again. (e.g. dialout group)

Current Behavior

I found the following error in the docker log:

Adding user `openhab' ...
Adding new user `openhab' (110) with group `openhab (115)' ...
useradd warning: openhab's uid 110 outside of the UID_MIN 1000 and UID_MAX 60000 range.

I guess that the newer debian version wants higher user id's.

Possible Solution

Assign higher user and group id's in the entrypoint script.

Steps to Reproduce

1. Launch latest OpenHab version in docker.
2. Check groups with command "groups openhab". It should list the following:
   openhab : openhab uucp dialout audio audio2 uucp2 dialout2 audio3 dialout3 uucp3 audio4 dialout4 audio5 gpio

Context

ZWave not working anymore. I had to revert to version 4.2.2.

Your Environment

OpenHab running on an Rasperry Pi 5 using Docker.

Image

• openHAB version: 4.2.3
• Image tag used: openhab/openhab:4.2.3

Docker Host

• Operating System: Debian GNU/Linux 12 (bookworm)
• Docker Version: 27.3.1
• Kernel Version: 6.6.51+rpt-rpi-2712
• Architecture: aarch64

Configuration

  openhab:
    image: openhab/openhab:4.2.3
    container_name: openhab
    restart: always
    devices:
      - /dev/serial/by-id/usb-0658_0200-if00:/dev/ttyZwave
    network_mode: host
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - /opt/docker/openhab/openhab/addons:/openhab/addons
      - /opt/docker/openhab/openhab/config:/openhab/conf
      - /opt/docker/openhab/openhab/userdata:/openhab/userdata
    environment:
      - CRYPTO_POLICY=unlimited
      - EXTRA_JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n
      - OPENHAB_HTTP_PORT=8080
      - OPENHAB_HTTPS_PORT=8443
      - USER_ID=110
      - GROUP_ID=115

[wborn]

In the latest image (4.2.3) the openhab user is not added to the additional groups anymore.

I don't see missing groups? 🤔

4.2.2

$ docker run -e USER_ID=110 -e GROUP_ID=115 -it --rm openhab/openhab:4.2.2 bash -c 'id openhab && groups openhab'
....
+ exec bash -c 'id openhab && groups openhab'
uid=110(openhab) gid=115(openhab) groups=115(openhab),10(uucp),20(dialout),29(audio),11(audio2),14(uucp2),16(dialout2),17(audio3),18(dialout3),32(uucp3),63(audio4),490(dialout4),492(audio5),997(gpio)
openhab : openhab uucp dialout audio audio2 uucp2 dialout2 audio3 dialout3 uucp3 audio4 dialout4 audio5 gpio

4.2.3

$ docker run -e USER_ID=110 -e GROUP_ID=115 -it --rm openhab/openhab:4.2.3 bash -c 'id openhab && groups openhab'
...
+ exec bash -c 'id openhab && groups openhab'
uid=110(openhab) gid=115(openhab) groups=115(openhab),10(uucp),20(dialout),29(audio),100(users),11(audio2),14(uucp2),16(dialout2),17(audio3),18(dialout3),32(uucp3),63(audio4),490(dialout4),492(audio5),997(gpio)
openhab : openhab uucp dialout audio users audio2 uucp2 dialout2 audio3 dialout3 uucp3 audio4 dialout4 audio5 gpio

Only difference in 4.2.3 is the new users group.

I found the following error in the docker log

It's a warning not an error.

[TheNetStriker]

Sorry I made a mistake testing this. I actually had a problem with a custom image based on the official image. I only briefly tested this on the official image and this when I saw the "outside of range" warning and confused this with the error I had on my custom image. I should have invested some more time analyzing this.

I've now found out what is causing the problem on my custom image:

I'm installing the openjdk-17-dbg package to get debug capabilities on the docker image. (e.g. to create memory dumps)
Since Debian 12 installing this package create's the following 3 groups:

systemd-journal:x:999:
systemd-network:x:998:
systemd-timesync:x:997:

The systemd-timesync service created by the package is using the same group id as the entrypoint script for the gpio group and this creates the following error on startup:

groupadd: GID '997' already exists

Do you have an idea how such problems could be avoided when installing custom packages on top of the official image?

My idea would be to just create the groups in advance in the Dockerfile and only create the openhab user and assign the groups in the entrypoint file. This way when installing additional packages it would automatically use other group id's for additional services.

[wborn]

If I find some time I'll update the entrypoint script with a function that checks if a group with the ID already exists and if so add the openhab user to it.

[TheNetStriker]

The problem with that is that the entrypoint is called after additional packages have already created groups. This would still result in the problem that group id 997 will already be taken by the systemd-timesync service.

I solved this problem for now by adding the groups directly in my Dockerfile like this:

FROM openhab/openhab:4.2.3

RUN groupadd -g 11 audio2; \
  groupadd -g 14 uucp2; \
  groupadd -g 16 dialout2; \
  groupadd -g 17 audio3; \
  groupadd -g 18 dialout3; \
  groupadd -g 32 uucp3; \
  groupadd -g 63 audio4; \
  groupadd -g 490 dialout4; \
  groupadd -g 492 audio5; \
  groupadd -g 997 gpio;

RUN apt-get update && \
  apt-get install -y \
  openjdk-17-dbg

COPY entrypoint /entrypoint
RUN chmod +x /entrypoint

At the end a custom entrypoint file is copied to the container image where I just removed those lines:

groupadd -g 11 audio2
groupadd -g 14 uucp2
groupadd -g 16 dialout2
groupadd -g 17 audio3
groupadd -g 18 dialout3
groupadd -g 32 uucp3
groupadd -g 63 audio4
groupadd -g 490 dialout4
groupadd -g 492 audio5
groupadd -g 997 gpio

This way the openjdk-17-dbg automatically takes a non used group id.

Is there any reason not to do it that way? I could also create a pull request for this if you like.