cant run https://github.com/home-assistant/private-demo without error

[maxandersen]

this works outofbox on docker:

git clone https://github.com/home-assistant/private-demo
cd private-demo
docker build -t pd
docker run -P 8123:8123 pd
visit localhost:8123 and all is well 

with podman I need to do this but still fails (its also noticably slower)

git clone https://github.com/home-assistant/private-demo
cd private-demo
docker build -t --load pd
docker run -P 8123:8123 pd
2024-03-24 19:42:25.075 WARNING (MainThread) [zeroconf] Address not available when binding to ('fe80::f8d3:17ff:fe63:36c6', 5353, 0, 2), it is expected to happen on some systems
2024-03-24 19:42:25.089 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 99] Address not available, transport: <_SelectorDatagramTransport fd=21 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=21, family=AddressFamily.AF_INET6, type=SocketKind.SOCK_DGRAM, proto=0, laddr=('::', 60296, 0, 0)>
2024-03-24 19:42:25.198 ERROR (MainThread) [homeassistant.setup] Error during setup of component ssdp
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/ssdp/__init__.py", line 225, in async_setup
    await server.async_start()
  File "/usr/src/homeassistant/homeassistant/components/ssdp/__init__.py", line 751, in async_start
    await self._async_start_upnp_servers()
  File "/usr/src/homeassistant/homeassistant/components/ssdp/__init__.py", line 807, in _async_start_upnp_servers
    http_port = await _async_find_next_available_port(source)
  File "/usr/src/homeassistant/homeassistant/components/ssdp/__init__.py", line 731, in _async_find_next_available_port
    test_socket.bind(addr)
OSError: [Errno 99] Address not available
2024-03-24 19:42:25.358 ERROR (MainThread) [homeassistant.setup] Unable to set up dependencies of default_config. Setup failed for dependencies: ssdp
2024-03-24 19:42:25.358 ERROR (MainThread) [homeassistant.setup] Setup failed for default_config: (DependencyError(...), 'Could not setup dependencies: ssdp')
2024-03-24 19:42:25.650 ERROR (SyncWorker_4) [homeassistant.components.dhcp] Cannot watch for dhcp packets: [Errno 1] Operation not permitted
2024-03-24 19:42:44.626 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472744597072] Error handling message: invalid ISO 3166 formatted country for dictionary value @ data['country']. Got ''
invalid RFC 5646 formatted language for dictionary value @ data['language']. Got '' (invalid_format) max from 192.168.127.1 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36)
2024-03-24 19:42:53.057 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472744597072] Error handling message: invalid RFC 5646 formatted language for dictionary value @ data['language']. Got 'dk' (invalid_format) max from 192.168.127.1 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36)

is this some difference in network setup?

[maxandersen]

I tried run with --network=host and get less errors:

2024-03-24 19:47:55.797 ERROR (SyncWorker_2) [homeassistant.components.dhcp] Cannot watch for dhcp packets: [Errno 1] Operation not permitted

[maxandersen]

--priviliged seem to work...but still...docker on desktop does not run with --privilieged --network=host by defult does it?

[maxandersen]

note...when running with --privilged the app does actually never seem to run/work.

[edsantiago]

I've never tried private-demo, but homeassistant works fine for me (rootless) with:

$ podman run --name homeassistant \
    --privileged \
    -e TZ=MST7MDT \
    -v /home/assistant/config:/config \
    -v /run/dbus:/run/dbus:ro \
    --network=host \
    ghcr.io/home-assistant/home-assistant:stable

(Not all of those may be necessary, some may be cargocult from prior attempts to get it working)

[maxandersen]

Ok - but any idea why I need them compared to docker run? Like, is dbus access magically configured by docker ?

[edsantiago]

No idea, sorry. It's been a LOT of years since I've touched docker.

[rhatdan]

Realize that you are probably comparing rootless podman to rootful docker, so you might want to try with talking to the rootful podman.socket. Another issue would be we tend to run with less capabilties then Docker, so we might be hitting one of those.

Are you testing on Linux or Mac or Windows?

[maxandersen]

Mac and im 97% sure it's running rootful.

Had a chat with @n1hility and our current guess is that since the failures are related to network discovery protocols the nested virtualization probably gets in the way here.

[n1hility]

re dbus, thats only relevant for a linux setup, and would be required for docker as well, but is just used for bluetooth according to their docs

[n1hility]

So here is what is happening. The default network for podman disables ipv6 and home assistant fails (didnt look into if they have a setting to disable or ignore lack of ipv6). Setting network to host works as workaround, except if you do that podman won't try to expose ports through gvproxy. Normally you wouldn't need to on Linux, since there is nothing to do with --net=host, but on machine this isnt the case. I think we should consider that a bug. (update it looks like dockers host driver doesn’t honor it either so not a bug)

However, you can create a new network with ipv6 to at least get the app functioning:

podman network create --ipv6  podman-ip6
podman  run --privileged --network=podman-ip6 -p 8123:8123 pd

[n1hility]

Btw the reason that you need privileged is because this app has a feature to sniff dhcp packets,and to do that it needs raw socket support (alternative is —cap-add NET_RAW)

Keep in mind though that dhcp sniffing isn’t going to work on either Podman or Docker Desktop since you need to do that on a host level interface. My impression is they really want you to run this on a dedicated VM with bridging.

[Luap99]

Note that podman machine (well gvproxy rather) does not support ipv6 so adding ipv6 to the network is likely causing more harm as it seems like to the container it can use v6 when it really cannot for external connections.

On my HA install I used --sysctl net.ipv6.conf.all.disable_ipv6=1 to disable ipv6 addresses in the container, that made the warning go away AFAICT.

Also I run my container with --cap-drop all and do not get the DHCP warning so I am not sure what is up with that. In any case as you said network discovery won't work across the podman machine anyway so it should be safe to ignore.