It’s probably SELinux, given those errors. Does it work with sudo setenforce 0?
If that works, try turning it back on again (sudo setenforce 1, or reboot), and then use sudo semanage boolean -m --on container_use_devices. This will allow containers to use all devices (more dangerous, obviously, but they at least do have to be mapped in first), and will persist across reboots.
If that works, we’ll figure out what’s going on with semodule.
It works when I manually do podman run.
When I do systemctl --user start container-zigbee.service it fails but because of a different issue: the only error I see in journalctl is Error: reading CIDFile: open /run/user/1001/container-zigbee.service.ctr-id: no such file or directory.
I know you set cidfile in all of the service configs, this is the first to complain.
Any reason you use this instead of the name for stop and rm?
Looks like the -f parameter of readfile is interpreted as a parameter for podman run when you use it in the .service file. However, with sudo setenforce 0 I can use the symbolic link. Even using /dev/ttyUSB0 when setenforce is set to 1 again, doesn’t fix it.
$ sudo semanage boolean -m --on container_use_devices
sudo: semanage: command not found
Looks like Fedora CoreOS may be adding some additional challenges?
@mattdm
Another thing I’d like to do is mount /run/dbus in the HA container so it gets access to my built-in Bluetooth module.
I’m getting permissions errors on that as well.
@mattdm I have written down my experiences so far in a blog post.
Most of it is based on this forum thread. I then also added ESPHome and HASSConfigurator, and my backup setup.
Sadly, I still have to run with setenforce 0 but at least Home Assistant is alive again 
When I get some cycles I’ll see if I can help you figure that out, or find someone who can. 
so I managed to switch from my current ARM server to a NUC running Fedora server edition, I got everything working thanks to @mattdm and @DezeStijn.
I had the same issue as @DezeStijn with the zigbee device, the Selinux module didn’t work, same exact error
libsemanage.semanage_pipe_data: Child process /usr/libexec/selinux/hll/mod failed with code: 1. (No such file or directory).
container-usbtty: libsemanage.semanage_pipe_data: Unable to execute /usr/libexec/selinux/hll/mod : No such file or directory
container-usbtty: (No such file or directory).
libsemanage.semanage_direct_commit: Failed to compile hll files into cil files.
(No such file or directory).
semodule: Failed!
I had to use the allow container to access all devices boolean although I did it in cockpit which gave me the command
setsebool -P container_use_devices 1
I assume it does the same thing as your semanage boolean
I was still having issues until I realised I needed to add
--group-add keep-groups \
option from your zigbee systemd unit file into my home assistant systemd unit file
I could then add my zigbee device in ZHA integration and it worked perfectly.
oddly enough in the home assistant container if I run the command
ls -la /dev/zigbee
crw-rw---- 1 nobody nobody 188, 0 Dec 5 12:35 /dev/zigbee
the device is in group nobody and owner nobody
and if I type
groups
root nobody nobody
not sure what to make of this, but it works
also weirdly enough auto discovery did work for some of my integrations but not all, I did open a few more ports on the firewall which is probably what did it.
however I still get the error message
Cannot watch for dhcp packets: [Errno 1] Operation not permitted
so obviously it shows discovery is not working fully
Ah, yeah, that totally makes sense — in my zigbee2mqtt setup, Home Assistant itself doesn’t need the access.
This is fine. Inside the container, Home Assistant is running as what appears to be root. It doesn’t know that that’s mapped to a non-root user outside the container. So the actual group doesn’t matter.
Yeah, snooping on DHCP packages requires the container to have actual root-level privileges. It would be possible to run the container that way (or possibly with just that particular capability), but for me DHCP discovery isn’t all that useful so not really worth it.
Hi all!
I have HA running in a rootless container with podman and I have managed to connect to another rootles container running ZWaveJS UI. So far so good. I am though having problems with getting tmy USB bluetooth adapter to work inside the rootles container. This is the way I am starting the container:
$podman run -d --privileged --name homeassistant --restart=unless-stopped --device=/dev/bus/usb/001/004 -v /run/dbus:/run/dbus:ro -v /etc/localtime:/etc/localtime:ro -v /etc/homeassistant.podman:/config --network=host ghcr.io/home-assistant/home-assistant:latest
As you see i’m binding both /run/dusb and the actual USB bluetooth dongle (/dev/bus/usb/001/004) but HA keeps on complaining that the bluetooth adapter is not found. I have opened a terminal in the container and bluetoothctrl bails out with the following message:
“bash-5.1# bluetoothctl
Waiting to connect to bluetoothd…dbus[418]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion “connection != NULL” failed in file dbus-connection.c line 5921.
This is normally a bug in some application using the D-Bus library.
Aborted (core dumped)”
I have checked that /run/dbus exists in the container:
bash-5.1# ls -la /run/dbus
total 4
drwxr-xr-x 2 nobody nobody 60 Jan 20 07:46 .
drwxr-xr-x 1 root root 4096 Jan 20 10:20 …
srw-rw-rw- 1 nobody nobody 0 Jan 20 07:46 system_bus_socket
and as you can see it is there even if owned by nobody.nobody… I wonder whether it is a problem of uid mappings when running the container, but I am our of ideas. Anyone that has any tips?
I forgot to add that I have SELinux completely diabled
Thanks!
/Nacho
Did you add the host user to the dialout group ? And then add
--group-add keep-groups
to the podman run command ?
Also I believe the only benefit to running as privileged is to enable auto discovery , I’m not sure if it helps at all with USB being passed through to the container
Hi!
Yes, the host user is in the dialout group (I’m using the same host use to run the ZWaveJS container in podman with access to the USB zway dongle… ). I have tried now as well with --group-add keep-groups but still the same. The --priviledged is just an attempt to test whichever flag I can feel could be relevant to see if it works… no success so far… 
Thanks for the suggestion!
New_info: It is definitely something with the DBUS access. I see this in the Podman logs:
“dbus_fast.errors.AuthError: authendbus_fast.errors.AuthError: authentication failed: REJECTED: [‘EXTERNAL’]”
Does not the access to DBUS get regulated by SELinux? But I don’t have SELinux enabled… Any DBUS guru around?
I think I read further down that you got past this, but I think this is a typo in the original post. The third line should be
$ sudo semodule -i container-usbtty.pp
I’m in the process of building out my HA environment and following this guide, so this may not solve everything, but it got rid of the error you’re seeing about no such file or directory.
Matt, you mentioned wanting to put all this into a git repo - just wondering if there was any movement down that path? Thanks for writing this up, I’m currently running through this on RHEL 9.
I just haven’t had time to work on it. I’m optimistically hoping this weekend, but I keep thinking that every week…
Hi guys,
I’m late to the game but run into this post while looking for something else. But while here, I wanted to point you to couple other things. Seems many are interested of running HA under Fedora and podman, great. And since it’s not yet in git, might be still worthwhile to make it all automated while at it. I’ve been running my containers in fedora-iot for some years using podman. Perhaps it might make sense to put this all into ansible?
I used this for my ansibles exactly for projects like this. I run this role to get them going:
I configure all my pods with such playbooks. There is newer version of that here:
So if you put stuff into git, might be worthwile ansible it while at it. Then the new user would only need to set some variables and get the whole thing going by one playbook. Here are some (old) samples
Looking at this thread, I’d probably go for running stuff in pod, might make things simpler. It’s supported also by the roles.
Anyhow, hopefully this would help new people get going with ha, podman and fedora.
Currently some recent commits to the podman-container-systmed broke it with fedora-iot, but should be rather small effort to fix it and should still work on normal fedora. I’ll put HA also under such config one day as I have time. I’ll fix it while at it.
Yeah, I think I’m going to do that. My approach is colored by some very early openshift-kubernetes training I took years ago, and in that, the instructor stressed that the best approach was one container per pod, unless the lifecycle of the two containers was completely tied together (which isn’t the case here). But that may be completely obsolete thinking.
I do like the idea of making an ansible playbook…
Tbh, I agree, I also run containers in separate pods. But just now, I was looking for how to run appdaemon. First I thought it should see the same filesystem as HA. Thus I thought I’d put them in the same pod. But now it looks like they don’t need to be, so perhaps I continue having all separated. There are benefits in both. I keep them separated so they are easily controlled one by one, independently. And some of them run on different hosts, and I can move them just by running the ansible against different host.
The plus side of one pod might be easier networking, and shared filesystem if needed. For a beginner, one pod might be easier.
At least for NSPanel-lovelace, but probably for more than that, the AppDaemon container needs to have access to /config/appdaemon inside the HA container.
I have been working on getting Bluetooth going via a similar setup to this:
The main issue I am having is getting the bluetooth integration going, and not really knowing if I am going down the right path. Has anybody got a rootless setup working with Bluetooth on Fedora?
I have seen advice to mount /var/run/dbus and also to launch the container with the --userns=keep-id flag set but have not had any success. I still get the same errors I have seen others get:
Logger: homeassistant.setup
Source: components/bluetooth/manager.py:206
First occurred: 10:24:08 PM (1 occurrences)
Last logged: 10:24:08 PM
Error during setup of component bluetooth
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 256, in _async_setup_component
result = await task
File "/usr/src/homeassistant/homeassistant/components/bluetooth/__init__.py", line 179, in async_setup
await manager.async_setup()
File "/usr/src/homeassistant/homeassistant/components/bluetooth/manager.py", line 206, in async_setup
await self._bluetooth_adapters.refresh()
File "/usr/local/lib/python3.10/site-packages/bluetooth_adapters/systems/linux.py", line 33, in refresh
await self._bluez.load()
File "/usr/local/lib/python3.10/site-packages/bluetooth_adapters/dbus.py", line 30, in load
self._packed_managed_objects = await _get_dbus_managed_objects()
File "/usr/local/lib/python3.10/site-packages/bluetooth_adapters/dbus.py", line 94, in _get_dbus_managed_objects
bus = await MessageBus(bus_type=BusType.SYSTEM).connect()
File "/usr/local/lib/python3.10/site-packages/dbus_fast/aio/message_bus.py", line 172, in __init__
super().__init__(bus_address, bus_type, ProxyObject, negotiate_unix_fd)
File "src/dbus_fast/message_bus.py", line 186, in dbus_fast.message_bus.BaseMessageBus.__init__
File "src/dbus_fast/message_bus.py", line 740, in dbus_fast.message_bus.BaseMessageBus._setup_socket
File "src/dbus_fast/message_bus.py", line 713, in dbus_fast.message_bus.BaseMessageBus._setup_socket
PermissionError: [Errno 13] Permission denied
To me the error above is cryptic because I don’t know which file/directory the “Permission denied” error is referring to. If anybody has any ideas on where to explore next I am keen to hear it, and will write it up for the community once I have it working!
I haven’t tried to get Bluetooth working. That setup makes me a little nervous though, because that’s probably a big container-break-out risk.
I’m not sure if this is helpful to your situation , I use 2 Bluetooth tags for presence detection , but rather than use the built in Bluetooth on my Intel NUC , I found it easier to have a dedicated esp32 running esphome that only detects if the Bluetooth tags are present or not and then sends the info to home assistant.
That way I have no issues with figuring out how to get Bluetooth working on the NUC with passing through to the container and esp32 are cheap and could be used for other things as well if needs be .
I suspect this will be the case. I have come far enough now that I feel I need to see it working, even if I end up going down the ESP32 path later anyway. Spent countless hours fumbling around with this already!