I’m afraid the problem is not whether windows supports symlinks. The problem is that mounted files are synced between your Windows host and Linux guest (where the Docker engine is running) with the SMB/Samba networking filesystem protocol, and symlinks are not supported there.
We’re working on a better filesystem mechanism, but it will take time.
I started a discussion with the Bash on Windows team, who developed two filesystems in order to support lots of Linux features (including symlinks!) on Windows.
I also created a separate etx4 partition and tried with ext2fsd and mounted it in the rare hope to get around this problem.
And I tried to create a data-container with busybox… Also here… No luck.
Do the symlinks really need to be represented at the host too? And if it is just a sync into the container what if the sync ignores symlinks and does not throw errors?
Same for php community who works with monolithic repositories and use symlinks for vendors in the same project (composer based). Dev environment seems to be impossible under the docker in that case. Thanks for any solutions in future,
If docker really uses SMB to connect to the filesystem, then the ‘mfsymlinks’ mount option will allow symlinks on the client. This will not expose the symlinked files or directories to the host machine, but will make them work internally, e.g. node or vendor symlinks.
Where and how can you set the “mfsymlinks” option? In some docker config? In the Hyper-V Manager? Couldn’t find anything … That really is a serious limitation, you can’t get any node.js based app to work in a container now e.g. - we just tried everything to get it running and gave up… for now we have to go back to Docker Toolbox on Windows
Anyone @Docker can tell me if it makes sense or not and if it’s possible via the Docker for Windows/ Docker Daemon configuration window please ? Or if those options will be passed at some point in a not so far beta release?
Unfortunately Bash for Windows will not help much as:
a) the Linux like filesystem semantics are only avail to Linux processes (and not Windows processes)
b) they are only avail in a subset of the host filesystem used as the root/home directory of the Linux subsystem
@bbrala thanks for the suggestion of mfsymlinks. We are looking into adding it. I have a slight concern that this will only work on the Linux side and might be confusing on the WIndows host side.
Yeah i does only work on the linux side. This is true, but it will fix npm and symlinks in general. I built a development env for out windows hosts and had a lot of time testing and trying to find good ways to mound an SMB share with the best possible performance and least hassle.
I used the following mount options to have the best results:
[“mfsymlinks”, “forceuid”, “noperm”, “nobrl”,“file_mode=0775”, “dir_mode=0775”]
You could also maybe add detection for the Windows version and with that the support SMB version. You can specify the SMB version to mount with, this can also improve the performance. (Mount opions vers=xxx). Default is SMB 1 bah.
I haven’t tried to use it with docker yet, i just saw this thread on connecting through SMB and had some extensive experience when creating our Vagrant development box so just gave my 2 cents.
I’m not sure if you can give mount options when creating a docker container with Docker for Windows. The thing is, this would be Windows specific, and therefor might not be available as a flag.
Just curious how this is going? I like many others are wondering if we should entertain one of the work arounds suggested above or wait? What kind of time frame are we looking at for symlinks to work on NTFS? Thank you!
Also looking for a solution for this to run an apache app.
I experimented a bit and found that you can create symlinks in windows (mklink /d x y) and those symlinks do work in the docker container. You can navigate through them and create files under the link path. What doesn’t work is the ability to create links from the container. But if you can make do by creating all your links from the windows side that might work for you.