Unable to update - Supervisor not privileged

Rebooting the Host machine, does seem to resolve the issue for me and I guess I will have to watch for the next time I want to do an update.

I have the same issue, and a reboot seems to always fix the issue. It tends to work for some time, then falls into a non-privileged state again. (maybe after a supervisor update?)

I am running a janky setup with proxmox which likes to mess with my DNS and interfaces though so who knows what else it is messing with

Running HA Supervised on an Ubuntu 20.04. I also have this problem for a while now. Since Supervisor updates itself automatically, with every new supervisor version this error comes up. My solution is, whenever i have this “Supervisor not Priviliged” written in Supervisor System page, i ssh into Ubuntu and:

sudo docker restart hassio_supervisor

And that solves the problem until the next automatic supervisor version update. As i see, whenever there is a new version, docker does not restart the container (that’s maybe it is a new container from a new image); so you have to do that yourself. I do not know how long this solution will last but we’ll see.

Although the administrators say “There is no support for unsupported systems like ubuntu supervised etc”, and close the issues on github without solution, i find them right in a way. They never guarantee that the system will work on an environment that they do not design it for.

However, on our defense, i also have other apps on this ubuntu system for other purposes. And the system works perfectly and i am planning to resist until the last moment not to use proxmox or hassos. That is not suitable for my situation, personally. And auto-updating of supervisor every time brings new surprises and problems together with it. Once my system is stable, i would like to keep the version intact and not update it unless i really need to because of a bug or a new item. So, for me, it is very normal to keep HA version 0.99 whatever if it is working stable. But unfortunately that is not the situation now. Of course i always have the option to work with HA core without supervisor; but i need config backup-restore and some addons desperately. If there was only a way to merge these two together… Anyway, i humbly and kindly request from the administrators to make supervisor updates optional. Thanks…


Just switch from Ubuntu to Debian, which is officially supported.

Can anyone tell me, if i re-run convenience installation script, does my entire Home Assistant setup get reset, and I have to restore to a snapshot???
Or does nothing happen to the setup.

Nothing happens to setup but you don’t need to do this if you can restart the supervisor as stated above.

Thank you for the answare @keithh666
A restart of the host machine solves the problem for a while, but comes back in a few days.
Or is it something i did not understand here? :slight_smile:

It will comeback every time the supervisor is automatically updated, there is nothing you can do about this other than not use supervisor or use the official OS install.

I had this problem, I think it got triggered by using a relative path for data - needs to be full path. I was getting coredns cannot be installed at that point. subsequent reinstalls failed. I then removed all the images and supervisor container from docker, and the systemd units, and json file in /etc. Reinstalled still had supervisor unprivileged. I added the journald and overlayfs stuff in the docker config, restarted docker, still supervisor unpriveledged. rebooted as @ludeeus suggested and it came back up fine. Its essential to journalctl -f after install script exits if you want to know how its going, otherwise you are blind.

Hello, if someone have an answer it would be really nice ?

Many thanks for your help :wink:

Thank you for the tip! It is working for me.

I was struggling to understand why everything worked for a while when I rebooted

Updating and rebooting worked for me. Thanks.

Rebooting helps but why is that happen again and again? How can the supervisor “loosing” his privileges while running?

Supervisor updates itself, and after that is ‘not privileged’ anymore. Restart the host, and it is fixed. (or even just restart the supervisor container) I would like a permanent fix too, but have not found one yet. Several years without that issue, but since the upgrade to bookworm I have it again.

1 Like

This issue has become active on Github recently, possibly related to updating Debian version 12 Bookworm. I can confirm this after recently updating to this version. Running quite stable without this issue for 3 years, until the update. Any chance this can be fixed?

It’s supervised installation, you have to fix it yourself. This is the drawback of using the supervised installation, you’re the manager. I recommend asking this question on the Community Guide for supervised if you do not know how to fix it.

By not using the Home Assistant Operating System, the user is responsible for making sure that all required components are installed and maintained. Required components and their versions will change over time. Home Assistant Supervised is provided as-is as a foundation for community supported do-it-yourself solutions. We only accept bug reports for issues that have been reproduced on a freshly installed, fully updated Debian with no additional packages.

1 Like

Thank you for suggesting to post it in the Community Guide. This thread has many people reporting about this particular problem though.

I have no idea how to fix it TBH. I would like to avoid doing the installer procedure, ‘just’ to fix this issue.

According to information in the related GitHub ticket, this is most probably a false positive. However, that being the case, it’s indeed a bug in the supervisor, and should be fixed there. The error appears for me as well, the supervisor container is running privileged, yet the error appears.

So, the error message that appears is most likely false, and doesn’t provide any hints as what to check or fix. Thus, for me, as a simple user, however prudent I am, it’s impossible to fix the error. This needs developer interaction (a bug fix in the supervisor code), whether it’s a supported upstream installation method or a community-supported one. The mentioned ticket is more than half years old, without a fix.

1 Like

Ouch. I tried re-running the ‘convenience installer script’ (which is actually a deb package, not a script, weird) for this. Since I glanced over the whole ‘restart’ bit (I was thinking, how could that fix it, I didn’t think that they meant ‘restart the supervisor container’).

Reinstalling the ‘deb’ package now locked me out of the computer which which is 7h driving away in an empty house in the middle of winter :(((((

That really feels bad. It should say ‘Restarting the supervisor might fix it’.

Anyone got any news on this? It’s too bad a system that is otherwise so stable, is getting bogged down over this issue.