Slow Docker commands on domain joined PC
I recently joined a new company and as part of that I got a new laptop. Normally that just means installing the things I need, and I’m good to go. However, this time I started having issues with Docker for Desktop…
Well, that’s kind of… Docker was working fine on my machine as long as I was at the office. WHen taking it to conferences to do demos, it would start having issues. Not crashing, but whenever I pulled up my terminal and ran a Docker command against Docker for Desktop, I would get a really annoying delay before the command would execute. Running something as simple as docker info would freeze for few seconds before giving me the response. Oddly enough, after running a “slow” command, it would then be back to responding quickly again for a while. And by “for a while” I mean about 30 seconds or something.
So I did what every computer savvy person would. I Googled it of course. The result was a mixed bag as usual. But I did find one interesting GitHub issue talking about the problem I was having. Reading through it, there were several suggestions for fixing it. Ranging from turning off IPv6 on all networks to changing DNS. None of them seemed to solve the problem. However, there were a few one comments that stood out to me. They were talking about connections being made across the network when the computer was domain joined. And yes, at my new job, my machine was domain joined…
Turning off the network connection would solve the problem. The delay would disappear, but on the other hand, turning off the network means that your applications cannot depend on an internet connection, which is a bit limiting…
So, what was my Docker client really doing? Well, I went and downloaded the Sysinternals Process Explorer so that I could see what was going on. And the result was this
| The highlighted line, if you can’t read it, says “Create file | \\ACTIVE\PIPE\samr | BAD NETWORK PATH”… And there it is… Because my machine is domain joined, any call using the Docker client tries to communicate with a named pipe on the domain controller. Something that obviously doesn’t work if you are not on the network where DC is located. |
So, on any other network than the one at my office, this call would lock up until it timed out. Causing the delay I was seeing.
I tried creating a local user on my machine, and run the Docker stuff as a local user. However, that fixed the problem. So I decided to try a suggestion that was mentioned in the GitHub issue.
I opened the HOSTS file on my machine and added the following line
127.0.0.1 ACTIVE
In my case, Docker.exe was trying to access “ACTIVE”, and the delay was caused by having to wait for it to time out. So by adding an entry for “ACTIVE” pointing to 127.0.0.1 all these calls to the DC end up at my local machine. However, since my local machine is not a DC, the call ends up with a “BAD NETWORK PATH” without having to wait for the timeout. But the good thing is that this doesn’t seem to be causing any problems when running the command. The only thing that happens is that the call fails almost immediately, instead of having to wait for the timeout.
Note: I just have to remember to comment out the line in the HOSTS file whenever I am at the office. Otherwise anything that has to do with the DC would have problems…
