hcsshim: hcsshim::ImportLayer failed in Win32: The system cannot find the path specified. (0x3) on Docker Desktop for Windows Community edition 2.3.0.3(45519)

I had this problem and solved it with the following steps: 1 ° I executed the following commands: to clear the images: docker images prune 2 ° I executed the one that cleans everything (Images, Containers, Cache and Networks) docker system prune

I solved this problem by allocating a 64 GB disk for my VMware Workstation Pro and initializing it as drive F:. In the DockerEngine settings, I provided Docker with a place to do its work with the data-root entry. { "registry-mirrors": [], "insecure-registries": [], "debug": false, "experimental": false, "data-root": "F:\\docker-root" }

@kempniu @farzonl @schribl I run into same problem trying build an image with Cygwin. It seems that it is hardlinks which Cygwin uses a lot are not handled correctly by Docker. After I got rid of the hardlinks in Cygwin installation I was able to commit the image without problems. To get rid of the hardlinks I have zipped and unzipped Cygwin folder.

I’ve encountered this with Engine 20.10.9 on Windows Server 2019 while building Boost libraries with VS Build Tools and Windows PowerShell. The data root is set to a directory on a secondary drive that’s dedicated to Docker and has plenty of free space. Increasing the storage-opts, pruning or a complete reinstall (including removal of files under Program Files, ProgramData and the data root) didn’t help. Both the dockerd process and data root are excluded from Defender scans.

What helped, was adding a wait at the end of the RUN script:

sleep -Seconds 300

Why does that work, I have no idea. There shouldn’t be anything interfering with the filesystem.

Paradoxically the VS Build Tools and Chocolatey + CMake installation in one of the previous steps is not a problem.

I got to a point where I had an image that kept dying at build time after a few steps even though I had just about enough free space as the last final image size from the previous build, but it seems a lot of extra space is necessary while building and while running.

Neither hcsshim nor Docker Desktop for Windows gave any comprehensive errors that space was an issue. 🤷‍♂️

As pointed above, I too solved this error by pointing "data-root" to a bigger drive and rebuilding my images.

For the Cygwin folks, my workaround looks like this:

RUN setx /M CYGWIN "winsymlinks:lnk"

RUN curl -SL --output %TEMP%\cygsetup.exe https://cygwin.com/setup-x86_64.exe `
    && powershell -Command `
        Start-Process %TEMP%\cygsetup.exe -Wait -ArgumentList '--quiet-mode --wait --root c:\cygwin --local-package-dir c:\cygwin --site http://mirrors.kernel.org/sourceware/cygwin/ --packages autoconf' `
    && C:\cygwin\bin\bash.exe -c 'for i in `/bin/find / -xdev -type l`; do j=`/bin/readlink $i`; /bin/rm -f $i; /bin/ln -sf $j $i; done' `
    && powershell -Command `
        Remove-Item -Recurse -Force c:\cygwin\http*

This forces Cygwin to use legacy (.lnk) based links, then recursively goes through Cygwin’s directory tree & recreates every symlink (some of which are NTFS junction points), such that there are no junction points on disk when docker tries to commit the RUN step’s changes. It works for me locally.

Sadly, I’m getting the same hcsshim error trying to install MSVC build tools on Server Core (but NOT on regular server) images. I checked, and there are no stray junction points created.

I’m experiencing this exact issue on a Windows Server 2019 (10.0.17763) instance running Docker 19.03.5, too.

I am experiencing exactly the same issue as @cosmo0920 when trying to create a docker container that uses choco install msys2. The docker version also matches. It runs on Windows 10 Enterprise 1809 and the base images is mcr.microsoft.com/dotnet/framework/runtime:4.8