$ docker-compose up
Creating network "app_default" with the default driver
ERROR: b'failed to parse pool request for address space "LocalDefault" pool "" subpool "": could not find an available predefined network'
What is the meaning of this error, and how can I fix it?
Additional context:
$ docker-compose version
docker-compose version 1.7.1, build 6c29830
docker-py version: 1.8.1
CPython version: 3.5.1
OpenSSL version: OpenSSL 1.0.2h 3 May 2016
$ docker version
Client:
Version: 1.10.3
API version: 1.22
Go version: go1.5.3
Git commit: 20f81dd
Built: Thu Mar 10 21:49:11 2016
OS/Arch: darwin/amd64
Server:
Version: 1.11.1
API version: 1.23
Go version: go1.5.4
Git commit: 5604cbe
Built: Wed Apr 27 00:34:20 2016
OS/Arch: linux/amd64
Are you using some vpn service?
Here is a link to a possible reason:
https://github.com/docker/libnetwork/issues/779
I was having this problem. Solved by removing all docker defined networks with:
docker network rm `docker network ls -q`
Related
I see that docker containers in my host show as Running/Up , however when I try to exec , I see .
rpc error: code = 2 desc = containerd: container not found
I don't see any related processes running on ps -aef output.
Looking through the dockerd logs I see -
level=error msg="containerd: get exit status" error="containerd:
process has not exited" id=e4e5d58359 pid=bba1944c4 systemPid=5132
docker version:
Client: Version: 1.13.1 API version: 1.26 Go
version: go1.7.5 Git commit: 092cba3 Built: Wed Feb 8
06:50:14 2017 OS/Arch: linux/amd64
Server: Version: 1.13.1 API version: 1.26 (minimum version
1.12) Go version: go1.7.5 Git commit: 092cba3 Built: Wed Feb 8 06:50:14 2017 OS/Arch: linux/amd64 Experimental: false
What might be causing this behavior ? Pointers?
This issue is fixed since v17.12.
Version 18.03 is the latest supported release so you should do upgrade your docker to latest edition.
On Gentoo Linux kernel 4.12.12
added docker info and version below
docker info : https://pastebin.com/Ph9ibMna
> docker version
Client:
Version: 17.06.2-ce
API version: 1.27 (downgraded from 1.30)
Go version: go1.8.3
Git commit: cec0b72
Built: Thu Sep 28 07:14:33 2017
OS/Arch: linux/amd64
Server:
Version: 17.03.2-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.8.3
Git commit: f5ec1e2
Built: Wed Sep 13 23:43:20 2017
OS/Arch: linux/amd64
Experimental: false
command:
> docker build -t some-test .
Sending build context to Docker daemon 234.9MB
Step 1/1 : FROM golang:1.7.3 as builder
Error parsing reference: "golang:1.7.3 as builder" is not a valid repository/tag: invalid reference format
from Dockerfile:
FROM golang:1.7.3 as builder
example taken from name-your-build-stages
The issue is your client is 17.06.2-ce and server is 17.03.2-ce. Multi stage build came in 17.06 i believe, so you need that version on the server. It is the server that processes the build. The client will only send the information to the server
So upgrade your server and it will work fine
Docker daemon in minikube
When I do
docker version
I have
Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.23)
I want to use export DOCKER_API_VERSION=1.23 to downgrade docker.
But it doesn't work when I use minikube and use eval $(minikube docker-env). The client version is always 1.23
Please see the image about the comparison before and after using minikube docker daemon. The DOCKER_API_VERSION is always 1.23. But the client version is not 1.23.
I cannot reproduce the issue with the newest minikube image and the latest docker installation. I think that the cause is that you are using an old version of minikube. Could you check that?
2017-10-04 17:17:34 ⌚ ip-192-168-200-196 in ~
○ → eval $(minikube docker-env)
2017-10-04 17:17:36 ⌚ ip-192-168-200-196 in ~
○ → docker version
Client:
Version: 17.09.0-ce
API version: 1.24 (downgraded from 1.23)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:40:09 2017
OS/Arch: darwin/amd64
Server:
Version: 1.12.6
API version: 1.24 (minimum version )
Go version: go1.6.4
Git commit: 78d1802
Built: Wed Jan 11 00:23:16 2017
OS/Arch: linux/amd64
Experimental: false
2017-10-04 17:17:41 ⌚ ip-192-168-200-196 in ~
○ → minikube version
minikube version: v0.22.2
I am using the docker docs to create a swarm
https://docs.docker.com/engine/swarm/swarm-tutorial/create-swarm/
[centos#dsm-manager1 ~]$ docker swarm init --advertise-addr 10.192.10.220
Error response from daemon: --live-restore daemon configuration is incompatible with swarm mode
[centos#dsm-manager1 ~]$
The version of docker I'm using
[centos#dsm-manager1 ~]$ docker version
Client:
Version: 1.12.6
API version: 1.24
Package version: docker-common-1.12.6-11.el7.centos.x86_64
Go version: go1.7.4
Git commit: 96d83a5/1.12.6
Built: Tue Mar 7 09:23:34 2017
OS/Arch: linux/amd64
Server:
Version: 1.12.6
API version: 1.24
Package version: docker-common-1.12.6-11.el7.centos.x86_64
Go version: go1.7.4
Git commit: 96d83a5/1.12.6
Built: Tue Mar 7 09:23:34 2017
OS/Arch: linux/amd64
The doc version is 1.17,I don't know whether this matters,
I just can't find the doc about swarm mode in version 1.12
For those who can’t find /etc/docker/daemon.json try /etc/sysconfig/docker
live-restore option is there:
OPTIONS=’–selinux-enabled --log-driver=journald --live-restore’
I am trying to use docker cp to copy .class files from my host into the container. I am using the following command:
docker cp foo.class container:/path/foo.class
I am doing this when the server running inside the container is shutdown.
However, I am seeing that the foo.class isn't getting updated with my latest file and if I try to rm the file I get a
rm: cannot remove foo.class: Stale file handle
Here is my docker version (Docker for Mac):
docker version
Client:
Version: 1.13.0
API version: 1.25
Go version: go1.7.3
Git commit: 49bf474
Built: Wed Jan 18 16:20:26 2017
OS/Arch: darwin/amd64
Server:
Version: 1.13.0
API version: 1.25 (minimum version 1.12)
Go version: go1.7.3
Git commit: 49bf474
Built: Wed Jan 18 16:20:26 2017
OS/Arch: linux/amd64
Experimental: true
Anyone seen this happen?
TIA