Docker-machine ls returns timeout when run from an elevated Windows cmd

Open Source Projects Machine
1

Issue

docker-machine ls returns timeout when run from an elevated Windows cmd However, running it from a normal cmd terminal works fine:

OS Version/build:

C:\>ver

Microsoft Windows [Version 10.0.14393]

App version

$ docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.7.5
 Git commit:   89658be
 Built:        Fri May  5 15:36:11 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.12.0-ce
 API version:  1.35 (minimum version 1.12)
 Go version:   go1.9.2
 Git commit:   c97c6d6
 Built:        Wed Dec 27 20:12:29 2017
 OS/Arch:      linux/amd64
 Experimental: false

C:\>docker-machine version
docker-machine version 0.11.0, build 5b27455

C:\>docker-compose version
docker-compose version 1.13.0, build 1719ceb8
docker-py version: 2.2.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016

C:\>"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" --version
5.2.6r120293

Steps to reproduce

First, I launch the Windows command prompt as an Administrator and run docker-machine ls as shown below:

C:\>docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER   ERRORS
default            virtualbox   Timeout

Then , I launch a normal cmd terminal with Administrator privileges. I get the out put below from the same command:

C:\>docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default   -        virtualbox   Running   tcp://192.168.99.100:2376           v17.12.0-ce

Any suggestions to fix this will be appreciated.

2

I just noticed this same thing while trying to setup a way to start the default docker machine upon Windows bootup.

The same thing happens in reverse as well; i.e. if you launch the default machine via an elevated prompt, non-elevated apps (command prompt, etc.) get timeouts and issues. Whichever way you launch the machine (elevated or non-elevated) you must always access the machine with any tools using the same level of elevation.

I suppose this makes sense if you launch it elevated, so non-elevated apps can’t mess with it, but kinda strange that elevated apps can’t work with non-elevated ones.

btw, side note, I REALLY wish Docker would make it easy to just create a Windows service to start docker machines, holy ish … eye roll

3

I eventually came to the same realization after wasting quite abit of time!

If you do find away to get around this, let me know.