Can anybody tell me why Home Assistant wants to block portainer? Never hat a problem with it…
same question. seems to come with the latest supervisor update
Now I could solve it.
sudo docker stop portainer
sudo docker restart hassio_supervisor
But this is an error, isn’t it? I don’t see a reasonable sense why portainer should be a party crasher. Issue, ok. But an error?
1 Like
let the people decide if portainer is an issue or not. To be honest, this seems to me too strict.
It was running for years and now I’m not able to update anymore
4 Likes
Just read this thread…
Still I think this change misses the target, I assume that the unhealthy/unsupported info is to tell users if you don’t run HA according to official configuration you won’t get support, right?
Blocking HA from execution is another thing, you stop users from doing stuff they want to do, even if they are well aware they’re doing it at their own risk and they won’t be eligable for any kind of support.
There’s probably going to be a lot of complaints about this.
12 Likes
don’t need to remove portainer.
sudo docker stop portainer
sudo docker restart hassio_supervisor
Update HA and then you can start portainer again
(sudo docker start portainer)
21 Likes
ah, thanks for the hint
Thanks, I’ve updated my post.
1 Like
here is another workaround
4 Likes
Also, no need to reboot host,
sudo docker restart hassio_supervisor
is enough.
1 Like
…now updating. Evien with docker 20.10.5 (dont need to meet docker 20.10.17 for healthy from docs).
Clearly Portainer was the issue HA was having for this update. I will start portainer as soon as I finish my updates. Never have a problem with it.
docker container list
(my portainer image alias was agitated_johnson)
docker container stop agitated_johnson
docker container restart hassio_supervisor
(back to HA and update)
docker container restart hassio_supervisor
docker container start agitated_johnson
2 Likes
Ok, updated it again. Thought I tried that, but I might be wrong. Thank you again 
Was deprecated from the list of community addons a long time ago. Because it was a source of tons of issues in the HA repos. Where users used it to get in strange configurations and then reported issues when things didn’t work. Hence the unhealthy check.
This works, but also if we’re just going to do this anyways, why block us from using Portainer in the first place? For anyone who doesn’t know what Portainer is, they’re not even going to know how to find this thread 9 times out of 10 as the error message just says ‘Docker’. It doesn’t even say ‘Docker Orchestration Software’ to be a bit more insightful. It seems like a rushed decision by management on this one.
5 Likes
Yes, you do know I completely agree with you?
You did read my earlier post?
Whole thing doesn’t make sense, people will understand that they won’t get any support if they start making changes. Doing things this way will make some people stay away from HA.
It’s not a commercial product, no need to harden the software like this. (or are they preparing for some kind of commercial launch…?)
We should start some kind of vote for having this change revoked!
10 Likes
Sorry Nikler, I know you agree / I was agreeing with you. My comment was more to the mods instead of you so I probably shouldn’t have quoted you. Sorry about that. I 100% agree we should have a vote on revoking this.
You’re wrong, they don’t. There’s issues all the time from people with systems that tell the user they are unsupported or unhealthy who still expect support. Let alone systems that aren’t given this designation.
People assume that if something did work it should keep working, regardless of what it is or how they did it. The fact that it was never supported in the first place frequently doesn’t seem to register, its apparently always the fault of the update 
Portainer was particularly problematic. Not only did it expose so many options that could break the system, it used to be an addon the community repo and there’s still people running that addon. Which means people running it may have had no idea they were unsupported. Not to mention the software itself is now woefully out of date with no updates ever coming.
Sorry, but, again, all this seems overly strict to me too, especially for an “open source” project. We understand that one of the main goals this past couple of years has been to “dumb down” the project and/or to “Applefy it”, but this is WAY too excessive.
First of all where is it documented that “people updating to HA core 2022.9.2 and having portainer will immediately have an unhealthy installation and further on that they will not be able to update from that point on”? I was not able to find such a warning. I always had an “unsupported” installation for this reason, which I accepted, but not being able to update the software goes a long way. At least make it an option.
Secondly, having HA and various other docker containers on the same host should be a valid option for the users, especially those who have a supervised install. Because what is the point of having a supervised installation if the user cannot use the host for anything else? That’s why we opt for a supervised setup in the first place! I understand the “unsupported” state, but not being able to use the host for anything else unless I accept to have an outdated HA instance is unacceptable to my eyes.
“Inexperienced” users will: a) Either have HA OS installed and (should) not tinker further. b) Or not even know what Portainer is, how to install it out of the HA environment as mentioned above, let alone “play” with it and mess HA. Even then, the project would not be the one to be blamed but the user, doing things without any knowledge.
Anyway, all this should not justify the strict, unrelenting decision for everyone else “either have ONLY HA or have also something else but an outdated HA instance” .
7 Likes
Then I’m sorry to tell you but you made a decision based on a fundamental misunderstanding of the supervised install. As it says very clearly in the ADR:
- The operating system is dedicated to running Home Assistant Supervised.
- All system dependencies are installed according to the manual.
- No additional software, outside of the Home Assistant ecosystem, is installed.
Both supervised and HAOS are only supported as pure appliance installs. Neither was intended to be used alongside myriad other software that is not part of the Home Assistant ecosystem.
All checks and conditions that are added also come with options for advanced users to ignore them. Scroll up in this thread to see the one for this check. If you want to run this way nothing stops you, there’s a built-in option to allow that.
The checks are all added because it has come up in issues forcing developers to spend time digging into things that aren’t bugs. They are user caused from doing unsupported things. So to prevent this from happening again a check is added. Always with a way to ignore but want to make sure everyone is on the same page - “{x} is not supported”. Or in some cases “{x} is deeply problematic (i.e. unhealthy)”
I hear you and I get the part about people still expecting support.
However, wouldn’t it be better to make a habit of declining support when users ask for support for unsupported HA setups?
Perhaps adding some pop-ups everytime HA is restarted; This is an unsupported setup, please do not report tickets occurring on this system, you will not get help.
Also, the support is community driven isn’t it, there might be people willing to give support as long as it is clarified from the user what tweaks has been done?
Why not implement an option where you can disable those checks, making the above statement very clear when doing so?
1 Like