Describe the issue you are experiencing
With the change of device handling in the supervisor update to 2021.02.6 the pigpio addon of mine stopped working.
Now it can't create its pipe devices /dev/pigerr and /dev/pigpio from inside the addon.
2021-02-10 01:01:16 myCreatePipe: Can't set permissions (434) for /dev/pigpio, No such file or directory
2021-02-10 01:01:16 pthFifoThread: fopen /dev/pigpio failed(No such file or directory)
Is there a way to allow specific device creation? Or create them beforehand?
What is the used version of the Supervisor?
supervisor-2021.02.6
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
What is the version of your installed operating system?
5.11
What version of Home Assistant Core is installed?
core-2021.2.2
Steps to reproduce the issue
Anything in the Supervisor logs that might be useful for us?
_No response_
Having the same issue on several different installations. Rather critical for me to get fix ASAP.
The /dev is a shared and protected space. It is recommended to use a different (local) part of the file system inside the container. For example, /tmp.
Also most addons which are just a wrapper around existing software have no possibility to change the way the internal software works.
@thunderdanp Issues are handled here on GitHub. The linked discussion is about an unsupported platform.
@Poeschl That I agree on, I see your point, however, there are other concerns as well. Which is part of this change in the first place. At this point, I'm not aware how to make both ways work.
Just an idea:
Would it be possible to map the devices in /dev separately instead of the the whole /dev folder? That way, the host devices would be mounted ro like now, but the addons could create their own independent devices there.
After changes in supervisor addons can't open tty devices, for example zigbee2mqtt addon:
Zigbee2MQTT:error 2021-02-11 17:41:58: Error: Error while opening serialport 'Error: Error: Operation not permitted, cannot open /dev/ttyAML2'
@adeepn That is a different problem than described in this issue. Please don't stack different issues. Thanks 馃憤
What about Poeschels Idea: Is that possible?
Just an idea:
Would it be possible to map the devices in
/devseparately instead of the the whole/devfolder? That way, the host devices would be mounted ro like now, but the addons could create their own independent devices there.
That sounds logical, but has other implications. For example, you plug in a Zigbee or Z-Wave stick... next you want to use it right? Nope... you have to restart the containers to get the device in.
So, doing that removes things like plug-n-play and adds a lot of overhead.
Uh, yes you are right. Haven't thought about that. Indeed PnP would be lost with it.
Since I compile the software inside the addon myself, I will now patch the file paths from /dev to /tmp before building it. That will solve my problem, but leaving a fishy smell since altering a fixed version.
Thanks for your time @frenck
Whatever the choice made in this department, something need to adjust/patching for either method. I think that passing in all devices as purely as possible has the biggest benefit and support for anything (except for the case where virtual devices are made, as is sketched right here).
Your welcome, @Poeschl, thanks for the discussion 馃憤
Most helpful comment
Just an idea:
Would it be possible to map the devices in
/devseparately instead of the the whole/devfolder? That way, the host devices would be mounted ro like now, but the addons could create their own independent devices there.