You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docker buildx breaks Windows symlinks when copying them over from another Windows image by prepending Files\ to their target. If the original symlink targets are absolute paths, they become unusable.
For example, let's have this Dockerfile and build a Windows image on a Windows node:
FROM mcr.microsoft.com/windows/nanoserver:1809
ADD https://github.com/kubernetes-sigs/windows-testing/raw/master/images/busybox/busybox.exe /bin/busybox.exe
USER ContainerAdministrator
RUN cd C:\bin && FOR /f "tokens=*" %i IN ('.\busybox --list') DO mklink .\%i.exe C:\bin\busybox.exe
The Dockerfile will basically create a C:\bin folder and create symlinks to C:\bin\busybox.exe. We can check that the symlinks are correct:
docker run claudiubelu/sample:1.29.0 cmd /S /C "dir C:\\bin"
Volume in drive C has no label.
Volume Serial Number is AEAD-02B2
Directory of C:\bin
08/31/2020 04:34 PM <DIR> .
08/31/2020 04:34 PM <DIR> ..
08/31/2020 04:34 PM <SYMLINK> ar.exe [C:\bin\busybox.exe]
08/31/2020 04:34 PM <SYMLINK> arch.exe [C:\bin\busybox.exe]
...
Then, we're copying C:\bin to another image with docker buildx on a Linux node with the following Dockerfile:
ARG BASEIMAGE
ARG REGISTRY
FROM $REGISTRY/sample:1.29.0 as helper
FROM $BASEIMAGE
COPY --from=helper /bin /bin
# NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, which is not desirable.
ENV PATH="C:\bin;C:\Windows\System32;C:\Windows;"
ENTRYPOINT ["cmd.exe", "/s", "/c"]
The command is: docker buildx build --no-cache --pull --output=type=registry --platform windows/amd64 --build-arg BASEIMAGE=mcr.microsoft.com/windows/nanoserver:1809 --build-arg REGISTRY=claudiubelu -t claudiubelu/symlink-sample:1.29 .
Checking the symlinks in the newly image, we notice that Files\ is prepended to their targets:
docker run claudiubelu/symlink-sample:1.29 dir C:\bin
Volume in drive C has no label.
Volume Serial Number is AEAD-02B2
Directory of C:\bin
08/31/2020 04:44 PM <DIR> .
08/31/2020 04:44 PM <DIR> ..
08/31/2020 04:34 PM <SYMLINK> ar.exe [Files\C:\bin\busybox.exe]
08/31/2020 04:34 PM <SYMLINK> arch.exe [Files\C:\bin\busybox.exe]
...
One workaround for this is to make the original symlinks with relative paths (to busybox.exe).Files\ will still be prepended to the target paths, but the busybox binary could be copied to C:\bin\Files\busybox.exe, which means that they will point to something that exists:
ARG BASEIMAGE
ARG REGISTRY
FROM $REGISTRY/sample:1.29.0 as helper
FROM $BASEIMAGE
COPY --from=helper /bin /bin
# NOTE(claudiub): Unfortunately, docker buildx has some issues copying over Windows symlinks.
# "Files/" is always prepended to the symlink target. The symlinks themselves are relative paths,
# so, in order to make use of them, we can simply add a busybox binary to C:\bin\Files\busybox.exe.
COPY --from=helper /bin/busybox.exe /bin/Files/
# NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, which is not desirable.
ENV PATH="C:\bin;C:\Windows\System32;C:\Windows;"
ENTRYPOINT ["cmd.exe", "/s", "/c"]
docker buildx
breaks Windows symlinks when copying them over from another Windows image by prependingFiles\
to their target. If the original symlink targets are absolute paths, they become unusable.For example, let's have this
Dockerfile
and build a Windows image on a Windows node:The
Dockerfile
will basically create aC:\bin
folder and create symlinks toC:\bin\busybox.exe
. We can check that the symlinks are correct:Then, we're copying
C:\bin
to another image withdocker buildx
on a Linux node with the followingDockerfile
:The command is:
docker buildx build --no-cache --pull --output=type=registry --platform windows/amd64 --build-arg BASEIMAGE=mcr.microsoft.com/windows/nanoserver:1809 --build-arg REGISTRY=claudiubelu -t claudiubelu/symlink-sample:1.29 .
Checking the symlinks in the newly image, we notice that
Files\
is prepended to their targets:One workaround for this is to make the original symlinks with relative paths (to
busybox.exe
).Files\
will still be prepended to the target paths, but the busybox binary could be copied toC:\bin\Files\busybox.exe
, which means that they will point to something that exists:Docker buildx version: github.com/docker/buildx v0.4.1-25-ge24e04b e24e04b
The text was updated successfully, but these errors were encountered: