Thanks for helping me! 
My router gives the IP address based on the RPi’s mac address. The internal IP address of the Raspberry is the same as always. I also checked the other settings: my domain points to my home IP address. The router points both ports 8123 and 443 to the internal IP address of the Raspberry.
I’m running out of ideas…
Linux firewall on your HA server?
If it is network related, a network packet capture with tshark or wireshark may give clues.
The audit2allow command can check if it is an selinux issue.
Can you tell me how to execute this test?
Is it even possible that suddenly a linux firewall pops up out of the blue, to block (almost) all communication? I never installed a firewall on hassio. Or is a firewall part of the hassio package?
The backup I restored has always worked, also after a reboot. Now suddenly I’m getting this strange behaviour. Theoretically it shouldn’t be something caused by hassio because the files and configurations were working. But nothing’s changed in the internet/router settings either.
OK, I made a few assumptions. Let’s back up a bit. What type of Hassio installation do you have?
For instance, I am currently running Hassio.in a virtual machine on Windows but will soon migrate to Hass.io on a RPI.
Some people run Hass.io on Linux.
Sorry for the confusion.
I’m running the 32-bit Hass.io image on a RPi 3B+.
I’m considering an Intel NUC with Ubuntu running Hass.io on a Virtualbox VM. But that’s something for the future.
In the next few weeks I am planning on installing Hass.io (likely 64 bit) on a RPI 3B+ I just ordered it this past weekend.
Is it possible the image on the SD card got corrupted? If you have not already tried, try another reboot. That would trigger an fsck (filesystem check) if it thinks it is needed.
Not being able to connect to the Hue bridge shouldn’t cause the UI not to load. It’s probably something else but I don’t see anything suspicious in the logs.
I don’t know the cause of your problem but I can tell you the Hass.io snapshot restore feature doesn’t work very well. It worked for me maybe one out of the five times I used it. Sometimes it would partially restore and stop, so I would need to run the restore again for the remaining Hass.io add-ons it missed.
I feel like I ran into your issue before after doing a Hass.io restore. In the end, I started from a fresh install of Hass.io and copied my \config directory over, and re-installed Hass.io add-ons manually. That was the safest way for me to get Home Assistant up and running again.
If you need to find your configs for certain Hass.io add-ons, you can open the snapshot file using an archive manager like 7-zip. Navigate through the directories and you’ll find your hass.io addon and config file there.
Is it possible the image on the SD card got corrupted? If you have not already tried, try another reboot. That would trigger an fsck (filesystem check) if it thinks it is needed.
I rebooted many times. I guess that should’ve triggered the filesystem check by now. I’m starting to believe that the files indeed are corrupted.
I don’t know the cause of your problem but I can tell you the Hass.io snapshot restore feature doesn’t work very well. It worked for me maybe one out of the five times I used it. Sometimes it would partially restore and stop, so I would need to run the restore again for the remaining Hass.io add-ons it missed.
I’ll try comparing the files on the RPI after the backup restore and the files inside the backup folder and let you know.
Okay, so, when I compare the RPi files through Samba, I’m seeing these folders:
Inside the backup file, I’m seeing these folders:
Should the a0d7b954 addon folders be inside the addon folder on the RPi?
My \addons folder is empty, though I have several Hass.io addons installed. So I guess that is normal.
You can spend hours trying to find the root cause, or you could start over with a fresh install and copy files from \config over. I really think you should start over…
Sometimes HA just dies–that happened to me yesterday. Samba share was still working (though stopped working sporadically), but SSH wasn’t, and accessing the web interface was spotty. I could access the HA site for one minute, then go offline for a long time. I was able to access the logs during the brief period it was online and saw HA was failing to communicate to everything, but didn’t find a source. So I started over again and reformatted my SD card, installed HA with the exact same configuration, sensors, Hass.io addons, custom Lovelace cards and components, and everything is working fine now. I never found the issue, but at least I have a working HA instance for now.
Some people have said that 32 bit Hassos is more stable than the 64-bit version.
what has been your experience?
I guess I’m gonna do that. I ordered an Intel NUC. I hope running Hass.io on a virtual machine will lead to a more reliable backup system, in case my files got corrupted again.
@anon34565116: I’ve tried installing the 64-bit first, but have never been able to get it working. I think that was because of the wifi settings in the network file. I ended up using the 32-bit version on eth0. That 32-bit version has always (for 6 months or so) been stable, until now. I’m not sure what advantages the 64-bit version offers. 32-bit supports up to 4GB of RAM. That’s way more than the RPi offers, so 32-bit should do fine. But, whatever you choose, now I’m recommending you to backup often and write the files to another HDD (or dropbox).
Perhaps Hassbian would be a better option.
I have a feeling HassOs is not reliable.
But with Hassbian there’s no docker environment right? Is it possible to install the addons then?
By backing up HassOS often on the VM I’ll always be able to restore it in case of a corrupted filesystem. I’m then avoiding the snapshot system of Hassio itself, which might not work as great.
Doing more research. Using an OS like Raspian and then using the Hassio installer would likely be a better choice.
I have not researched Linux options for Pi I just know Raspian is popular.
Keep me posted! 
I’m going to look into the Intel NUC with Ubuntu installed, running Hassio on a Virtualbox VM. I’ll let you know about my experience with that. A NUC is more expensive than a RPi of course, but they say it’s a hell of a lot faster also. I’m looking forward to seeing my lights turning on faster than 5 seconds after a motion detection 
I ran into this and wanted to share this. Might also be something worth trying:
If anyone is moving from RPi to a NUC using a snapshot, I advise you to delete the home-assistant_v2.db file and let hassio rebuild a fresh database after restore/transfer.
Reference: My steps to success for Hass.io on Intel NUC - #197 by Rorschach-x
Actually using NOOBS to install Raspian looks like the way to go. My SD Card should arrive today & my Pi tomorrow.
I hope this will be more stable than running HassOs in VirtualBox on a laptop. The HassOs VM images are all 64-bit. I think Raspian is 32-bit. That should help things/
Aren’t you going to install the Hassio image directly on the SD card?
I’ve a few other Raspberries with Raspbian installed (manually installing Raspbian Stretch is also very easy!). I think Raspbian is not a very good base because you’re then running Hassio on top of another OS. In case of a PC/laptop/NUC you’ll have plenty of resources left. In case of a raspberry you might waste quite a lot of resources. You’ll also need to make scripts that automatically execute the Hassio program when starting up Raspbian, or you’ll need to manually start the script every time your Raspberry reboots.
Do you have a reason choosing for Raspbian?
Installing HassOS is installing Hass.io docker containers on a base OS that currently appears to not be stable. I am currently running HassOS directly in VirtualBox. Although I am running the 64 bit version, I understand the 32-bit version has its challenges too.
I like some of the Hassio Addons. I have been a Unix administrator so Linux is not very daunting to me.
It appears the RPI group recommends NOOBS & Raspian. It there any better Linux distribution for RPI? I will not really need the bloat of a desktop environment.