Am I trying to connect to a TLS-enabled daemon without TLS?

I'm trying to learn about Docker, but I keep getting cryptic (to me) error messages.

Possibly the simplest example of this is trying to print the version of Docker I installed:

$ sudo docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
FATA[0000] Get http:///var/run/docker.sock/v1.16/version:
    dial unix /var/run/docker.sock: no such file or directory.
    Are you trying to connect to a TLS-enabled daemon without TLS?

I've just been going through the user guide and following every step exactly, so I'm surprised that I get this message... What should I do now?

I just noticed that if I don't use sudo I don't get the error:

$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

Of course, this is not a solution as I may need to use sudo somewhere down the road...

I just found another page saying "If you're using OS X then you shouldn't use sudo." I don't know if they mean only for that example, or in general.

For me, running $(boot2docker shellinit 2> /dev/null) fixed the problem.

This runs the output of the boot2docker shellinit command (the three set -x ... lines) in your current terminal session, which lets the docker command know where to find the boot2docker virtual machine.

Adding $(boot2docker shellinit 2> /dev/null) to the bottom of your ~/.bash_profile file will make sure the docker command is configured, every time you open your terminal.

---

For people using Fish shell: boot2docker shellinit ^ /dev/null | source.

---

Note that 2> /dev/null (and the Fish equivalent ^ /dev/null) are optional. Like @pablo-fernandez suggested, this hides the Writing .. lines.

I was getting the same error on MacOS with sudo and without it.

I have solved it with:

boot2docker start
$(boot2docker shellinit)

P.S.: Thanks to Alan. I found out that this approach is recommended in their official documentation.

P.S.2: Sometimes boot2docker init can be required before running two commands (thank you Aaron).

In my case (Linux Mint 17) I did various things, and I'm not sure about which of them are totally necessary.

I included missing Ubuntu packages:

$ sudo apt-get install apparmor lxc cgroup-lite

A user was added to group docker:

$ sudo usermod -aG docker ${USER}

Started daemon (openSUSE just needs this)

$ sudo docker -d

---

Thanks\Attribution

---

Thanks Usman Ismail, because maybe it was just that last thing...

> Stupid question but have you started the docker daemon? – Usman Ismail Dec 17 '14 at 15:04

---

Thanks also to github@MichaelJCole for the solution that worked for me, because I didn't check for the daemon when I read Usman's comment.

GitHub comment:

sudo apt-get install apparmor lxc cgroup-lite
sudo apt-get  install docker.io
# If you installed docker.io first, you'll have to start it manually
sudo docker -d
sudo docker run -i -t ubuntu /bin/bash

---

Thanks to fredjean.net post for noticing the missing packages and forget about the default Ubuntu installation instructions and google about other ways

> It turns out that the cgroup-lite and the lxc packages are not installed by default on Linux Mint. Installing both then allowed me to run bash in the base image and then build and run my image.

---

Thanks to brettof86's comment about openSUSE

The underlining problem is simple – lack of permission to /var/run/docker.sock unix domain socket.

From Daemon socket option chapter of Docker Command Line reference for Docker 1.6.0:

> By default, a unix domain socket (or IPC socket) is created at > /var/run/docker.sock, requiring either root permission, or docker > group membership.

Steps necessary to grant rights to users are nicely described in Docker installation instructions for Fedora:

> Granting rights to users to use Docker
> > The docker command line tool > contacts the docker daemon process via a socket file > /var/run/docker.sock owned by root:root. Though it's recommended to > use sudo for docker commands, if users wish to avoid it, an > administrator can create a docker group, have it own > /var/run/docker.sock, and add users to this group. > > $ sudo groupadd docker
> $ sudo chown root:docker /var/run/docker.sock
> $ sudo usermod -a -G docker $USERNAME

Log out and log back in for above changes to take effect. Please note that Docker packages of some Linux distributions (Ubuntu) do already place /var/run/docker.sock in the docker group making the first two of above steps unnecessary.

In case of OS X and boot2docker the situation is different; the Docker daemon runs inside a VM so the DOCKER_HOST environment variable must be set to this VM so that the Docker client could find the Docker daemon. This is done by running $(boot2docker shellinit) in the shell.

Make sure the Docker daemon is running:

service docker start

That fixed it for me!

1. Docker calls itself a self-sufficient runtime for Linux containers. In simple terms it acts both as server and client.
2. The $ docker version command query is internal to the Docker executable and not to the daemon/service running.
3. $ docker images or $ docker ps or $ docker pull centos are commands which send queries to the docker daemon/service running.
4. Docker by default supports TLS connections to its daemon/service.
5. Only if the user you are logged in as is part of user group docker or you have used sudo before the command, e.g. $ sudo docker images, does it not require TLS connectivity.

Visit Docker documentation page Protect the Docker daemon socket.

Scroll a little to the top and find warning section for clarity.

You will need to do:

$boot2docker init
$boot2docker start

The following settings fixed the issue:

$export DOCKER_HOST=tcp://192.168.59.103:2376
$export DOCKER_CERT_PATH=/Users/{profileName}/.boot2docker/certs/boot2docker-vm
$export DOCKER_TLS_VERIFY=1

It is possible that you do not have the permission to the file yet. It happened to me after I add myself to docker group using

sudo gpasswd -a user docker

but not yet logout.

To resolve this, you can either re-login, or use sg docker "docker <subcommand> ..." before you logout.

If you are in group docker in /etc/group, you should be able to run it without typing password.

https://dingyichen.wordpress.com/2015/02/05/docker-dial-unix-varrundocker-sock-no-such-file-or-directory-are-you-trying-to-connect-to-a-tls-enabled-daemon-without-tls/

On Ubuntu after installing lxc-docker you need to add your user to the docker user group:

sudo usermod -a -G docker myusername

This is because of the socket file permissions:

srw-rw---- 1 root docker 0 Mar 20 07:43 /var/run/docker.sock

DO NOT RUN usermod WITHOUT "-a" as suggested in one of the other comments or it will wipe your additional groups setting and will just leave the "docker" group

This is what will happen:

➜  ~  id pawel
uid=1000(pawel) gid=1000(pawel) groups=1000(pawel),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),124(sambashare),998(docker)
➜  ~  usermod -G docker pawel
➜  ~  id pawel               
uid=1000(pawel) gid=1000(pawel) groups=1000(pawel),998(docker)

TLDR: This got my Python meetup group past this problem when I was running a clinic on installing docker and most of the users were on OS X:

boot2docker init
boot2docker up

run the export commands the output gives you, then

docker info

should tell you it works.

---

The Context (what brought us to the problem)

I led a clinic on installing docker and most attendees had OS X, and we ran into this problem and I overcame it on several machines. Here's the steps we followed:

First, we installed homebrew (yes, some attendees didn't have it):

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Then we got cask, which we used to install virtualbox, and then used brew to install docker and boot2docker (all required for OS X) Don't use sudo for brew.:

brew install caskroom/cask/brew-cask
brew cask install virtualbox
brew install docker
brew install boot2docker

The Solution

That was when we ran into the problem the asker here got. The following fixed it. I understand init was a one-time deal, but you'll probably have to run up every time you start docker:

boot2docker init
boot2docker up

Then when up has been run, it gives several export commands. Copy-paste and run those.

Finally docker info should tell you it's properly installed.

To Demo

The rest of the commands should demo it. (on Ubuntu linux I required sudo.)

docker run hello-world
docker run -it ubuntu bash

Then you should be on a root shell in the container:

apt-get install nano
exit

Back to your native user bash:

docker ps -l

Look for the about 12 digit hexadecimal (0-9 or a-f) identifier under "Container ID", e.g. 456789abcdef. You can then commit your change and name it some descriptive name, like descriptivename:

docker commit 456789abcdef descriptivename`

Everything that you need to run Docker on Linux Ubuntu/Mint:

sudo apt-get -y install lxc
sudo gpasswd -a ${USER} docker
newgrp docker
sudo service docker restart

Optionally, you may need to install two additional dependencies if the above doesn't work:

sudo apt-get -y install apparmor cgroup-lite
sudo service docker restart

I tried the solutions here, and boot2docker didn't work.

My solution: Uninstall boot2docker on the Mac, install a Centos 7 VM in VirtualBox, and work with Docker inside that VM.

For me the following steps worked:

1. I noticed that running docker run hello-world fails with this socked error as in the question, but running sudo docker run hello-world worked.
2. I added my current user to the docker group, sudo adduser user docker. Then you must restart your machine or use su - user (check using groups command if are in the docker group).

After that, hello-world started to work.

My answer is based on How can I use docker without sudo? which explains what go wrong.

---

For what it is worth, I tried all the solutions in this question and in this related question and none resolved my issue until I uninstalled and re-installed VirtualBox. This process upgraded the VirtualBox from version 4.2.16 to 4.3.22 (my previous one had been lying unused on the system for a few months).

Then boot2docker and docker worked without any other adjustments.

I had the same problem. A simple service docker restart solved the problem.

The Docker daemon binds to a Unix socket instead of a TCP port. By default that Unix socket is owned by the user root and other users can only access it using sudo. The Docker daemon always runs as the root user.

sudo groupadd docker
sudo usermod -aG docker $USER

Log out and log back in so that your group membership is re-evaluated.

docker run hello-world

Source: Manage Docker as a non-root user

I had the same issue and tried various things to fix this, amending the .bash_profile file, logging in and out, without any luck. In the end, restarting my machine fixed it.

Make sure there is

127.0.0.1    localhost

in your

`/etc/hosts `

file.

I faced the same issue when I was creating Docker images from Jenkins. Simply add the user to the docker group and then restart Docker services and in my case I had to restart Jenkins services.

This was the error which I got:

http:///var/run/docker.sock/v1.19/build?cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&t=59aec062a8dd8b579ee1b61b299e1d9d340a1340: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?
FATAL: Failed to build docker image from project Dockerfile
java.lang.RuntimeException: Failed to build docker image from project Dockerfile

Solution:

[root@Jenkins ssh]# groupadd docker
[root@Jenkins ssh]# gpasswd -a jenkins docker
Adding user jenkins to group docker
[root@Jenkins ssh]# /etc/init.d/docker restart
Stopping docker:                                           [  OK  ]
Starting docker:                                           [  OK  ]
[root@Jenkins ssh]# /etc/init.d/jenkins restart
Shutting down Jenkins                                      [  OK  ]
Starting Jenkins                                           [  OK  ]
[root@Jenkins ssh]#

Another possible reason is that your BIOS CPU visualization is not enabled. Go and enable it first!