mDNS name changed with 4.13 OS update

I updated the OS 4.13 on my Pi 4 about 6 hours ago.

Since then all of the sensor devices that were reporting data via MQTT can not connect to the mosquitto server. Those I checked are reporting rc=2 (Connection Refused: Identifier rejected)
The connection and all the devices were working properly before the update.

I can still send commands to devices that listen to MQTT and respond.
I restored backups from before the upgrade, but it does not restore the older OS version.
Please advise what to check or do.

I just checked the assesscontrollist is unchanged. The user still has permissions.

The Supervisor -> Host System -> Hostname is still “hassio”.
But my devices trying to connecting to “hassio.local” no longer connect.

What has to change to put this back like it was?

semi solved:
Conclusion from above: mDNS is not working correctly…

avahi-browse -alr

and find that on mDNS the system is now “hassio-2”

How do I set it back to “hassio”???

Since I have seen nothing here about how to repair this, I decided to blow the system away ad restore it from a backup.
When I mounted the SD on my laptop to re-write it, the volumes on the card were opened in file browser windows. As usual, there were partitions for hassos-data and hassos-overlay.
There was mounts for hassos-kernel and hassos-kernel1… I guess a new kernel with the 4.13 upgrade.

But instead of a single “disk” being mounted, there were two. disk and disk1.

Is it possible this is way my hassio.local has become hassio-2.local?

I didn’t hear anything better from the community, so I reloaded my system.
I re-flashed the SD card with the latest .iso (3.14) and restored from the backup I made just before the 3.14 upgrade.
My system is back and running.




Apologies if replying to your post a month later doesn’t help you directly, but in case others search for the same issue…


If you find a desktop PC browser link to http://hassio.local:8123/ stops working, but http://hassio-2.local:8123/ works, login and browse to the Supervisor setting and change the Hostname from hassio to hassio ignoring that the desired value is displayed:
HASS -> Supervisor -> Host System -> Hostname


I recently noticed that after an update HASS was not available using the mDNS URL http://hassio.local:8123/ . Multicast DNS works by servers broadcasting ‘I offer a service’ out to the local network - hence the *.local domain.

Using Fedora Linux (with avahi and and avahi-tools installed - see here for more help), it was easy to see that HASS was broadcasting mDNS as hassio-2 rather than hassio.
Testing from a desktop PC showed that http://hassio-2.local:8123/ now worked, however http://hassio.local:8123/ did not.

Note - Android doesn’t support mDNS despite many Nest / Google services relying on it - use a desktop PC to test mDNS

After searching for hassio-2, I found this post. Like you, I found the Supervisor hostname displayed as ‘hassio’ - HOWEVER after changing it to something else and back to ‘hassio’ the mDNS name changed back and http://hassio.local:8123/ started working again.

If you have a Linux machine with Avahi installed:

$ avahi-browse -al
+   eno1 IPv6 hassio                                        _ssh._tcp            local
+   eno1 IPv4 hassio                                        _ssh._tcp            local
+   eno1 IPv6 hassio                                        _sftp-ssh._tcp       local
+   eno1 IPv4 hassio                                        _sftp-ssh._tcp       local
1 Like

Thanks for your reply.
My system became “hassio-2” again with the last update and your post reminded me how to fix it!


Again to help the community search for the fix, I had to re-install HASS on a RPi4 and found the default hostname had changed from http://hassio.local:8123/ to http://homeassistant.local:8123/.

Sadly, this bug still exists - after an update, mDNS couldn’t find my install, however avahi-browse -ar quickly found http://homeassistant-2.local:8123/.

The fix is the same - change the hostname to something else, then immediately change it back to remove the -2 unwanted suffix.


I’ve had that problem for quite a while myself - I often have occurrences of “-2”, “-3” and even “-6” being added at the end of the hostname.

My workaround is to SSH to the host and run sudo service avahi-daemon restart

I sometimes run service avahi-daemon status before and after that previous command to see what hostname it was set to, and then visually check it’s been fixed.

Thanks, that makes sense. I’ll try it next time.

The hostname’s extension is still incrementing for me… I’ve seen it go up to “-26” using the command journalctl -u avahi-daemon
It’s getting really annoying to constantly restart the service. And out of principle I don’t want to set a cron to work around a bug.

I did some digging and the problem is quite widespread, as per this GitHub issue: Spurious name conflicts #117

Based on this, I will try some other workarounds like disabling ipv6 (use-ipv6=no) or force the interface (allow-interfaces=eth0) in the file /etc/avahi/avahi-daemon.conf

The last comments from the maintainer are from just over a month ago so I’m hopeful a fix might hit us soon…

Not sure if my attempts for a workaround are going to fix it.

Using the command journalctl -u avahi-daemon -f to follow the logs, I notice that I consistently get the following warning when I restart the service:

*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***

I do not think any of the Docker containers running on my host have Avahi running though, and I definitely don’t have Plex installed. So it’s probably part of that reported issue.

Here’s a positive update:

After having added these 2 lines to /etc/avahi/avahi-daemon.conf


I can report that the .local hostname has been stable for multiple days!
This should take care of it until a new version of avahi, with a bug fix, is released.

I hope this helps.