Repository navigation
buildctl fails on Windows with "archive/tar: invalid tar header" #5528
Description
Description
buildctl fails on Windows with "archive/tar: invalid tar header" for both type=oci and type=docker using CMD or PowerShell.
> buildctl.exe build --progress=tty --frontend=dockerfile.v0 --local=context=. --output=type=docker,name=test/hello-buildkit,push=false --local=dockerfile=./ --opt=filename=Dockerfile | docker load
archive/tar: invalid tar header
error: failed to solve: failed to copy to tar: rpc error: code = Unknown desc = write /dev/stdout: The pipe is being closed.
Test Dockerfile
FROM mcr.microsoft.com/windows/nanoserver:ltsc2022
RUN echo "hello"Additional info
Using --progress plain works
> buildctl.exe build --progress=plain --frontend=dockerfile.v0 --local=context=. --output=type=docker,name=test/hello-buildkit,push=false --local=dockerfile=./ --opt=filename=Dockerfile | docker load
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 108B done
#1 DONE 0.0s
#2 [internal] load metadata for mcr.microsoft.com/windows/nanoserver:ltsc2022
#2 DONE 0.3s
#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s
#4 [1/2] FROM mcr.microsoft.com/windows/nanoserver:ltsc2022@sha256:be37c9e8bf388c4e3ef27b4a2592b94adab551e231644ce3c9d4d3dc0a50af41
#4 resolve mcr.microsoft.com/windows/nanoserver:ltsc2022@sha256:be37c9e8bf388c4e3ef27b4a2592b94adab551e231644ce3c9d4d3dc0a50af41 0.0s done
#4 DONE 0.0s
#5 [2/2] RUN echo "hello"
#5 CACHED
#6 exporting to docker image format
#6 exporting layers done
#6 exporting manifest sha256:5beace3848b86d36f96ada17197ca4558cb4ae79608610094cc878529bb578d7 0.0s done
#6 exporting config sha256:72a13ebdd2882395f1acaa8af867ed4d48993d7cd153a566aa135f12c96efeb4 0.0s done
#6 sending tarball
#6 sending tarball 4.2s done
#6 DONE 4.2s
afe057336777: Loading layer [==================================================>] 116.9MB/116.9MB
35185b6eab61: Loading layer [==================================================>] 73.08kB/73.08kB
Loaded image: test/hello-buildkit:latestEnvironment
- Windows
ProductName : Windows Server 2022 Datacenter Evaluation
ReleaseId : 2009
CurrentBuild : 20348
DisplayVersion : 21H2 - buildctl
buildctl github.com/moby/buildkit v0.17.1 8b1b83e - Containerd
containerd github.com/containerd/containerd/v2 v2.0.0 207ad711eabd375a01713109a8a197d197ff6542 - docker
Version 27.3.1
Activity
TinaMor commentedon Nov 18, 2024
May be caused by https://github.com/containerd/console: https://github.com/containerd/console/issues/83
profnandaa commentedon Nov 18, 2024
What do you get on the CMD shell?
TinaMor commentedon Nov 18, 2024
Same error:
modaiwang commentedon Jan 9, 2026
i have seen the same problem in windows docker environment (within vmware), do you have any new solutions?
ngebremariam-msft commentedon Jul 28, 2026
The reason for getting "archive/tar: invalid tar header" when running on PowerShell or CMD is because of the commands that are chained together during the build.
--progress=tty → requires a live terminal (an interactive console window, i.e. output going straight to the screen, not into a pipe or file). Because of that, if you try to write a tar file and load it at the same time (piping to docker load), you get "failed to get console: The handle is invalid" from buildctl, or "archive/tar: invalid tar header" from docker. It's essentially the same problem seen from two different sides: buildctl fails right away and prints a short error message instead of building the image, and that error text gets passed down the pipe to docker load, which was expecting an image (a tar file). Since it received a bit of error text instead of a tar, it reports the tar as invalid.
Workarounds
Default:
Continue to use --progress=plain or --progress=auto (these don't need a terminal, so you can keep piping to docker load).
Fix:
Write the tar to a file, then load it (two steps, no pipe):
thaJeztah commentedon Jul 30, 2026
The fix in containerd/console mentioned above may also help (once shipped); progress normally is meant to be printed on STDERR, but on windows unconditionally was put on STDOUT (which is the stream that's piped here);