Does docker work in WSL or connect back to Windows?

Question

After successfully installing Docker in WSL, if I run the standard Docker commands, I get connection errors. Executing with sudo or does not produce the same result in all examples.

root@SUR002731165154 :~# sudo docker info Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? root@SUR002731165154 :~# sudo docker version Client: Version: 1.13.1 API version: 1.26 Go version: go1.7.5 Git commit: 092cba3 Built: Wed Feb 8 06:42:29 2017 OS/Arch: linux/amd64 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 

However, if I add -H localhost: 2375 to the command, I can start Docker without any problems. Does the docker connect to my local computer with Windows 10, or runs locally on WSL, or does it somehow?

 root@SUR002731165154 :~# docker -H localhost:2375 version Client: Version: 1.13.1 API version: 1.26 Go version: go1.7.5 Git commit: 092cba3 Built: Wed Feb 8 06:42:29 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 08:47:51 2017 OS/Arch: linux/amd64 Experimental: true root@SUR002731165154 :~# docker -H localhost:2375 info Containers: 11 Running: 0 Paused: 0 Stopped: 11 Images: 8 Server Version: 1.13.1 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 ipvlan macvlan null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1 runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f init version: 949e6fa Security Options: seccomp Profile: default Kernel Version: 4.9.8-moby Operating System: Alpine Linux v3.5 OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 1.934 GiB Name: moby ID: 4LYM:R5T5:6CPZ:Z2KC:YQ4R:NGN4:V6SR:DF7E:YPYO:7FHY:EQW5:2T7W Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): true File Descriptors: 13 Goroutines: 21 System Time: 2017-02-28T18:54:13.7726687Z EventsListeners: 0 Registry: https://index.docker.io/v1/ Experimental: true Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false 

Answer 1

The Docker daemon cannot run under WSL because it does not implement the required ABI kernel. If you use Docker for Windows, you might be connecting to the Hyper-V virtual machine that it manages.

Since you cannot mount WSL directories as Docker volumes on another machine, but you can create images from the WSL directory. This is due to the fact that during the build, the client creates a tarball and sends it to the daemon.

Answer 2

This is the workaround that Docker should use on windows in WSL.

Just add the following to your WSL .bashrc .

 export PATH="$HOME/bin:$HOME/.local/bin:$PATH" export PATH="$PATH:/mnt/c/Program\ Files/Docker/Docker/resources/bin" alias docker=docker.exe alias docker-compose=docker-compose.exe 

Link: https://blog.jayway.com/2017/04/19/running-docker-on-bash-on-windows/

Answer 3

As noted in other answers, Docker cannot be installed and hosted inside WSL, but can be used directly from there like any Windows executable.

It may take only an extra effort to make it usable without these nasty .exe extensions: Windows Bash is an alias for executable files . A related workaround provides a ready-made user script to easily create a symbolic link. Symlinks can be freely used inside non-interactive shell scripts, unlike bash aliases.

---

There is also an approach with connecting from WSL to Docker for Windows as a remote host, described at https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly .

If you are interested in “why not just launch docker.exe and docker-compose.exe from Docker for Windows directly into WSL?”, Then this is due to an error when interactively launching Docker or Docker Compose in this environment. TL DR - you cannot run anything in the foreground interactively, which makes it unsuitable for real web development.

But, unfortunately, there is no reference to the exact symptoms of the error. And I have not encountered this so far.