NFS synced_folder is broken under 1.9.1

[andronat]

Vagrant version

1.9.1

Host operating system

ProductName: Mac OS X
ProductVersion: 10.11.6
BuildVersion: 15G1212

Guest operating system

Centos 7

Vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "bento/centos-7.2"

  config.vm.network "private_network", ip: "10.11.12.13"

  config.vm.synced_folder "/Users/tasos", "/Users/tasos", :nfs => true
end

Please note, if you are using Homestead or a different Vagrantfile format, we
may be unable to assist with your issue. Try to reproduce the issue using a
vanilla Vagrantfile first.

Debug output

Provide a link to a GitHub Gist containing the complete debug output:
https://www.vagrantup.com/docs/other/debugging.html. The debug output should
be very long. Do NOT paste the debug output in the issue, just paste the
link to the Gist.

Expected behavior

NFS should had mounted

Actual behavior

Get an error:

$ vagrant up
...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
Password:
==> 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 10.11.12.1:/Users/tasos /Users/tasos
result=$?
if test $result -eq 0; then
if test -x /sbin/initctl && command -v /sbin/init && /sbin/init 2>/dev/null --version | grep upstart; then
/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/Users/tasos
fi
else
exit $result
fi


Stdout from the command:



Stderr from the command:

mount.nfs: access denied by server while mounting 10.11.12.1:/Users/tasos

Steps to reproduce

1. vagrant up

Extra

I found that if I do vagrant ssh to the VM after the error and I do a sudo service network restart everything works. I noticed that before the network restart the routes are broken:

# before network restart
# ip route
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100

# after network restart
# ip route
default via 10.0.2.2 dev enp0s3  proto static  metric 100
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100
10.11.12.0/24 dev enp0s8  proto kernel  scope link  src 10.11.12.13
169.254.0.0/16 dev enp0s8  scope link  metric 1003

[andronat]

I downgraded to 1.8.7 and the above Vagrant config works normally

[smelchior]

I also have this issue.
I dug a bit deeper and it happens due to this change in 1.9.1:
166d10d
NetworkManager is running for centos7 but it is not managing the private network interface due to the NM_CONTROLLED=no that is used here
As networkmanager is running, it is restarted but does not bring up the private interface as it is shutdown before. So either it has to be NM_CONTROLLED=yes or the network service needs to be restarted for centos/redhat

[wwek]

Now 1.9.1 still has this problem

[andronat]

Any news on this? I'm completely blocked...

[Artistan]

blocked here also...
reference that may be relevant to network issues...
#8052

[ilmarioranen]

I've lost too much time trying to get NFS mounts working on my new setup, which was:
Mac OS Sierra, Virtualbox 5.1, Vagrant 1.9.1, Ansible 2.2.0.
I also happen to use WunderTools.

As the WunderTools readme advises, downgrading to Vagrant 1.9.0 solves the mounting issue. Phew!

I hope Vagrant 1.9.2 will bring the proper solution to this issue.

[nilsga]

Same here. Had to downgrade to 1.9.0 to get it working.

[ekka21]

Downgrade to v1.9.0 worked for me as well.
Here what I did:

• Bring a VM down with vagrant halt
• Download and install v1.9.0 (no need to uninstall v1.9.1)
• Bring it back up with vagrant up

Link to Vagrant Archives.

[astephensen]

Experienced the same issue here. If anyone is using brew cask to install vagrant you can easily rollback by installing the 1.9.0 commit.

brew cask uninstall vagrant
brew cask install https://raw.githubusercontent.com/caskroom/homebrew-cask/b99d5280a3fae60bc18bf16ab314d9cc84e7af87/Casks/vagrant.rb

[andronat]

Is this #8148 fixing our issue here? Is it going to be released in 1.9.2?

[alexivkin]

This did not fix it for me in 1.9.1. To fix I had to add
/sbin/ifup '#{network[:device]}'
right after
nmcli c reload || true
in
/plugins/guests/redhat/cap/configure_networks.rb

[ascotan]

@astephensen you just saved me hours of debugging this.
I've been trying to figure out why this wasn't working for almost an entire day. Confirmed that 1.9.0 works and 1.9.1 doesn't.
Vagrant 1.9.1, macOS Sierra, Centos 7 guest

[federivo]

OSX El Capitan / vagrant 1.9.1

Same issue. Solved by downgrading to 1.9.0.
@ekka21 I had to uninstall before installing 1.9.0. I didn't work otherwise.

[Kotpes]

@alexivkin Thanks a lot your fix worked for me

[geerlingguy]

Note that Vagrant 1.9.2 will be released sometime today (hopefully!). I'll test and see if it works with NFS + CentOS 7.

[jordimolesblanco]

Just tried with 1.9.2 and ubuntu 16.04 host. I'm getting the same issue.
Going back to 1.9.0 for now.

[geerlingguy]

Testing on macOS 10.12.3 with CentOS 7 guest as well...

It looks like NFS is mounting correctly on macOS hosts with CentOS 7 now, yay!

[andronat]

@jordimolesblanco it is not expected to be fixed on ubuntu. This is a CentOS/Redhat explicit issue. I'm waiting for @geerlingguy's outcome patiently 👂

[geerlingguy]

@andronat - It's working for me in all cases on macOS, at least.

Though, now that S3 is down, just about everything else I try is breaking today :P

[rncain]

This is still breaking for me on Ubuntu guest.

app.vm.box = 'bento/ubuntu-16.04'

Installed Version: 1.9.2
Latest Version: 1.9.2

mount.nfs: access denied by server while mounting 10.10.10.1

[ghost]

The problem persists for me with version 1.9.4

[kiyanwang]

I'm having the same problem i'm running Vagrant 1.9.3 on OSX 10.12.4

[ghost]

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.