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? 
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 
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.
Just wanted to report that this is happening for me as well on a completely fresh and up-to-date Debian 12 install with only Home Assistant Supervised installed. The supervisor loses its privileged status after some time (as I understand after an auto-update) and results in further updates to any addon or the supervisor itself failing with an error in the UI that it’s not privileged. I also can’t use a VM image as the host is an M1 Mac, and there’s no ARM64 VM image of Home Assistant available.
docker restart hassio_supervisor
fixes it, until Supervisor updates itself again.
That’s a workaround, not a fix unfortunately…
But as Supervised does not get much love from the dev’s, it is better then nothing.
yes, I fully agree with you.