Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker commands are very slow on Windows #2131

Open
jasonmcboyd opened this issue Jun 20, 2018 · 37 comments

Comments

@jasonmcboyd
Copy link

commented Jun 20, 2018

  • I have tried with the latest version of my channel (Stable or Edge)
  • I have uploaded Diagnostics
  • Diagnostics IDs:
    C293FACB-C45E-482B-83F6-F4390B2C1A89/2018-06-19_22-39-49
    C293FACB-C45E-482B-83F6-F4390B2C1A89/2018-06-20_06-14-16

Expected behavior

Commands to execute very quickly.

Actual behavior

Most commands (maybe all?) take 23 seconds to complete on my machine. In my case it is consistently 23 seconds plus or minus a couple hundred milliseconds; I have measured the time it takes various docker commands to complete many times with PowerShell's Measure-Command command and it is always 23 seconds. Sometimes a command will run slow the first time, run fine a few times after that, then run slow again. This even affects simple commands like 'docker' or 'docker --help'

Information

  • Windows Version: Microsoft Windows 10 Pro: 10.0.17134 Build 17134
  • Docker for Windows Version:
    • Version 18.03.1-ce-win65 (17513)
    • Channel: stable
    • 93354b3
  • I am on a domain joined machine.

I have been able to correlate the 23 second pause I mentioned above with what look to be a suspicious pair of events in Process Monitor. If I only look at events from the docker.exe process I see the following:

Process Name: docker.exe
Operation:    RegCloseKey	
Path:         HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Result:       SUCCESS
Detail:

... 23 second gap in activity ...

Process Name: docker.exe
Operation:    CreateFile
Path:         \\CORP\PIPE\samr
Result:       BAD NETWORK PATH
Detail:       Desired Access: Generic Read/Write, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a

@laymain reported seeing the second event in Process Monitor as well in this issue: #1936.

I have seen reports of general slowness in Docker for Windows reported many times in various corners of the internet with no real resolution. Some users have reported that uninstalling Docker and all its components and then reinstalling Docker works sometimes. In extreme cases I have seen users report that they had to wipe their system and reinstall Windows to get Docker to work correctly. Neither of these solutions are palatable.

Steps to reproduce the behavior

  1. It is consistently slow on my machine... not sure how to reproduce it on any other machine

@jasonmcboyd jasonmcboyd changed the title Docker commands are very slow Docker commands are very slow on Windows Jun 20, 2018

@rvdmei

This comment has been minimized.

Copy link

commented Jun 29, 2018

I have been haunted by the same problem since I started using Windows 10 Enterprise and haven't found a clear solution (except ssh-ing into the VM).

I have been researching the issue a bit more today and this issue looks similar to an old issue in QT creator (see [1]). Apparently, in QT creator, a performance issue occurred when making a Win32 API-call to GetEffectiveRightsFromAcl(), this triggered Windows Domain Controller calls, and consequently delay or even errors per that call. In my case we are using Azure AD and passing privileges from Docker client to Azure AD is an issue too (#132 ). Maybe making the SAM RPC calls is an issue too.

I have been checking if I see the issue anywhere else and I found that minikube is having the same issue. My guess is that there is a bug in one of the libraries that both Docker and Minikube are using or the issue might even be in the Go standard library.

Hope this helps.

[1] http://qt-creator.qt-project.narkive.com/o5QRFTU3/qt-creator-response-too-slow

@rwese

This comment has been minimized.

Copy link

commented Jul 6, 2018

@jasonmcboyd thank you for pointing me to the Process Monitor.

I figured out, using the Process Monitor, that the docker.exe was trying to connect to the dockerd via IPv6, which the dockerd wasn't listening on. It takes 3 Timeouts of 5 seconds ish for it to fallback to IPv4.

Once I disabled IPv6 on all my Network Interfaces, I really don't need it in my CorpLan, I rebooted to be sure and now docker.exe starts within a second.

Maybe give this a try, sadly the docker-cli doesn't allow for IPv6 to be disabled.

@mattanknol

This comment has been minimized.

Copy link

commented Jul 6, 2018

The comment made by @rvdmei helped me a lot! I had to wait up to 3 minutes for docker info to respond. Because I'm also logged in into Azure AD, his comment resonated with me. As soon as I pull my network cable from my rig I get a response from docker info within seconds (as expected). So this problem is clearly related to either being logged in using Azure AD or network overall, or maybe both.

@hermanvantriest

This comment has been minimized.

Copy link

commented Jul 9, 2018

In order to work around this issue you need to execute the docker command using a local user (instead of an Azure AD user).

You can accomplish this by creating a new user (eg localadmin). Furthermore you need to add this user to the docker-users and administrator groups. Next you need to login using this user once to create a profile.

After switching back to your Azure AD account you can execute the following command (eg WIN + R): runas /user:localhost\localadmin cmd (and type in the password). In this session you can now use the docker command without latency.

Good luck!

@laymain

This comment has been minimized.

Copy link

commented Jul 9, 2018

Have you installed Docker before joining your Azure AD?

@hermanvantriest

This comment has been minimized.

Copy link

commented Jul 9, 2018

@laymain Docker was installed after joining the Azure AD.

@laymain

This comment has been minimized.

Copy link

commented Jul 9, 2018

I had this issue when I joined the AD after installing Docker, but it seems there is no link then.
I just can't explain how it now works smoothly for me after reinstalling Windows...
Hopefully you've found a workaround

@jasonmcboyd

This comment has been minimized.

Copy link
Author

commented Jul 11, 2018

@laymain I also installed Docker after joining a domain.

@hermanvantriest Using a local user seems to have solved the problem for me. Does this tell us anything about whether or not this is a Docker issue or an issue with a library as @rvdmei suggests? Is there anything I can do (information I can provide or steps I can take) to help identify the root cause?

@laymain laymain referenced this issue Jul 23, 2018
3 of 3 tasks complete
@sthuber90

This comment has been minimized.

Copy link

commented Jul 24, 2018

@rwese Disabling IPv6 on all my network adapters seemed to have helped me as well. I'll keep an eye on it to see if it keeps working faster now.

Unfortunatly it did not resolve my problem :( Docker is still just too slow on Windows to actually work with it!

@rorlic

This comment has been minimized.

Copy link

commented Aug 1, 2018

@hermanvantriest: using a local user indeed solved the issue on my system. Thank you for this.

@billw2012

This comment has been minimized.

Copy link

commented Aug 21, 2018

It is painfully slow for me on any kind of command once some containers are actually running. Disabling IPv6 made no difference. Once a container is up and running rather than in an install or setup phase it seems to be okay mostly. But given that plenty of containers take minutes to setup this isn't much good.

@casey-at-trimble

This comment has been minimized.

Copy link

commented Sep 9, 2018

@rvdmei Thank you for pointing to the domain controller suspicion. I only have this problem when running Docker commands from home, not at work. I originally thought it was tied to me being on wireless because the commands would execute quickly when I disconnected wireless. Finally had a chance to connect to my ethernet from home and had the same problem. After reading your comment I tried connected to corp via our VPN and the Docker commands began to execute MUCH more quickly. There is still a minor one second-ish delay, probably due to latency of the domain controller calls, but that's all. Thanks again!

@wyckster

This comment has been minimized.

Copy link

commented Nov 9, 2018

I'm observing an occasional 10-13 second delay when executing something as simple as just docker --version.

Using Process Monitor (SysInternals) I was able to observe a 10+ second period of inactivity from docker.exe. Here's an excerpt surrounding the delay from 11:07:51 to 11:08:02.

11:07:51.6979211 AM	docker.exe	5844	CreateFile	C:\Windows\System32\logoncli.dll	SUCCESS	Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
11:07:51.6980115 AM	docker.exe	5844	CreateFileMapping	C:\Windows\System32\logoncli.dll	FILE LOCKED WITH ONLY READERS	SyncType: SyncTypeCreateSection, PageProtection: |PAGE_NOCACHE
11:07:51.6980413 AM	docker.exe	5844	CreateFileMapping	C:\Windows\System32\logoncli.dll	SUCCESS	SyncType: SyncTypeOther
11:07:51.6981313 AM	docker.exe	5844	Load Image	C:\Windows\System32\logoncli.dll	SUCCESS	Image Base: 0x7ff806040000, Image Size: 0x3e000
11:07:51.6982716 AM	docker.exe	5844	CloseFile	C:\Windows\System32\logoncli.dll	SUCCESS	
11:07:51.6983703 AM	docker.exe	5844	RegQueryKey	HKLM	SUCCESS	Query: HandleTags, HandleTags: 0x0
11:07:51.6983860 AM	docker.exe	5844	RegOpenKey	HKLM\SYSTEM\Setup	SUCCESS	Desired Access: Query Value
11:07:51.6984041 AM	docker.exe	5844	RegQueryValue	HKLM\SYSTEM\Setup\SystemSetupInProgress	SUCCESS	Type: REG_DWORD, Length: 4, Data: 0
11:07:51.6984212 AM	docker.exe	5844	RegCloseKey	HKLM\SYSTEM\Setup	SUCCESS	
11:08:02.9784420 AM	docker.exe	5844	CreateFile	C:\Windows\System32\samcli.dll	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
11:08:02.9784772 AM	docker.exe	5844	QueryBasicInformationFile	C:\Windows\System32\samcli.dll	SUCCESS	CreationTime: 2018-04-11 6:34:20 PM, LastAccessTime: 2018-04-11 6:34:20 PM, LastWriteTime: 2018-04-11 6:34:20 PM, ChangeTime: 2018-06-25 2:00:55 PM, FileAttributes: A
11:08:02.9784978 AM	docker.exe	5844	CloseFile	C:\Windows\System32\samcli.dll	SUCCESS	

Immediately before that were accesses related to:

unpigz
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
userenv.dll
profapi.dll
HKLM\System\CurrentControlSet\Control\ComputerName\ActiveComputerName
HKLM\SYSTEM\Setup\SystemSetupInProgress
netapi32.dll
wkscli.dll
HKLM\Software\Policies\Microsoft\Windows NT\Rpc
netutils.dll
secur32.dll

This all suggests something network related to me. I don't know much about the internals of docker, but I'm surprised it did anything network-related by just calling docker --version. (I guess maybe it contacts the daemon to get its version?) But if the root cause of the delay occurs within the hyper-V VM and not in docker.exe then this transcript is not as useful. I don't know how to interpret this observation and how to solve the problem.

Anyway, this is all really annoying that there's a delay that occurs when executing any docker command.

By the way, I notice that if I execute docker commands back-to-back (with less than about 20 seconds of inactivity between runs) then the subsequent calls rarely cause a delay. But if I let the machine sit for 20+ seconds, then run docker --version again, I observe the delay. I get the delay any time I've not executed a docker command in the last 20 seconds. (Which in practice is annoyingly often.) I've done a thorough check of power management settings and disk idle settings, and the machine is not throttling down or sleeping or powering down the spinning disk or anything like that. My performance settings are all set to max performance, no idling / sleeping. No other programs are affected -- just docker.

I'm looking forward to finding out the cause and getting a resolution.

@casey-at-trimble

This comment has been minimized.

Copy link

commented Nov 13, 2018

@Bohdan-Sydor

This comment has been minimized.

Copy link

commented Dec 3, 2018

I'm also experiencing this issue when connected to Active Directory. If I turn off internet everything works fine.
I installed docker client on WSL and connected to Docker Engine on windows and it works without delays.
Also docker-compose works witout any delays as well.

@malloc32

This comment has been minimized.

Copy link

commented Dec 12, 2018

Disabled ipv6 works for me (all network interfaces). Thank you.

@wyckster

This comment has been minimized.

Copy link

commented Dec 18, 2018

Using a local user as per instructions given by @hermanvantriest unfortunately did not solve the problem for me.

I still have not found a solution.

@rosberglinhares

This comment has been minimized.

Copy link

commented Jan 16, 2019

I had a very similar problem when running git bash. The resolution is at the following link: https://gist.github.com/k-takata/9b8d143f0f3fef5abdab.
With docker, for the time being, the solution for me was to run with a non-domain user:

  • Create a local user if you don't have one.
  • Add this user to the docker-users group:
    • From an elevated PowerShell prompt, type Add-LocalGroupMember -Member <LocalUserName> -Group docker-users.
  • For the start menu shortcut, I changed the Target to powershell.exe -Command "Start-Process 'C:\Program Files\Docker\Docker\Docker for Windows.exe' -RunAs '<LocalUserName>'".
  • For use the docker client, I open a PowerShell prompt and type Start-Process powershell -RunAs "<LocalUserName>".
@kind-serge

This comment has been minimized.

Copy link

commented Mar 11, 2019

Running Docker for Windows as local admin reduces delay form ~20 seconds to ~10 seconds for me. Still, the issue persists and delays occur every 30 seconds.
Disabling IPv6 takes no effect.
Complete disconnect from network solves the problem.

P.S. my PC is in a joined AAD domain, and the issue is gone when I'm inside corporate network only. VPN does not help.

@rosberglinhares

This comment has been minimized.

Copy link

commented Apr 1, 2019

Running Docker for Windows as local admin reduces delay form ~20 seconds to ~10 seconds for me. Still, the issue persists and delays occur every 30 seconds.
Disabling IPv6 takes no effect.
Complete disconnect from network solves the problem.

P.S. my PC is in a joined AAD domain, and the issue is gone when I'm inside corporate network only. VPN does not help.

@tyrotoxin , have you tried to run also the client prompt as a local admin in addition to running the Docker for Windows as a local admin?

@kind-serge

This comment has been minimized.

Copy link

commented Apr 1, 2019

@tyrotoxin , have you tried to run also the client prompt as a local admin in addition to running the Docker for Windows as a local admin?

yes, I tried to run every bit of docker under local admin

@wyckster

This comment has been minimized.

Copy link

commented Apr 8, 2019

I would like to mention that disabling my ethernet adapter technically does eliminate the 10-13 second delay. But obviously that is not a viable solution. But I can accept that ethernet is somehow related. So, what's the right solution to fix this?

@Bohdan-Sydor

This comment has been minimized.

Copy link

commented Apr 8, 2019

Also, because this issue is not present in docker-compose and when using docker client from WSL while connecting to Docker engine on Windows host it seems like the problem is not in the engine itself but somewhere in the client.

@telb99

This comment has been minimized.

Copy link

commented Apr 24, 2019

I was having the same problem with docker commands running with an initial pause of 20-30 seconds, then fast for 20ish seconds, then the next one would pause again... found a solution yesterday while trying to get Kubernetes installed and running locally.

I am on COX broadband and was using their DNS servers...
They resolve unknown DNS lookups to a site that will give you a "friendly error" page unless you opt out in your account settings, this page has options to do other searches etc.
So, for instance, "nslookup localhost" returns an IP address instead of indicating there is no DNS entry.
Oh, and that IP address does NOT respond to PING requests.

After changing to OpenDNS servers for my DNS lookups in the network connection IPv4 settings I no longer have problems with docker slowness or Kubernetes failing to start.

@wyckster

This comment has been minimized.

Copy link

commented May 13, 2019

@telb99 I've been investigating and docker never tries to resolve localhost via DNS. So I disbelieve that this could be causing a slowdown. I've confirmed this by setting my DNS to 8.8.8.8 (which reports nslookup localhost not found) instead of my normal DNS server (which reports nslookup localhost is some random machine that happens to be named "localhost" on my network.) And I get slowdowns either way. Perhaps something else was happening in your case?

(Thanks to you though, I did however find and scold the person responsible for adding a machine called "localhost" to our network.) But it's not causing any docker problems.

@ellolazo

This comment has been minimized.

Copy link

commented May 19, 2019

like to share something stupid that worked for me. enable the vpn interface even when there is no vpn connection. before it took like a minute to respond after less than a second

@Fuflino

This comment has been minimized.

Copy link

commented May 19, 2019

@ellolazo where exactly did you enable vpn?

@ellolazo

This comment has been minimized.

Copy link

commented May 19, 2019

@Fuflino I have an anyconnect enterprise vpn on my laptop. the enable/disable only solve it temporarily. even I thought automate the proccess to make it fastest. but it don't solve it :/

@artisticcheese

This comment has been minimized.

Copy link

commented Jun 14, 2019

+1 Same issue #4078

@sakurai-youhei

This comment has been minimized.

Copy link

commented Jun 25, 2019

Although my case doesn't seem to be the same as the issue discussed here, I wanna share a way how to work around my own "Extremely slow on Windows 10" issue (Docker version 18.09.2, build 6247962 / Windows 10 10.0.17763) because 1) Google takes me here when I was struggling and 2) it could remove someone else's pain.

Output of Process Monitor

13:39:39.6679948	docker.exe	14348	CreateFile	\\NB771*\MAILSLOT\NET\NETLOGON	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Superseded
13:39:39.6680526	docker.exe	14348	WriteFile	\\NB771*\MAILSLOT\NET\NETLOGON	BAD NETWORK PATH	Offset: 0, Length: 62, Priority: Normal
13:39:48.9562435	docker.exe	14348	CloseFile	\\NB771*\MAILSLOT\NET\NETLOGON	SUCCESS	

Workaround - Just disable "NetBios over TCP/IP" on each network adapter's TCP/IP v4 Properties; This trick is mentioned here.

@artisticcheese

This comment has been minimized.

Copy link

commented Jun 25, 2019

This did NOT work for me. netbios is disabled on all adapters but Docker still tries to connect to DC

PS C:\Users\1a> ipconfig /all | select-string "netBIOS"                                                                                                                                                                                                                                                                                                                                                                     NetBIOS over Tcpip. . . . . . . . : Disabled                                                                                                                                                                  NetBIOS over Tcpip. . . . . . . . : Disabled                                                                                                                                                                  NetBIOS over Tcpip. . . . . . . . : Disabled                                                                                                                                                                  NetBIOS over Tcpip. . . . . . . . : Disabled
@Bohdan-Sydor

This comment has been minimized.

Copy link

commented Jun 25, 2019

Neither did for me. For now switching to Google DNS is only workaround, though I still need corporate DNS.

@artisticcheese

This comment has been minimized.

Copy link

commented Jul 9, 2019

Find which name your docker connects to and then create hosts file entry pointing to 127.0.0.1, this will remove delay since it will fail immediatelly. In my case connection was to americas.mycompany.com
I created hosts file entry pointing americas.mycompany.com to 127.0.0.1 and delay is gone. Obviously there will be issues now talking to AD but I'm permamently disconnected mode so not an issue here

@Bohdan-Sydor

This comment has been minimized.

Copy link

commented Jul 10, 2019

@artisticcheese how do you find to what host name Docker is trying to connect?

@artisticcheese

This comment has been minimized.

Copy link

commented Jul 10, 2019

Process monitor will show attempts to connect. But this looks like for me was just value of UserDomain environment variable.

@BrainSlugs83

This comment has been minimized.

Copy link

commented Jul 20, 2019

I'm on an Azure AD domain joined PC also.

  • Connecting to VPN doesn't really make sense because I'm already here in the office on our corpnet.

  • I already run everything as a local user (so that's a complete red herring and not related; my domain credentials are cached and known to windows but I run as a local user for all the crazy dev stuff I get up to...).

  • Disabling IPv6 on all 10 of my network devices (not an exaggeration, there's really 10 there) did not make the issue go away for me.

  • Disabling NetBIOS (via IPv4 ->Properties->Advanced->WINS->Disable NetBIOS over TCP/IP) was an instant fix for me. (It was not specifically enabled before but set to Default.) -- Setting some of the adapters (it's completely random which ones it seems) back to Default or Enabled makes the issue return... (and disabling them all again, makes the issue go away).

EDIT:
I agree with others that this sounds like it could be a DNS issue -- I think the command line tools are trying to use WINS and your local DNS to find the service that's just running on the local machine...

In a Windows domain, when a client device performs a DNS or WINS query, it will wait for a certain amount of time before timing out. -- This would explain why the timeouts are so consistent for the people that are experiencing them. -- And why you can run commands back to back quickly, but then 5 minutes later the timeout is back.

I wonder if the bug could be fixed in the client tools to just use 127.0.0.1 (or perhaps ::1) instead of whatever it's doing that is triggering these WINS/DNS queries.

@ams-tschoening

This comment has been minimized.

Copy link

commented Aug 3, 2019

I would like to put some more attention on the already mentioned GetEffectiveRightsFromAcl, because the same problem described here happens with mod_perl as well, but the root cause is in APR and their implementation of apr_stat. Whenever that implementation tries to resolve group and world permissions for a file, the latency comes in for AD-users and in my case even for non-AD, strictly local users, regardless of their group membership, e.g. of being admin or not. It seems that GetEffectiveRightsFromAcl simply always tries to resolve something regarding AD, no matter if a user has joined one or not. I get the following stacktrace always:

19      logoncli.dll    logoncli.dll + 0x4511   0x7ffac14c4511  C:\Windows\System32\logoncli.dll
20      logoncli.dll    DsGetDcNameWithAccountW + 0x2c5 0x7ffac14c5d45  C:\Windows\System32\logoncli.dll
21      logoncli.dll    DsGetDcNameW + 0x2d     0x7ffac14c5a6d  C:\Windows\System32\logoncli.dll
22      ntmarta.dll     AccProvSetAccessRights + 0x90f  0x7ffac5bab7df  C:\Windows\System32\ntmarta.dll
23      ntmarta.dll     AccProvSetAccessRights + 0x14a  0x7ffac5bab01a  C:\Windows\System32\ntmarta.dll
24      ntmarta.dll     AccProvSetAccessRights + 0xcb6  0x7ffac5babb86  C:\Windows\System32\ntmarta.dll
25      ntmarta.dll     EventNameFree + 0x4210  0x7ffac5b9f450  C:\Windows\System32\ntmarta.dll
26      ntmarta.dll     AccGetAccessForTrustee + 0x99   0x7ffac5ba2099  C:\Windows\System32\ntmarta.dll
27      advapi32.dll    GetEffectiveRightsFromAclW + 0x53       0x7ffac8898a53  C:\Windows\System32\advapi32.dll
28      libapr-1.dll    apr_stat + 0xc47        0x6e7a8c97      C:\Program Files\Apache Software Foundation\httpd\bin\libapr-1.dll

ntmarta.dll and the observed behavior is mentioned in some old KB 814055 as well, but I can't find an english version anymore. Pretty much like KB 2018746 seems to be lost. That stacktrace leads to multiple rounds of network communication failing in the end:

18:12:09,8570352      httpd.exe       20396   CloseFile       C:\Windows\System32\logoncli.dll        SUCCESS 
18:12:09,8577214      httpd.exe       20396   CreateFile      C:\Program Files\Apache Software Foundation\httpd\bin\netutils.dll      NAME NOT FOUND  Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
18:12:09,8580361      httpd.exe       20396   CreateFile      C:\Windows\System32\netutils.dll        SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
18:12:09,8581042      httpd.exe       20396   QueryBasicInformationFile       C:\Windows\System32\netutils.dll        SUCCESS CreationTime: 15.09.2018 09:28:46, LastAccessTime: 15.09.2018 09:28:46, LastWriteTime: 15.09.2018 09:28:46, ChangeTime: 18.12.2018 14:29:37, FileAttributes: A
18:12:09,8581470      httpd.exe       20396   CloseFile       C:\Windows\System32\netutils.dll        SUCCESS 
18:12:09,8583470      httpd.exe       20396   CreateFile      C:\Windows\System32\netutils.dll        SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
18:12:09,8584031      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\netutils.dll        FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE|PAGE_NOCACHE
18:12:09,8584618      httpd.exe       20396   CreateFileMapping       C:\Windows\System32\netutils.dll        SUCCESS SyncType: SyncTypeOther
18:12:09,8586230      httpd.exe       20396   CloseFile       C:\Windows\System32\netutils.dll        SUCCESS 
18:12:09,8622225      httpd.exe       20396   CreateFile      \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Superseded
18:12:09,8622960      httpd.exe       20396   WriteFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   BAD NETWORK PATH        Offset: 0, Length: 78, Priority: Normal
18:12:23,4057050      httpd.exe       20396   CloseFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS 
18:12:23,4094073      httpd.exe       20396   CreateFile      \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON   SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Superseded
18:12:23,4095101      httpd.exe       20396   WriteFile       \\VORDEFINIERT*\MAILSLOT\NET\NETLOGON           Offset: 0, Length: 78, Priority: Normal

So it seems most likely that something around docker is trying to read file permissions, uses GetEffectiveRightsFromAcl and runs into the current problem. It might even be that something is really only using apr_stat, in which case changing the flags to retrieve data from APR_FINFO_NORM to APR_FINFO_MIN might already solve the problem:

While modules should just be asking for APR_FSTAT_MIN scope most of the time[...]

https://mail-archives.apache.org/mod_mbox/apr-dev/201908.mbox/%3CCACsi251xHt96bMz=YhQcDP4nSCaRcTA2EUyTri47SYCgLaK0dA@mail.gmail.com%3E

Things heavily depend on if one only needs things like file size and timestamps or really effective file permissions, with the latter being less likely in most cases. By changing those flags I was easily able to work around the problem in my mod_perl-app, simply because neither mod_perl itself nor my app makes any use of file permissions.

Regarding effective file permissions, I would additionally like to mention the fact that Windows Explorer itself is able to provide those and DOES NOT run into the problems described here or occurring with apr_stat. My standard non-admin user without any AD-membership or else is easily able to execute the dialogs of Windows Explorer providing effective file permissions INSTANTLY for that file on which apr_stat fails by default. That is even true for all users and groups having permissions on the file.

Clipboard01

Clipboard02

Regarding my tests, the main difference between apr_stat and what Windows Explorer does seems to be the latter not using GetEffectiveRightsFromAcl, but some different authz-API instead, because I see calls to that DLL in Process Monitor. That API is even documented as an example for GetEffectiveRightsFromAcl itself:

The following example shows using Authz API to get effective access rights from an ACL.

https://docs.microsoft.com/en-us/windows/win32/api/aclapi/nf-aclapi-geteffectiverightsfromacla
https://docs.microsoft.com/de-de/windows/win32/secauthz/using-authz-api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.