search

docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.86k stars 291 forks source link

An error occurred while attempting to build Docker image #3884

Closed vinaychandra closed 3 years ago

vinaychandra commented 5 years ago

Information

Create new project from ASP.NET Core 3 API template with Enable Docker Support checked. This is the sample DockerFile

#Depending on the operating system of the host machines(s) that will build or run the containers, the image specified in the FROM statement may need to be changed.
#For more information, please see https://aka.ms/containercompat

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-nanoserver-1809 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-nanoserver-1809 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

This is the full build output when trying to run the image from VS 2019

1>------ Build started: Project: WebApplication1, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.0.100-preview5-011568\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(157,5): message NETSDK1057: You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
1>WebApplication1 -> C:\Users\vinay\source\repos\WebApplication1\WebApplication1\bin\Debug\netcoreapp3.0\WebApplication1.dll
1>docker build -f "C:\Users\vinay\source\repos\WebApplication1\WebApplication1\Dockerfile" -t webapplication1:dev --target base  --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=WebApplication1" "C:\Users\vinay\source\repos\WebApplication1"
1>Sending build context to Docker daemon  19.97kB
1>
1>Step 1/6 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-nanoserver-1809 AS base
1> ---> 03ea2d12b576
1>Step 2/6 : WORKDIR /app
1> ---> Running in b43c8006530c
1>hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)
1>C:\Users\vinay\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.7.8\build\Container.targets(196,5): error CTP1001: An error occurred while attempting to build Docker image.
1>Done building project "WebApplication1.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Note that I am able to login (docker login works) but the build fails in another step.

heoelri commented 5 years ago

i've the same issue here with docker ce on win10 (1903 - 18362.53)

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: false

docker build .

Sending build context to Docker daemon 3.072kB Step 1/3 : FROM nanoserver/iis ---> 7eac2eab1a5c Step 2/3 : LABEL maintainer="xyz@mail.com" ---> Running in 226619c1f55f hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1) path=C:\ProgramData\Docker\windowsfilter\226619c1f55fc86c2b91383d4715fbd21b095b1d813b334e4b6bd400067848a2

glautrou commented 5 years ago

Similar issue when creating a .NET Core 2.2 project from either VS 2017 or 2019, with Windows Docker support toggled. However it works fine when choosing Linux Docker support.

mikeparker commented 5 years ago

This isn't a Docker Desktop bug this is a moby/moby or windows bug, see here for thread and upcoming fix: https://github.com/moby/moby/issues/27588#issuecomment-466624189

jasonmcboyd commented 5 years ago

@mikeparker Pardon my ignorance here (I am by no means an expert when it comes to Docker) but it is not clear to me that this issue is related to the issue that you linked to. The issue you reference is nearly three years old and appears to be related to timeouts. The error in the case is "Incorrect Function" and a Google search for:

docker "Win32: Incorrect function"

turns up only this question (and some site that scraped this question) suggesting this is a relatively recent issue. Given that I only just upgraded to Windows 1903 hours ago and now all docker builds fail with:

hcsshim::PrepareLayer failed in Win32: Incorrect function.

regardless of which image version I target (1809 or 1903) I have to assume this is specific to Windows 1903.

mikeparker commented 5 years ago

The issue I linked is indeed relevant, whilst the original ticket started three years ago, the latest comment from Microsoft about the fix (see linked comment) was Feb 2019, which coincides with the 1903 windows release.

You're right though, the error messages are slightly different. I'll double check whats going on here.

ShemTovYosef commented 5 years ago

I have the same issue when I upgraded Windows from 1809 to 1903

olljanat commented 5 years ago

Looks to be very Windows version specific issue (Win32 is Windows kernel and hcsshim is library which is used to call it) so I highly recommend you to contact Microsoft support about this issue.

eriawan commented 5 years ago

I can confirm that this issue is certainly reproducible on Windows 10 1903. It looks like the problem is on the MS hcsshim side.

lowenna commented 5 years ago

Hmmm, I haven't been able to repro this so far using one of the examples in the linked issue, using both hyper-v and process isolations. Using Windows build 18361.1/1903.

If someone has a repro, can they please try using the latest moby binaries from master.dockerproject.org. If that still repros, please start the daemon in debug mode (dockerd -D) and paste the log.

eriawan commented 5 years ago

@jhowardmsft

If you are using Windows build 18361.1, then you are not using the same Windows 1903 release as I have. Are you using Windows Insider?

As far as I know, the official build of Windows 1903 is 18362, and the latest patch set my current Windows 1903 to be 18362.175:

image

lowenna commented 5 years ago

Typo, I meant 18362

eriawan commented 5 years ago

@jhowardmsft Have you tested with the same build number as mine, 18362.175 like previous screenshot?

olljanat commented 5 years ago

@eriawan have you tested with latest binaries from https://master.dockerproject.org like it was requested?

eriawan commented 5 years ago

@olljanat CMIIW, the master.dockerproject.org is bleeding edge Docker. To use that, I have to test on separate machine, uninstall any stable Docker Desktop to use it and it's not straightforward for me.

I'll test that next week after I could setup new VM, because I won't jeopardize the existing stable Docker .

olljanat commented 5 years ago

@eriawan yes those are latest nightly builds of Moby. However you can just drop those binaries to another folder, stop Docker service and run .\dockerd.exe -D from command line on that folder to get this tested without jeopardize existing installation.

donny-dont commented 5 years ago

I have been hitting the same issue since I upgraded to Windows 10 1903 (OS Build 18362.175) but have a much simpler Dockerfile. It seems like it always fails when creating the first layer across the different Dockerfiles I'm trying to build.

FROM mcr.microsoft.com/windows:1903@sha256:9befaf22c0f9802fc6d68a6bdea46c7f7bbcb3646769e22298469c88bc1fec0f

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

RUN Set-ExecutionPolicy -ExecutionPolicy RemoteSigned;

Command Output

Starting build at 6/21/2019 12:49:48 PM
docker build -t webkitdev/base:windows-1903  -f C:\Users\eolmstead\Documents\webkit-trunk\docker-webkit-dev\base\Dockerfile.windows-1903 C:\Users\eolmstead\Documents\webkit-trunk\docker-webkit-dev\base
Sending build context to Docker daemon   7.68kB
Step 1/3 : FROM mcr.microsoft.com/windows:1903@sha256:9befaf22c0f9802fc6d68a6bdea46c7f7bbcb3646769e22298469c88bc1fec0f
 ---> 1bee20cb5117
Step 2/3 : SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
 ---> Running in 69d840b80e19
hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

dockerd from master.dockerproject.org run with -D

time="2019-06-21T12:27:46.039785900-07:00" level=info msg="Starting up"
time="2019-06-21T12:27:46.040770800-07:00" level=warning msg="Running experimental build"
time="2019-06-21T12:27:46.043766500-07:00" level=debug msg="Listener created for HTTP on npipe (//./pipe/docker_engine)"
time="2019-06-21T12:27:46.047786000-07:00" level=info msg="Windows default isolation mode: hyperv"
time="2019-06-21T12:27:46.047786000-07:00" level=debug msg="Stackdump - waiting signal at Global\\stackdump-25188"
time="2019-06-21T12:27:46.048761200-07:00" level=debug msg="Using default logging driver json-file"
time="2019-06-21T12:27:46.048761200-07:00" level=debug msg="[graphdriver] trying provided driver: windowsfilter"
time="2019-06-21T12:27:46.048761200-07:00" level=debug msg="WindowsGraphDriver InitFilter at C:\\ProgramData\\Docker\\windowsfilter"
time="2019-06-21T12:27:46.049761300-07:00" level=debug msg="Initialized graph driver windowsfilter"
time="2019-06-21T12:27:46.311763500-07:00" level=debug msg="[graphdriver] trying provided driver: lcow"
time="2019-06-21T12:27:46.312757300-07:00" level=info msg="lcowdriver: init: dataRoot: C:\\ProgramData\\Docker\\lcow globalMode: false"
time="2019-06-21T12:27:46.312757300-07:00" level=debug msg="Initialized graph driver lcow"
time="2019-06-21T12:27:46.336752100-07:00" level=debug msg="Max Concurrent Downloads: 3"

time="2019-06-21T12:49:49.253838600-07:00" level=debug msg="Calling POST /v1.39/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile.windows-1903&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&session=l4281c0e0yjsbjr9f2lrqegka&shmsize=0&t=webkitdev%2Fbase%3Awindows-1903&target=&ulimits=null&version=1"
time="2019-06-21T12:49:49.254755500-07:00" level=debug msg="Calling POST /session"
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="parsed scheme: \"\"" module=grpc
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="scheme \"\" not registered, fallback to default scheme" module=grpc
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="ccResolverWrapper: sending update to cc: {[{ 0  <nil>}] }" module=grpc
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000d84400, CONNECTING" module=grpc
time="2019-06-21T12:49:49.254755500-07:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000d84400, READY" module=grpc
time="2019-06-21T12:49:49.276876500-07:00" level=debug msg="client is session enabled"
time="2019-06-21T12:49:49.278761100-07:00" level=debug msg="[BUILDER] Cache miss: [powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; #(nop)  SHELL [powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';]]"
time="2019-06-21T12:49:49.278761100-07:00" level=debug msg="[BUILDER] Command to be executed: [powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; #(nop)  SHELL [powershell -Command $ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';]]"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::GetLayerMountPath" path="C:\\ProgramData\\Docker\\windowsfilter\\d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="Calling proc (1)" path="C:\\ProgramData\\Docker\\windowsfilter\\d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="Calling proc (2)" path="C:\\ProgramData\\Docker\\windowsfilter\\d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::GetLayerMountPath - succeeded" mountPath="C:\\ProgramData\\Docker\\windowsfilter\\d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7" path="C:\\ProgramData\\Docker\\windowsfilter\\d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::CreateScratchLayer" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::NameToGuid" name=d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::NameToGuid - succeeded" guid=0f28caa3-87d0-5c83-a85d-4ca8291c4561 name=d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::NameToGuid" name=c240f91d664f8d9b6ecf24fd24ff0285bfabe1cb334591113a928f6770f36105
time="2019-06-21T12:49:49.283829000-07:00" level=debug msg="hcsshim::NameToGuid - succeeded" guid=d792512c-2c1f-50a8-9f38-55b8a441d2aa name=c240f91d664f8d9b6ecf24fd24ff0285bfabe1cb334591113a928f6770f36105
time="2019-06-21T12:49:49.291757300-07:00" level=debug msg="hcsshim::CreateScratchLayer - succeeded" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.291757300-07:00" level=debug msg="hcsshim::ExpandScratchSize" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344" size=128849018880
time="2019-06-21T12:49:49.498760100-07:00" level=debug msg="hcsshim::ExpandScratchSize - succeeded" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344" size=128849018880
time="2019-06-21T12:49:49.531751800-07:00" level=debug msg="WindowsGraphDriver Get() id 69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344 mountLabel "
time="2019-06-21T12:49:49.534749100-07:00" level=debug msg="hcsshim::ActivateLayer" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::ActivateLayer - succeeded" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::PrepareLayer" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::NameToGuid" name=d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::NameToGuid - succeeded" guid=0f28caa3-87d0-5c83-a85d-4ca8291c4561 name=d2bcf2ac469526f115e134b1c2bfbe99e6aa3b389236305dc5283bc5ece281d7
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::NameToGuid" name=c240f91d664f8d9b6ecf24fd24ff0285bfabe1cb334591113a928f6770f36105
time="2019-06-21T12:49:49.544749100-07:00" level=debug msg="hcsshim::NameToGuid - succeeded" guid=d792512c-2c1f-50a8-9f38-55b8a441d2aa name=c240f91d664f8d9b6ecf24fd24ff0285bfabe1cb334591113a928f6770f36105
time="2019-06-21T12:49:49.555747700-07:00" level=error msg="hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)" error="hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.555747700-07:00" level=debug msg="hcsshim::DeactivateLayer" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.560746600-07:00" level=debug msg="hcsshim::DeactivateLayer - succeeded" path="C:\\ProgramData\\Docker\\windowsfilter\\69d840b80e1991942c8aff72cb819af61ea2a6f6de6543d733675e00341f0344"
time="2019-06-21T12:49:49.564746700-07:00" level=warning msg="grpc: addrConn.createTransport failed to connect to { 0  <nil>}. Err :connection error: desc = \"transport: Error while dialing only one connection allowed\". Reconnecting..." module=grpc
time="2019-06-21T12:49:49.564746700-07:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000d84400, TRANSIENT_FAILURE" module=grpc
time="2019-06-21T12:49:49.564746700-07:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000d84400, CONNECTING" module=grpc
time="2019-06-21T12:49:49.564746700-07:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000d84400, TRANSIENT_FAILURE" module=grpc

I don't have any problems running containers but they refuse to build.

jbolduan commented 5 years ago

I'm getting the exact same issue when trying to build docker images on 1903.

tianon commented 5 years ago

@jhowardmsft just ran into this on a client's laptop running Windows 10, version 1903 (OS Build 18362.175)

I downloaded yesterday's dockerd.exe from master.dockerproject.org (2019-06-27) and it didn't do anything except make the client error message less verbose (same error).

eriawan commented 5 years ago

@jhowardmsft

I have tried to use the dockerd.exe from master.dockerproject.org to build a docker image on Windows 1903 and I still get the same error message caused by hcsshim. I am using on Windows 10 1903 build 18362.175, and I have tried on 18362.207 as well.

Looking at the many users that have confirmed failed build, I'm pretty sure that it is caused by hcsshim running on Windows 10 1903 build 18362.175 and newer.

I suggest let's not dillute this issue further, because I think it's more on hcsshim side. Please reply on the MS hcsshim repo especially (I have submitted) this related hcsshim issue: https://github.com/microsoft/hcsshim/issues/624

solvingj commented 5 years ago

+1 Cannot build after upgrading from 1803 to 1903

hcsshim::PrepareLayer failed in Win32: The parameter is incorrect. (0x57) path=C:\ProgramData\Docker\windowsfilter\4b18b89d4a1028eaa5f7ece5896728f9324a17533f5cda5f82c632f484be4b42

Windows 10 1903 18362.175 Docker Desktop Community Version 2.0.0.3 (31259) Channel: stable Build 8858db3 Engine 18.09.2 Machine: 0.16.1

solvingj commented 5 years ago

As per this potentially related ticket, removing storage opts from my configuration solved the issue: https://github.com/moby/moby/issues/36831

moo-ecxio commented 5 years ago

got the same issue on win10 release 1903 when trying to copy content from a container to the file system: docker cp [containerName]:[containerPath] [hostFilesystem] resulting in Error response from daemon: hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1) path=C:\ProgramData\Docker\windowsfilter\6a7019f5530c15951e6a7441dba27ed40a87c560b4ab5befe324aa26956c498d

Docker version 18.09.2, build 6247962

jbolduan commented 5 years ago

As per this potentially related ticket, removing storage opts from my configuration solved the issue: moby/moby#36831

I checked my daemon.json and I did not have storage-opts defined but I do get the error. Based on a comment on the hcsshim repo it might be related to some undocumented flags being used: https://github.com/microsoft/hcsshim/issues/624#issuecomment-509526835

antonkhelou commented 5 years ago

After upgrading to 1903, I couldn't build anything. The only thing that fixed it was removing the storage-ops.

thaJeztah commented 5 years ago

For those running into this; if you have a custom storage location configured; could you try if things work if you disable Windows defender, or exclude the location? https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-security

jbolduan commented 5 years ago

@thaJeztah I know you asked for those with custom storage locations but I tried on my default locations (so the C:\ProgramData\Docker and just to be double sure I added C:\Users\Public\Documents\Hyper-V) to the exclusion list and I still get the error.

thaJeztah commented 5 years ago

Thanks for checking; I recalled we recently had a setup where similar issues were caused by Windows Defender, so I thought it was worth checking

solvingj commented 5 years ago

I already had windows defender services completely disabled.

eriawan commented 5 years ago

@thaJeztah

I think it's not related to Windows Defender. I have tried to other machine of 1903 without Windows Defender, and it still failed.

@solvingj for removing storage options/locations, it still doesn't work. I always get the same error when building Docker image.

jbolduan commented 5 years ago

Here's my setup as well in case there's something that might help identify the root cause.

DockerFile

ARG TAG=ltsc2016
FROM mcr.microsoft.com/windows/servercore:$TAG

WORKDIR /pester

ADD . /pester

CMD powershell.exe .\Build\build.ps1

daemon.json

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false
}

dockerbuild.ps1 (Script used to execute docker build commands)

docker build -t umn-activedirectory .

docker run umn-activedirectory

Console Output from docker build command

Sending build context to Docker daemon  783.4kB
Step 1/5 : ARG TAG=ltsc2016
Step 2/5 : FROM mcr.microsoft.com/windows/servercore:$TAG
 ---> 5df67de47444
Step 3/5 : WORKDIR /pester
 ---> Running in 43014a0cadd1
hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)
lowenna commented 5 years ago

The problem is now understood. It looks like it will require a fix for a regression in docker, and a fix in Windows itself. For now, the only workaround is as others have put here to take out the storage-opt in daemon.json. It also affects docker run where --storage-opt size=30GB for example (any number, 30 is just arbitrary for demonstration). It also means that it is not possible to build layers larger than 20GB in Windows 1903 builds.

lowenna commented 5 years ago

To add, it has nothing to do with Windows Defender, or whether the data root has been moved to another location.

thaJeztah commented 5 years ago

@jhowardmsft do you know what needs to happen in docker to address it?

michael-n123 commented 5 years ago

@jhowardmsft I removed storage-opts and still can't build docker.

I am on Windows 10.0.18362.10006 & Docker 2,0,5,0 (35318)

lowenna commented 5 years ago

do you know what needs to happen in docker to address it?

@thaJeztah Yes, but if I fix it, no-one will be able to docker run or build at all until the platform is fixed

jrad88 commented 5 years ago

So, is there an ETA on when this is fixed? Maybe you're not aware of the importance here, but I don't understand how we have identified this issue and not put it on a schedule to push out. It's been 2 months since this has been reported, and basically means there's one good version of Windows 10 that works with docker, and the rest are broken or gimped, and the only people who can build 1903 images are Microsoft themselves, while the rest of us drag our feet on 1809 and hope the Windows Update fairies dont visit us while we step out to lunch.

I've tried everything in this thread, I have all default everything, totally reset every setting, I can't build even the simplest one line change-to-powershell windows images on 1903. There are no workarounds, and I've spent entirely too much time trying to find one. People are in-memory-patching the docker daemon as a workaround, and that's not a viable solution for me.

Unless Microsoft can offer a service to build my images for me, I need to know when this will be resolved.

metrotyranno commented 5 years ago

I have a clean docker install and the same issue, I get the error on the LABEL maintainter= command

Server: Docker Engine - Community Engine: Version: 19.03.0-rc2 API version: 1.40 (minimum version 1.24) Go version: go1.12.5 Git commit: f97efcc Built: Wed Jun 5 01:52:18 2019 OS/Arch: windows/amd64 Experimental: true

Windows 1903 18362.267 Updated to insider fast 18945.1001, issue persists

moo-ecxio commented 5 years ago

Any news on that? there was a update to 19.03.1 but still no fix. This bug should be considered as a blocker

imphasing commented 5 years ago

Any update on this? My team sees this happen inconsistently, some on 1903 are using docker with no issues others see this issue whenever attempting to build images. Can we get any additional details on the root cause from someone who understands the issue in depth?

PerArneng commented 5 years ago

This is currently blocking our work since no one with Windows 10 can use docker right now. Is this somehow related to the GraphDriver for windows? https://github.com/moby/moby/search?q=PrepareLayer&unscoped_q=PrepareLayer

ghost commented 5 years ago

Same for us. Our Reqchecker build image fails on Windows 10 1903 18362.267, while it works with previous version Win 10 october 2018. This image fails : 

# escape=

# Use the latest Windows Server Core image with .NET Framework 4.8.
FROM mcr.microsoft.com/dotnet/framework/runtime:4.8

# Restore the default Windows shell for correct batch processing below.
SHELL ["cmd", "/S", "/C"]

# Download channel for fixed install.
ARG CHANNEL_URL=https://aka.ms/vs/15/release/channel
ADD ${CHANNEL_URL} C:\TEMP\VisualStudio.chman

# Download and install Build Tools for Visual Studio 2017 for native desktop workload.
ADD https://aka.ms/vs/15/release/vs_buildtools.exe C:\TEMP\vs_buildtools.exe

RUN C:\TEMP\vs_buildtools.exe --quiet --wait --norestart --nocache `
    --channelUri C:\TEMP\VisualStudio.chman `
    --installChannelUri C:\TEMP\VisualStudio.chman `
    --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended`
    --installPath C:\BuildTools `
    --all `
    --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 `
    --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 `
    --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 `
    --remove Microsoft.VisualStudio.Component.Windows81SDK `
    || IF "%ERRORLEVEL%"=="3010" EXIT 0
RUN DEL C:\TEMP\vs_buildtools.exe

# Install chocolatey
ENV chocolateyUseWindowsCompression false
RUN powershell -Command iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

# Install JDK for JNI headers
RUN choco install jdk8 -y

# Use developer command prompt and start PowerShell if no other command specified.
ENTRYPOINT C:\BuildTools\Common7\Tools\VsDevCmd.bat && 

CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

The error is :

Preparing: C:\Users\ContainerAdministrator\AppData\Local\Temp\c5507fb721d7caaebec22fd70bae\vs_bootstrapper_d15\vs_setup_bootstrapper.json...
re-exec error: exit status 1: output: time="2019-08-10T01:59:50+02:00" level=error msg="hcsshim::ImportLayer - failed failed in Win32: Le chemin d’accès spécifié est introuvable. (0x3)" error="hcsshim::ImportLayer - failed failed in Win32: Le chemin d’accès spécifié est introuvable. (0x3)" importFolderPath="C:\\ProgramData\\Docker\\tmp\\hcs813114883" path="\\\\?\\C:\\ProgramData\\Docker\\windowsfilter\\cd545810c97a235674fd520544d26340db783d0daaed4d9560de4f7d8117799e"
hcsshim::ImportLayer - failed failed in Win32: Le chemin d’accès spécifié est introuvable. (0x3)

But a similar image works for Java building, it does not include vs_buildtools.exe. Only the setup of vs_buildtools.exe fails. We are still investigating the problem.

heaths commented 5 years ago

@khilogic try removing the storage-opts from your configuration and don't specify any storage-opt parameter. Unfortunately, the size was also regressed from 127GB to 20GB according to a linked bug, so you will not be able to build a billfold image in many cases unless you can really reduce the workloads and components installed.

@jhowardmsft is there a timeframe for a fix? This is blocking Visual Studio Build Tools in a container.

imphasing commented 5 years ago

My team gets this with a stock docker configuration, no storage-opt parameter set - any ideas for a mitigation? This blocks using docker on 1903 for a subset of my team with no apparent cause..

jrad88 commented 5 years ago

We're at 3 months now with no ETA. 1903 is rolling out for anyone with 1803 without even asking. Completely bypassing the first and only version of Windows with proper docker support. The best part of this thread is that even Microsoft doesn't know when or if Microsoft will ever get around to fixing it.

I suppose its my fault for using the latest incarnation of Windows only 3 months after its release.

imphasing commented 5 years ago

I’m just going to tell my team to downgrade to 1809, I’ve tried every combination of possible mitigation at this point, like native vs hyperv isolation - 1803, 1809, and 1903 images, etc with no change in behavior. I have a few teammates who reproduce this issue every time they attempt to build an image so their only option is downgrade to 1809 or not use docker.

imphasing commented 5 years ago

@jhowardmsft Is there any chance this will be resolved in the upcoming windows 10 1909?

imphasing commented 5 years ago

I have mitigated this through the absolutely insane solution suggested here: https://github.com/microsoft/hcsshim/issues/624#issuecomment-518530342

Patching the running dockerd to remove these undocumented parameters to AttachVirtualDisk resolves the issue for everyone on my team that sees this while building images for 1903. I modified the code slightly to build in VS2017 (make it work with wide char strings, a couple other things) but this actually resolves the issue and allow my team mates to build images and use docker. This seems completely crazy and I'm super curious about what happened here. Will this be resolved in 1909?

olivier-haddad commented 5 years ago

Any news or ETA about a fix? We're quite stuck for a few weeks already as our QA guys don't have a full fledged dev environment and are only running under Docker... Same config as many others: -Windows 10 Pro 10.0.18362 -HAL 10.0.18362.267 -no storage options set at all (relatively small images anyway) -services running asp.net core 2.2 on nanoserver 1903 image

Geogboe commented 5 years ago

I'm in same boat is @jbolduan and don't see storage-opts defined in my daemon.json. In fact nothing is really in my config. 

cat C:\ProgramData\Docker\config\daemon.json
{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false
}

Am I missing something or looking in the wrong location or something? This fixed seemed to have helped a lot of others....

olivier-haddad commented 5 years ago

@Geogboe : That is very similar to my config. The fix proposed by @jhowardmsft does NOT solve the problem for many users. There is a combination of several issues at work and his solution probably solves one of the issues.