Vscode-remote-release: Attaching to docker running on remote machine fails

[pvasek]

I am trying to reproduce the steps described in documentation here:
https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host

but got an error: _"Docker returned an error. Make sure the Docker daemon is running."_

Setup

Two machines:

• mac with VS Code and docker/docker-machine
• linux box

Steps to reproduce

1. From the mac, with help of docker-machine, install the docker on the linux box. (after this you can use docker CLI on mac to control the docker running on the remote linux machine now)
2. Create workspace and add appropriate docker host settings to .vscode/settings.json.
3. Start a container on the remote machine
4. Check the docker extension, you should be able to see all running containers on the linux machine.
5. Try to _attach to container_ to one of these running containers. (either via command or container context menu)
6. You get an error _"Docker returned an error. Make sure the Docker daemon is running."_

Error

Message box: _"Docker returned an error. Make sure the Docker daemon is running."_

Developer console:

{
    "error": {
        "cmd": "docker version --format '{{.Server.Version}}'",
        "code": 1,
        "killed": false,
        "signal": null
    },
    "stderr": "Get http://192.168.1.201:2376/v1.39/version: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02".↵* Are you trying to connect to a TLS-enabled daemon without TLS?↵",
    "stdout": "↵"
}

Configuration details

docker-machine env dev

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.1.201:2376"
export DOCKER_CERT_PATH="/Users/pvasek/.docker/machine/machines/dev"
export DOCKER_MACHINE_NAME="dev"

workspace settings.json

{
    "docker.host": "tcp://192.168.1.201:2376",
    "docker.certPath": "/Users/pvasek/.docker/machine/machines/dev",
    "docker.machineName": "dev",
    "docker.tlsVerify": "1"
}

Versions

• VSCode Version: 1.37.0-insider
• Local OS Version: Darwin x64 17.7.0
• Remote OS Version: Ubuntu 16.04.3 LTS
• Remote Extension/Connection Type: Docker
• Remote-Containers Version: 0.66.0
• Local Docker Version: 18.09.2, build 6247962
• Remote Docker Version: 18.09.7, build 2d0083d

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: N/A

Experiments

I verified that the workspace settings are really used by changing the machine IP address and could see it in the error log. I also tried to run vs code from a terminal where all the docker environment variables were set but that didn't helped.

I noticed that the docker extension is able to connect to remote docker regardless of docker.tlsVerify value.

Conclusion

From the error message it's obvious that the remote-containers extensions try to use http for https endpoint but I have no idea why. Did I miss any settings?

[rasikas]

I'm getting the same error in my windows 10 machine when using docker-machine

$ docker-machine env windocker
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="C:\Users\ras\.docker\machine\machines\windocker"
export DOCKER_MACHINE_NAME="windocker"
export COMPOSE_CONVERT_WINDOWS_PATHS="true"
# Run this command to configure your shell:
# eval $("C:\Users\ras\bin\docker-machine.exe" env windocker)

my VS settings

    "docker.host": "tcp://192.168.99.100:2376",
    "docker.tlsVerify": "1",
    "docker.certPath": "C:\\Users\\ras\\.docker\\machine\\machines\\windocker",
    "docker.machineName": "windocker",

error in dev tools

error:
cmd: "docker version --format '{{.Server.Version}}'"
code: 1
killed: false
signal: null
__proto__: Object
stderr: "WARNING: Error loading config file:Invalid auth configuration file↵Get http://192.168.99.100:2376/v1.20/version: malformed HTTP response "\x15\x03\x01\x00\x02\x02".↵* Are you trying to connect to a TLS-enabled daemon without TLS?↵* Is your docker daemon up and running?↵"
stdout: "''↵"

VS version 1.36.1
Remote development ext version 0.15.0
Remte- Containers version 0.66.0

[Chuxel]

@rasikas @pvasek The certPath, machineName, and tlsVerify properties are new in the Docker extension and not yet supported by Remote - Containers. See #859.

So, you will need to set the environment variables via Docker Machine and then start VS Code using the command line in the same terminal to get those to pick up currently. It's only processing docker.host.

Does following that approach fix it?

[rasikas]

@Chuxel as you can see in my previous comment I've already have the environment variables setup, and that's where I've got the settings to put into VS settings. and I ran the vs code from the same command line by typing code . and still not working. I will give another try. thanks

[Chuxel]

@rasikas Are you in WSL, git bash, or cygwin? (I see $ which is making me ask.) If you do code . and end up in WSL mode, then VS Code itself (and by extension Docker) might not see the environment variables. Try from cmd.exe.

[rasikas]

@Chuxel no I'm in git bash I'll try the cmd.exe and get back to you, thanks a lot

[rasikas]

I tried it with cmd.exe and no luck

and the error in dev tools

[rasikas]

Update, I removed the vs settings altogether and just kept the environment variables only and now I'm getting this error when trying to attach or even using "Remote-Containers: Open Folder in Container..."

My question is VS IDE can fetch the container details images etc, as shown in the above image and why it cannot connect? if it is an error due to finding docker-machine environment variables, then it shouldn't be able to fetch image info and container status (running, stopped etc)

[Chuxel]

@rasikas Unclear -- I just tried the following devcontainer.json without issue against a remote host:

{
    "image": "node",
    "workspaceFolder": "/workspace",
    "workspaceMount": "src=remote-workspace,dst=/workspace,type=volume,volume-driver=local",
    "postCreateCommand": "apt-get update && apt-get -y install git"
}

What happens when you run docker system info from the command line? VS Code is doing nothing other than shelling out to the command line in this case.

[rasikas]

I assume you first need to ssh into docker-machine before running docker system info
from my git bash i can do that and this is the output
~~~
$ docker-machine ssh windocker
( '>')
/) TC ( Core is distributed with ABSOLUTELY NO WARRANTY.
(/-_--_-) www.tinycorelinux.net

docker@windocker:~$ docker system info
Containers: 32
Running: 0
Paused: 0
Stopped: 32
Images: 139
Server Version: 18.09.5
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 local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.14.111-boot2docker
Operating System: Boot2Docker 18.09.5 (TCL 8.2.1)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 989.4MiB
Name: windocker
ID: V472:GW2T:VMQN:AQWC:SA2U:VTXS:FNG7:CUDO:74FE:DTWJ:Y3ZQ:LRHL
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
~~~

However in my cmd.exe I get this error
~~~
c:mywork>docker-machine ssh windocker
exit status 255

c:mywork>
~~~

not sure this is the problem.

[rasikas]

I was wondering this is the problem with cmd.exe which leads to vscode. (https://github.com/baram204/Used-Car-Price-Expectation-with-ML/issues/13)
so @Chuxel you saying launching VS code from gitbash doesn't make it work? we have to run from cmd.exe ? if so I may have to follow the steps in the above issue and remove openssh client and see

[Chuxel]

@rasikas No, docker system info will test the Docker connection if you call it, you shouldn't need to ssh first - VS Code is not using docker-machine directly.

I don't know exactly how Git bash processes environment variables and it may place things in locations Windows itself does not know about. I would use either cmd.exe or powershell.exe to get things working before trying anything else.

I also have the Windows 10 open SSH client installed, so it seems unlikely that is the cause, but you can give it a shot. It seems like there's something going on with your docker config, so if you can get docker system info working, you should be able that should resolve the problem.

[rasikas]

Thanks @Chuxel I will first try to get docker system working

[rasikas]

I reinstalled the docker for windows (note that I don't run hyper-v instead I use VirtualBox with docker-machine)
after installing the latest docker for windows I now have the system option and this is the output

c:\mywork>docker system info
Containers: 32
 Running: 1
 Paused: 0
 Stopped: 31
Images: 139
Server Version: 18.09.5
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 local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.14.111-boot2docker
Operating System: Boot2Docker 18.09.5 (TCL 8.2.1)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 989.4MiB
Name: windocker
ID: V472:GW2T:VMQN:AQWC:SA2U:VTXS:FNG7:CUDO:74FE:DTWJ:Y3ZQ:LRHL
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

However the previous error still exists - [Window Title]
Visual Studio Code
[Content]
Docker returned an error. Make sure the Docker daemon is running.
[OK]

[Chuxel]

@rasikas That sounds like you're back to not having the environment variables in VS Code. I would create a fresh Docker Machine and see if that resolves your problem.

These are the steps that are known to work are:

1. Setup Docker Desktop for Windows
2. Create a docker machine from the command line (cmd.exe or powershell.exe) using Docker Desktop's copy
3. Use docker-machine env in cmd.exe to set your environment variables
4. Completely shut down VS Code if it is running
5. Run code . in the terminal window

I use this setup myself on a pretty regular basis.

If you are using Docker Toolbox, that is a legacy solution so the problem could be there. Most of Docker's energy is going into Docker Desktop particularly given their announcement that they'll be using WSL2 instead of Hyper-V as that rolls out. That's why we don't officially support Toolbox - there does not appear to be much energy going into supporting it on the Docker side, so odd things could happen.

[rasikas]

Thanks @Chuxel , yes I tried creating new docker machine from the cmd after installing Docker desktop and still no luck, anyway thanks for the help. I think I will wait and see, it's not a big deal but nice to have it working, yes if I can get it working once WSL2 update available that would be great. Thanks for the help anyway

[ironbishop]

Same issue. The remote Docker is OK when I open code, but as I click on "Attach running container...", the new window does not share the same environment, so it fails.

One of these things solved the issue, but I honestly don't know which one because I did them at the same time:

• Completely shut down VS Code (as suggested by https://github.com/microsoft/vscode-remote-release/issues/975#issuecomment-513245552)
• Setting DOCKER_TLS_VERIFY, DOCKER_HOST and DOCKER_CERT_PATH in settings.json
• Setting DOCKER_TLS_VERIFY, DOCKER_HOST and DOCKER_CERT_PATH as global environment variables

setx DOCKER_TLS_VERIFY 1
setx DOCKER_HOST tcp://omissis:2376
setx DOCKER_CERT_PATH C:\Users\omissis\.docker

[Nosferican]

I get a similar issue when trying to attach VS Code to it, (local OSX and Ubuntu server),

It seems it tried to look for a local container rather than in the remote. Attaching a shell works fine.

[gustavovalverde]

The new VS code insiders fixed this for me: https://github.com/microsoft/vscode-remote-release/issues/1089#issuecomment-535645668

We'll just have to wait for this to land stable

[Chuxel]

@chrmarti I'm noticing attach is not working from the Docker extension in the latest insiders. It also seemed to be a problem using the command.

Weirdly, "Remote Explorer" works, however.

Folks, note that not all of the docker properties in settings.json are supported by Remote - Contaienrs yet. https://github.com/microsoft/vscode-remote-release/issues/859 is the issue to add these in.

You have to set environment variables either globally, or in a terminal window and then start VS Code from there. Note that VS Code cannot already be running.

[bluelancer]

@

I get a similar issue when trying to attach VS Code to it, (local OSX and Ubuntu server),

It seems it tried to look for a local container rather than in the remote. Attaching a shell works fine.

Double confirm the issue, on Ubuntu 16.04 as remote host, OSX as local

[chrmarti]

@bluelancer You seem to be connected to a SSH host. The Remote-Containers currently cannot connect a container on the SSH host.

@Chuxel Remote-Containers: Attach to Running Container... works for me when launching with either the environment variables set or the settings configured for the remote Docker daemon. Do you still see this in the latest Insiders and could you provide steps to reproduce?

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!