No serial device connection in root-less podman container

Question

No serial device connection in root-less podman container

stephanritscher opened this issue 7 months ago · comments

Describe the bug
A raspberry pi 2 is running iobroker in slave mode in a root-less podman container. The infrared reader (FT232R) is connected to it and redirected to the container. But the smartmeter adapter runs into read timeouts.

To Reproduce

Setup iobroker on "server" in master mode with redis for objects & states.
On "slave" as non-root user with group "dialout" run: podman play kube --annotation run.oci.keep_original_groups=1 podman.txt (see attached podman.txt)
Configure smartmeter adapter on "slave" using device "/dev/ttySMARTMETER"

Expected behavior
Smartmeter adapter should start reading the current meter values.

Screenshots & Logfiles
Instead the communication times out (the infrared head hasn't been moved since successfully reading the meter values using smartmeter adapter on "server" running iobroker natively, i.e. not using podman).

smartmeter.1 | 2023-10-24 21:31:03.094 | warn | No or too long answer from Serial Device after last request.
smartmeter.1 | 2023-10-24 21:31:03.092 | debug | Error: No or too long answer from Serial Device after last request.
smartmeter.1 | 2023-10-24 21:31:03.089 | debug | MESSAGE TIMEOUT TRIGGERED
smartmeter.1 | 2023-10-24 21:29:03.086 | debug | SET MESSAGE TIMEOUT TIMER: 120000
smartmeter.1 | 2023-10-24 21:29:03.078 | debug | CREATE SERIALPORT: 9600 8 1 none
smartmeter.1 | 2023-10-24 21:24:03.075 | debug | SCHEDULE NEXT RUN IN 300s
smartmeter.1 | 2023-10-24 21:24:03.070 | debug | Transport Reset!! Restart = true
smartmeter.1 | 2023-10-24 21:24:03.067 | debug | Error: No or too long answer from Serial Device after last request.
smartmeter.1 | 2023-10-24 21:24:03.063 | warn | No or too long answer from Serial Device after last request.
smartmeter.1 | 2023-10-24 21:24:03.056 | debug | Error: No or too long answer from Serial Device after last request.
smartmeter.1 | 2023-10-24 21:24:03.050 | debug | MESSAGE TIMEOUT TRIGGERED
smartmeter.1 | 2023-10-24 21:22:03.174 | debug | connected set to false
smartmeter.1 | 2023-10-24 21:22:03.042 | debug | SET MESSAGE TIMEOUT TIMER: 120000
smartmeter.1 | 2023-10-24 21:22:03.016 | debug | CREATE SERIALPORT: 9600 8 1 none
smartmeter.1 | 2023-10-24 21:22:03.003 | debug | SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"SerialResponseTransport","requestInterval":"300","anotherQueryDelay":"1000","transportSerialPort":"/dev/ttySMARTMETER","transportSerialBaudrate":null,"transportSerialMessageTimeout":null,"protocolSmlIgnoreInvalidCRC":false}
smartmeter.1 | 2023-10-24 21:22:02.807 | info | starting. Version 3.3.4 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v18.18.2, js-controller: 5.0.14

Versions:

Adapter version: 3.3.4
JS-Controller version: 5.0.14
Node version: 18.18.2
Operating system: Apline Linux (on "slave")

Additional context
The behaviour is the same as in #374.

stephanritscher · Answer 1 · Wed Oct 25 2023 04:05:22 GMT+0800 (China Standard Time)

At least it work when running the same container as root. Any idea which kind of access it needs in addition?
I already had to add some capabilities to podman to be able to run the iobroker container as non-root:

# getcap /usr/bin/podman
/usr/bin/podman cap_net_bind_service,cap_net_admin,cap_net_raw=eip

Ingo Fischer · Answer 2 · Wed Oct 25 2023 16:32:48 GMT+0800 (China Standard Time)

Honestly ... no idea ... In fact the adapter, and so the nodejs process is not getting any data because your debug log do not show it.

In nodejs I can not do anything ... so it must be a config thing in the container ... !? Maybe the nodejs process needs to get additional capabilities or such?

@buanet any idea?

stephanritscher · Answer 3 · Sat Oct 28 2023 17:51:19 GMT+0800 (China Standard Time)

Capabilities was my first guess and I already tried a few, but didn't find the right one(s) yet

stephanritscher · Answer 4 · Sun Oct 29 2023 05:04:23 GMT+0800 (China Standard Time)

I tried adding all capabilities to podman but it didn't help.
However, I was able to get the adapter to work after changing the permissions within the container.

podman exec -it iobroker-app sh

chmod a+rw /dev/ttySMARTMETER

Not yet sure why this not needed if podman runs as root.
I will still need to investigate how to handle this in podman.txt.

André Germann · Answer 5 · Sun Oct 29 2023 05:16:46 GMT+0800 (China Standard Time)

@stephanritscher try environment variable USBDEVICES. This should set the permissions for the device inside the Container...

stephanritscher · Answer 6 · Sun Oct 29 2023 21:36:00 GMT+0800 (China Standard Time)

Unfortunately chown doesn't work (I also tried manually).
The last lines in podman log before the container loops into a restart are:

USBDEVICES is set.
Setting permissions for "/dev/ttySMARTMETER"... chown: changing ownership of '/dev/ttySMARTMETER': Operation not permitted

Maybe again due to running podman in root-less mode?

André Germann · Answer 7 · Mon Oct 30 2023 01:17:58 GMT+0800 (China Standard Time)

Maybe again due to running podman in root-less mode?

Pretty sure thats the problem. The startup script of the container is designed to run as root.

stephanritscher · Answer 8 · Mon Oct 30 2023 05:13:09 GMT+0800 (China Standard Time)

According to my understanding of containers/podman#13090 (comment) there is no good solution which propagates the user or group ownership to a non-root process in a root-less container. So I'll stick with allowing all users to modify the character device (chmod on the host) since my system only has very few users.
Thanks anyways!