And then we have a new issue (hassio_dns can’t ping):
bash-4.3# docker exec -it homeassistant cat /etc/resolv.conf
search local.hass.io
nameserver 172.30.32.3
bash-4.3# docker exec -it hassio_dns ip a s eth0
84: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:1e:20:03 brd ff:ff:ff:ff:ff:ff
inet 172.30.32.3/23 brd 172.30.33.255 scope global eth0
valid_lft forever preferred_lft forever
bash-4.3# docker exec -it hassio_dns ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
So I run the fix from the second bullet of the second message in this thread (recreating the hassio network). It works:
bash-4.3# docker exec -it hassio_dns ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=6.226 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 6.226/6.226/6.226 ms
No it doesn’t work (note the changed IP address):
bash-4.3# docker exec -it hassio_dns ip a s eth0
101: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:1e:20:05 brd ff:ff:ff:ff:ff:ff
inet 172.30.32.5/23 brd 172.30.33.255 scope global eth0
valid_lft forever preferred_lft forever
failed to resize tty, using default size
So now the homeassistant container can’t find the DNS server as it’s IP address changed.
When I restart the packages, hassio_dns does get back the proper IP address (*.3), yeah. But then ping fails again and we’re back to square zero.
I feel like you know way more than me about networking but I’ll throw this out there. I had problems with any other container but the one from https://github.com/korylprince/hassio-caddy. I am having no current issues with caddy and this hassio package. I’m using duck and letsencrypt. The only issue I had was DSM was binding to 443 and I had to get that stopped. I dont used any of the quick connect options, or the built in reverse proxy and I hacked around a bit and I’m not sure what fixed and forced DSM to let go of that port.
@fredrike Your amazing. You straight up saved me. Sorry I cant give you more than just gratitude. I have to sell my house and somebody while showing must have switched my tower on and off repeatedly killing my proxmox installation. I was able to move everthing thing over to the syno nas in a few hours and now at least we have some entertainment/automation in these dark times. Thanks so much
Just one question… What are your expectations of hassio_dns containers?
If I’m not mistaken it’s use is not resolving public Domains but rather providing internal HA domain name resolving so that in HA you can use for ex. addon_vscode for URL instead of internal docker IP address.
So to test it, you need to use internal names and check from other container inside hassio network.
Hi @BeardedConti, hassio_dns serves as a DNS forwarder for the homeassistant container. Homeassistant needs to resolve external domain names for services like weather information.
I think the network issues I’m facing have more to do on how hass.io is setup in combination with Synology is working. So I’ll take a deep dive into hass.io and report back.
Hmm, not sure, because homeassistant is in host network, isn’t it? So any requests there for weather would be done by your router’s DNS settings (or any way you have it).
But as I said, I may be wrong. @markruys - just look at how containers are distributed in networks:
And is this second homeassistant in container running? If yes, then this definitely will not work, especially not if you haven’t changed ports for one running in container.
You can’t have both of them running (unless you use for one bridged network with alternative ports).
Is anyone else faced issue with upgrading to 0.117?
Hassio package version is: 20200910-2
DSM 6.2.3-25426 update 2
Running on DS1815+ for long time with no issues, tried to upgrade to 0.117 but it fail, before getting the logs i tried to restart the container but it reverted back to 116.4.
I got all the errors mention above but according to the thread i can ignore them.
Hi @BeardedConti - I have some issues all of a sudden with the new version of HA 117.2 and the latest supervisor. A few days ago a new supervisor update was released and I unfortunately did the upgrade. In the beginning, it worked, but now, since this morning, the supervisor does not load anymore. and I get a notification in HA that :
Invalid config
The following integrations and platforms could not be set up:
default_config
Please check your config and logs.
I tried restarting HA both from config and also from docker - in docker, the hassio-observer does not start and does not output any error, it just does not start.
Hi @lostprophet - from the error, it looks like there is a problem with configuration file. It looks like default_config can’t be loaded.
If you look at this Default Config - Home Assistant - you’ll see that without fixing this you’ll probably not get it working.
Can you check configuration.yaml file if there is any obvious error there.
Other stuff looks ok, except hassio_observer. It should run - do you have anything in logs file from it?
Hi, thank you for answering. Unfortunately I cannot start it - it starts for a second or two and dies. No logs are generated.
The config file is the same as yesterday - I have not edited anything since a couple of days - I have looked and it’s untouched. This happened all of a sudden - yesterday evening was working, today not. I have no clue as to what is going on.
I finally migrated to a virtual vmdk image running on NAS - given 50GB as storage, 2 cpu’s and 2 gigs of RAM - all integrated - no more separate docker images - and running smooth (for now ) - hope it lasts
I’m facing the same problem.
I thought because the problem is declared on August 2019 it has been already solved, but it’s not the case.
What solution do we have there ?
Thank you.
Just a quick reply to thank for the work that has been put into this package.
Installed it yesterday and without all too much troubles I had Home Assistant running.
Few quirks I ran into:
After the first boot in the setup, it was unable to save the information. Rebooting the package and refreshing the HA page showed that it actually did save some settings but in the log it showed errors that setup was not ready. Didn’t matter to me because I restored the package from my original HA instance.
I had to install the USB drivers from http://www.jadahl.com/ to be able to use some of my USB connected devices.
Thank you for the reply.
I’m pretty new to Hass.io and HomeAssistant, maybe this is the wrong topic but I still think it is.
I have installed hass.io on my Synology DSM using fredrike’s package. This is running fine.
I’m also running add-ons.
My question is: How are the add-on containers started in this specific setup on the Synology DSM?
Can I influence this, specifically map docker volumes (-v)?
Is the way add-on containers are run specific to this Synology installation, or is this some general supervisor stuff?
The only thing that pops on my mind is problem with configuration… That should automatically stop restart so you could fix it.
I did have that problem once, restarted using Docker and after that never seen it and I couldn’t recreate it.
My guess here only - network problem? Could traffic be blocked on firewall?
That is related to two problems with connection - one to met.no other to home-assistant.io
Can you try to restart HA one more time?
Do you maybe use PiHole or AdGuard?
I have no clue as to what is going on.
) - hope it lasts