I am attempting to build a Linux container on Windows 10 Pro / 1809 set to Windows container mode.
When I do a docker build ., the first few lines that copy files, set my workdir, and so on, run just fine.
But on my first attempt to run something in the container that starts a process, I get access denied from Windows:
Step 7/14 : RUN ["pipenv", "install"]
---> Running in 11ff6d6e09c3
container 11ff6d6e09c36c95018bbb73f97131054038b67a6d5268dc0776d418a3cef131 encountered an error during CreateProcess: failure in a Windows system call: Unspecified error (0x80004005)
[Event Detail: failed to run runc create/exec call for container 11ff6d6e09c36c95018bbb73f97131054038b67a6d5268dc0776d418a3cef131: exit status 1 Stack Trace:
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*container).startProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:576
g
If I switch Docker to Linux containers, this works just fine.
I can run Linux containers interactively in Windows-container mode – eg docker run -it ubuntu:latest /bin/sh while in Windows-container mode works just fine.
Has anyone else tripped over this?
Versions of things: Docker for Windows 2.0.0.3, build 8858db3; engine 18.09.2; Windows 10 Enterprise, OS build 17763.1
I’m getting exact the same error as well. It doesn’t seem to be an access denied problem…
In my docker file, I have instruction like RUN chmod +x .... While building the image, it just got stuck at this line. The service log shows exact same as @wattdave posted. There’re also stack traces like bellow:
[01:45:56.163][WindowsDaemon ][Error ] exec's CreateProcess() failed [namespace=moby module=libcontainerd exec=626dd7791b549ec47b85815a746f6104f0c4673d08ab0d803ffcae90de1a1f54 container=f0b333850865a78d137b7afcdc0cac4dfaf93a40b6b165e4912652a8b05dbd09 error=container f0b333850865a78d137b7afcdc0cac4dfaf93a40b6b165e4912652a8b05dbd09 encountered an error during CreateProcess: failure in a Windows system call: Unspecified error (0x80004005)
[Event Detail: failed to run runc create/exec call for container f0b333850865a78d137b7afcdc0cac4dfaf93a40b6b165e4912652a8b05dbd09: exit status 1 Stack Trace:
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*container).startProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:576
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*container).runExecCommand
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:516
github.com/Microsoft/opengcs/service/gcs/runtime/runc.(*container).ExecProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/runtime/runc/runc.go:136
github.com/Microsoft/opengcs/service/gcs/core/gcs.(*gcsCore).ExecProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/core/gcs/gcs.go:425
github.com/Microsoft/opengcs/service/gcs/bridge.(*Bridge).execProcess
/go/src/github.com/Microsoft/opengcs/service/gcs/bridge/bridge.go:582
github.com/Microsoft/opengcs/service/gcs/bridge.(*Bridge).(github.com/Microsoft/opengcs/service/gcs/bridge.execProcess)-fm
/go/src/github.com/Microsoft/opengcs/service/gcs/bridge/bridge.go:236
github.com/Microsoft/opengcs/service/gcs/bridge.HandlerFunc.ServeMsg
/go/src/github.com/Microsoft/opengcs/service/gcs/bridge/bridge.go:68
github.com/Microsoft/opengcs/service/gcs/bridge.(*Mux).ServeMsg
/go/src/github.com/Microsoft/opengcs/service/gcs/bridge/bridge.go:139
github.com/Microsoft/opengcs/service/gcs/bridge.(*Bridge).ListenAndServe.func2.1
/go/src/github.com/Microsoft/opengcs/service/gcs/bridge/bridge.go:315
runtime.goexit
However, the same docker file, same command works fine on the other machine. The only difference I’m seeing with these two machine is the Windows version. 1803 vs 1903. The docker versions are the same.
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:31 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.24)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:28:48 2019
OS/Arch: windows/amd64
Experimental: true
And then I made a change on the dockerfile, RUN ["chmod", "+x", ...]. It worked fine on both machines. This way seems to change the cached layers as the workaround.