TLS error on 11 of 13 docker installs (SOLVED)

General
1

I was getting 13 students to install docker on a variety of laptops (mixture of Windows and Mac). Of the 13 only 2 installs worked. The other 11 installs, docker installed fine, but after installation and running the ‘docker quickstart terminal’ we got the error “Are you trying to connect to a TLS-enabled daemon without TLS?” Even just doing ‘docker version’ gives the TLS error.

We did a lot of google to try and trouble shoot the problem, but most of the help was linux based. It seemed to me that there was a connection problem between the docker command line and VirtualBox. We tried uninstalling and re-installing. Tried using older versions of VirtualBox to no avail. Double checked that virtualization was enabled in the BIOS. Is there any reference on helping to debug the problem?

My plan is to double check the docker environmental variables (set by docker-machine env default). Check to make sure the virtual machine is running in VirtualBox and check its output. Any help would be appreciated. Thanks.

2

Usually when you get the TLS error, it’s because the TLS library gets a connection refused because it isn’t configured to connect to the remote docker daemon. The default location to connect to is /var/run/docker.sock. Since my OSX host doesn’t have a docker daemon listening at /var/run/docker.sock, I get the following error:

 docker version
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:      darwin/amd64
Get http:///var/run/docker.sock/v1.20/version: dial unix /var/run/docker.sock: no such file or directory.
* Are you trying to connect to a TLS-enabled daemon without TLS?
* Is your docker daemon up and running?

The real error message is dial unix /var/run/docker.sock: no such file or directory.

Once I configure my environment with docker-machine env default I can connect again:

$ eval "$(docker-machine env dev)"
$ docker version
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:      darwin/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

There are other errors that can happen as well. Things to check:

  • what happens if you open the virtualbox UI and start the VM manually? There could be output in the VM’s framebuffer that doesn’t show up somewhere else. Having hardware virtualization disabled in the host’s bios can cause errors at this level. Having a 32-bit system can do the same thing.
  • what happens if you type docker-machine env default, or docker-machine env --shell=cmd default on windows?
  • Can you docker-machine ssh default to gain shell access to the machine? Does the docker CLI work from there?
  • Does your host machine have a VPN running, or some other non-default firewall or network configuration? Sometimes you can docker-machine ssh since it uses the virtualbox NAT port forwarding, but can’t access the VM over its host-only network IP address due to a network route conflict.

Hopefully this helps,

/Jeff

3

On one system the docker-machine ssh default worked and we were able to use docker image from there. I am running a VNC server and a webserver, so I worry about port forwarding but should work.

4

I think I figured it out. Most of the students had virtualization disabled in their BIOS, but installed Docker first. Then after enabling virtualization, the created docker default machine was bogus. I found that we needed to make sure that VirtualBox allowed us to create 64bit images. If that was working, I found it was best to delete the default machine in VirtualBox and allow docker to create a new one.

I am happy to say that I have at least 13 working docker installs right now.