Symlinks not possible in Linux guest using Vagrant with VMWare Workstation on Windows hosts

[thewebists]

Seems to me that there is a lot of confusion on this topic. But from what I have gathered there is a fundamental problem with using Vagrant + VMWare Workstation + Windows + Linux VMs.

The specific issue I'm referring it is being able to execute a ln -s /home/vagrant/example /vagrant/link-to-example command within the Linux GUEST without it failing and then being able to successfully ls /vagrant/link-to-example. i.e Create a Linux symlink in a Vagrant share from inside the Linux VM so that it can be using within the VM (the host should just ignore it).

This is as opposed to being able to use a Windows symlink residing in the NTFS share, pointing to a non-shared HOST path, which can then be followed from inside the guest Linux VM.

The latter requirement can apparently be solved by using sharedfolder0.followsymlinks = "TRUE" in the .vmx file. However I've seen several tickets here (e.g #4809 and #5840 ) where this is suggested as a solution to creating Linux symlinks in the guest VM.

---

It seems that VMWare on Windows simply does not support the ability to create a Linux symlink in a shared folder. For more info straight from the horses mouth see Steve Goddard's comments in this thread: https://communities.vmware.com/thread/312591

At least from my perspective, this is a very significant flaw, which would preclude Vagrant + VMWare + Windows from being useful for a large majority of programming projects as many (if not most) major programming frameworks will use symlinks in their file structure.

Also, using NPM under a Vagrant managed Linux VM entails having to use a symlink for the node_modules folder due to restrictions on the length of Windows file paths, which NPM exceeds (e.g. #4815 ).

If this is actually the case, and no viable workaround exists, then it would seem to me that this issue needs to be clearly documented in the Vagrant VMWare plugin pages. I for one have just spent ~2 days getting myself setup to use VMWare with Vagrant only to find out that I won't be able to use it because it doesn't support my projects.

Can I suggest that this issue should be confirmed so that this information can be clearly presented to Vagrant VMWare plugin users?

---

For other Vagrant users reading this, I should point out that VirtualBox supports this functionality just fine. However it has significant performance issues with its shared folder implementation that cannot be easily resolved on Windows hosts. There is vagrant-winnfsd plugin, which goes a long way to solving this, but as of a few months ago, it was not stable enough for day-to-day usage (at least in my environment - ymmv).

[nfloersch]

This is basically the same issue as #5844 too ... because VMWare Workstation (and Fusion) uses Windows file sharing for syncing the folders, symlinks don't work. I tried all sorts of hacks for this. Until VMWare Workstation uses a different way to share folders, that native approach will be a roadblock. Unfortunately, it also turns out that the use of rsync-based synced folders on a Windows guest and host does not work properly. The only solution I found - don't use a Windows host. Which is really pretty ridiculous... considering that Windows is still the primary desktop OS. But for me, I only got NPM working for my Windows guests by using a Mac desktop with rsync folder synchronization. This is a pretty huge roadblock/ requirement and it seems like Hashicorp should try and provide a better solution for folder syncing on A) Windows hosts, and B) Windows guests. I realize there are some serious technical challenges.

[foxx]

Although the fix in #5844 explains how to enable symlinks, using node_modules via shared folders or even NFS results in quite poor performance and, in most cases, random npm errors depending on the guest/host combination.

One option was to use a symlink to move node_modules outside of the shared folder, however even with symlink fixes this still resulted in strange npm errors.

I have spent a while looking into this, and so far the only solution which works across the board, whilst maintaining good performance, is to use bind mounts as part of your project bootstrapping process.

For example;

SRC=./node_modules
DST=`mktemp -d`
mkdir ${SRC}
mount --bind ${DST} ${SRC}

This does however prevent you from accessing node_modules via your host machine, but this isn't usually an issue for most people (unless you want to do ghetto debugging by editing libs in-line with print statements etc)

This also does not persist between reboots, and you have to either run this command every time you restart the guest machine, or add it to /etc/fstab, although you cannot use /tmp as the source as these are sometimes purged periodically.

I'm yet to see a better solution than this, but would welcome comments from @mitchellh and the team.

[mitchellh]

Dup #5474 probably.

Symlinks for VMware is pretty rough. I recommend trying some other synced folder providers.

[foxx]

For anyone seeing this in future, there is a fix here

[Perni1984]

Another fix - although I am not sure if it works with VMWare workstation as I am using VirtualBox:

Using a guest OS with linux kernel > 3.18 (e.g. ubuntu/vivid64):

config.vm.synced_folder "/projectfolder/www", "/var/www", type: "smb", mount_options: ["vers=3.02","mfsymlinks"]

Symlinks are then supported in the guest OS, aswell as smb3 (improved performance for shared folders). One can then move node_modules to another location inside the native filesystem of the guest OS and can then symlink to this location. Nearly no performance hit or whatsoever.