I have installed docker on windows and successfully brought up the bash shell window. However, when I test my installation with docker run hello-world I get the following:
Post http://127.0.0.1:2375/v1.20/containers/create: 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?
I thought at first it was because I needed to be logged in to docker hub. When I tried docker login and gave it my docker-hub account name, I got
The handle is invalid.
BTW, it did not ask me for my password.
I am puzzled. Please advise.
A little more troubleshooting helped resolve the problem. Steps taken:
I ran the new program Kitematic. It complained that it could not run the VM and offered a remove-and-setup-again option.
I chose the remove-and-setup-again option.
I then ran Kitematic again and it prompted for my dockerhub credentials
Once I successfully entered those and Kitematic seemed healthy I tried the Quickstart terminal again.
Running that provoked some checks from my anti-virus software which wanted to block internet activity from the VM. Once I overrode that, all went well.
In conclusion, it seems that retrying an install does change things (I do not know why) and secondly, anti-virus software can be a bother.
Related
Original Post
I have a Windows workstation with WSL2 and Docker installed that I am able to use for container based development in VS Code. I would like to be able to develop inside the containers on this system remotely. I am able to SSH directly into the WSL2 environment on the workstation and am able to start the docker daemon without logging directly into Windows by creating a Task to start the daemon automatically as described here: https://stackoverflow.com/a/59467740/10692741
However when I try to access Docker on the remote machine by following this guide: https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host, I get the following error:
error during connect: Get http://docker/v1.24/version: net/http: HTTP/1.x transport connection broken: malformed HTTP status code "\x00c\x00o\x00m\x00m\x00a\x00n\x00d\x00"
I have also tried connecting via a SSH tunnel as outlined here: https://code.visualstudio.com/docs/remote/troubleshooting#_using-an-ssh-tunnel-to-connect-to-a-remote-docker-host and am unable to connect to Docker as well.
Has anyone had success with a setup like this? Or is this not supported due to limitations with Docker on Windows, WSL2, and/or Windows OpenSSH implementation?
Update: 2021-01-21
When I SSH into the Windows machine remotely, I am able to see the docker containers in the VS Code extension. I am able to start them, stop them, and enter into them with the shell. However, when I try to attach VS Code I get same error shown above.
Things that may have possibly affected this over the past couple days:
Adding SSH keys on my local machine to the ssh-agent via ssh-add /my/key
Exposing Docker daemon on tcp://localhost:2375 without TLS on the remote Windows machine
Also I want to note that the I've tried using Windows, Mac, and Linux as the local machine. With Mac and Linux I am able to open a remote session into the Windows machine, but from the Windows local machine I am able to SSH into the remote Windows machine but cannot open a remote connection in VS Code for some reason.
Ok, I was able to get this working using the port/socket forwarding technique. For sake of clarity, I'll use:
local development workstation, local workstation, or just workstation to indicate the computer from which we wish to use VSCode to access Docker containers on ...
the remote Docker host, remote, or just Docker host
Sanity check -- Do you have Docker Desktop installed on both systems? On the local development workstation, you can skip the WSL2 integration, but you'll at least need the client tools, since the VSCode extension uses them.
Steps I took:
I already had Docker with WSL2 integration set up on my main system (which for the purposes of this exercise, became my remote Docker host), along with VSCode, so I knew everything was working there. It sounds like that was your starting point as well.
On another system on the same network (accessed with RDP to make it simple), I already had VSCode installed as well, with the Remote Development Extension Pack. I also have WSL on that system, but only a v1 instance there. Not that WSL on the workstation should be a factor at all for the purposes of this exercise.
I installed Docker Desktop for Windows on that local development workstation.
I also installed the Docker extension for VSCode, since I didn't yet have it on the local development workstation.
On the workstation, I was not yet set up to SSH from PowerShell into my WSL Ubuntu distro on the remote. From PowerShell on the workstation, I generated an ECDSA key (per this and other documents) and added the public key to my authorized_keys on the the remote.
On the workstation, I started the OpenSSH Authentication Service and added the newly created key to the agent (in PowerShell) with ssh-agent add ~\.ssh\id_ecdsa.
I logged out of the workstation and back in so that the path changes were picked up for the Docker desktop install.
I was then able to ssh from Powershell on the local to Ubuntu/WSL on the remote with the port forwarding. Since I'm using the Windows 10 OpenSSH server as a jumphost to my WSL SSH servers, my command looked slightly different (with a -o "ProxyCommand ... mainly), but overall the structure is the same as the one listed in the "SSH Tunnel" doc you linked in your question.
On the remote (manually, not through any integration from the local), I did a basic docker run -it --rm Ubuntu and left it open.
On the local, from PowerShell, I set the DOCKER_HOST environment variable via [System.Environment]::SetEnvironmentVariable("DOCKER_HOST","tcp://localhost:23750").
I was then able to see the remote container using docker ps on the local. I could also docker exec -it containername bash into it remotely.
Of course, the above two steps aren't needed in the long term for VSCode, they were just part of my process to make sure everything was up and running (since, as you might expect, I did have several points at which I failed during this process).
So with that working, it was a simple matter in VSCode to change the Docker extension's DOCKER_HOST setting to tcp://localhost:23750. And voila, I could see all images on the remote as well as attach to them from VSCode.
Other thing(s) to check
I'll add to this list if we find additional reasons why it might not be working, but for now:
You mention that you are starting the Docker Desktop daemon automatically at startup via Task Manager, but you don't mention anything about the WSL2 instance. However, since you are able to ssh into it, I assume you have a way to bring it up as well? My experience has been that, unless the owning user is logged in, WSL terminates any instances after a few seconds, even if a service is running. There's a workaround, I believe, that I can dust off if this is a problem.
I am running docker on windows. But I am getting this error:
17:07:22 ---> Running in 8c6a46bbe049
17:07:33 container 8c6a46bbe049260df0ef60b165bd7929a2d8368dcb2baa3cffc7434175a2f811 encountered an error during CreateContainer: failure in a Windows system call: winapi error #2147749890 (0x80041002) extra info: {"SystemType":"Container","Name":"8c6a46bbe049260df0ef60b165bd7929a2d8368dcb2baa3cffc7434175a2f811","Owner":"docker","IsDummy":false,"VolumePath":"\\\\?\\Volume{885e371e-7607-11e9-a9ef-00155de60a79}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\8c6a46bbe049260df0ef60b165bd7929a2d8368dcb2baa3cffc7434175a2f811","Layers":[{"ID":"70d02c58-59c2-5c57-832b-040fbae4082d","Path":"C:\\ProgramData\\docker\\windowsfilter\\3f3b1333b3e56c53c9cdedab9c4ec0e536b923e35c4cfbb64d68d775f7e189ab"},{"ID":"f2b424b8-a849-53e1-9257-7e17fcf4a3fa","Path":"C:\\ProgramData\\docker\\windowsfilter\\874be3b3d29cd1420a8799b482648281a5a04a4604b6f955b305f16c5ffd87db"},{"ID":"865b0b0c-60dc-5052-9af1-6f48b0081b58","Path":"C:\\ProgramData\\docker\\windowsfilter\\ca13b9af8dcc734a0b7dab288ff35a9de9e0b1831122d80315038a368e4be979"},{"ID":"e027a8bd-497f-51a0-bba6-56de6579fd8c","Path":"C:\\ProgramData\\docker\\windowsfilter\\9b2b43be7ff215bea3764306e1d8bbc5a2663c418b5af5643cf720b3604e1909"},{"ID":"754b58d8-c4c4-526a-84df-17b6113fd181","Path":"C:\\ProgramData\\docker\\windowsfilter\\47284b3fd596123a45b89439805ba7f38a7900b1bd67696fafc508f247ca8879"},{"ID":"170bb839-9260-50cf-9f16-2d104a0a41a0","Path":"C:\\ProgramData\\docker\\windowsfilter\\963bfd0727440da144ef3634b9201cf122704bf6171b2306a513c8cc9ca1bd7b"},{"ID":"a3fb6aee-3e04-54c1-8e5b-e665ee073dfe","Path":"C:\\ProgramData\\docker\\windowsfilter\\1daa28b5b08959c93789085549c21165ae66eaebb21092c6019d04939b544085"},{"ID":"a4b61e7f-94cc-5174-95cf-cd5840cd0a92","Path":"C:\\ProgramData\\docker\\windowsfilter\\c81fd28ba0796e1447eee305a9c05f088a0b3ef7920d5fb20b44399fbe584079"},{"ID":"ac5b7f9d-6b96-56fb-93b8-276e30c421ed","Path":"C:\\ProgramData\\docker\\windowsfilter\\58c0426733a33c783f6e3c359c83a63fb31c00fe629bb82764d6a1871b5ac433"},{"ID":"1cd2b979-13de-5fdd-a19b-d33d85fb14eb","Path":"C:\\ProgramData\\docker\\windowsfilter\\5eae35195cd3f58f2d02312aa5df2fec6f87cedf57f41554b625ddac21dddf66"},{"ID":"bee4c6c2-fda9-53d1-97a2-730790e98655","Path":"C:\\ProgramData\\docker\\windowsfilter\\54e2d38e2056906db9e434c33c546a0e536a29a545fe98406be4c1836d90887d"},{"ID":"d30d22d3-5197-555b-928c-d0f2f2099a61","Path":"C:\\ProgramData\\docker\\windowsfilter\\21c171679948030094aa20ecc6c9cf02ea0cc6b438f9a0fde0eb1f76e057d825"}],"HostName":"28224361016f","MappedDirectories":[],"HvPartition":false,"EndpointList":["6864626d-9cdf-4e21-9a34-2ae818f2e8f5"],"Servicing":false,"AllowUnqualifiedDNSQuery":true}
17:07:33 Build step 'Execute shell' marked build as failure
Unfortanely, as soon as I get this error, I am not able to RDP to the remote windows machine anymore ( it's on aws ). So I am not able to investigate further by doing RDP.
[ FYI, my jenkins master is running docker commands on this windows container/slave via SSH ].
Any help/hint will be appreciated here.
I can still run some commands via ssh on the machine if some information needed.
Maybe the two events "not able to RDP" and "the docker error" are somehow connected. But I don't know how.
The docker machine keeps working fine. RDP also works fine in the beginning. But sometime after connecting it as a slave ( and running docker commands via ssh ), RDP stops working.
It turns out the my problem was occuring due to some cleanup utility deleting up the system files required for mstsc ( and also required for docker ).
Everything started working fine after I switched off the cleanup utility.
Thanks for the help though.
Recently started to use Docker in Windows because that's the enviroument where I work. I don't have any problem connecting WSL with Windows Docker an using it for first instance.
After reboot my laptop the problems cames to me. When I'm trying to create an image I get the next error:
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
Is so weird beacause if uninstall windows docker and reinstall it, everything works but if reboot or shut down my laptop, the problem comes again.
It seems like DNS resolve issues about Docker registry.
Sometimes DNS on DHCP information or your network settings makes this trouble on windows.
Try to change DNS options from Automatic to Fixed GoogleDNS(8.8.8.8) on Docker for Windows settings.
Please refer this screenshot.
Fixed DNS Settings on Docker for windows
When I began to start docker it stuck and there are so many bad problem with it
System: Windows 8.1 64-bit
I replace virtualbox 5.0.6 to virtualbox 5.0.7 Still, there's an error
Error One:
When Docker Quickstart Terminal want to begin Starting VM... is hanging
Error two
I test my installation with docker run hello-world I get the following:
Post http://127.0.0.1:2375/v1.20/containers/create: 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?
Error three
Kinematic doesn't work
It work until 99% BUT suddenly it doesn't work
Machine IP could not be fetched. Please retry the setup. If this fails please file a ticket on our GitHub repo.
Best solution I've found after googling for a while:
First check if your Virtualbox version is the latest or at least above 5, then
Run on CMD docker-machine rm -f ##dockerContainerName## (Generally: default)
Delete .docker folder from your user folder
Run docker-machine create --driver virtualbox ##dockerContainerName##
Profit!!!
I have just installed docker using docker-toolbox 1.8.2 on Windows 10.
Due to due to this issue I had to recreate the docker image using these commands
docker-machine rm default
docker-machine --native-ssh create -d virtualbox default
After that it has been working fine, except for one problem:
When the PC has gone to sleep and then wakes again, the docker commands can no longer connect. Example:
> docker images
An error occurred trying to connect: Get https://192.168.99.100:2376/v1.20/images/json:
dial tcp 192.168.99.100:2376: ConnectEx tcp: A connection attempt failed because the
connected party did not properly respond after a period of time, or established connection
failed because connected host has failed to respond.
However the docker-machine lists the machine as running:
> docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
default * virtualbox Running tcp://192.168.99.100:2376
I can also confirm in VirtualBox that the VM screen seems to be active.
I have tried starting and stopping the machine, but that does not help
C:\x> docker-machine stop default
C:\x> docker-machine start default
Starting VM...
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
C:\x> docker-machine env default --shell=powershell
Ironically, the last command hangs, so I never get any environment settings.
The only thing that helps is to restart the whole PC. But that should be unnecessary?
I have also posted this as an issue on the docker github repository,but that was closed. A related issue seems to be this one, but no workaround or solution has been posted for Windows.
After hous of fighting with VirtualBox + Docker Toolbox, I finally found the way, how to make Docker working again (even without restarting all the containers):
Wake up PC from sleep
Try docker images (won`t work)
Open VirtualBox -> Close VM with saving state (CTRL+V)
Run your VM again
Try docker images again (now should work)
Please note: All steps are in VirtualBox only! Running docker-machine restart default will create another host-only adapter, which is something you do not want. If you did it anyway, delete all additionally created adapters (File->Preferences->Network on VirtualBox), then follow steps 1-5.
I have experienced the exact same symptoms on Windows 8.1... The thing is that it's not really a docker-specific issue, but more how Windows manages the VirtualBox network adapters after sleep (I think...). The culprit in my case is that the network adapter's addresses were becoming private after sleep (they became 169.* addresses).
Credits to this guy who gave me the idea: http://lyngtinh.blogspot.ca/2011/12/how-to-disable-autoconfiguration-ipv4.html
Fix:
Start a command prompt as Administrator
Find out the "useful" network adapters: ipconfig /all. The useful ones in my case were the ones labeled "VirtualBox Host-Only Ethernet Adapter" that didn't have private ips (not starting with 169.*).
Run this command and note the "Idx" of the useful VirtualBox network adapters: netsh interface ipv4 show inter.
Run this command to disable the IP auto configuration: netsh interface ipv4 set interface <idx> dadtransmits=0 store=persistent. Replace <idx> with each index found in the previous step.
Restart Windows
Afterwards, I was able to docker-machine start default, then docker-machine env default --shell cmd, put the PC to sleep, wake up and run docker-machine env default --shell cmd again.
I found that removing 'host only adapter' (File->Preferences->Network on VirtualBox), and restart the docker-machine helps.
Not a real solution. But probably better over restart the computer.
Having tried all the other answers here, and having varying but not consistent success, the following seems to reliably bring it back for me after this problem occurs.
Open a powershell/command window (I have most success if I run all docker-machine commands in a powershell window opened as administrator, I don't know if that's important or not) then run (where "dev" is the name of your docker machine instance):
docker-machine ssh dev
Then on the terminal that is opened, run:
sudo shutdown -r now
When the machine restarts, it seems to refresh the network and work correctly. Note, however, that simply running docker-machine restart dev did not have the same effect for me.
Your machine needs to be running before you can do the ssh, so if it's not running, execute docker-machine start dev before trying to SSH.
Had the same problem on Windows 8.1 and docker toolbox 1.12.0
None of the above solutions worked for me, too.
[edited]
Found another way to make docker work after system wake up:
In the docker Quickstart Terminal window, stop docker process Ctrl-C (if it is still running)
Run command docker-compose down
Shut down docker with docker-machine stop default
Exit terminal window Ctrl-D
Run Quickstart Terminal again and do all subsequent steps you need.
This worked for me, on Windows host machine.
Configure your network adapter to
1) Allow the network adapter to wake the computer,
2) Allow a magic packet to wake the computer,
3) Allow IPV6
http://www.worldstart.com/dropped-internet-connection-in-sleep-mode/
Also, on virtual box network settings, go to advanced, and allow promiscuous mode to VM machines, or allow all