Related
I am trying to use vscode on the containers running on a remote server, but when I use 'Attach visual studio code' function I got this:
I have docker daemon running:
I am in the 'docker' group and I am able to run docker without sudo:
I am running out of solutions here could someone help me?
#Romain
This is the print out of ps aux | grep -i vscode (I just screenshot the process of my userid):
System Info:
Ubuntu 16.04.6 LTS;
vscode version:
Version: 1.60.0-insider (Universal)
Commit: 699084fdb48460c68086b85b5c08f3d39055e772;
vscode Docker extension version:
v1.15.0
I am trying to setup minikube in a VM with ubuntu desktop 20.04 LTS installed, using docker driver.
I've followed the steps here, and also taken into consideration the limitations for the docker driver (reported here), that have to do with runtime security options. And when I try to start minikube the error I get is : Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key.
This is what I have done to have my brand new VM with minikube installed.
Install docker
Add my user to the docker group, otherwise minkube start would fail because dockerd runs as root (aka Rootless mode in docker terminology).
Install kubectl (that is not necessary, but I opted for this instead of the embedded kubectl in minikube)
Install minikube
When I start minikube, this is what I get:
ubuntuDesktop:~$ minikube start
😄 minikube v1.16.0 on Ubuntu 20.04
✨ Using the docker driver based on user configuration
👍 Starting control plane node minikube in cluster minikube
🔥 Creating docker container (CPUs=2, Memory=4500MB) ...
✋ Stopping node "minikube" ...
🛑 Powering off "minikube" via SSH ...
🔥 Deleting "minikube" in docker ...
🤦 StartHost failed, but will try again: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset051825440 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset051825440: no such file or directory
: exit status 1
🔥 Creating docker container (CPUs=2, Memory=4500MB) ...
😿 Failed to start docker container. Running "minikube delete" may fix it: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
❌ Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
😿 If the above advice does not help, please let us know:
👉 https://github.com/kubernetes/minikube/issues/new/choose
I suspect that the error has to do with the security settings issues with the docker driver, but this seems to be like a dog chasing its tail: if I don't use rootless mode in docker and I attempt to start minikube with sudo (so that docker can also start up with a privileged user), then I get this:
ubuntuDesktop:~$ sudo minikube start
[sudo] password for alberto:
😄 minikube v1.16.0 on Ubuntu 20.04
✨ Automatically selected the docker driver. Other choices: virtualbox, none
🛑 The "docker" driver should not be used with root privileges.
💡 If you are running minikube within a VM, consider using --driver=none:
📘 https://minikube.sigs.k8s.io/docs/reference/drivers/none/
❌ Exiting due to DRV_AS_ROOT: The "docker" driver should not be used with root privileges.
So, or either I am missing something or minikube doesn't work at all with docker driver, which I doubt.
Here is my environment info:
ubuntuDesktop:~$ docker version
Client:
Version: 19.03.11
API version: 1.40
Go version: go1.13.12
Git commit: dd360c7
Built: Mon Jun 8 20:23:26 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 19.03.11
API version: 1.40 (minimum version 1.12)
Go version: go1.13.12
Git commit: 77e06fd
Built: Mon Jun 8 20:24:59 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit:
docker-init:
Version: 0.18.0
GitCommit: fec3683
ubuntuDesktop:~$ minikube version
minikube version: v1.16.0
commit: 9f1e482427589ff8451c4723b6ba53bb9742fbb1-dirty
If someone has minikube working on ubuntu 20.04 and could share versions and driver, I would appreciate. with the info in minikube and docker sites I don't know what else to check to make this work.
Solution:
As I mentioned in my comment you may just need to run:
docker system prune
then:
minikube delete
and finally:
minikube start --driver=docker
This should help.
Explanation:
Although as I already mentioned in my comment, it's difficult to say what was the issue in your specific case, such situation may happen as a consequence of previous unseccessful attempt to run your Minikube instance.
It happens sometimes also when different driver is used and it is run as a VM and basically deleting such VM may help. Usually running minikube delete && minikube start is enough.
In this case, when --driver=docker is used, your Minikube instance is configured as a container in your docker runtime but apart from container itself other things like networking or storage are configured.
docker system prune command removes all unused containers, networks, images (both dangling and unreferenced), and optionally, volumes. So what we can say for sure it was one of the above.
Judging by the exact error message:
❌ Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: creating: prepare kic ssh: copying pub key: docker copy /tmp/tmpf-memory-asset544814591 into minikube:/home/docker/.ssh/authorized_keys, output: lstat /tmp/tmpf-memory-asset544814591: no such file or directory
: exit status 1
I guess it could be simply clearing some cached data that helped in your case and removing broken references to non-existing files. The above message explains quite clearly what couldn't be done, namely docker couldn't copy a public ssh key to the destination minikube:/home/docker/.ssh/authorized_keys as the source file /tmp/tmpf-memory-asset544814591, it attempted to copy it from, simply didn't exist. So it's actually very simple to say what happend but to be able to tell why it happened might require diving a bit deeper in both Docker and Minikube internals and analyze step by step how Minikube instance is provisioned when using --driver=docker.
It's a good point that you may try to analyze your docker logs but I seriously doubt that you will find there the exact reason why non-existing temporary file /tmp/tmpf-memory-asset544814591 was referenced or why it didn't exsist.
minikube start --force --driver=docker fixed it for me
The issue is that the docker driver should not be used with root privileges. And by default, the docker daemon always runs as the root user. To run the docker daemon not as root user, create a Unix group called docker and add users to it. When the Docker daemon starts, it creates a Unix socket accessible by members of the docker group.
Run the following commands to fix this issue
Create the docker group if not exist
sudo groupadd docker
Add user to the docker group
sudo usermod -aG docker [user]
To activate changes to the group
newgrp docker
start minikube cluster
minikube start
This worked for me
minikube start --driver=docker --container-runtime=containerd
if you use Linux Desktop OS with docker and minikube already installed, just run
sudo usermod -aG docker $USER
and restart your computer.
It worked for me.
I was running into the same issue when I attempted to install Minikube on an Ubuntu 20.04 system.
The "docker system prune" didn't help in my case, but I figured out the cause for my issue was that /var was mounted with the nosuid option and I had to remove that and remount /var. The minikube cluster initialization then worked.
I might be too ignorant but I didn't find that info stated as a requirement.
Restarting my mac helped me.
I was getting below error earlier:
❌ Exiting due to DRV DOCKER NOT RUNNING: Found docker, but the docker service isn't running. Try restarting the docker service.
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker
systemctl status docker
sudo systemctl start/stop docker
sudo groupadd docker
sudo usermod -aG docker user_name --- to add the user to docker group.
newgrp docker -- to activate the grp
minikube start or minikube start --driver=docker ---to start minikube
On my Raspberry Pi this problem was resolved with:
sudo usermod -aG docker $USER && newgrp docker
Try the following:
minikube delete
Then try to delete all docker images with name like k8s... and minikube:
docker rmi <container id> <container id2> <container id3>
Finally:
minikube start
On my end just a docker system prune did the job (Ubuntu).
I had a few configurations I did not want to lose on my minikube profile and it recreated the container accordinlgy and booted fine.
So before the minikube profile deletion it is something to try first.
It's worth checking to see if it's running in Docker desktop on a Mac. If it is then run the kubectl command. If that returns the commands screen then you're good to go.
I ran
choco install docker-cli
choco install docker-machine
choco install docker-compose
choco install docker-desktop
I tried to test the installation according to the documentation, but got an error.
https://docs.docker.com/get-started/#test-docker-version
# docker --version
Docker version 19.03.1, build 74b1e89
# docker version
Client: Docker Engine - Community
Version: 19.03.1
API version: 1.40
Go version: go1.12.5
Git commit: 74b1e89
Built: Thu Jul 25 21:17:08 2019
OS/Arch: windows/amd64
Experimental: false
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.40/version: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
# docker info
Client:
Debug Mode: false
Server:
ERROR: error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.40/info: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
errors pretty printing info
I looked at this question but none of the answers were useful: docker cannot start on windows
I'm using Windows 10.
Reference: https://chocolatey.org/search?q=docker
I also downloaded an ran the installer directly from Docker.com.
https://hub.docker.com/editions/community/docker-ce-desktop-windows
It only said the existing installation is up to date and exited. There is no whale icon in the system tray.
From Task Manager > Performance > CPU showing virtualization is enabled:
There are definitely different ways to install Docker on Windows using Chocolatey, and rather than repeat all of the content here, I would recommend that you take a look at this blog post from Stefan Scherer:
https://stefanscherer.github.io/how-to-install-docker-the-chocolatey-way/
He works for Docker, and he is also a long term user of Chocolatey, and hopefully this blog post will help you get underway.
To summarize though, his TL/DR:
The best experience with Docker on a Windows 10 machine is using the Docker Desktop product. Try to grab an up-to-date Windows 10 Pro machine to be all set for it and then run
choco install docker-desktop
You'll have to start the program from the start-menu (at least once) to activate and configure the daemon.
I started the Docker container:
VirtualBox:~$ sudo docker run --name rabbitmq -d -p 0.0.0.0:5672:5672 -p 0.0.0.0:15672:15672 bitnami/rabbitmq
All is well, the container is working.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
dd3d12133774 bitnami/rabbitmq:latest "/app-entrypoint.sh …" 37 minutes ago Up 37 minutes 0.0.0.0:4369->4369/tcp, 0.0.0.0:5672->5672/tcp, 0.0.0.0:15672->15672/tcp, 0.0.0.0:25672->25672/tcp sad_knuth
203500ee7f1e bitnami/rabbitmq "/app-entrypoint.sh …" 5 hours ago Up 5 hours 0.0.0.0:5672->5672/tcp, 4369/tcp, 25672/tcp, 0.0.0.0:15672->15672/tcp rabbitmq
When I use command :
docker stop 203500ee7f1e
or
docker stop rabbitmq
Nothing happens (Error):
VirtualBox:~$ docker stop rabbitmq
Error response from daemon: cannot stop container: rabbitmq: Cannot kill container 203500ee7f1eb09bf0ecb2fdaf2041f4da27990a3654bca90b808a3ec36238cf: unknown error after kill: docker-runc did not terminate sucessfully: container_linux.go:393: signaling init process caused "permission denied"
: unknown
Output Docker version
VirtualBox:~$ docker version
Client:
Version: 18.06.0-ce
API version: 1.38
Go version: go1.10.3
Git commit: 0ffa825
Built: Wed Jul 18 19:09:54 2018
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.06.0-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: 0ffa825
Built: Wed Jul 18 19:07:56 2018
OS/Arch: linux/amd64
Experimental: false
Output Docker info
VirtualBox:~$ docker info
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 2
Server Version: 18.06.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.15.0-29-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.852GiB
Name: ivanpuzyrev-VirtualBox
ID: 2LAE:PADC:VVDH:G2OW:MWUD:IRTS:CRNU:J727:DDEV:ZYBS:GTGG:SIOI
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Help Please!!! Nothing happens. Perhaps you have any ideas?
Update
Note that I have added another answer after I have found out what the root cause was in my case: Concurrent docker installations
I recommend that you check if that is the case for you, too, because if so, the other answer provides the preferred solution.
This answer helped me with docker as well:
After
sudo aa-remove-unknown
the problem was instantly gone and docker stop would work again as expected. See: aa-remove-unknown - remove unknown AppArmor profiles
Background
As far as I understand it, the problem cause is that the docker package does not install a profile for docker in the AppArmor service, so docker is categorized as 'unknown' by AppArmor. The above command removes the profile for all unknown applications, so they are no longer restricted by AppArmor.
Of course, the correct way would be to keep the profile for unknown applications and create an AppArmor profile for docker. According to the docker docs on AppArmor security profiles for Docker, "A profile for the Docker Engine daemon exists but it is not currently installed".
I'm going to disagree with everyone suggesting sudo. The docker command sends api calls to the daemon, and if you needed sudo to run the command, you would know from the failure to connect to the docker socket. The daemon itself should be running as root.
The permission error to me looks like something that could be caused by an AppArmor policy or it could just be a bug in the engine/containerd/runc. You are also running Ubuntu 18.04 which docker only recently added support, so if possible, try running a slightly older version of Ubuntu LTS, or see if one of the edge/nightly builds fixes the issue. In the short term, you may have luck restarting the docker engine (systemctl restart docker) and possibly the entire host to see if that clears up the issue.
I was having the same issue I solved it by executing a shell in the docker container using this command
docker exec -it imagebase bash then issuing kill 1 command.
Try executing these two commands:
$ sudo systemctl restart docker.socket docker.service
$ docker rm {container_id}
Note: I decided to add this answer in addition to my earlier one after I have eventually found out what the root cause was in my case. This may not always be the case, so I keep the old answer, too.
Concurrent docker installations
The issue can be caused by docker being installed through apt and snap at the same time.
In my case, I had installed docker via apt, but accidentally another install via snap happened. This can happen because, on Ubuntu, apt is configured to use snap under the hood, unless you disable it (see this answer and this question on how to prevent this). After that, the "permission denied" issues started appearing, as described in the question.
How to check
In order to check if that's the case, check the snap installs, as in this example:
$ sudo snap list | grep docker
docker 20.10.17 2285 latest/stable canonical✓ -
Here we can see that snap has installed docker 20.10.17.
Now check the apt installs, like so:
$ sudo apt list --installed | grep docker
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
docker-ce-cli/focal,now 5:20.10.21~3-0~ubuntu-focal amd64 [installed]
docker-ce-rootless-extras/focal,now 5:20.10.21~3-0~ubuntu-focal amd64 [installed,automatic]
docker-ce/focal,now 5:20.10.21~3-0~ubuntu-focal amd64 [installed]
docker-scan-plugin/focal,now 0.21.0~ubuntu-focal amd64 [installed,automatic]
Here we can see that apt has installed docker 20.10.21. This was the one that got executed, but somehow the snap install was interfering with it.
How to fix
The problem can be fixed by removing the snap install:
$ sudo snap remove docker
In my case, this command would hang. To check:
$ snap changes
ID Status Spawn Ready Summary
6 Doing today at 15:19 CET - Remove "docker" snap
The status should be 'Done'. If it stays 'Doing', you can abort it via
$ sudo snap abort 6
where 6 is the number from the ID column of the previous command output.
Then, try removing it forcely (should always work):
$ sudo snap remove --purge docker
Finally, I recommend to reboot and check again, but after the snap installation has been removed, Docker should usually instantly be back to working as expected.
You may prefer to keep the snap installation rather than the apt installation, which may work equally well, but I haven't tried it.
It is possible this was cause by Ubuntu's security and in particular apparmor
In that case, you should have added to the docker run the --security-opt apparmor:unconfined. This seems preferable to removing apparmor.
e.g. try:
docker run --security-opt apparmor:unconfined -ti ubuntu bash
then try to docker stop and see it works!
If this does not work, or if you want to stop an already running container, consider killing with -9 the root process from inside the container.
I have had a similar issue with the mssql container. mssql server drops its priviledges and so docker stop fails. However, to solve this, one has to explicitly elevate the priviledges inside the container usin e.g. -u 0 priviledges:
docker exec -u 0 -it mssql ps aux
check the outputm in my case it was:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mssql 1 0.4 0.0 61108 18380 ? Ssl 16:55 0:00 /opt/mssql/bin/sqlservr
mssql 9 8.4 1.5 16865624 1014056 ? Sl 16:55 0:04 /opt/mssql/bin/sqlservr
root 267 0.0 0.0 5896 2848 pts/0 R+ 16:56 0:00 ps aux
so, I needed to kill (with -9) processes 1 and 9 inside the container...
docker exec -u 0 -it mssql kill -9 1 9
note here that when running mssql i gave the container the name mssql...
in your case it would have been rabbitmq
After installing docker with snap on Debian GNU/Linux 10 (buster) I had the same issue. After removing the snap docker version and installing docker according to https://docs.docker.com/engine/install/debian/#install-using-the-repository
and
https://docs.docker.com/engine/install/linux-postinstall/ up to Configure Docker to start on boot with $ sudo systemctl enable docker
and a reboot, the $ docker stop name-of-container worked.
Try to reload daemon and restart the docker, then remove all your containers.
On Linux:
$sudo systemctl daemon-reload
$sudo systemctl restart docker
$docker ps –qa|xargs docker rm
On Win.10:
$docker stop $(docker ps -a -q)
$docker ps -qa|xargs docker rm
Try as superuser:
sudo docker container stop rabbitmq
Try killing it:
sudo docker kill rabbitmq
This will force the stop but will not remove the container.
You need to tell rabbitmq to quit, by using rabbitmqctl so:
docker exec rmq rabbitmqctl stop
(swap rmq for your containers name)
Once the process has safely stopped the docker container should shutdown.
Since you ran the docker as 'sudo', you have to stop it with the 'sudo' privileges
To stop the container
sudo docker stop 203500ee7f1e
To remove the container
sudo docker rm 203500ee7f1e
If you want to stop and remove all the containers, the below command will be useful
sudo docker stop $(docker ps -a -q) && sudo docker rm $(docker ps -a -q)
I've installed Docker toolbox now and I get the error for everything:
Get http://127.0.0.1:2375/v1.20/version: dial tcp 127.0.0.1:2375: ConnectExtcp: No connection could be made because the target machine actively refused it..
* Are you trying to connect to a TLS-enabled daemon without TLS?
* Is your docker daemon up and running?
docker version output:
Client:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:49:29 UTC 2015
OS/Arch: windows/amd64
Get http://127.0.0.1:2375/v1.20/version: dial tcp 127.0.0.1:2375: ConnectEx tcp: No connection could be made because the target machine actively refused it..
* Are you trying to connect to a TLS-enabled daemon without TLS?
* Is your docker daemon up and running?
But the VM is running under VirtualBox. I have searched everywhere but can't find a solution.
UPDATE1: I'm using Windows 8.1 and also tried to start through Kinematic also.
UPDATE2: Everything worked like charm when I tried Virtualbox Test Build 5.0.3 or later. You can download here: https://www.virtualbox.org/wiki/Testbuilds
Just run:
"C:\Program Files\Docker Toolbox\docker-machine" ls
get the machine name, and then run:
"C:\Program Files\Docker Toolbox\docker-machine" env <MACHINE_NAME_HERE> --shell=[cmd|powershell]
and you should get something like this:
"C:\Program Files\Docker Toolbox\docker-machine" env default --shell=cmd
set DOCKER_TLS_VERIFY=1
set DOCKER_HOST=tcp://192.X.X.X:2376
set DOCKER_CERT_PATH=C:\Users\X\.docker\machine\machines\default
set DOCKER_MACHINE_NAME=default
# Run this command to configure your shell:
# copy and paste the above values into your command prompt
I also get an error open C:\Users\X\.docker\machine\machines\default\server.pem: The system cannot find the file specified.
and solved it by upgrading my VirtualBox to version 5.0.3 (from their nightly builds)
Long version:
I got the same problem and after and the "Using Docker from Windows Command Line Prompt (cmd.exe)" section from the installation manual put me in the right direction
Basically, the way docker works is that the "docker " commands are passed to a docker service (running on port 2375). As you are running the docker from windows host, the service actually runs on the linux host created by docker (you can see it by opening the virtualbox ui).
The usual flow is the following:
default machine is created
the starter (kinamatic / "Docker Quickstart Terminal" / cmd) of the machine waits for the machine to boot, gets it's IP address and sets the linux ip:port as the service address (instead of 127.0.0.1:2375) in few enviremnt/powershell variables
from this point all docker ... commands are send to the linux host and everything works almost as native linux
The problem is that there is some issue with the machine setup (my guess the new virtual box but I am not sure and have the time to dig into it). You can see that by runnung the ls command and notice that (at least in my case) the state of the machine is "timeout" and there is no url, unlike the output shown in the manual.
This causes the enviorment values not to be set and the docker ... commands to fail.
Apart from running the command, you can also start the Docker Quickstart Terminal that does the same thing but with sh shell
Regarding the certificate error, I tried to regenrate the certificates from within the virtual machine using:
/usr/local/bin/generate_cert --overwrite --host=default,127.0.0.1,10.0.2.15,192.168.99.100 --ca=/var/lib/boot2docker/tls/ca.pem --ca-key=/var/lib/boot2docker/tls/cakey.pem --cert=/var/lib/boot2docker/tls/server.pem --key=/var/lib/boot2docker/tls/serverkey.pem
I got "protocol error"s when tried to copy the certificate to the host machine, which reminded me an old virtualbox shared folders bug, so this may not be a problem with docker but with virtualbox - I upgraded to the latest nightly version (5.0.3-102224), regenerated the default image and that seems to solve it. As windows 10 is not officially supported yet neither by docker nor by virtualbox, I am not sure if this is the same thing that causes you to get the certificate error, In any case can try to copy the certificates from the virtual machine (you have the paths in code block) to your local user directory (it is mapped to /c/Users/X/ in the virtual machine)
The following worked for me (Docker Toolbox 1.8.1b and Windows 7). It is a simplified version of what #baptiste-gaillard outlined in the comments above. Short answer: Use VirtualBox 5.03 or later from the get-go.
Download VirtualBox 5.03 (nightly build at the time of this post) and extension pack.
Reboot laptop. (Clears out running VirtualBox stuff.)
Install VirtualBox 5.03 and extension pack 5.03.
Delete the default VM entirely (remove files).
Re-run Docker Quickstart Terminal shortcut to generate the default VM.
The Quickstart script seems to get along better with VirtualBox 5.03 with regards to creating the requisite TLS keys.
Had the same issue as you showed and Just fixed it a few hours ago.
All need to do is disable Hyper-V. Run a command prompt with administrator rights and run the following command:
bcdedit /set hypervisorlaunchtype off
Restart your PC, open virtualbox and delete default vm after relaunch, go back to docker quickstart terminal and put the following in command:
docker run hello-world
and you're done! Hope it solves your problem
this works for me
1) start the command line tool first and get the machine ip address by running
docker-machine ls command
2) Re-generate certs
docker-machine regenerate-certs
3) Set the evn variables manually in my case the location of certs was different
set DOCKER_TLS_VERIFY=1
set DOCKER_HOST=tcp://machine_IP:2376
set DOCKER_CERT_PATH=C:\Users\X.docker\machine\certs
set DOCKER_MACHINE_NAME=default
Now run docker version
Here is the output in my case
Client:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:49:29 UTC 2015
OS/Arch: windows/amd64
Server:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:49:29 UTC 2015
OS/Arch: linux/amd64
The Docker Toolbox (in 1.8.x) installation configure by default your Docker Daemon to use secure connection via the TLS protocol (version 1.8).
If you were using an older version of the daemon that wasn't secured that means at least two things :
- the port number changed from 2375 to 2376
- your daemon client need to present a certificat to communicate with you docker engine/server.
So the reply of sandiindia indicates the environment variables that precise to the docker client the good configuration to connect to the docker server/engine:
#You're using a TLS secured daemon :
set DOCKER_TLS_VERIFY=1
# Precise the Docker Host IP and port, the TLS default is 2376
set DOCKER_HOST=tcp://*<docker_host_IP>*:2376
# The paths to the certificate and client key needed to authenticate to the daemon
# You should have 3 files in this directory : ca.pem, cert.pem and key.pem
# In my case the default path looks like :
set DOCKER_CERT_PATH=C:\Users\*<username>*\.docker\machine\machines\default
#the name of your Docker Host VM :
set DOCKER_MACHINE_NAME=default
The docker documentation about TLS configuration :
https://docs.docker.com/articles/https/
I hope it helps ;)
Close the virtual machine from Virtual Box (you don't have to delete it)
Close Kitematic
Close Docker Quickstart Terminal
Now do this in-order:
Open Kitematic
Open Docker Quickstart Terminal
Its important not to open Docker Quickstart Terminal before Kitematic, as Kitematic will initialize things for Docker Quickstart Terminal
I didn't need to execute any command line..
I hope this will help some body..
I too had the same problem, but I was able to solve it without having to type anything on the command line, it just worked out of the box.
It turns out a few initialization steps were missing, as pointed out in the accepted answer above. Why wasn't the default Docker installation already doing this? I also had missing certs. So, I uninstalled everything and restarted from scratch. However, after the installation completed, this time around do not open the Docker Quick Start terminal first, open Kitematic instead to do the first initialization for you.
Kitematic created the certs for me, set the missing env variables and then I opened the Docker Quick Start terminal. I typed docker run hello-world, then docker version and this time it worked as expected, no error messages.
Note that this didn't work when I opened the Quick Start terminal first.
I'm testing Docker inside VMWare 10 instances and I was able to duplicate this problem and its solution (workaround) in every case.
I hope this helps.
I fixed my issue by simply Removing the default VM in the VirtualBox manager, rebooting PC (just in case), and then re-running Docker Quickstart Terminal. That's it.
Docker 1.8.2 and Virtual Box 5.0.4
Update to the latest virtual box above 5.0.3
Restart the system
open virtual box and remove the default virtual machine
open the docker quick start terminal
run docker run hello-world
And you are done.
Delete and remove all old v.machines on your laptop:
1. Open VirtualBox, right click on 'default', Remove, 'Delete All files'.
2. Command Prompt (Run as Admin)> docker-machine rm default
Uninstall Virtualbox, Docker toolbox and Git.
Navigate to c:\Users\Vinita, and delete dirs. .docker and .Virtualbox
CClean files and registry.
Reboot.
Cleaning is done.
I. Download latest version of Docker tools for windows (1.10.2) from Docker Toolbox
Right click on the downloaded file and 'Run as administrator'
This will install - Docker Quickstart, Kitematic and Virtualbox.
II. Download latest test build of VirtualBox (5.01.15-105696-win.exe) from
Testbuilds – Oracle VM VirtualBox . Run as Administrator again.
(You can ignore any warnings and overwrite on the already Docker-installed VirtualBox).
So far, Nothing out of the ordinary. We just installed the software with Admin rights.
Now, Control Panel>Network and Sharing Center>Change adapter settings:
Right click VirtualBox Host-Only Network #2 for Properties.
Check> VirtualBox NDIS6 Bridged Networking Driver.
(If it is already checked, uncheck and check again.)
You are done. This is the only fix that we have employed!
Both Kitematic and Docker Quickstart should work now.
Right click on Kitematic and Run as admin the first time.
Tested on Windows 10.
I encountered exactly the same error when I run docker images after a system reboot. I used docker version 1.10 on Windows 7 64 bits with virtualbox 5.0.10 and mintty(the terminal come with Git for Windows)
Executing docker-machine ls showed me the virtual machine is in Timeout state.
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default virtualbox Timeout
So I restarted the virtual machine
$ docker-machine restart default
Then list the status again told me the cert is bound to an incorrect address:
$ docker-machine ls
Unable to query docker version: Get https://192.168.56.101:2376/v1.15/version: x509: certificate is valid for 192.168.99.101, not 192.168.56.101
Then I regenerate the cert
$ docker-machine regenerate-certs default
and finally
$ eval $(docker-machine env default --shell=bash)
Then docker is working again!
With Docker 1.8.1d had the same problem, having uninstalled 1.8.1c. Eventually fixed problem by installing latest Virtual Box (5.0.18), rebooting when prompted and starting Kitematic. Kitematic fails at first and offers option to remove and re-install the VM which I did. After that my QuickStart Terminal was OK.
It sounds like the problem with virtual box,
In my case, I have performed below steps to resolve the issue
Stop Docker machine by 'docker-machine stop'
Open Network and sharing Center in Windows OS
Click on Change Adapter settings
Disable the VirtualBox-Host Only Network
Start Docker machine by 'docker-machine start'
I had the same issue with Docker Toolbox on Windows 10 Home. The steps to fix the problem from here:
run docker-machine ls to get a list, you should probably see this:
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default - virtualbox Stopped Unknown
Optional step upgrading (be patient):
docker-machine upgrade
restart the default:
docker-machine start default
don't worry if says:
Machine "default" is already running.
now you should be able to run docker version and see something like:
Client:
Version: 19.03.1
API version: 1.40
Go version: go1.12.7
Git commit: 74b1e89e8a
Built: Wed Jul 31 15:18:18 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:28:45 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683
This has happened a few times for me on Windows 10 with VirtualBox 5.0.14.
It seems to be related with not shutting down VirtualBox correctly (I believe) - for example, a power cut!
Shutdown the Docker VM
Close Kitematic
Start the Docker Quickstart Terminal
Type in the terminal:
docker-machine.exe -D ls
Start Kitematic. VM's show up now.
If that does not work, try 1-3 again and this time try to regenerate
certs. Then do step 4.
One thing that is odd, is that in the terminal docker images does not list them but says it cannot connect to 127.0.0.1:2375 (but docker-machine ls shows the default machine running on 192.168.99.100:2376).
Just recreate the default machine, and then run
docker-machine env default
It works for me.
if you are using docker for windows(beta) follow this steps:
Disable the "DockerNAT" network adapter
Run the "Reset to factory defaults" via the taskbar / docker / settings / Reset to factory defaults"
On my non-virtual machine, I got same error. Below steps worked for me
Right click docker->Under Settings->General do you have Expose daemon on tcp://localhost:2375 without TLS enabled? You need to if you want to access the daemon as described. But please do keep in mind that this setting is insecure as explained in the warning.
My issue was "...error getting IP address" Thanks to all the people here who have contributed their solutions which I read through and performed these steps:
Close Docker
Open VirtualBox Manager
Delete default VM
Start Kitematic first (I think this is important)
Start Docker