Deploying any container results in error "starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24"
robcav862 opened this issue · 57 comments
Problem/Motivation
Deploying any container results in error "starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24"
(Why the issue was filed)
Expected behavior
Container deploys
(What you expected to happen)
Steps to reproduce
Deploy any container from the docker.io
nginxdemos/hello:latest
tutum/hello-world:latest
Same issue here, just trying to deploy a container of an image I made with a dockerfile.
I will definitely take a look, however, please note, this add-on is mainly useful/meant for debugging purposes. Running additional containers on a Home Assistant OS or Supervised system is not supported by Home Assistant.
Also having the same issue here guys.
I will definitely take a look, however, please note, this add-on is mainly useful/meant for debugging purposes. Running additional containers on a Home Assistant OS or Supervised system is not supported by Home Assistant.
This does also apply to containers installed via the add-on system. You can stop them, but can't start them again.
You can stop them, but can't start them again.
You should never do such a thing in a system with a Supervisor, so for that specific issue, it is actually good.
All my own created portainer docker containers have the same issue... weird fact, for example pihole I got that fixed by using a portainer Stack instead of the UI
Neil here from Portainer. We will take a look at this from our side.. this only seems to impact HASS users tho, so something specific to that deployment.
All my own created portainer docker containers have the same issue.
That is not a supported scenario by Home Assistant and thus out of scope for this project and issue.
Same issue here. Hassio, just installed portainer add-on and same errors
Failure
starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24
Please avoid posting "I have same issue" responses on GitHub, instead leave a 👍 on the initial issue description. Thanks 👍
Also having the same issue. Previously used with an older version of Hassio with no problem. Tried the EDGE version with the same error. Perhaps Hassio upgraded something in the new version that isn't compatible?
EDIT: I've locally installed v1.5.2 of this plugin and the error went away. Looks to be specific to v2.0 of the release.
@al3x1337 may I ask how did you install the previous release in HA ? Looks like my partial portainer snapshop is scrap and unable to restore before the upgrade. It would be useful :) Thanks!
Same issue as everyone above obviously. I don't use the Portainer addon to run containers on my HASSOS supervisor or anything. I use to to manage my docker containers on other systems. So when I tried to restart and re-pull an image to my surprise like many of you I can't start it.
@al3x1337 may I ask how did you install the previous release in HA ? Looks like my partial portainer snapshop is scrap and unable to restore before the upgrade. It would be useful :) Thanks!
https://github.com/hassio-addons/addon-portainer/releases/tag/v1.5.2
Download the source and copy the folder into Addons on Home Assistant via Samba/Vscode.
Go to Supervisor -> Add on Store -> 3 dots in top right -> Reload and you should see at the top Portainer under Local Addons
From what i can see, this v2 addon is mounting the docker socket connection as Read Only (RO).. as you can see by inspecting the mounts that Portainer uses when starting. This means Portainer is in "look, but dont touch" operating mode.. it cannot control Docker.
or if via SSH on HaaS.
That has no effect on the capabilities, the socket still allows for writing. the ro/rw applies to the file descriptor, not the socket.
Same here. Just installed and fails out of the box.
Had the same problem, however I tried pressing "Restart" instead of start and the container started. I don't know why it worked or if it will work for you, but try it.
Faced with the issue on hassos with plex container. I've workaround it by creating the plex stack instead of a singleton container, here is the compose file for deployment:
version: "2.1"
services:
plex:
image: ghcr.io/linuxserver/plex
container_name: plex
network_mode: host
environment:
- DEBIAN_FRONTEND=noninteractive
- GUID=0
- HOME=/root
- LANG=en_US.UTF-8
- LANGUAGE=en_US.UTF-8
- PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- PLEX_ARCH=arm64
- PLEX_DOWNLOAD=https://downloads.plex.tv/plex-media-server-new
- PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR=/config/Library/Application Support
- PLEX_MEDIA_SERVER_HOME=/usr/lib/plexmediaserver
- PLEX_MEDIA_SERVER_INFO_DEVICE=Docker Container (LinuxServer.io)
- PLEX_MEDIA_SERVER_INFO_VENDOR=Docker
- PLEX_MEDIA_SERVER_MAX_PLUGIN_PROCS=6
- PLEX_MEDIA_SERVER_USER=abc
- PUID=0
- TERM=xterm
- VERSION=latest
volumes:
- /mnt/data/docker/volumes/plexconfig:/config
- ds_plexscanner:/config/Library/Application Support/Plex Media Server/Scanners
- ds_photo:/mnt/photo
- ds_video:/mnt/video
- ds_surveillance:/mnt/surveillance
restart: unless-stopped
Where the ds_* volumes are nfs shares. But a root cause is still unclear for me.
Add-on version: 2.0.0
You are running the latest version of this add-on.
System: Home Assistant OS 6.2 (aarch64 / raspberrypi4-64)
Home Assistant Core: 2021.8.8
Home Assistant Supervisor: 2021.08.1
I will definitely take a look, however, please note, this add-on is mainly useful/meant for debugging purposes. Running additional containers on a Home Assistant OS or Supervised system is not supported by Home Assistant.
I mainly use Portainer on HASS to manage other hosts, even there it seems to happen. It also seems to be unable to "Recreate containers", it seems to just load indefinitely on Deploy which may be related to this issue.
OK, i have continued to investigate...
I cloned the add-on repo to my machine, and built an image from it... i then started the image with the following command: docker run -d -p 8099:8099 -v /var/run/docker.sock:/var/run/docker.sock --entrypoint /opt/portainer/portainer b26bdd27337f -p :8099 which started fine, and i can run/start/stop containers fine.. so something in the HaaS init script is causing this issue.
Frenck, i have emailed you directly if you want to triage this together with Portainer.
I will definitely take a look, however, please note, this add-on is mainly useful/meant for debugging purposes. Running additional containers on a Home Assistant OS or Supervised system is not supported by Home Assistant.
@frenck: Could you please add this statement in the readme of the plugin? I was not aware of this also ran into problems while update my OS to version 6.1 (I'm not able to run my 2 small containers anymore). The whole portainer GUI is so nice that it just screams to be used to run simple containers. :-)
Failure
starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24
....
Problem/Motivation
Deploying any container results in error "starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24"
(Why the issue was filed)
Expected behavior
Container deploys
(What you expected to happen)
Steps to reproduce
Deploy any container from the docker.io
nginxdemos/hello:latest
tutum/hello-world:latest
I will definitely take a look, however, please note, this add-on is mainly useful/meant for debugging purposes. Running additional containers on a Home Assistant OS or Supervised system is not supported by Home Assistant.
Is it possible to develop K8S add-on?
Same problem with mine. I updated today and now I can't start new containers.
Any updates on this? Super annoying that it doesn't work at all...
Is this problem only on supervised install or also on stock hass?
As mentioned by @Depechie a temporary workaround is to deploy another portainer via a stack.
All my own created portainer docker containers have the same issue... weird fact, for example pihole I got that fixed by using a portainer Stack instead of the UI
Just head towards Stacks, and use this one:
version: '2'
services:
portainer:
image: portainer/portainer-ce
ports:
- "9000:9000"
- "8000:8000"
volumes:
- portainer_data2:/data
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/docker/volumes:/var/lib/docker/volumes
volumes:
portainer_data2:The new portainer, that lives beside the other one, is available at http://homeassistant.local:9000/
Now I have some new portainer2 running that works just as needed, and I can deploy something.
Caution: Take care!
As this annoyed me way more than I thought, I cloned the version before the current one and integrated it to my Home Assistant Add-on Repository: https://github.com/MaxWinterstein/homeassistant-addons
Maybe this helps someone else too ✌️
As this annoyed me way more than I thought, I cloned the version before the current one and integrated it to my Home Assistant Add-on Repository: https://github.com/MaxWinterstein/homeassistant-addons
Maybe this helps someone else too ✌️
This is great 👍 finally someone steps up to get at least a working version available. I actually think it's time that the community should have a secondary repository with all the official Home Assistant addons that are currently broken in their latest version. I would prefer to have the option of using a repository that always had the last well known working version, since there is no way to downgrade addons.
As this annoyed me way more than I thought, I cloned the version before the current one and integrated it to my Home Assistant Add-on Repository: https://github.com/MaxWinterstein/homeassistant-addons
Maybe this helps someone else too ✌️
this is perfect. thanks for the workaround
As this annoyed me way more than I thought, I cloned the version before the current one and integrated it to my Home Assistant Add-on Repository: https://github.com/MaxWinterstein/homeassistant-addons
Maybe this helps someone else too ✌️
Yap, totally working. Thanks a lot mate 😉
Workaround
- Install SSH Addon
- Install latest portainer via SSH
docker volume create portainer_data_new
docker run -d -p 8002:8000 -p 9002:9000 --name=portainer --restart=unless-stopped -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data_new:/data portainer/portainer-ce
- Use following path for volumes
/mnt/data/supervisor/share/<your folder>
So... is this going to get fixed or just left in a broken state?
So... is this going to get fixed or just left in a broken state?
DISCLAIMER: THE FOLLOWING SOLUTION IS UNSUPPORTED AND EVEN DISCOURAGED BY THE HASS TEAM DUE TO EXTERNAL REPOS BEING USED, PLEASE CONTINUE WITH CAUTION
What I did was using the following Repository by @alexbelgium for Portainer: https://github.com/alexbelgium/hassio-addons
Simply add it via the Repository option in the Add-on Store, go to your currently broken official Portainer install and export the Settings there, install Alex's Portainer fork, go into Config and delete the Password to see the initial setup screen and import your Backup from there. Now you've got your old Settings and Login working again.
Its kind of nuts that this is just being ignored... I haven't been able to update/restart my containers in months.
Its kind of nuts that this is just being ignored... I haven't been able to update/restart my containers in months.
Its not ignored. I've been on holiday and in the hospital for surgery (can't plan for that shit) and still working my way through over a month of stuff to catch up on. My current list of GitHub issues and PR to work on/look at is (at the time of writing) 492.
As for this add-on, running custom containers IS NOT SUPPORTED by Home Assistant. This tool is never meant to be used for that either (as well, not supported).
The goal of this tool is to overview and access the docker eco system that runs your Home Assistant system; for the purpose of debugging. That goal works and isn't flawed at this point.
As also notes here on 24 Aug: #127 (comment)
Gotcha, sorry I just hadn't seen any indication here that there was a plan to fix this, almost seemed like it was being binned into "not to be fixed". In particular this comment seemed to indicate that we're all doing something that you don't want to support:
That is not a supported scenario by Home Assistant and thus out of scope for this project and issue.
Hope you have a speedy recovery from surgery 👍
indicate that we're all doing something that you don't want to support
It's not about wanting to support; It is simply not supported by the Home Assistant project.
Understood. So just to be clear -- are we expecting a fix for this or should we proceed under the assumption that it's not supported and thus may not get a fix?
It would be nice if there would an official support, since not everybody has multiple Pi's or servers.
are we expecting a fix for this or should we proceed under the assumption that it's not supported and thus may not get a fix?
At this point, the Supervisor will get more checks towards if systems are in a supported state. It is possible to the add-on will not be able to be fixed or keep fixed in the future.
Again; The goal of this add-on (why I originally made it) is debugging and development. Not running extra containers on your Home Assistant system.
It would be nice if there would an official support, since not everybody has multiple Pi's or servers.
That is not up to the add-on, but up to the Home Assistant project. Its the amount of issues in the past that made it officially unsupported from upstream.
Hey @frenck the comment about not allowing extra containers on a home assistant system, can that be detailed? As in what version of HA? Core, Supervised, OS?
Because the main problem we as users face ( the root of the cause ) is the fact that the team still allows own linux installs with manual install of Home Assistant Supervised. Small reminder, that was once pushed back by the team but allowed back after a lot of user complaints on that rule.
So even though the add-on has this small remark that it is not allowed, the tool is just so easy to use for the other containers we do install on our own Linux installs.
To be honest, I just installed it outside HA now and that works too. So the 'need' is less now, but the message is a bit mixed now.
And I get the other side too, allowing to much custom on an install has impact on what the team allows to spend time for logged issues because the environment is too large to grasp the possible bugs.
But my view, I would think HA became big because you allowed a lot a free roaming on installs.
My 2 cents...
Because the main problem we as users face ( the root of the cause ) is the fact that the team still allows own linux installs with manual install of Home Assistant Supervised.
@Depechie Yes, but without additional software.
This has been put into Architectural decision, which has been discussed, announced and approved by a lot of core developers:
https://github.com/home-assistant/architecture/blob/master/adr/0014-home-assistant-supervised.md
This architectural decision is in place for over a year now.
However, discussion on this is quite out of place for this issue.
I respect and thank Frenck for all the work he does for this community, but it appears there's not a commitment to making this add-on work like it did prior to 2.0, so I've moved to the unofficial add-on at this point. Hopefully it won't stop working at some point.
I do, and I noticed a lot of word play that I eventually interrupted as you couldn't make guarantees. Perhaps I read and I don't comprehend, but that maybe due to my own ignorance and maybe due to your usage of a word storm to avoid a yes or no answer. Maybe you see it as more complex than that.
Short answer, no it will not be supported.
Use a workaround if you want to use it. But then you are out of support in case you HA behaves strange
as you couldn't make guarantees
No, not until I've sit down and looked at it.
That's what I interrupted, so I guess I do read and even comprehend to some level. Hope you're well.
That's what I interrupted, so I guess I do read and even comprehend to some level. Hope you're well.
No, you don't.
This architectural decision is in place for over a year now.
However, discussion on this is quite out of place for this issue.
Ok, thx for pointing that out.
This was not known to me...
I guess we as users don't follow all changes as long as something works of course.
But I understand the need/reason, although I don't like it ;)
What is it you think I have misinterpreted? Please do clear it up, because I doubt I'm only one having trouble with the commentary. You have not committed to a fix (as I originally state when you asked me if 'I even read'), or even if a fix is possible because you have yet to get a chance to look at it, due to your schedule, yes?
But I understand the need/reason, although I don't like it ;)
Yeah, I understand why. But honestly, if you want that level of control, that using just plain Docker with the Home Assistant Container installation type is really a better way to go.
You have not committed to a fix
Goddammit son, I've explained above why I haven't looked at it, yet. I'm sorry, I did not choose this either. I'm not making promises, without looking, as I cannot hold up to it at that point. That is how it works. Furthermore, this is an open source project I do in my spare time; there is no schedule.
If you don't like that concept, and want promises, go somewhere else.
This add-on is being discontinued.