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

An error occurred while attempting to build Docker image #3884

Closed
vinaychandra opened this issue May 9, 2019 · 167 comments
Closed

An error occurred while attempting to build Docker image #3884

vinaychandra opened this issue May 9, 2019 · 167 comments

Comments

@vinaychandra
Copy link

Information

  • Windows Version: Windows 10 1903
  • Docker for Windows Version: 2.0.4.0 (33772) - Windows Containers

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
Copy link

heoelri commented May 9, 2019

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="[email protected]"
---> Running in 226619c1f55f
hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1) path=C:\ProgramData\Docker\windowsfilter\226619c1f55fc86c2b91383d4715fbd21b095b1d813b334e4b6bd400067848a2

@glautrou
Copy link

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
Copy link
Contributor

This isn't a Docker Desktop bug this is a moby/moby or windows bug, see here for thread and upcoming fix:
moby/moby#27588 (comment)

@jasonmcboyd
Copy link

@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
Copy link
Contributor

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
Copy link

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

@olljanat
Copy link

olljanat commented Jun 6, 2019

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
Copy link

eriawan commented Jun 13, 2019

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
Copy link

lowenna commented Jun 19, 2019

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
Copy link

eriawan commented Jun 20, 2019

@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
Copy link

lowenna commented Jun 20, 2019

Typo, I meant 18362

@eriawan
Copy link

eriawan commented Jun 21, 2019

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

@olljanat
Copy link

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

@eriawan
Copy link

eriawan commented Jun 21, 2019

@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
Copy link

olljanat commented Jun 21, 2019

@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
Copy link

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
Copy link

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

@tianon
Copy link

tianon commented Jun 28, 2019

@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
Copy link

eriawan commented Jul 1, 2019

@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: microsoft/hcsshim#624

@solvingj
Copy link

solvingj commented Jul 1, 2019

+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
Copy link

solvingj commented Jul 1, 2019

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

@moo-ecxio
Copy link

moo-ecxio commented Jul 4, 2019

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
Copy link

jbolduan commented Jul 9, 2019

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: microsoft/hcsshim#624 (comment)

@antonkhelou
Copy link

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

@thaJeztah
Copy link
Member

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

eiffel-fl pushed a commit to eiffel-fl/cli that referenced this issue Jul 28, 2020
full diff: https://2226e083fc390003ae5aa8325c3c92789afa0e7a...b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2

includes:

- microsoft/hcsshim#718 wclayer: Work around Windows bug when expanding sandbox size
    - fixes microsoft/hcsshim#708 Windows Host Compute Service bug breaks docker (and other) sandboxes bigger than 20G on Windows 1903
    - fixes microsoft/hcsshim#624The hcsshim on Windows 10 1903 always fails to build Docker image
    - fixes/addresses docker/for-win#3884 An error occurred while attempting to build Docker image (especially this comment and the next comments after: docker/for-win#3884 (comment))
    - fixes/addresses docker/for-win#4100 Windows 1903 fails when storage-opt used
    - fixes moby/moby#36831 hcsshim::PrepareLayer failed in Win32: The parameter is incorrect (moby/moby#36831 (comment))
    - fixes Stannieman/audacity-with-asio-builder#5 Docker won't build container
    - fixes MicrosoftDocs/visualstudio-docs#3523 Error when running build with storage-opts set
    - fixes moby/moby#39524 Docker build windows 19.03 --storage-opt size>20G

Note that this is a temporary workaround for a bug in the platform, and will be reverted once that is addressed:

- microsoft/hcsshim#721 Revert 718 when Windows 19H1 has expand sandbox fix

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@nickwesselman
Copy link

Somehow Box still does not have a timeline for incorporating the updated CBFS Connect driver. Keep asking them about it...

Hi Nick,

Thank you for reaching Box product Support. Allow me to assist you form here.

As now, this issue still doesn't have a fix and we do not have a update on when this will be be resolved or when an update will be released.

For the meantime, you may consider subscribing our page to get updated: https://community.box.com/t5/Box-Product-Updates/idb-p/ProductUpdates

Let me know if you have further questions.
Best,
Mark
Box Product Support

@joelvaneenwyk
Copy link

For those more aware of the contribution process for this, would it make sense to perhaps add a better log message to prepareLayer call (https://github.com/microsoft/hcsshim/blob/master/internal/wclayer/preparelayer.go) that included information about the driver (stored in stdDriverInfo)? I ran into this as well and ended up being due to ExpanDrive as well. This may not be resolved any time soon so more information could really help demystify this issue. CC @jterry75 who contributed to preparelayer.go in case they have thoughts. Happy to log a feature request (or rather improvement) to https://github.com/microsoft/hcsshim if that is the right thing to do here.

@mirwaisx
Copy link

deleting C:\Windows\System32\drivers\cbfs6.sys works for me as well:

If unable to delete, right-clicking and rename the file, then reboot the computer, now you can delete the renamed version.

cbfs6.sys from Eldos corporation some Callback technologies used apparently by some application creating virtual drives (onedrive?, dropbox?m google drive?) in my case I did not had any but it was still there. After deleting and restarting the system does not complain, yet!

@A1AG
Copy link

A1AG commented Sep 25, 2020

So there is a lot going on in this issue and I'm trying to wrap my head around it. This comment by Geogboe summarizes things pretty well. I believe the storage-opts issue pertains to what I'm trying to do.

Basically, I'm trying to transition my build agents to run under docker containers and in doing so I'm running into container size limitations installing VS2019 build tools but I suspect that I'd run into this problem even if I got VS build tools installed because the repository that I'm building has a good chunk of binary dependencies/artifacts. I've had no success changing the size of docker containers up to this point - setting storage-opts in the docker config file doesn't seem to do anything.

This comment by lowenna and this comment by heaths both mention something similar to what I'm seeing so I think I'm on the right issue. I'm using Windows LTSC2019 (Version 1809, OS Build 17763.1457) with Docker Desktop Community (Version 2.3.0.4 stable, Engine: 19.03.12, Notary: 0.6.1, Compose: 1.26.2, Credential Helper: 0.6.3, Kubernetes: 1.16.5).

I'm not 100% confident I'm on the right issue but if so, is there an ETA for this fix? Should I open separate issue with more detail for what I'm seeing? Any advice would be greatly appreciated.

@IvanAverin
Copy link

IvanAverin commented Nov 6, 2020

I don't have this driver(cbfs6.sys) on my machine and I have the same problems.
Windows version 1909
Docker 2.5.0.0

I have this error when start containers with volume

@nickwesselman
Copy link

Box still has no ETA on updating their CBFS Connect driver.

Ley (Box Customer Success)
Nov 10, 2020, 6:41 AM PST
Hello Nick,

Thank you for reaching out to Box Product Support. I'd be glad to help you with your concern!

Upon checking your original ticket #2165663, it appears that this is a known issue and unfortunately we do not have an expected release for this fix yet. Our team is aware of this issue and will be planning to implement it within a future release, but we do not have a timeline for this fix.

Please let us know if you need anything else.
Warm regards,
Ley
Box Product Support

@dylanbinarystream
Copy link

We encountered this issue with WD Discovery being installed in our of our environments, uninstalling resolved it.

@fbouteruche
Copy link

I have the same issue with cbfsconnect2017.sys file from https://www.callback.com/cbfsconnect/

@DimIsaev
Copy link

I was helped by uninstalling the SFTP program

Edit 2 The software which installed that driver was SFTP Net Drive
Thasks @xyrus02

@mloskot
Copy link

mloskot commented Mar 29, 2021

Another software that installs the cbfs6.sys and cbfsconnect2017.sys by the EldoS Corporation seems to be the pCloud and for some reason the drivers were left after removal of pCloud, and still used/locked for unclear reasons.

The only way to remove them that worked for me was, in Command Prompt > Run As Administrator:

takeown /F C:\Windows\System32\drivers\\cbfs6.sys
cacls C:\Windows\System32\drivers\cbfs6.sys /G username:F
rename C:\Windows\System32\drivers\cbfs6.sys C:\Windows\System32\drivers\cbfs6.txt

Reboot, then delete C:\Windows\System32\drivers\cbfs6.txt, and the same for cbfsconnect2017.sys.

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@nickwesselman
Copy link

/remove-lifecycle stale

This definitely still happens, and Box continues to claim that it's an issue in Docker/Windows, not their software.

@ShadowJonathan
Copy link

@nickwesselman why isn't this bot removed from this repo? it's only hurting the docker-win project.

If that project is in maintainance mode, it should be marked as such, else these staleness bots are only causing aggravation. If it's about pushing down the "open issues" number to look nice to your manager, state it so, don't let these valid issues just get tossed out for no reason.

@FWest98
Copy link

FWest98 commented Aug 30, 2021

It seems like MountainDuck includes a very new version of this driver, cbfs20.sys that causes the same issue, even on the latest versions of Windows 10 (21H1).

I've been in contact with Box Drive support about this issue, and they just informed me today that the developers of CBFS Connect included a workaround for Docker in the 2017.0.25 release on March 4, 2020. I haven't gotten the updated version yet, but it may resolve this issue for Box Drive users. See the link for release notes:

https://files.eldos.com/cbfsconnect/changes.txt

There might have been some regression, as the 2020 versions of the driver are again causing this issue.

@nickwesselman
Copy link

nickwesselman commented Aug 31, 2021

@stephen-turner How bout this one? Bot closed but still an issue. Should this have been in moby the whole time?

Edit: Looks like someone referenced moby/moby#27588 above, but that issue contains a comment saying to follow up here:
moby/moby#27588 (comment)

@stephen-turner
Copy link
Contributor

I don't know who the person who is who wrote that comment, but not a Docker employee. It's definitely a moby/moby issue, as @mikeparker (who is a Docker employee) said right at the beginning.

@EatonZ
Copy link

EatonZ commented Sep 19, 2021

The issue should be resolved now. The CBFS Connect developers mention a fix in v20.0.7921, released on September 8, 2021.

Software will need to update their CBFS Connect driver, though.

@thaJeztah
Copy link
Member

Thanks for the update, @EatonZ

@sidShinde
Copy link

We encountered this issue with WD Discovery being installed in our of our environments, uninstalling resolved it.

This worked for me as well.

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Oct 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests