Mount Fails Due to Incorrect NFS Host?

[jamiejackson]

Test case, with Vagrant 1.7.1 on Windows 7 Enterprise SP1 64-bit.

c:
mkdir www\trynfs\theshare
type NUL > www\trynfs\theshare\foo.txt
cd www\trynfs
vagrant init

Then replace the Vagrantfile with the following

Vagrant.configure(2) do |config|

  config.vm.hostname = "sharetest"
  config.vm.box = "ubuntu/precise64"
  # A private dhcp network is required for NFS to work (on Windows hosts, at least)
  config.vm.network "private_network", type: "dhcp"
  config.vm.synced_folder "./theshare", "/theshare", type: "nfs"

end

vagrant up yields:

Bringing machine 'default' up with 'virtualbox' provider...
...
==> default: Configuring and enabling network interfaces...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit nfs mounting file.
[NFS] Status: halted
[NFS] Start: started
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp,nolock' 172.28.128.1:'/C/www/trynfs/theshare' /theshare

Stdout from the command:

Stderr from the command:

stdin: is not a tty
mount.nfs: mount to NFS server '172.28.128.1:/C/www/trynfs/theshare' failed: timed out, giving up

Then, play around in a vagrant ssh session:

Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-74-virtual x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Feb 19 03:20:00 UTC 2015

  System load:  0.2               Processes:           69
  Usage of /:   2.6% of 39.37GB   Users logged in:     0
  Memory usage: 13%               IP address for eth0: 10.0.2.15
  Swap usage:   0%                IP address for eth1: 172.28.128.3

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

New release '14.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

vagrant@sharetest:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:0a:66:d0
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe0a:66d0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44613 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15252 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:61003494 (61.0 MB)  TX bytes:924133 (924.1 KB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:82:57:fd
          inet addr:172.28.128.3  Bcast:172.28.128.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe82:57fd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:95 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10115 (10.1 KB)  TX bytes:3588 (3.5 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2988 (2.9 KB)  TX bytes:2988 (2.9 KB)

vagrant@sharetest:~$ sudo mount -o 'vers=3,udp,nolock' 172.28.128.1:'/C/www/trynfs/theshare' /theshare
mount.nfs: mount to NFS server '172.28.128.1:/C/www/trynfs/theshare' failed: timed out, giving up
vagrant@sharetest:~$ sudo mount -o 'vers=3,udp,nolock' 10.0.2.2:'/C/www/trynfs/theshare' /theshare
vagrant@sharetest:~$ ls -al /theshare/
total 4
drwxrwxrwx  1 root root    0 Feb 19 02:32 .
drwxr-xr-x 24 root root 4096 Feb 19 03:18 ..
-rwxrwxrwx  1 root root    0 Feb 19 02:32 foo.txt

Notice how if I run the same mount command, but with 10.0.2.2 instead of what the plugin came up with (172.28.128.1), it works.

I'm brand new to this Vagrant plugin, and also to NFS on Windows, so maybe i'm doing something wrong, but my Vagrantfile is very basic, and I think it conforms to the instructions in the README.

[jamiejackson]

I guess this tells me that I can (manually) mount through the NAT interface (eth0 is always NAT in vagrant), but not the private (host-only) interface (eth1).

All of my original questions still stand, but I wanted to mention that.

[GM-Alex]

Could you try to disable your firewall and check again.

[jamiejackson]

That works, thanks. Now that we know it's a firewall issue, do you happen to know what the correct firewall configuration would be if the firewall is re-enabled?

Once I know the procedure, I'll write up a little how-to. (I'm sure other people in the future will have some of the same questions I did.)

[worthwhileindustries]

@jamiejackson You need to configure your firewall to allow all for whatever network scheme you are using. For instance I make my virtual boxes private network on 10.33.33.XXX where XXX are where all my VMs are running. So, I set a firewall rule to allow all traffic in and out for 10.33.33.*

There might be a less "hey let everything in and out" approach but, the network is private and that's how I do it.

[jamiejackson]

@worthwhileindustries Thanks for the response.

I think I follow you. To accomplish that, here's what I would think to do:

In Windows Firewall, I'd create a new inbound rule with a local IP address of 10.33.33.1 and a remote IP range between 10.33.33.2 and 10.33.33.255, and leave the rest at the defaults (all profiles, Domain, Private, and Public, are checked). I'd also specify a static IP of, say, 10.33.33.10 in the Vagrantfile.

The above doesn't seem to work for me, but I wanted to mention what I attempted. I am by no means a Windows firewall expert--I had to look up how to do the above, so please let me know if I did something wrong.

Also, if you really are setting a static IP in your Vagrantfile, that would seem to contradict the "dhcp" stipulation of the README:

# A private dhcp network is required for NFS to work (on Windows hosts, at least)
config.vm.network "private_network", type: "dhcp"

I just tried it (with the firewall disabled), and it does seem to work. Is there some side effect of static IP that I don't know about, or is the README's "dhcp" stipulation inaccurate?

Finally, I also see a VagrantWinNFSd-1.0.11 inbound rule already in place. How does that figure into all of this?

[worthwhileindustries]

@jamiejackson

db.vm.network :private_network, ip: 10.10.10.3

I use comodo so, I'm not sure what it would be. I am not using DHCP so the readme might be wrong. I can only say that if you had the above network configuration. I would just allow incoming and outgoing traffic from any to any from and to range of IP's 10.10.10.0 - 10.10.10.255 with protocols TCP/UDP. I'm not sure which one or if it uses both protocols. I just essentially tell my firewall that all traffic between these range of IP's is safe. You'll have to dig around how to do that in windows firewall.

Obviously, you would have to replace the range of IP's with whatever you are using in your vagrant file.

[GM-Alex]

The module tries to grand admin access through UAM to add the firewall rules by using this script https://github.com/GM-Alex/vagrant-winnfsd/blob/master/bin/setupfirewall.vbs

I think that will not work if you are using a different firewall than the build in of Windows.

So I would say it's more a configuration issue than a bug.

[jamiejackson]

@GM-Alex: So is it supposed to create the needed firewall rules for me, or am I supposed to configure them myself? If the former, it's not working, but I am using the built-in firewall:

Windows Firewall with Advanced Security Microsoft Corporation Version: 6.1.7601.17514

[GM-Alex]

Are there already any entries for winnfsd at your firewall rules?

[jamiejackson]

@GM-Alex: Yes, the details of those rules are here, FWIW: https://github.com/GM-Alex/vagrant-winnfsd/issues/25#issuecomment-75587104

[jamiejackson]

@GM-Alex I'm curious as to why this ticket is closed, BTW. If it's supposed to work out-of-the box with the Windows firewall, then I'd still consider it open.

[GM-Alex]

I closed this issue because it seems for me like a configuration issue. I tested the plugin on all of our company machines and several private ones. And it works on all. So it seems for me that the issue is related to your configuration. Are you using a internet security suite?

[jamiejackson]

I run "System Center Endpoint Protection", but that's anti-malware.

Besides, we've established that the plugin works when Windows Firewall is disabled, so that leads me to believe that Windows Firewall is the only thing in the way.

[jamiejackson]

@GM-Alex I tried again today after a colleague (with the same machine configuration as mine) tried it and reported success. I don't know what's different this time around, but my test is now successful on my machine.

Thanks.

[GM-Alex]

Really strange thing... If you found out more let me know, maybe we are able to figure it out and solve it for others.

[jamiejackson]

Here's a bit more information:

I have my private and public firewalls turned on, and both are configured as "Notify me when Windows Firewall blocks a new program."

After installing the plugin and performing the first subsequent vagrant up, the plugin creates a couple firewall rules--an inbound and outbound rule named VagrantWinNFSd-1.0.11. Although these rules seem to be wide open for C:\Users\15037\.vagrant.d\gems\gems\vagrant-winnfsd-1.0.11\bin\winnfsd.exe, once the vagrant up gets to the NFS share configuration, my firewall prompts me with the following:

If I leave private networks checked, and also check public networks, I end up with two new rules for C:\Users\15037\.vagrant.d\gems\gems\vagrant-winnfsd-1.0.11\bin\winnfsd.exe--one for UDP and one for TCP. Aside from the protocols being specified, they're wide open. Afterwards, things seem to behave as expected.

However, if I leave the defaults (as pictured), then I end up with four new rules for C:\Users\15037\.vagrant.d\gems\gems\vagrant-winnfsd-1.0.11\bin\winnfsd.exe--two private rules are wide open for the specified protocols, two public rules are explicitly blocked for the specified protocols. Afterwards, I seem to have trouble with NFS shares. (Whatever networking is in play for a vbox private network doesn't seem to be considered as private to the firewall.)

As I mentioned before, I'm not experienced with firewalls, but I'm confused as to why I ever get the pictured prompt in the first place. It seems like after having the VagrantWinNFSd-1.0.11 rules, that any traffic would be allowed without prompt.

I have more questions, but I'll wait to read your reply first.