Docker can't connect to boot2docker because of TCP timeout

后端 未结 12 1911
遇见更好的自我
遇见更好的自我 2021-01-29 20:59

I\'m running Mac OS 10.9.5 (Mavericks), I\'ve followed https://docs.docker.com/installation/mac/ to install Docker. I get a timeout error message when I run Docker even though t

相关标签:
12条回答
  • 2021-01-29 21:02

    I had this issue after running Cisco AnyConnect. Even after I shut down AnyConnect, the issue persisted.

    @treehau5's answer works, but doing boot2docker poweroff, and then using Activity Monitor, kill the ciscod left behind by AnyConnect also worked for me. Then I opened a new Terminal window and started boot2docker normally and Docker commands then worked fine.

    0 讨论(0)
  • 2021-01-29 21:03

    This happened to me as well, and none of the previous answers fixed the problem.

    Today, thanks to a colleague's suggestion, I did not startup my VPN connection first. I rebooted my machine, and started with Docker from the beginning.

    boot2docker init
    boot2docker up
    $(boot2docker shellinit)
    docker run hello-world
    

    It worked as expected!

    I found this post by Florian Rosenberg useful. I read through it in detail, but I think most of what he is suggesting in the first part has been factored into the most recent version of boot2docker. But the insightful bit was "Connecting to VPN Things will break".

    It suggested to look for a firewall rule that denies any to any. So, without VPN fired up I looked for this rule, and it was not there. Sure enough, once I fired up my VPN, I got the following (different) error...

    docker run hello-world
    2014/11/13 11:11:18 Post https://192.168.59.103:2376/v1.15/containers/create: dial tcp 192.168.59.103:2376: permission denied
    

    I checked the firewall rules, and sure enough a new rule was added...

    sudo ipfw -a list | grep "deny ip"
    00411    1      64 deny ip from any to any 
    

    Once I removed that firewall rule with:

    sudo ipfw delete 00411
    

    I was able to talk to Docker from the OS X command shell.

    0 讨论(0)
  • 2021-01-29 21:10

    I have had this issue as well and here is a temporary solution.

    First, open VirtualBox and check the network settings on the boot2docker VM to see what the host only adapter is named. In my case, it's vboxnet1; for you, it may be vboxnet0.

    Then, apply this command:

    sudo route -nv add -net 192.168.59 -interface vboxnet1
    

    Now you should be able to run Docker commands.

    See this issue for more information.

    I am noticing over time that a common denominator in this problem is Cisco anyconnect (me included), for what it's worth.

    0 讨论(0)
  • 2021-01-29 21:11

    OK, so this happened to me as well.

    First of all, setting the environment variables is necessary. But then, I kept getting the I/O timeout error even after that.

    So, instead of starting boot2docker by running the application package (clicking on the boot2docker icon), I started it from the command line.

    I first executed,

    $boot2docker init
    

    This said, the VM was already running.

    Then I went ahead and tried to start it.

    $boot2docker start
    

    This started it.

    You can verify it by running

    $boot2docker info
    

    It prints a JSON about your running instance.

    Then, you can ssh into it and run

    $boot2docker ssh
    $docker run hello-world
    

    That's it.

    0 讨论(0)
  • 2021-01-29 21:11

    I tried treehau5's method, but it did not work. I changed VirtualBox's Network setting of boot2docker VM setting - 'host-only Adapter's Promiscuous mode to 'Allow All'.

    0 讨论(0)
  • 2021-01-29 21:12

    Here's what worked for me when I hit a similar snag. Make sure you've upgraded VirtualBox, then:

    1. boot2docker stop
    2. boot2docker init
    3. boot2docker start; eval "$(boot2docker shellinit)"

    Then, just for sanity's sake, check that $DOCKER_HOST matches $(boot2docker ip). I suspect I had many things going on, as when I first started, $DOCKER_HOST had become unset somehow.

    The issue and some discussion can be found in the GitHub issues page here - it does rather seem as if it's often just a case of VirtualBox being flaky.

    0 讨论(0)
提交回复
热议问题