Doesn’t Z2M generate a random network_key if this is left empty when you start it for the first time?
The z2m security guide says that by default it uses a known default encryption key. To generate a random key, you need to specify the value GENERATATE in the advanced.network_key parameter on the first run. After the first launch, the value of this parameter in the configuration will be replaced with a random key. Note that changing the network key requires re-pairing of all devices.
Ah yes, forgot about GENERATE even though I did have it in my config
# ...
advanced:
# Zigbee network - auto-generate new keys
pan_id: GENERATE
network_key: GENERATE
# Zigbee network - set channel to avoid interference with 2.4GHz WiFi
channel: 24
There’s a better way to do the timezone:
podman run --tz=local <whatever>
2 Likes
I’ve noticed some containers don’t react well to podman auto-updates.
I assume they either don’t get the proper signals or there’s an issue in the order the updates occur.
After my most recent update (last Saturday night) my AppDaemon and HassConf containers didn’t come up properly causing my NSPanel to be off and me losing the ability to change my HA configs from Home Assistant’s web dashboard.
Any ideas what might be going on?
Hmmm… not really. Anything in the logs?
Just a small note for anyone running Podman version >4.4? I believe: the new pasta network mode for rootless containers is a fair amount faster than the older slirp4netns with your reverse proxy. Using it with Traefik in front of my services and is a nice evolution.
1 Like
I was struggling getting my Sonof Zigbee ZBDongle-E working in a the home assistant container in rootless podman. I added the device by serial id and kept the groups from the user for the container, after adding the user to the dialout group, and I could see the device in the container, but would still get generic errors from HA when trying to setup Zigbee. I tried a bunch of things that I saw on this and many other threads, like disabling selinux and running the container as privileged and still the same issue from HA. The thing that worked with minimal permissions was setting the mode to 666 instead of 660. I couldn’t find which udev rule was causing 660 because it looked like it should’ve been 666 as a tty and usb. Either way, I created my own udev rule for this specific vendor id and product id in /etc/udev/rules.d/90-sonof-zigbee.rule :
ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="55d4", MODE="0666"
I got those values from lsusb :
Bus 001 Device 031: ID 1a86:55d4 QinHeng Electronics [unknown]
or from udevadm info /dev/ttyACM0 looking for ID_VENDOR_ID and ID_MODEL_ID.
I’ve got Bluetooth over dbus working with the following SELinux policy, haven’t seen anyone post a full policy for this, so just in case it helps anyone:
module container-dbus 1.0;
require {
type bluetooth_t;
type container_t;
type system_dbusd_t;
class dbus send_msg;
class unix_stream_socket connectto;
}
#============= bluetooth_t ==============
allow bluetooth_t container_t:dbus send_msg;
#============= container_t ==============
allow container_t bluetooth_t:dbus send_msg;
allow container_t system_dbusd_t:dbus send_msg;
allow container_t system_dbusd_t:unix_stream_socket connectto;
Install the same way as the tty file, just switch out the names.
Mounting dbus into the container may be worse than avoiding it, but definitely much better than using --privileged or --security-opt label=disabled.
Fedora also seems to suggest migrating to podman-systemd which automatically generates the .service files from a more specific DSL to allow better support from the OS (podman auto-update, etc). My file for this looks like this:
# /etc/containers/systemd/homeassistant.container or ~/.config/containers/systemd/homeassistant.container
[Unit]
Description=HomeAssistant
[Container]
# dhcp sniffing
AddCapability=CAP_NET_RAW
AutoUpdate=registry
HostName=homeassistant.local
Image=ghcr.io/home-assistant/home-assistant:stable
Network=host
Timezone=local
Volume=/mnt/media/homeassistant:/config:Z
# bluetooth mounting
Volume=/var/run/dbus/:/var/run/dbus/:ro
[Install]
WantedBy=default.target
This format still allows the [Service] section as well for the ExecStartPre commands in the first post.
Nice! Migrating to this was on my list for possible holiday break projects, but I didn’t get to it…
Thanks for this topic!
I use Raspbian so no selinux, so Bluetooth works just fine by maping /run/dbus and pass --userns=keep-id to podman run.
If it can help, to be able to use DHCP discovery, --cap-add=CAP_NET_RAW,CAP_NET_BIND_SERVICE has to be passed in the podman run arguments.
In fact the only remaining point for me is the unclean shutdown which logs database warning when Home Assistant starts.
If someone found a solution, all could be perfect in my case. I don’t ses what could be different between docker stop and podman stop…
Hi! Sorry to interrupt in the midle of the thread… I’ve been trying to get my ZwaveJS2MQTT container to work on a rootless podman container and I get a really weird behaviour. When I start the container, I can see the permisions and access the dev like this:
podman exec zwavejs /bin/sh -c ‘stty -a -F /dev/zwave’
speed 115200 baud;stty: /dev/zwave: Not a tty
line = 0;
But after some 20 seconds the permissions get dropped and the same command gives me a ‘stty: can’t open ‘/dev/zwave’: Permission denied’
Checking the permission right after start of the container I get:
podman exec zwavejs /bin/sh -c ‘stat /dev/zwave’
File: /dev/zwave
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 5h/5d Inode: 1319 Links: 1 Device type: a6,0
Access: (0660/crw-rw----) Uid: (65534/ nobody) Gid: (65534/ nobody)
Access: 2024-04-11 10:40:16.843642310 +0200
Modify: 2024-04-11 10:40:16.843642310 +0200
Change: 2024-04-11 10:39:43.843642310 +0200
But after some 20 secs it changes on itself to:
File: /dev/zwave
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 5h/5d Inode: 1343 Links: 0 Device type: a6,0
Access: (0000/c---------) Uid: (65534/ nobody) Gid: (65534/ nobody)
Access: 2024-04-11 10:47:01.290191907 +0200
Modify: 2024-04-11 10:47:01.290191907 +0200
Change: 2024-04-11 10:47:04.845254517 +0200
I’m completely baffled by this. I assume that something inside the container is changing the permission for some reason? SELinux inside the container? Any ideas on how to mak it work?
Of course the container as root works flawlessly
Regards,
/Nacho
Hmm — no idea. It’s still working for me with thr above config.
It’s not SELinux inside the container, though, because that isn’t possible (it’s not namespaced). Also, that wouldn’t show a delay — it’d just fail.
Do you see any errors logged on the host system?
No, I don’t see much related to it in the logs, but I consistently see the change in attributes after the zWaveJS2MQTT daemon tries to open then /dev/zwave which is mapped on invocation. This is the way I’m starting the container:
podman run --name=zwavejs --cgroups=no-conmon --rm --sdnotify=conmon --replace --group-add keep-groups --userns=keep-id -it -p 192.168.1.2:8091:8091 -p 192.168.1.2:3000:3000 --device=/dev/serial/by-id/usb-0658_0200-if00:/dev/zwave:rw -e TZ=“Europe/Stockholm” -v /var/run/dbus:/var/run/dbus:ro -v /etc/timezone:/etc/timezone:ro -v /etc/zwavejs:/usr/src/app/store --label io.containers.autoupdate=registry docker.io/zwavejs/zwave-js-ui:latest
and the user podman is a member of dialout group and I have /dev/ttyACM0 (which is the one the id points to) with the following attributes:
crw-rw---- 1 root dialout 166, 0 Apr 11 15:20 /dev/ttyACM0
I’m baffled by this… I have 8 other containers working flawlessly in rootless mode, but I can’t make ZWaveJS or HomeAssistant work, since they need access to USB
thanks anyway!
I found a workaround after asking on reddit. Here comes the answer:
Hmmm, maybe there is a newer podman thing here?
Hey there, I’m hoping you’re still helping folks get this working with Fedora and Podman. The following was working for me on Fedora 39:
podman run -dt --pod homeassistant --device=/dev/ttyACM0:/dev/zwave -v zwavejs2mqtt:/usr/scr/app/store --name zwavejs zwavejs/zwavejs2mqtt:latest
since updating to Fedora 41, I get a failure to open the serial port error from zwavejs.
I have run
setsebool -P container_use_devices=true
I’m not getting any selinux errors.
In order to try and get this to work, I’ve been modifying based on what you have above and:
podman run -dt --pod homeassistant --cgroups=no-conmon --sdnotify=conmon --group-add keep-groups --device=/dev/ttyACM0:/dev/zwave:rw -v zwavejs2mqtt:/usr/scr/app/store --name zwavejs zwavejs/zwavejs2mqtt:latest
I’m running as root and:
groups
root dialout
Thoughts and ideas on making this work?
1 Like
Hmmm, I’m not sure. Mine has continued working across updates.
Hey @mattdm thanks for posting this and great work. I went through the effort of moving all my services from my raspberry pi to a CentOS Stream 10 box recently, and used this to help get me unstuck as I also moved to using quadlets.
Question for you or anyone running HA in a podman container - have you had any issues with HACS integrations? What I’m seeing is that anything that tries to install a package from pip is failing. The most recent one being uptime-kuma:
ERROR (MainThread) [homeassistant.config_entries] Error occurred loading flow for integration uptime_kuma: No module named 'pyuptimekuma'
And similar for the bambu integration:
[homeassistant.setup] Setup failed for custom integration 'bambu_lab': Unable to import component: No module named 'cloudscraper'
In both cases, I can exec into the HA container and run the pip install and it’ll find the packages, so I believe the issue is that HA is not installing the packages correctly
Edit: Of course despite plenty of searching before this, I found an answer shortly after posting 
. Seems to be an issue introduced around 2024.10. I used this fix and just added Environment="PYTHONPATH=/config/deps" to my quadlet definition.
Here’s another thread with some more details and other workarounds
1 Like
FWIW, I haven’t encountered any problems. But I may have configured something in the meantime that I didn’t document.