Symbolic Links not Working as Expected

[t0rr3sp3dr0]

Expected behavior

Previously Docker would resolve the symbolic link before mapping the volume, so the link would be visible as a regular file inside the container and you would be able to access it even if its real path is not explicitly mounted.

Actual behavior

Now Docker is treating Windows symbolic links as Linux symbolic links, that way you may not be able to access the files if they are not bellow the mounted directory.

And if you have a symbolic link pointing to other driver on Windows, it is impossible to have a configuration that allow these symbolic links to resolved.

Information

• Windows Version:
  Microsoft Windows 10 Version 1909

• Docker Desktop Version:
  Docker Desktop 2.2.1.0

• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM:
  No

[stephen-turner]

@t0rr3sp3dr0 You are right that this doesn't work in 2.2.0.3: however, it didn't work in the previous version (2.1.0.5) either. My understanding, although I haven't verified this myself, is that it also doesn't work under Linux, and you get a dangling symlink like under Windows.

NTFS junction points are a different matter. We do have a regression there in 2.2.0.3 compared to 2.1.0.5, but that is covered by #5582.

[t0rr3sp3dr0]

I actually had this working until this week for at least 3 months and nothing has changed rather than the Docker version. I'm downgrading and testing to verify which version of Docker I was using.

[t0rr3sp3dr0]

@stephen-turner, it does work on this version:

For now I'll stay on the downgraded version until the issue is fixed.

[stephen-turner]

Hmmm, that's curious, because that version was the release candidate for 2.2, so should be nearly the same. But you're right, this is working in my experiments too. Maybe it didn't work in all cases, or maybe we broke it while fixing something else. I will consult with the lead engineer on this feature.

[MagicShoebox]

To add some more data to this discussion, I tried to be systematic, created a link of every type I could think of, and tested them both with a Dockerfile COPY instruction and via mount.

Results

Docker Desktop 2.2.0.3 (42716)
Client: Docker Engine - Community
Version: 19.03.5
Server: Docker Engine - Community
Engine:
Version: 19.03.5

C:\test\symbolic>dir
2020-02-24  15:04    <SYMLINKD>     dAbs [C:\test\original]
2020-02-28  14:59    <SYMLINKD>     dExtAbs [C:\external]
2020-02-28  15:00    <SYMLINKD>     dExtRel [..\..\external]
2020-02-24  15:02    <SYMLINKD>     dRel [..\original]
2020-02-28  14:47    <SYMLINK>      fAbs.txt [C:\test\original\foo.txt]
2020-02-24  15:03    <SYMLINK>      fRel.txt [..\original\foo.txt]
2020-02-24  15:03    <JUNCTION>     jAbs [C:\test\original]
2020-02-28  15:00    <JUNCTION>     jExt [C:\external]
2020-02-28  14:47    <JUNCTION>     jRel [C:\test\original]

C:\test>docker run --rm -v C:\test:/mnt/windows alpine ls -l /mnt/windows/symbolic
ls: /mnt/windows/symbolic/dRel: No such file or directory
ls: /mnt/windows/symbolic/fRel.txt: No such file or directory
ls: /mnt/windows/symbolic/jAbs: No such file or directory
ls: /mnt/windows/symbolic/jExt: No such file or directory
total 0
lrwxr-xr-x    1 root     root             0 Feb 24 20:04 dAbs -> ../original
lrwxr-xr-x    1 root     root             0 Feb 28 19:59 dExtAbs -> ../../external
lrwxr-xr-x    1 root     root             0 Feb 28 20:00 dExtRel -> ../../external
lrwxr-xr-x    1 root     root             0 Feb 28 19:47 fAbs.txt -> ../original/foo.txt
lrwxr-xr-x    1 root     root             0 Feb 28 19:47 jRel -> ../original

C:\test>type Dockerfile
FROM alpine
COPY . /windows

C:\test>docker build .
[...]
Successfully built 34839611fbc0

C:\test>docker run --rm 34839611fbc0 ls -l /windows/symbolic
total 0
lrwxrwxrwx    1 root     root            16 Feb 24 20:04 dAbs -> C:\test\original
lrwxrwxrwx    1 root     root            11 Feb 28 19:59 dExtAbs -> C:\external
lrwxrwxrwx    1 root     root            14 Feb 28 20:00 dExtRel -> ..\..\external
lrwxrwxrwx    1 root     root            11 Feb 24 20:02 dRel -> ..\original
lrwxrwxrwx    1 root     root            24 Feb 28 19:47 fAbs.txt -> C:\test\original\foo.txt
lrwxrwxrwx    1 root     root            19 Feb 24 20:03 fRel.txt -> ..\original\foo.txt
lrwxrwxrwx    1 root     root            16 Feb 24 20:03 jAbs -> C:\test\original
lrwxrwxrwx    1 root     root            11 Feb 28 20:00 jExt -> C:\external
lrwxrwxrwx    1 root     root            16 Feb 28 19:47 jRel -> C:\test\original

Analysis

Mount failed on the relative symlinks but successfully converted absolute symlinks to relative. Junctions were the reverse: absolutes failed but the relative succeeded. This is particularly interesting because they look identical from the Windows command-line. Both external links made it into the container with relative paths, but of course they point to a nonexistent location.

Build brought everything into the image with no modifications, so all the absolute links and both junctions are dead. Neither external link works as they point to nonexistent locations.

Comments

The Docker Desktop team has done an amazing job making as much of this work as it does, but symlinks on Windows are a giant pitfall of "works/doesn't work". I'm hoping WSL 2 improves my Docker experience.

[stephen-turner]

Thanks for your experiments, @MagicShoebox.

Following up on my previous comment: it didn’t actually work properly in 2.1.7.0. The files appeared, but they would stop syncing after a while, so you would see stale copies in the container. That’s why we reverted to the previous behaviour where dangling symlinks are just dangling. This matches the behaviour in the old Samba solution, as well as on Linux.

For junctions, we now have a new private build that improves the situation. See #5582 for the main ticket on this.

[tinrie]

Same here. I had to backport to version 2.1.0.5 from 2.2.0.3 Now the links on windows work like expected.

[MagicShoebox]

I just upgraded to 2.2.0.5, so I decided to rerun the tests I ran back on 2.2.0.3.

Results

Docker Desktop 2.2.0.5 (43884)
Client: Docker Engine - Community
Version: 19.03.8
Server: Docker Engine - Community
Engine Version: 19.03.8
containerd Version: 1.2.13
runc Version: 1.0.0-rc10
docker-init Version: 0.18.0

C:\test\symbolic>dir
2020-02-24  15:04    <SYMLINKD>     dAbs [C:\test\original]
2020-02-28  14:59    <SYMLINKD>     dExtAbs [C:\external]
2020-02-28  15:00    <SYMLINKD>     dExtRel [..\..\external]
2020-02-24  15:02    <SYMLINKD>     dRel [..\original]
2020-02-28  14:47    <SYMLINK>      fAbs.txt [C:\test\original\foo.txt]
2020-02-24  15:03    <SYMLINK>      fRel.txt [..\original\foo.txt]
2020-02-24  15:03    <JUNCTION>     jAbs [C:\test\original]
2020-02-28  15:00    <JUNCTION>     jExt [C:\external]
2020-02-28  14:47    <JUNCTION>     jRel [C:\test\original]

C:\test>docker run --rm -v C:\test:/mnt/windows alpine ls -l /mnt/windows/symbolic
total 0
lrwxr-xr-x    1 root     root             0 Feb 24 20:04 dAbs -> ../original
lrwxr-xr-x    1 root     root             0 Feb 28 19:59 dExtAbs -> ../../external
lrwxr-xr-x    1 root     root             0 Feb 28 20:00 dExtRel -> ../../external
lrwxr-xr-x    1 root     root             0 Feb 24 20:02 dRel -> ../original
lrwxr-xr-x    1 root     root             0 Feb 28 19:47 fAbs.txt -> ../original/foo.txt
lrwxr-xr-x    1 root     root             0 Feb 24 20:03 fRel.txt -> ../original/foo.txt
lrwxr-xr-x    1 root     root             0 Feb 24 20:03 jAbs -> ../original
lrwxr-xr-x    1 root     root             0 Feb 28 20:00 jExt -> ../../external
lrwxr-xr-x    1 root     root             0 Feb 28 19:47 jRel -> ../original

(rebuilt Dockerfile as above)

C:\test>docker run --rm 2bef33784219 ls -l /windows/symbolic
total 0
lrwxrwxrwx    1 root     root            16 Feb 24 20:04 dAbs -> C:\test\original
lrwxrwxrwx    1 root     root            11 Feb 28 19:59 dExtAbs -> C:\external
lrwxrwxrwx    1 root     root            14 Feb 28 20:00 dExtRel -> ..\..\external
lrwxrwxrwx    1 root     root            11 Feb 24 20:02 dRel -> ..\original
lrwxrwxrwx    1 root     root            24 Feb 28 19:47 fAbs.txt -> C:\test\original\foo.txt
lrwxrwxrwx    1 root     root            19 Feb 24 20:03 fRel.txt -> ..\original\foo.txt
lrwxrwxrwx    1 root     root            16 Feb 24 20:03 jAbs -> C:\test\original
lrwxrwxrwx    1 root     root            11 Feb 28 20:00 jExt -> C:\external
lrwxrwxrwx    1 root     root            16 Feb 28 19:47 jRel -> C:\test\original

Analysis

Mount succeeded on everything. Absolute paths were converted to relative paths so they still work inside the container. External links were converted, but point to nonexistent locations (as to be expected). This fixes the issue I was seeing in 2.2.0.3.

Build behavior was unchanged. It brought everything into the image with no modifications, so all the absolute links and both junctions are dead. Neither external link works as they point to nonexistent locations.

Comments

Unfortunately I don't have 2.1.0.5 data to compare against, but I think 2.2.0.5 is working as well or better than 2.2.0.3. Thanks so much for improving the experience.

I'm going to test if this fixed my original issue with PHP Composer & local Repository links.

[stephen-turner]

Thanks for testing it, @MagicShoebox.

[docker-robott]

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

[docker-robott]

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