Symlinks on shared volumes not supported

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 :frowning:

Would be to pass one of those storage-opts : dm.mkfsarg and/or dm.mountopt to the devicemapper (

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 did find the 3.02 kinda flakey, but we are still on and older kernel.

when you say ‘I use the following mount options’, can you elaborate how you did configure those on your setup please?

In the docker daemon configuration of the Docker for Windows or in your docker-compose file or docker container/volume creation?

Thanks a lot

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.

Thanks @bbrala for the info.

@rneugeba, any timeframe as when the mfsymlinks integration will be at least started? Or is there a workaround to get this scenario working?

Thank you very much


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!

Check this out

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.

1 Like

Hopefully this will be in beta22 which is slated for next week (week starting 8/8/2015).


I installed the Docker for Windows Beta from here. My npm install command worked when using the local directory syncing. So awesome!


8/8/2015? this is really confusing, do you mean 8/8/2016?

Yes, sorry about that:

I’m not sure if I’m having the same issue as @barnumd but could be related.

I’m using the latest Beta 26 on Windows 10 1607, If I use MKLINK /D test C:\Users and then run docker run --rm -v C:/Code/docker/research/test:/data alpine ls /data I get the following error.

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: mkdir /C/Code/docker/research/test: file exists.

If I use MKLINK /J test2 C:\Users and then run docker run --rm -v C:/Code/docker/research/test2:/data alpine ls /data then I get the full directory listing.

It would seem that junctions are working correctly but symlinks aren’t. The problem I have with this is that I need to use symlinks since the data I’m sharing with the container resides on a network drive forcing me to use symlinks instead of junctions.

Docker for Windows Beta definitely fixed all the issues I was having with npm install on a shared mounted volume. Awesome!

Symlinks on bind mounted volumes are still not working in latest beta for me. They show up in windows as files rather than links and show up as corrupt files in any other containers you mount them in.

Using docker-machine with virtualbox driver this is working (currently my only option).

Not sure if this helps, but instead of using a symlink I added a mount point for a separate drive I want to use under %Userprofile%\Docker using the Disk Management console. Docker seemed to be happy using these folders.

1 Open Disk Management Console
2 Right click on partition / drive you want to use for docker content
3 Click Change Drive Letter and Paths
4 Click Add
5 Select “Mount in the following empty NTFS folder”, and click Browse
6 Navigate to your user folder and select / create a folder to mount under
7 Click OK OK

You can now use this folder which is mapped to the separate partition

1 Like