An error occurred while attempting to build Docker image #3884
Comments
|
i've the same issue here with docker ce on win10 (1903 - 18362.53)
|
|
Similar issue when creating a .NET Core 2.2 project from either VS 2017 or 2019, with Windows Docker support toggled. |
|
This isn't a Docker Desktop bug this is a moby/moby or windows bug, see here for thread and upcoming fix: |
|
@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:
regardless of which image version I target (1809 or 1903) I have to assume this is specific to Windows 1903. |
|
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. |
|
I have the same issue when I upgraded Windows from 1809 to 1903 |
|
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. |
|
I can confirm that this issue is certainly reproducible on Windows 10 1903. It looks like the problem is on the MS |
|
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. |
|
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:
|
|
Typo, I meant 18362 |
|
@jhowardmsft |
|
@eriawan have you tested with latest binaries from https://master.dockerproject.org like it was requested? |
|
@olljanat I'll test that next week after I could setup new VM, because I won't jeopardize the existing stable Docker . |
|
@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. |
|
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. Command Output dockerd from master.dockerproject.org run with -D I don't have any problems running containers but they refuse to build. |
|
I'm getting the exact same issue when trying to build docker images on 1903. |
|
@jhowardmsft just ran into this on a client's laptop running Windows 10, version 1903 (OS Build 18362.175) I downloaded yesterday's |
|
I have tried to use the 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 |
|
+1 Cannot build after upgrading from 1803 to 1903
Windows 10 1903 18362.175 |
|
As per this potentially related ticket, removing storage opts from my configuration solved the issue: |
|
got the same issue on win10 release 1903 when trying to copy content from a container to the file system:
|
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) |
|
After upgrading to 1903, I couldn't build anything. The only thing that fixed it was removing the |
|
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 |
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 <github@gone.nl>
|
Somehow Box still does not have a timeline for incorporating the updated CBFS Connect driver. Keep asking them about it...
|
|
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. |
|
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! |
|
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 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 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. |
|
I don't have this driver(cbfs6.sys) on my machine and I have the same problems. I have this error when start containers with volume |
|
Box still has no ETA on updating their CBFS Connect driver.
|
|
We encountered this issue with WD Discovery being installed in our of our environments, uninstalling resolved it. |
|
I have the same issue with cbfsconnect2017.sys file from https://www.callback.com/cbfsconnect/ |
|
I was helped by uninstalling the SFTP program
|
|
Another software that installs the The only way to remove them that worked for me was, in Command Prompt > Run As Administrator: Reboot, then delete |
|
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an 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. |
|
/remove-lifecycle stale This definitely still happens, and Box continues to claim that it's an issue in Docker/Windows, not their software. |
|
@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. |
|
It seems like MountainDuck includes a very new version of this driver,
There might have been some regression, as the 2020 versions of the driver are again causing this issue. |
|
@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: |
|
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. |
|
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. |
|
Thanks for the update, @EatonZ |
This worked for me as well. |
|
Closed issues are locked after 30 days of inactivity. 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. |
and others
Information
Create new project from ASP.NET Core 3 API template with Enable Docker Support checked. This is the sample DockerFile
This is the full build output when trying to run the image from VS 2019
Note that I am able to login (
docker loginworks) but the build fails in another step.The text was updated successfully, but these errors were encountered: