Hassio visible in network but web gui not accessible

I also wonder what the solution was. I just restarted the system and now I cant reach it anymore. If I ping the ip it works.

Same problem here. After restart I can’t reach the home assistant via IP or host name.
But it is reachable via the remote access (nabu casa / home assistant cloud).
Any suggestions?

I appear to have a similar problem. I flashed the image for a 32-bit Raspberry Pi 4 B. Booted the Pi but the web interface is not accessible either by host name or IP (using port 8123). Chrome says the connection is refused. I can ping the Pi’s IP address from my PC. I’ve shutdown the Pi to verify I cannot ping IP, proving it is the Pi.

The image file I downloaded and used is named hassos_rpi4-3.13.img.

When I connect with keyboard/HDMI, I can login and run nmcli to verify the IP address. The date/time is also correct.

Since this is the first time I’m using Hassio, I do not know what to check next. The device is accessible on the network, but it does not appear there is a webserver running.

Also hitting this and really disappointed I can’t find a solution :frowning:

2 Likes

Also been getting this issue on my nuc for the past few weeks. Have to keep restarting and hoping it lasts.

Interestingly I noticed when it stops, it also stops writing to the log and database

If you plug it into a monitor and watch it boot, are there any errors? I have the same outcome (can ping the pi but not see the webgui) which in my case I have narrowed down to be caused by reboots leading to hard disk corruption in HassOS (I posted my issue here

Has anyone found a solution for this? I’m stuck here now as well. Are you all just running away and not ever finding a solution?

Another person with same issue.

Can PING and see the Pi on my network, but GUI doesn’t work and automation stops working too.

Only way to get it back working again is a power pull.

Before I throw it all in the bin, has anyone found a solution?

Ugh I hate this so much. Have done full reinstall and still have the same intermittent issue.

I have the exact same problem had the raspberry on for the hole night and at morning I was able to access to the GUI but after a reboot the GUI wasn’t able to access anymore. I can also ping the Pi, but cannot acces any of the GUI. I use the cable on the pi and now the pi don’t have any internet connection, but I cannot se that this is nessesary? Is there anything to do with WiFi settings?

Having the same issue…hassio on a pi4 wired with DHCP static reservation. The interesting part is that I can access HA from my phone and work laptop (both on same wifi network) but not from personal laptop also on same wifi network, both laptops with same OS.

This is the route table output from laptop that fails:

Destination        Gateway            Flags        Netif Expire
192.168.x.x       dc:a6:32:69:49:xx  UHLWIi         en0   1184

And this from laptop that works:

Destination        Gateway            Flags        Netif Expire
192.168.x.x       dc:a6:32:69:49:xx  UHLWIi         en0   1188

Also VERY interesting, nmap sees some services open but tcp/8123 appears to be a filtered port (e.g. behind a firewall) – WTH?

Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 13:16 EDT
Nmap scan report for 192.168.x.x
Host is up (0.0041s latency).

PORT     STATE    SERVICE
8123/tcp filtered polipo
MAC Address: DC:A6:32:69:49:xx (Raspberry Pi Trading)

Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 13:14 EDT
Nmap scan report for 192.168.x.x
Host is up (0.0046s latency).
Not shown: 8973 filtered ports
PORT     STATE  SERVICE
22/tcp   closed ssh
25/tcp   closed smtp
53/tcp   closed domain
80/tcp   closed http
88/tcp   closed kerberos-sec
110/tcp  closed pop3
139/tcp  open   netbios-ssn
143/tcp  closed imap
389/tcp  closed ldap
443/tcp  closed https
445/tcp  open   microsoft-ds
465/tcp  closed smtps
587/tcp  closed submission
636/tcp  closed ldapssl
993/tcp  closed imaps
995/tcp  closed pop3s
3389/tcp closed ms-wbt-server
5800/tcp closed vnc-http
5900/tcp closed vnc
6129/tcp closed unknown
MAC Address: DC:A6:32:69:49:xx (Raspberry Pi Trading)

Nmap done: 1 IP address (1 host up) scanned in 4.74 seconds

from: https://wiki.onap.org/display/DW/Nmap
Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed.

Clearly layers 1-3 are fine so not an issue with the network itself – spent too much time troubleshooting this already. Think I’ll flash again & see if something is different.

quick update…using ssh local port forwarding through a linux system that can access HA for now.Will try a fresh build soon.

Having the same issue. Suddenly, after reboot, the device simply not accessible. Can ping, but not SSH and no web. Mobile app also cannot connect. Seems my only option now is to completely reinstall this thing.

HA just isn’t ready. WAY too many issues that are so elementary. There’s potential, but I’m a systems engineer and software engineer and even I find myself wasting just hours of time with it.

For me, its not an issue of money. It’s privacy and performance that are important. And I want a more universal way to connect various technologies. If I could buy a hubitat right now, I think I’d do it. This just wastes too much precious time.

1 Like

I was able to login via HDMI console with a keyboard. It now says…

[ERROR] Somethings going wrong! Jump into emergency console...

It then drops you at a console. But that’s it. I will try to check into network settings I guess…

How about asking for help first? To help we would need to know what installation method you used, hardware etc. HA is super easy to set up so there must be something you have done wrong, no offence.

Flashed to brand new sd and completely new RPI 4. Same issue. It did initially seem to start, but then if you type CORE CHECK, it says connection refused to the hassio supervisor. In other threads, they are saying the ip gets blocked? I also checked the time on the RPI, but the date is good.

I am going to try to scrap the idea of running on a PI and install again on Hyper-V - which is what I used during some initial testing. Perhaps that’s more stable.

Have you set the pi up to have a fixed IP address? Where are you typing ‘core check’? And why?

I tried core check to see if it was actually running because the web ui never would come up.

The IP is from dhcp, but it is reserved.

I just tried again a fresh install. Flashed the RPI 4 image again and tried to allow it to boot. I connected a monitor because it still never fully boots up. Can ping, but that’s it. I can type in root for login, and then it immediately says Somethings going wrong" Jump to emergency console.

When typing docker ps, there are no containers. Just an empty list.

Maybe the current version (hassos_rpi4-4.11.img) is just not working.

At the moment, I am running virtualized in Hyper-V. But it’s not a good solution because I want to connect my conbee 2. Hyper-V has no way to use the host’s USB ports when the VM is not windows based.

So… I guess I will just wait for the next release? I have now tried this on two RPI 4 machines and two different SD cards. Same outcome.

Update:
This seems to have been a DNS issue - as far as the root cause. The hassos supervisor image was never getting pulled from the repo due to a DNS resolution issue. The local DHCP server was issuing a local DNS IP, but for some reason that server was not able to provide proper name resolution.

A workaround was to hard code 1.1.1.1 into the /etc/resolv.conf file and then issue a restart for the hassos-supervisor service.

systemctl restart hassos-supervisor

After a short while, the image was pulled and finally the supervisor could communicate. The error message that is thrown is a bit misleading “connection refused”. In fact, it can’t connect at all because the service is not even running. So perhaps it should say something like timeout, or something a bit more useful.

FYI… there are other tips that suggest setting the system time, but that seems to be an old “fix” that does not apply in this case.

My permanent fix to this is to set the DNS (not from DHCP) so the name resolution issue does not come back.

2 Likes

Well for me it was entirely the fault of the crappy micro SD card I had. No issues for over four weeks now I’ve got a Sandisk.