Vagrant: VMware provider HGFS shared folders broken due to unnecessary kernel module requirement using open-vm-tools 10.x

[ironcladlou]

Using VMware 8.1.0 (3272237) and Fedora 23 guest with open-vm-tools-10.0.0-7.fc23.x86_64, the HGFS kernel module is not present (nor is it required) for shared folder functionality (because it's now a userspace FUSE implementation).

Nevertheless, the vagrant vmware_fusion provider will try (and fail) to detect the HGFS kernel module when using shared folders.

As far as I can tell, this means HGFS shared folders simply don't work with the latest VMware/vagrant/Fedora without trying to install the "legacy" VMware tools package (which is not recommended and shouldn't be necessary).

I'm not sure if this is the right place to report issues with the VMware provider; if there's a separate tracker, please let me know.

[gtirloni]

I'm experiencing the same issue with VMware Workstation 12.1 Pro on Windows 10 64-bit with Vagrant 1.8.1 and a Fedora 23 box.

The vmhgfs kernel module has been deprecated in favor of a FUSE filesystem. I believe Vagrant shouldn't look for this kernel module anymore, as even installing VMtools from the ISO won't install the module.

The vmtoolsd service takes care of initiating the vmhgfs-fuse client to mount the shared folders.

[sykesm]

fwiw, I'm running into this issue as well. I'd very much like to see this resolved in the vmware plugin.

[bovi]

same here. it should at least be possible to de-activate the kernel module check for vmhgfs which isn't necessary anymore today.

[StefanScherer]

Is there a any news when this will be fixed in the vagrant-vmware-fusion plugin? I'm using version 4.0.8

[khromov]

Same issue... Running vmware-config-tools.pl inside the VM and answering yes to this question makes it possible to move forward with HGFS detection.

The VMware Host-Guest Filesystem allows for shared folders between the host OS 
and the guest OS in a Fusion or Workstation virtual environment.  Do you wish 
to enable this feature? [yes] 

You can also not do this through Vagrantfile because the process aborts before provisioners are run....

[kikitux]

from other issue, seems this works:

https://gist.github.com/vadviktor/5aa034bbee6e53d26b70

[bovi]

@kikitux this is not a solution as the problem isn't the shared folder. the shared folder works for everyone but it does not use the kernel modul. vagrant on the other side seems not to properly check the shared folder funtionality but the existence of the kernel module which is already deprecated since several years.

[tzvetkoff]

At some point VMware changed the tools package and moved HGFS to FUSE instead of being in the kernel.
So far I'm working around this using NFS shares, but since we're _paying_ for the VMware provider support, I'd like to see this fixed.

[ggeldenhuis]

It would be fantastic to get an update on this as it is really useful functionality that is missing. I can confirm the same behaviour for Ubuntu 14.04.4 using kernel 4.2.0-27.

[nickcharlton]

I'm building my boxes with an older Ubuntu 14.04.03 ISO to work around this issue. This has the 3.19 kernel version rather than the 4.2.0 series of the later builds. Hopefully those links can help someone else out.

It seems like the best fix would be to follow the direction VMware are going and remove the check on HGFS.

[juvenal]

This is a real problem to me, as much of the development that I need to do involves Fedora 23 / 24 Alpha. I was using vagrant for a long time, I bought the vmware plugin from Hashcorp to be assured that problems like this should be solved quickly...
@mitchellh, please inform us about a possible plan to solve this...
Thanks.

[dragon788]

Also running into this issue, its possible to work around by installing the legacy vmware tools kernel module, but not very user friendly and a step backwards in functionality.

[111A5AB1]

This issue was opened on Jan 2, and currently has no milestone or assignee. This is a bit disappointing as the VMware plugin is a licensed product costing $79 per seat. Any ETA or progress on resolving this so that share folders work correctly with: config.vm.synced_folder ".", "/vagrant"?

[wyaeld]

@sethvargo we need some sort of communication or eta on this. Vagrant is a pretty important part of a lot of our workflows, even more so when using certain platforms cough _vmware_ which don't have the developer ease of use.

I realize vagrant is a very complex codebase, and people have competing priorities, but there are too many issues and PRs sitting around with no maintainer input.

[choco]

This is getting ridiculous, almost 5 months without any sign of a fix on the way.... What's worse no communication either.

[tomislav]

Yeah, I was told by Hashicorp support to use old boxes and not to even use the latest VMware Fusion because it had some kind of networking bug... and they continue to sell the plugin. I got into the Docker for Mac beta and looking into using that to replace my Vagrant workflow.

[bovi]

@tomislav was that really an official answer from hashicorp to not use the latest vmware fusion version??? that is hilarious due to the reason that they usually come out with a new vmware plugin for supporting new versions but without any additional features.

on the other side you get open source attitude, with shareware prices and closed software quality. the best from all words 💩😷

[tomislav]

Thanks for your email.

Per the log, it seems the HGFS module is not present on the VM.

Can you please test with hashicorp/precise64 box ?

As today Vagrant requires the HGFS module for be able to mount the shared folders.

Additionally, there is a VMWare fusion issue with 8.1.* and forwarded ports, if you hit issues that Vagrant can't connect on the 22nn port, please try to go to Fusion 8.0.2 since thats the last one known to work without issues.

[gtirloni]

There is no HGFS module with latest VMware versions anymore. That's the point.

Agreed this is open source attitude, shareware prices and proprietary software quality. This sucks. I've paid for the Vmware plugin and I'm back to VirtualBox. This sucks, I'm so frustrated.

[rmoriz]

I understand, that Hashicorp now focuses on enterprise products, that VMWare is not very cooperative and "recent" changes introduce a lot of issues that need to be addressed.

IMHO there are two+ options:

• fix it, hire people to fix it
• discontinue the product, release the existing plugin as OSS so people can contribute without having to reverse engineer the ruby encoder obfuscated code and become criminals…
• something better

So, @mitchellh what's your decision?

[geerlingguy]

So far I'm working around this using NFS shares, but since we're paying for the VMware provider support, I'd like to see this fixed.

That's the crux of the issue for me. I paid for the plugin twice now (v7 and v8), and I'd gladly pay again for a new version of VMware if needed, but not if I'm going to run into these kinds of bugs and not have any credible solution (currently I'm telling people to override with NFS or SMB) or even official response for months...

I'm seriously considering dropping my support for VMware for the OSS boxes I maintain, just because the number of bug reports I get due to this issue is getting annoying. The sad thing is, AFAICT, my ubuntu1604 box is one of the only VMware boxes that can currently work around _another_ bug that's been fixed in Vagrant master, but the fix isn't available to anyone because Vagrant itself has not seen a tagged release since 1.8.1 months ago...

[Jalle19]

This really is a show stopper. We're using the VMware provider for a Symfony project because VirtualBox's shared folder implementation is a bit slow. Rsync is out of the question since we need two-way syncing and NFS is out of the question since one developer uses Windows. This leaves us with VMware using shared folders, but even that won't work without crazy hacks because of this issue.

If we can't find a solution we'll have to forego Vagrant and use bare virtual machines for the time being, which is truly sad considering this is a paid product.

[khromov]

fwiw, we've been using the cbednarski/ubuntu-1404 box for a while now and it's the only box that consistently works without causing the HGFS issue.

[111A5AB1]

I contacted support regarding this which was very unhelpful, it went something like this (portions trimmed for brevity):

May 1
Contacted support with a link to this github issue, advised them that:

• HGFS kernel model has been deprecated and no longer needed.
• I was able to mount folders just fine in Arch Linux with open-vm-tools.

May 4
Alvaro Miranda (HashiCorp) responded:

We would review any proposal in the form of Pull Request if you would like to give it a go.

Replied that I don't see how I can submit a Pull Request on a closed source product that is not on github. I linked to their own VMware plugin page (https://www.vagrantup.com/vmware/) and quoted it:

"PROFESSIONAL SUPPORT
Every purchase of the Vagrant VMware provider comes with direct email support. VMware products themselves are eligible for professional support from VMware. Someone always has your back in case things are not working as well as they should be."

"OPEN SOURCE
Vagrant is free and open source. While the VMware providers are not"

May 5
Alvaro Miranda (HashiCorp) responded:

You are right, I will contact the Developers and see if there is any update on their end.
At the moment there is no ETA for that open-vm-tools feature and Vagrant VMWare expect the normal vmtools to be installed.

I replied and pointed out that using vmtools is contrary to VMware's own advice:

"It is recommended that open-vm-tools be used for the Linux distributions where open-vm-tools is available. VMware will not provide OSPs for operating systems where open-vm-tools is available." (https://github.com/vmware/open-vm-tools#will-there-be-continued-support-for-vmware-tools-and-osp)

May 19
Alvaro Miranda (HashiCorp) responded _(Note two weeks later)_

The work for make Vagrant to work with open-vm-tools is underway, however at early stage so there is no ETA at the moment.
If you could create a VM with normal vmware-tools in the meantime will be great.
I can understand this is not the optimal, so perhaps I can process the 30 days refund for you.

May 24
Apparently it's OK for them to take 14 days to reply but 5 days is too long for customers. My ticket was apparently closed [as "Solved"] and I received a "How would you rate the support you received?" email from their system.

vagrant-sshfs work-around
@Jalle19 @geerlingguy et. all. Until Hashicorp resolves this (which I don't have high hopes based on the above support interaction) one possible workaround is vagrant-sshfs, "a vagrant plugin that adds synced folder support for mounting folders from the Vagrant host into the Vagrant guest via SSHFS" found at https://github.com/dustymabe/vagrant-sshfs. Best of all its free! This is what I'm using as a work around now as its "cross platform", with the caveat as noted in the documentation being:

The drawbacks with this approach:
Performance is worse than an implementation like NFS
There must be sftp-server software on the Vagrant host
On windows you only need to install openssh via cygwin and you will get sftp-server.

Hope this helps anyone that may be in the same situation and need a working alternative solution until Hashicorp fixes this.

[bovi]

Thanks for the further information. It is interesting that you linked to this post and yet nobody from Hashicorp ever replied here. I also contacted them but never got an answer.

For all these so called workarounds (nfs, raync, sshfs, etc.): The one point and really only point of using VMWare with Vagrant is that the performance of VirtualBox sucks. So a suggestion like the file sync which can easily be outperformed by VirtualBox defeats the purpose of a VMWare plugin.

Furthermore the only immediate issue with the vmware plugin is, that it checks for the kernel module. I'm not sure how shitty the vmware-plugin code is, but if it takes more than 10min to find and skip such a check I would be shocked.

I'm now using the vmware plugin since the very first version and since then I bought every single upgrade also to support the overall business around Vagrant. I'm deeply disappointed that nobody answers to this thread. If they openly say that they are not competend enough to fix this issue but also don't want to open-source the plugin it's fine. But how hard can it be to provide at least an official reply to clarify the status.

[Jalle19]

@111A5AB1 thanks for the information, it's indeed pretty sad that simply removing a check is too much.

[mitchellh]

Hi all, I was just directed to this issue. This does indeed sound like a real issue that needs to be fixed.

I'm sorry I didn't respond earlier, this is the first time I'm hearing of this issue (and HashiCorp support did finally escalate this to me). I've just woken up for the day and need to take some family to the airport. After I return I'll look at this and fix this issue today (if it is that simple). I apologize for not finding this earlier but I hope you can understand that as much as I want to be able to simply handle issues on a daily basis for the projects I love, I have other duties to fulfill that take up too much of my time. This should've been escalated earlier and that is a failure on us. I'll take a look today and update this ASAP.

[Jalle19]

Thanks for the update, let's hope it's indeed a simple fix.

[mitchellh]

As an update, here is where I'm at currently:

I'm using a box with open-vm-tools installed. I verified that vagrant up currently hangs on waiting for HGFS. I then _disabled_ this check, and ran it again, and now VMware itself is failing to mount the synced folders using the VMware API. The error verbatim from VMware is: "Error: There was an error mounting the Shared Folders file system inside the guest operating system."

So this may also require a reimplementation in how the plugin actually mounts the folders as well, but that isn't certain yet. I'm still digging. I have confirmed though that this isn't a simple "disable the check" fix.

[cbednarski]

@mitchellh Is the gist @kikitux linked earlier any help? https://gist.github.com/vadviktor/5aa034bbee6e53d26b70

[dragon788]

There used to be some documentation on the Arch Wiki about how to work
around this problem. But the latest update states that to build vmblock
(required for hgfs legacy style share folders), you have to disable FUSE at
the kernel level. https://wiki.archlinux.org/index.php/VMware#Installation

• fuse https://www.archlinux.org/packages/?name=fuse - the
  vmware-vmblock-fuse service is favored
  https://www.mail-archive.com/[email protected]/msg00213.html
  over
  the vmblock module, and the vmblock module not built anymore without
  disabling fuse http://cateee.net/lkddb/web-lkddb/FUSE_FS.html in the
  kernel

It is my recollection that the Vagrant plugin for VMware logs in and runs
mount -t vmhgfs host:-vagrant /vagrant or something like that. The issue is
that with the new style fuse model, it will probably need to be calling
vmware-hgfsclient and figuring out the available folders (to make sure the
modules are working) and then performing a mount against any (all) that are
present according to the Vagrant plugin's logic for which folders the user
requested.

On Tue, May 31, 2016 at 3:07 PM, Chris Bednarski [email protected]
wrote:

@mitchellh https://github.com/mitchellh Is the gist @kikitux
https://github.com/kikitux linked earlier any help?
https://gist.github.com/vadviktor/5aa034bbee6e53d26b70

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mitchellh/vagrant/issues/6775#issuecomment-222804118,
or mute the thread
https://github.com/notifications/unsubscribe/AAdxXg7E9pWxyO9WbaQAnaL-rteLaZeqks5qHJTugaJpZM4G9bKl
.

[mitchellh]

Yeah that helped, so with the new open-vm-tools we have to use vmhgfs-fuse to mount things. I'm now working on the logic to detect that.

[cbednarski]

@mitchellh I forget the exact kernel version where this changed but IIRC it changed in the jump between 3.19 and 4-series, when the vmware-tools fuse stuff was merged into mainline. So easiest way is probably to check the guest kernel version <= some number.

You can test the old version using my box cbednarski/ubuntu-1404, which has the old kernel (3.19) that is the latest one that works works with HGFS. If you update the kernel in that VM to the latest it will switch to the fuse type of kernel (4-series I think). Also if you use the latest 14.04.4 installer they have updated the kernel past the HGFS compatibility (so I presume this is fuse now).

[mitchellh]

I have a patch. Waiting on reviews and a bit more QA and we'll cut an update.

[mitchellh]

Reopening until release.

[mitchellh]

In v4.0.9 of the plugin. Please verify the fix yourselves and report back if there are problems. Please note that the guest must have open-vm-tools installed and /mnt/hgfs must exist (seems to be a VMware requirement).

[111A5AB1]

Hi @mitchellh, can you clarify why you say /mnt/hgfs must exist and that it seems to be a VMware requirement? I am able to manually mount a share fine to /mnt with open-vm-tools installed. I sent the following details to Support in my original support request on 1 May:

[vagrant@arch ~]$ uname -a
Linux arch 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux

[vagrant@arch ~]$ vmhgfs-fuse --version
vmhgfs-fuse: version 1.6.2.0

FUSE library version: 2.9.5
fusermount version: 2.9.5
using FUSE kernel interface version 7.19

[vagrant@arch ~]$ sudo vmware-hgfsclient
Images

[vagrant@arch ~]$ ls -alh /mnt
total 8.0K
drwxr-xr-x  2 root root 4.0K Oct  1  2015 .
drwxr-xr-x 17 root root 4.0K Apr 27 14:24 ..

[vagrant@arch ~]$ sudo vmhgfs-fuse -o allow_other .host:/Images /mnt

[vagrant@arch ~]$ ls -alh /mnt
total 12K
drwxr-xr-x  1  502 utmp  136 May  1 22:39 .
drwxr-xr-x 17 root root 4.0K Apr 27 14:24 ..
-rw-r--r--  1  502 utmp 6.1K May  1 22:39 .DS_Store
drwxr-xr-x  1  502 utmp   68 May  1 22:39 Folder_On_Host_System

[cbednarski]

@111A5AB1 As you can see in this example, you must create /mnt/hgfs in order for this feature to work automatically. Overall there's a lot less work involved now, though.

[111A5AB1]

@cbednarski Hi thanks for your reply and links, however I'm not using Ubuntu and your post doesn't answer my previous question regarding _why_ with the plugin /mnt/hgfs must be created. I created a custom packer Arch install that I'm using in Vagrant and already updated my packer script to mkdir /mnt/hgfs for testing purposes of the plugin. However, as show in my post above I am able to manually mount folders fine without /mnt/hgfs existing. So I'm trying to understand why its only this plugin that demands /mnt/hgfs to exists. Being forced to mount to /mnt/hgfs doesn't work with my workflow, I would prefer to be able to choose my own Guest mount location and avoid having to create a symlink (e.g. /some_folder/my_intended_mount_location -> /mnt/hgfs).

[Jalle19]

I don't mind creating a /mnt/hgfs directory, but does that mean that all shared folders will appear inside that directory or can we still mount things on /vagrant?

[111A5AB1]

I think this issue was closed prematurely. Has anyone actually gotten this to work? It just hangs for me; and yes I created /mnt/hgfs 😃 .

VMware Fusion > About VMware Fusion:

VMware Fusion Professional Version 8.1.1 (3771013)

% /Applications/VMware\ Fusion.app/Contents/Library/vmrun | grep version 
vmrun version 1.15.3 build-3771013
% vagrant --version
Vagrant 1.8.1
% vagrant plugin list
vagrant-share (1.1.5, system)
vagrant-sshfs (1.1.0)
vagrant-vmware-fusion (4.0.9)

vagrant up with Vagrantfile containing config.vm.synced_folder ".", "/mnt/hgfs", disabled: true:

==> default: Configuring network adapters within the VM...
% vagrant ssh
arch% uname -a
Linux arch 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux
arch% pacman -Q open-vm-tools
open-vm-tools 6:10.0.7-4
arch% vmhgfs-fuse --version
vmhgfs-fuse: version 1.6.2.0

FUSE library version: 2.9.6
fusermount version: 2.9.6
using FUSE kernel interface version 7.19
arch% ls /mnt
hgfs

vagrant up with Vagrantfile containing config.vm.synced_folder ".", "/mnt/hgfs" just hangs at:

==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...

[StefanScherer]

The Vagrant VMware Plugin 4.0.9 works fine, tested on OSX and Windows 7. The boxcutter/ubuntu1404 box 2.0.17 works right out of the box again.

[111A5AB1]

@StefanScherer Thanks for the feedback. Can you provide specific version details like I provided in my above post? I would like to see if there is any difference other than Arch vs Ubuntu. I'll grab boxcutter/ubuntu1404 as well and try to run locally to see if file sharing works on my system with that image to help narrow down what the issue might be. Cheers.

[StefanScherer]

@111A5AB1 OK.

This is what I did on a Windows 7 machine, VMware Workstation Pro 12.1.1, Vagrant 1.8.1:

vagrant init boxcutter/ubuntu1404
vagrant plugin update
vagrant up --provider vmware_workstation
vagrant ssh
ls -l /vagrant

So just a standard Vagrantfile with the default shared folder.

PS C:\Users\stefan.scherer\GitHub\ubuntu> vagrant up --provider vmware_workstation
Bringing machine 'default' up with 'vmware_workstation' provider...
==> default: Cloning VMware VM: 'boxcutter/ubuntu1404'. This can take some time...
==> default: Checking if box 'boxcutter/ubuntu1404' is up to date...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.219.132:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Forwarding ports...
    default: -- 22 => 2222
==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
    default: -- C:/Users/stefan.scherer/GitHub/ubuntu: /vagrant
PS C:\Users\stefan.scherer\GitHub\ubuntu> vagrant ssh
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 4.2.0-27-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
----------------------------------------------------------------
  Ubuntu 14.04.4 LTS                          built 2016-04-26
----------------------------------------------------------------
vagrant@vagrant:~$ uname -a
Linux vagrant 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
vagrant@vagrant:~$ ls -l /mnt
total 5
dr-xr-xr-x 1 root root 4192 Jun  1 07:03 hgfs
vagrant@vagrant:~$ ls -l /vagrant
total 4
-rwxrwxrwx 1 vagrant vagrant 3103 Jun  1 06:12 Vagrantfile

[cbednarski]

I don't mind creating a /mnt/hgfs directory, but does that mean that all shared folders will appear inside that directory or can we still mount things on /vagrant?

@Jalle19 No, things can still be mounted wherever you like. /mnt/hgfs (in the guest OS) is somehow related to how vmrun enableSharedFolders works. When I tried without /mnt/hgfs, vmrun enableSharedFolders failed; after adding this it worked. There seems to be some magic here but I haven't spent more time looking into this.

with Vagrantfile containing config.vm.synced_folder ".", "/mnt/hgfs"

@111A5AB1 Sorry, this is not what I meant. You don't need to mount _to_ this location in this in your Vagrantfile, you just need to have this folder exist inside your VM. You can omit / customize the Vagrantfile mount points as usual.

I tested this with my Ubuntu 16.04 box; I have not tried with other unixes yet (and I presume Windows is different). open-vm-tools is in the kernel source tree now it and may be tweaked by your distro maintainers, so it's possible the rules here vary between distros.

[khromov]

If /mnt/hgfs needs to be created, perhaps the VMWare Fusion / Workstation plugins can create it automatically? Otherwise it sounds like it might be a breaking change for a lot of boxes that don't have this folder.

[bovi]

Wow, ok something happened.

I can confirm that version 4.0.9 is working with a fresh installed Ubuntu 16.04 and open-vm-tools. This is new and wasn't proper booting and using the shared folder function before. The only gotcha I notice is, that this is not working with the actual vmware-tools (the ones provided together with the VMWare Software). This is not a deal-breaker at all, as VMWare nevertheless suggests to use the open-vm-tools of the distribution. The other gotcha is, that you have to manually create /mnt/hgfs (as already mentioned before).

So, even if it took some time. Thanks for fixing this issue Hashicorp! This helps me actually a lot to move some of my projects to a more recent linux version.

[111A5AB1]

@cbednarski Thanks for the clarification, its good that /mnt/hgfs is nothing more than prerequisite that it exists. I do like the suggestion by @khromov that maybe the plugin can create this directory if it doesn't already exists. I'm still trying to figure out why its hanging with Arch; is there any debugging option I can turn on or logs I can have a look at to see what is happening?

@StefanScherer Cheers, but I'm running on OSX with Fusion. You mentioned you were able to get the plugin working in OSX with boxcutter/ubuntu1404. Can you provide details for that OS? Did you generate the Vagrant box via packer, or is there a pre-built Vagrant box you grabbed from somewhere? I didn't see a pre-built image; not sure if I missed it or if it just needs to be built from Packer. Seeing if the plugin works with boxcutter/ubuntu1404 on my system will help determine if my system is just borked, or if its an issue specific to the packer Arch build.

[StefanScherer]

@111A5AB1 Just type in the command, it will work on your machine as well :-)

The boxcutter/ubuntu1404 is available in Atlas by HashiCorp and you just can run vagrant init boxcutter/ubuntu1404; vagrant up --provider vmware_fusion, it will download the box and spin it up.

The packer configs are available at their GitHub repo boxcutter/ubuntu, and there are other platforms as well.

[111A5AB1]

@StefanScherer As yes, thanks. Your earlier link to Github threw me off, I was looking on there thinking thats where the Vagrant box was suppose to be and couldn't find it. The HGFS ran just fine with Ubuntu; however I couldn't find the "open-vm-tools" package installed and it looks like based on the file system and the doco that it's running VMware tools, and not open-vm-tools:

VMware Tools 10.0.5
https://atlas.hashicorp.com/boxcutter/boxes/ubuntu1404

However @bovi found version 4.0.9 is working with a fresh installed Ubuntu 16.04 and open-vm-tools, but not the VMware tools which seems to the opposite of the 14.04 box. So I'll start trying to have a closer look at why the plugin seems to be failing with Arch Linux and open-vm-tools; which might be difficult given its closed source.

@cbednarski I am able to manually mount file shares in my Packer built Arch Vagrant box using vmhgfs-fuse, so that leads me to believe its an issue with the plugin still and not my build.

[mitchellh]

For all, @cbednarski is spot on for why /mnt/hgfs needs to exist.

As others have said, it is possible in the future for the plugin to create this for you. I just wanted to make sure to get a release out as quick as possible that can get people working again on these platforms. If you run into any other issues please let me know.

[StefanScherer]

@111A5AB1 Yes I also wonder why the boxcutter/ubuntu1404 works with VMware Tools installed instead of open-vm-tools. But it's probably better to switch over to the open-vm-tools, I've opened boxcutter/ubuntu#66 and send a PR if I find some time for it.

[cbednarski]

Otherwise it sounds like it might be a breaking change for a lot of boxes that don't have this folder.

@khromov This is not a breaking change because this is new functionality. If your box does not support this then shared folders will not be enabled. They would not have been enabled before either.

The only gotcha I notice is, that this is not working with the actual vmware-tools (the ones provided together with the VMWare Software).

@bovi This is because of a bug in the vmware tools installer which does not correctly identify newer kernels. There is a workaround which consists of installing open-vm-tools and then _also_ using the proprietary vmware tools installer.

Fortunately you don't need to do this anymore. You _do_, however, have to identify whether you should use the proprietary VMware tools installer or open-vm-tools. Try open-vm-tools first since newer kernels will support this. (Potentially any kernel after 3.10, 4.* for sure.)

... with Arch Linux and open-vm-tools; which might be difficult given its closed source.

@111A5AB1 open-vm-tools is completely open source and is maintained by VMware. IIRC the FUSE driver is in the linux kernel source tree (maybe other parts, too). If there is a problem with open-vm-tools in a particular distro, try their issue tracker or mailing lists.

Yes I also wonder why the boxcutter/ubuntu1404 works with VMware Tools installed instead of open-vm-tools.

@StefanScherer The previous plugin version's support for HGFS via kernel module (instead of FUSE) was not removed, and is still tried first. If your box worked with HGFS before it will continue working with HGFS with the 4.0.9 plugin.

[111A5AB1]

@cbednarski Hi Mate, my comment about closed source was in reference to the Vagrant VMware plugin. i.e. it was hard to troubleshoot and debug why it was hanging for me when I couldn't see the source code to follow what it was doing.

@cbednarski @mitchellh
I've identified why the plugin was not working on my Arch box. Apparently installing open-vm-tools package via pacman does not set the vmtoolsd service to start upon boot; it has to be manually turned on [:rolls eyes:].

I discovered this by using the vmrun command-line tool:
% /Applications/VMware\ Fusion.app/Contents/Library/vmrun -T fusion addSharedFolder ./1464757726.vmx cmdTest /Users, which after a short period timed out with Error: The VMware Tools are not running in the virtual machine. The enableSharedFolders option also responded the same way. So it appears the vmrun command depends on vmtoolsd running in the Guest OS.

However, strangely through the GUI you _can_ check "Enable Shared Folders" and manually add a shared folder to the list, and then mount with vmhgfs-fuse _without_ vmtoolsd running. ¯\_(ツ)_/¯

Unfortunately, with the VMware plugin it just seemed to hang for ever and I never got any error message. That combined with scratching my head why I could manually mount folders gave me the impression it was an issue with the plugin still. Maybe you can add a timeout and a friendly reminder message asking the user if the vmtoolsd tools daemon is running?

Thanks for getting the plugin sorted, and for putting up with the "it doesn't work for me" while I tried to figure it out :)

[ksquaredkey]

4.0.9 is not working for me. Fusion 8.1.1 Pro, Vagrant 1.8.4, fusion plugin 4.0.9, Guest OS CentOS 6.6 box I built in December from Fusion 8.0.x Pro. I tried running the vmhgfs-fuse my self and got exit code 255.

` default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
default: -- /Users/key/Dev/Stash/Server-stuff/cortext-dev-tools/vm: /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

vmhgfs-fuse -o uid=id -u vagrant,gid=500,allow_other '.host:/-vagrant' /vagrant

Stdout from the command:

Stderr from the command:

`

[cbednarski]

@ksquaredkey Since you are having a different problem, please open a new issue so we can follow up. It's hard to keep track of a convo in a closed thread. Thanks!

[bryanhuntesl]

This is a long discussion. What I'd like to know is, have architecture changes in Vmware Fusion (Pro) and/or the underlying distro made the vagrant-vmware-fusion plugin untenable.

If so, I'll just dump VMware and just use Virtualbox (despite the fact it crashes my kernel) - time is life.

$ vagrant plugin list
vagrant-share (1.1.9, system)
vagrant-vmware-fusion (4.0.24)

vmware - Professional Version 8.5.8 (5824040)
Centos CentOS Linux release 7.3.1611 (Core)

[khromov]

@bryanhuntesl It works fine, but your mileage may vary depending on which box you choose. The issue discussed here affects only certain boxes. We've been running VMWare Fusion + Vagrant on a large project for over a year now and it's been working fine (and much faster than VBox).

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.