Symlinks on shared volumes not supported

@atrauzzi out of curiosity, are you running npm restore against with the npm packages being restored to a mounted volume?

Yup! I figure it’s not working because that’s an NTFS filesystem.

For a laugh I tried adding myself as an exception to the NTFS symlink blocking policy, but no dice. I’m sure that’s not even relevant, but it was worth a shot.

@friism - Is this something that’s likely to be addressed and if so, is there anywhere I can follow along or maybe even help with testing?

Hi Alexander

as @friism pointed out we are scoping the work for better host filesystem integration but it is significantly non-trivial due to the inherent differences between NTFS and how Linux filesystems work.


Definitely. Thanks for following up, I’ll wait semi-patiently :slight_smile:

@friism: Would probably be a good idea to take a look at syncthing. A service that uses a bittorrent-like protocol to keep remote filesystems in sync across networks. It does pretty well keeping linux/windows fs in sync.

I’d rather not get into adding additional software kludges for this. Seems unnecessary.

I didn’t mean as in add a dependency, I meant take a look at the code :wink: It’s golang (or python) I can’t remember.

I hope this is useful.
This was a big problem for me. The way I got around it was by making a new folder (with suffix) then mounting the symlink link to that folder. I have to tell my application to use the suffix’d folder instead of the symlink with a switch in my config but works pretty well. Here’s my bash file which searches creates etc

(note, this just works with dirs for now)

no symlinks … make useless docker on windows for many usage :
exemple :

  • jhipster
  • node modules

I have to agree with @karatsu

I’m facing the same issue. I’m running ‘npm install’ in a docker container on a mounted volume and it fails on symlinks.

Is there a ticket that we can watch & vote for this to be resolved? Thanks

Symlinks would be greatly appreciated.

I’m trying to use angular-cli, which is based on ember-cli, but it fails to run the ng serve command because broccoli uses symlinks.

It seems like users can get symlink permissions (see here), it might work for the docker background service too.

EDIT: I just informed myself, and I understand that the problem is in the SMB protocol. Giving permissions won’t change a thing.

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.



Hey Michael,

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.

Maybe you want to participate!


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?

Is there any update on this? Without symlinks support on Windows it’s difficult to create a dev environment with docker.

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