I also was using a Home Assistant installation on a NUC running on Ubuntu server and docker. Setup way back with the provided script at that time. Running other dockerized services as well.
Finally gave in after last Supervisor update, which bricked my setup. Not wanting to deal with the being ‘not privileged’ and having an ‘unsupported installation’ anymore, it was time to make some changes.
Migrated all to a Proxmox setup with one VM running Home Assistant with the available QCOW2 image.
On the fresh Home Assistant VM, I just loaded my latest snapshot during first onboarding step to get that going again.
Setup a second VM I did a fresh Ubuntu Server 20.04.1 install with docker (compose) containers for all other services.
Having a separate SSD available to start fresh made the migration a lot easier and less time consuming.
Mounted the old SSD (using an USB to SATA convertor) to the Ubuntu VM and copied my ‘home\user\docker’ folder with all settings for my containers and docker-compose.yml file.
Next ran docker-compose to get my other services up and running again.
Took less total time than I already invested trying to get my old setup running again after the latest Supervisor update ruined it.
Time well spent, knowing that with the next update I would probably have to do that all over again anyway.
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…
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.
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.
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.
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.
