b0m541

I am having the same problem, but even on a fresh install of hassio-supervisor! Have you solved what to do to make it work? I am wondering why it is using amd64 code... using Intel Xeon here. It HAS installed some containers, including homeassistant. So I assume that I have to use that homeassistant container in the future instead of my current HA container which is working quite well, correct?

It would be great if the yubikey could be used to unlock LUKS drives by providing a keyfile authenticate the user on various login channels, such as console login, SSH, web UI dashboard (no HTTP basic auth any more!) authenticate the user to docker containers (ssh, web proxy with U2F,..)

Summary: Fetching NZB from URL works only with internal docker container IP, not with real host IP Description: Some content management application M only send references to NZBs to the downloader as an URL so that the NZB must be fetched by the downloader itself. Imagine that the NZB URL points to NZBhydra2 as meta indexer X running in a docker container A on the same host H where SABnzb is also running in a docker container B. As a result M (running in docker container C on H) wants SABnzb in B to fetch the NZB from X in A. The containers A, B, C run in their vanilla setting as downloaded (Bridge mode), just the pathes were set properly. Container A is the linuxserver container with NZBhydra2. Container B is the binhex container with SABnzbd, OpenVPN and Privoxy. Observation: Depending on how X (NZBhydra2) is referenced in the URL, SABnzbd will be able to fetch the NZB or it will time out, and this can be verify using curl in the container terminal session What works: (1) internal IP of container A running NZBhydra / curl 172.17.0.x:5076 works What does not work (2) external IP of container A running NZBhydra, i.e. real IP of host H / curl "local IP":5076 -> connection refused (3) local DNS name of H / curl "local dns name":5076 -> Could not resolve host Thoughts: (1) should NOT work, since this IP may change and applications external to the container should always use the real IP address or DNS name of H, could be that OpenVPN treats the container-internal IPs as on the same network and not to be forwarded through the VPN tunnel? (2) should actually work, could this have to do with OpenVPN, sending traffic for IP of H through the VPN tunnel and nothing answering there? Why would it consider its won hosts real IP address to be on the internet and not on the own end of the tunnel? (3) reason: if using the binhex SABnzbd-VPN container, within the container local DNS names cannot be resolved because all DNS traffic is sent to the DNS server on the other end of the VPN tunnel My questions (decreasing priority): -How can I make (3) work? probably some proper setting for OpenVPN for name resolution? which? -Why does (2) not work and how can I make (2) work? -Why does (1) work and how can I prevent container-external processes to access container-internal IPs? Thank you for your tme and effort!