Error After password change

Configuration
1

I recently changed my password in the UI and ever since I’ve been getting this error show up in logs:

Login attempt or request with invalid authentication from supervisor (172.30.32.2) (Python/3.8 aiohttp/3.7.2)

Does anyone know the best route forward to get rid of this error, I’ve considered restoring from Snapshot but IIRC it remembers your password

1 Like
2

I’m getting the same error after I reinstalled the MQTT Addon and Integration. I can use the MQTT Server just fine. But every time I run this python script. I get the same error message.

3

Same here, keep getting the same error.
I tried to allow that IP range in trusted_network but doesn’t help.

homeassistant:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 172.16.0.0/16
4

I had the same issue.

Remove Mosquitto broker addon and restart home assistant. After reboot you can install the addon again. Problem solved.

5

This worked, it seems Mosquito doesn’t update the password when changed in Home Assistant.

Also had to use this method to get it to work, simply uninstalling Mosquito didn’t seem to work

  1. Remove Mosquito from the Integrations page
  2. Restart HA
  3. Uninstall Mosquito
  4. Restart HA
  5. Install Mosquito
  6. Restart Ha
  7. Add Mosquito on the Integrations page

(The restarts may be unnecessary, a force of habit…)

A word of warning if you use this Solution is that all of your MQTT devices will temporarily break as Mosquito now expects the new password.

6

Hello everyone,

I am getting the same error but the weird thing is I haven’t got Mosquito broker installed. I use ZHA.

Login attempt or request with invalid authentication from supervisor (172.30.32.2) (Python/3.8 aiohttp/3.7.2)

Any ideas what might be causing this?

7

I only have a loose understanding of this but the way I understand it is that the 172.xx.xx.x addresses are used by docker to identify different containers, when you install an add-on it gets it’s own container on docker. I don’t think that each add-on has a set IP that it always uses.

So the only troubleshooting step I can think of is uninstalling and reinstalling any add-ons you may of installed to see if this fixes it.

There’s still some sort of underlying bug that is causing internal docker containers to get banned but I couldn’t tell you what it is or how to reproduce it