-
Notifications
You must be signed in to change notification settings - Fork 2k
Error response from daemon: client is newer than server with Docker 1.9 RC3 #2147
Comments
Yeah, the UX is not great but if you want to use a RC Docker binary you need to specify to use a release candidate ISO to use e.g. |
Why this special treatment for RC? This makes it non-intuitive. |
Well, your Docker client binary is also an RC. How do you feel it should work? |
RC should automatically pick up the boot2docker.iso from RC. |
I do think we could do better about allowing |
Matching the No magic, just intuitive at least to me! |
Seeing the exact same error with Docker 1.9.0 and Machine 0.5.0:
Don't see any way to reopen the issue now. |
Did you run |
This machine was just created. Do I need to run |
@arun-gupta Most likely, to update your cache and/or in case you made the machine before the official b2d release happened. |
@nathanleclaire created the machine 30 mins ago again and still got the same error.
Upgrading the machine explicitly. Is there a mapping of b2d.iso and Client/Server API version? |
The |
|
Thanks Arun. We're going to be working on some issues around upgrade flow this iteration so hopefully it will be a little more clear in the future. |
👍 for |
+1 for docker-machine upgrade - assuming the only thing being upgraded is docker-related ;) |
👍 for |
After upgrade with Docker Toolbox, default machine was stopped but upgraded.
|
I'm on Windows 10 and saw a similar issue which strangely just disappeared on a second run. Here's what I had and the sequence of steps.
7.Checked to see that machine is created
8.All fine so far, but
9.What do I have?
10.Run the machine upgrade as suggested above and I get:
11.All fine after that. Just running the upgrade a second time seemed to work. |
@arun-gupta @nathanleclaire docker-machine upgrade [machine-name] fixed mine!!! Thanks Much. FWIW, this upgrade-sync between client & server is really a PITA. Any cycles spent on making this better will be much appreciated! |
This is not restricted to RC3 nor to docker machine. If the docker client is 1.9.x and the server is running docker 1.8.x, the error message is observed. This is very impractical in terms of managing deployments if you do not or cannot have the same docker engine version installed on all servers and all clients. I am of the opinion that this is quite a serious breakage. |
Also basically the same issue as #1839 |
|
After the manual downgrade, I then ran |
my fault ... I needed to delete the newer docker binary from my path. |
docker-machine upgrade worked for me, as well. |
Here's how I got it running after getting the same error for the 1.10.0-rc1:
|
@ctroncoso I see your point, but if I run At any rate, there's nothing Machine can do about this issue, so I suggest an issue be opened (search for existing ones first) on https:/docker/docker to share your thoughts with upstream if desired. |
@nathanleclaire sure it would, but would you trade 20 x 300 (or 600)ms for an upgrade that is guaranteed to work? Also, it would be just for the first call. Maybe a "session key" can be generated on that first call that establishes that the handshake has already been made. and used on the following without re-handshaking. I'm sure that there are security issues that this might bring up, but I'd rather have a not-so-fast fail-proof system, than one that might introduce an unsuspected load of work just because ubuntu/fedora/centos didn't update its repos on time. I see that this is an docker-engine issue but machine is taking the blame. I'll check on the issues on docker-engine. I think we've got a nice feature going here. I like it when issue talks end up in a constructive idea. Thanks for your time @nathanleclaire !!! |
The client already queries the server for version. There should be no I would believe that this approach would require deprecation of older You simply cannot have the client choking on older versions though, it's On Thu, Apr 21, 2016 at 2:47 PM, Nathan LeClaire [email protected]
|
Can you point me to where in the Docker client code this occurs? |
I don't really know Go, but I'm fairly sure that's what this does: Either way you see a pattern of querying API version all over the project. On Thu, Apr 21, 2016 at 5:25 PM, Nathan LeClaire [email protected]
|
here is my method to resolve this issue:
but there are daemon binaries generated in the directory : then i modify /etc/init.d/docker to add the directory of the dockerd to PATH with the highlighted lines DOCKERD=/home/master/github.com/docker/bundles/1.12.0-dev/binary-daemon BASE=dockerd modify these in /etc/default/$BASE (/etc/default/docker) then i restarted the service of dockerd ,it start succefully: root@master:~# docker version Server: all run happy just for reference |
Hi, can someone please help me? I am following this instructions to make a test up for playing with docker content trust In the dockerfile provided, it takes the 1.12.0 image and then creates the image , so when I run the container it does not connect to my base machine because my base machine (Linux) has 1.11.0 docker and this has 1.12.0 , so I then changed the docker file and passed the 1.11.0-dev path to it and generated the image again. This time when I ran the container with this new file, docker version is 1.11.0-dev only but API version is still 1.24 but my base Linux has API version of 1.23. How do I get rid of this? How do I reduce my container API version to 1.23 or else increase my base API version to 1.,24 so that there will no errors? P.S: I tried upgrading my base linux docker version but still API version is 1.23 only. |
@mkonakan On Ubuntu,
|
@nathanleclaire Hi, upgraded my docker engine on my base ubuntu and it has latest 1.11.1 client version and API version 1.23 , but the container I built has 1.24 API version and hence there is the issue. So, I am looking for the way how can I downgrade my API version in container or else how can I upgrade my API version on base machine from 1.23 to 1.24? |
@mkonakan Your best bet is probably to compile Docker from source, drop the binary into the relevant location, and restart the daemon. If the container you have built is using such a version of Docker it's likely that there's a line in the Dockerfile doing something similar. |
Solved. I copied the binary file from my base machine to container instead of the default file in that dockerfile which is getting the latest API version. Thanks. |
👍 |
Why is this closed? Is the latest docker client able to interface with older docker daemons? |
@megastef Not that I'm aware of, but that's an issue of the upstream project (https:/docker/docker), so I'd suggest looking for forwards compatibility issues there if you'd like to discuss. |
|
@pcgeek86 try |
For the people that find this having the same issue on Windows, use $env:DOCKER_API_VERSION=1.23 to set the environment variable. |
I was having this issue as well, with the Windows beta. Details:
|
Can this one be fixed (or perhaps worked around) by adding the |
I solved the problem thanks to @eddieajau. My docker client (DOCKER_API_VERSION=1.24) is Ubuntu linux and the docker server (DOCKER_API_VERSION=1.23) is at Carina by Rackspace BETA. Just add Thanks. |
|
Thank you @kid1412z it worked for me too as a quick fix. |
Back to the older version brew uninstall docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/ba2a4f0358395010e84346d2224378c74d76c527/Formula/docker.rb
brew pin docker |
omg. negotiating protocol versions isn't a thing that still needs to be invented. i've worked with software from the 90s that could handle this. yuck, really. |
@FlorianHeigl docker client 1.13 and higher does API version negotiation with the daemon; the minimum daemon version that it will fall back to is docker 1.12. For older daemons, the |
@eddieajau The workaround of the environment variable DOCKER_API_VERSION=1.23 doesn't work anymore. Windows:
Nas:
Does anyone have an idea? |
@manuelsalvatori that's an issue in the docker 17.09 cli; it's fixed in 17.10 (see moby/moby#35008)., not yet backported to 17.09. Be aware that docker 1.11 is end of life though, and has known vulnerabilities, among which a CVE in RunC that allows container processes to break out of the container and get access to the host (resolved in docker 1.12.6 and up, which ship with a patched RunC version https:/moby/moby/releases/tag/v1.12.6) |
Here is the version information:
Created a Docker machine:
Configured as:
docker ps
gives the following error:This is a newly created machine using the latest version of Docker CLI and Docker Machine.
The text was updated successfully, but these errors were encountered: