New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NFS] vagrant up hangs while "Mounting NFS shared folders" #5802

Closed
lordgordon opened this Issue Jun 5, 2015 · 32 comments

Comments

Projects
None yet
@lordgordon

lordgordon commented Jun 5, 2015

Hi there,

I'm trying to use NFS with FreeBDS yet every time I run vagrant up it hangs at the "Mounting NFS shared folders".

Output:

==> default: Attempting graceful shutdown of VM...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> 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...

Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.guest = :freebsd
  config.vm.box = "dev-freebsd"
  config.vm.box_check_update = false
  config.vm.network "private_network", ip: "192.168.1.2"
  config.vm.synced_folder ".", "/vagrant", create: true, :nfs => true, :mount_options => ['nolock,vers=3,tcp,noatime,clientaddr=192.168.1.2'], id: "vagrant-root"
end

/etc/exports (host):

# VAGRANT-BEGIN: 501 XXX-XXX-XXX
"/Users/mypath/myrepo" 192.168.1.2 -alldirs -mapall=501:20
# VAGRANT-END: 501 XXX-XXX-XXX

Host: OS X 10.9.5
Guest: FreeBSD 10.1-p10

Actually, the problems seems in the way vagrant runs the mount command in the guest box. While vagrant up hangs I can access the box with vagrant ssh and check the blocking commands:

ps -afxu | grep nfs
mount -t nfs -o nfsv3 192.168.1.1:/Users/mypath/myrepo /vagrant
mount_nfs -o nfsv3 192.168.1.1:/Users/mypath/myrepo

Then if I kill them and re-execute, everything works fine:

sudo killall mount mount_nfs
sudo mount -t nfs -o nfsv3 192.168.1.1:/Users/mypath/myrepo /vagrant

I'm unable to understand why the command issued by vagrant get stuck. Could you please investigate?

Thank you for your help!

Regards,

Nicholas

Further reference: wunki/vagrant-freebsd#4

@lordgordon

This comment has been minimized.

lordgordon commented Jun 6, 2015

Sorry, my fault. I didn't notice the firewall was still enabled during vagrant up.

@lordgordon lordgordon closed this Jun 6, 2015

@bronger

This comment has been minimized.

bronger commented Aug 26, 2015

Because I'm suffering from the same issue currently, I wonder which firewall you mean, and why it is down when you re-execute the command manually? Thank you!

@lordgordon

This comment has been minimized.

lordgordon commented Aug 26, 2015

I have Little Snitch firewall on my host (Mac OS X). I had to temporary disable the firewall the first time to make the NFS mount.

Then, the second time, I recorded the various port used and I placed the correct rules.

@cdaringe

This comment has been minimized.

cdaringe commented Oct 1, 2015

hmmm. i confirmed my firewall is off in OSX.

cdieringer@Snapper-osx:/coins/localcoin$ sudo mount -v -t nfs -o nfsv3 192.168.1.1:/Users/cdieringer/Sublime/ /coins/test
mount_nfs: option nfsv3 deprecated, use vers=#
mount_nfs: can't mount /Users/cdieringer/Sublime/ from 192.168.1.1 onto /coins/test: Operation timed out

still searching for the cause

@bronger

This comment has been minimized.

bronger commented Oct 2, 2015

Maybe something in NFS is still hanging from a previous run. I solved the issue by restarting the NFS server every time before I call "vagrant up".

@lordgordon

This comment has been minimized.

lordgordon commented Oct 2, 2015

Hi there,

I no longer had the problem. I checked back my setup and I confirm the settings I already posted in this thread. To help out others, I add there further settings.

In OS X firewall settings (stealth mode is ON):

netbiosd           block incoming connections
nfsd                  allow incoming connections
rpc.lockd          allow incoming connections
rpc.rquotad      allow incoming connections
rpc.statd          allow incoming connections
rpcbind            allow incoming connections
VirtualBoxVM  allow incoming connections

In your guest OS (FreeBSD) make sure that NFS is enabled and the firewall is correctly set up. In my case I have pf and it allow everything as I use Little Snitch on OS X as global firewall.

/etc/rc.conf in FreeBSD (relevant parts to NFS and Vagrant only):

# Firewall
pf_rules="/etc/pf.conf"
pf_enable="YES"

# SSH
sshd_enable="YES"

# Virtualbox
vboxguest_enable="YES"
vboxservice_enable="YES"

# NFS
rpcbind_enable="YES"
nfs_client_enable="YES"

# extra settings
dbus_enable="NO"
avahi_daemon_enable="YES"
avahi_dnsconfd_enable="NO"
rsyncd_enable="NO"

/etc/pf.conf in FreeBSD (with a jail nat):

# Interfaces
ext_if = "em0"
int_if = "lo1"

jail_net = $int_if:network

# NAT
set skip on lo1
nat pass on $ext_if from $jail_net to any -> $ext_if
@lordgordon

This comment has been minimized.

lordgordon commented Oct 2, 2015

@bronger True: every time I changed the firewall settings I had to restart NFS.

@bradleyflood

This comment has been minimized.

bradleyflood commented Oct 25, 2015

For anyone on OSX check your Firewall preferences System Preferences -> Security & Privacy -> Firewall -> Firewall Options.
Make sure Automatically allow signed software to receive incoming connections is checked.

Otherwise just disable the OSX Firewall altogether if you don't need it.

@lordgordon

This comment has been minimized.

lordgordon commented Oct 26, 2015

@bradleyflood Actually, I don't have that option enabled and it works fine. In fact I don't think is a good security suggestion.

Please look at your settings, it's not necessary to disable the firewall to make NFS working properly with Vagrant.

@mtpereira

This comment has been minimized.

mtpereira commented Jan 25, 2016

Hello,

I've just tested on Yosemite and these are the daemons that I had to allow on my firewall so that the shared folder was successfully mounted:

  • nfsd
  • rpcbind

It wasn't necessary to restart nfsd after changing the firewall in order to mount the share.

Thank you!

@Thinkscape

This comment has been minimized.

Thinkscape commented Mar 4, 2016

This issue is far from resolved. It still hangs with different distros, several OSX and Vagrant versions ahead.

Here's another thing that sometimes helps:

Restart nfsd on the osx host

sudo nfsd restart

nfsd might be sensitive to power state changes, osx low-power modes, network state changes etc. Restarting it before vagrant up might help with the issue.

@EvanK

This comment has been minimized.

EvanK commented May 6, 2016

I'm running into this same issue (hanging on Mounting NFS shared folders...) on OSX, and it's only started today.

I've been using vagrant (and this particular project VM with an NFS mount) for years, and the latest 1.8.1 version of vagrant since its release. The specific line from my Vagrantfile:

web.vm.synced_folder ".", "/vagrant", :nfs => true

I've tried destroying the vm, emptying the /etc/exports file, restarting nfsd and rpcbind. No joy.

In fact, the only thing that seemed to work was rebooting the entire OS...and the problem appeared again within an hour.

@dacodekid

This comment has been minimized.

dacodekid commented May 10, 2016

Never had this problem b4, but suddenly hit by this. It works for the first time you create / recreate a machine. Once the VM reboots, it comes back. - OSX - Vagrant 1.8.1.

@EvanK

This comment has been minimized.

EvanK commented May 11, 2016

I've narrowed down my issue to something altogether different: my vms were becoming unreachable at their private ip addresses when a PIA vpn connection was established...and disconnecting it temporarily fixes the issue, so I suspect it was a network routing problem

@yalcinsurkultay

This comment has been minimized.

yalcinsurkultay commented Jun 15, 2016

@EvanK +1

It hangs when I am using VPN (Junos Pulse)

@aaronjwood

This comment has been minimized.

aaronjwood commented Aug 2, 2016

@EvanK @yalcinsurkultay I've noticed that most VPN services (especially ones configured/deployed by your workplace) will by default suck up all connections in your system. For example, if you're on VPN and you spin up a Linux VM and try to SSH to it from your host, you'll see that the traffic gets taken into the VPN. I'm sure this is due to the way they're changing the routing table on your host. At least in my case the routing table gets changed and everything is sent to a different gateway.

@EvanK

This comment has been minimized.

EvanK commented Aug 2, 2016

@aaronjwood The VPN I use from my workplace (a Cisco, iirc) doesn't have this same issue, so it really does seem to be hit or miss ¯_(ツ)

@rabin-io

This comment has been minimized.

rabin-io commented Sep 2, 2016

My 2c for this issue, Had the same problem with my Linux machine running Fedora 24 (using firewalld) and using libvirt as provider, so after reading this thread i enabled the logging option for the FW and start nmap-ing (nmap -p2049 HOST and nmap -p2049 -sU HOST ; for nfs over udp ) from inside the vm to my host (which is the nfs server), and I start seeing the traffic blocked on the virtual interface which was set to use the default zone, I changed the zone to the internal zone and enabled nfs and rpc-bind services for the internal zone, but that solved only the tcp mount option, for mouning using udp, i had to edit the service definition for nfs to include 2049/udp, and that solve my 2nd problem.

@jurgenweber

This comment has been minimized.

jurgenweber commented Sep 20, 2016

I had this again, different machine.. I found I had a broken version of virtual box, VirtualBox-5.1.4 just timed out and did nothing... VirtualBox-5.1.6 works fine.

@taoza

This comment has been minimized.

taoza commented Oct 20, 2016

Another possible cause of the issue is to do with the network interface ordering bug reported from: #7876. Fixed in: #7866

@bashirawaty

This comment has been minimized.

bashirawaty commented Mar 17, 2017

For anyone on OSX check your Firewall preferences System Preferences -> Security & Privacy -> Firewall -> Firewall Option

go to the advanced options and make sure Automatically allow signed software to receive incoming connections is checked.
Or disable the OSX Firewall altogether if you don't need it.

this did work for me and its the simplest solution

@chadfurman

This comment has been minimized.

chadfurman commented May 30, 2017

This issue, for me, is usually caused by network connection issues between Host / Guest. If you don't have firewall issues, then make sure your host's vboxnet0 network is both up and configured with an IP.

Solution for Ubuntu 17.04:

$ sudo ip a add 192.168.33.1/255.255.255.0 dev vboxnet0
$ sudo ip link set vboxnet0 up
@mpmumau

This comment has been minimized.

mpmumau commented Jun 15, 2017

Just an FYI, @chadfurman, as I've noticed your proposed solution in a few different places, that doesn't work to solve the problem for me (hanging on "Mounting NFS shared folders...") in Arch. Not sure why Vagrant isn't working anymore; had previously worked for me for a great number of years until I started having tons of pesky little problems with it like this.

@snfnwgi

This comment has been minimized.

snfnwgi commented Sep 28, 2017

default: 5986 (guest) => 55986 (host) (adapter 1)

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: WinRM address: 127.0.0.1:55985
default: WinRM username: IEUser
default: WinRM execution_time_limit: PT2H
default: WinRM transport: plaintext
==> 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...
==> default: Mounting NFS shared folders...
Vagrant attempted to execute the capability 'mount_nfs_folder'
on the detect guest OS 'windows', but the guest doesn't
support that capability. This capability is required for your
configuration of Vagrant. Please either reconfigure Vagrant to
avoid this capability or fix the issue by creating the capability.

@lordgordon

This comment has been minimized.

lordgordon commented Sep 28, 2017

@snfnwgi

Be aware that NFS is not supported on Windows hosts.

Reference: https://www.vagrantup.com/docs/synced-folders/nfs.html

@snfnwgi

This comment has been minimized.

snfnwgi commented Sep 28, 2017

@lordgordon I am MAC os above windows7 operation, this can not it?

@ArminVieweg

This comment has been minimized.

ArminVieweg commented Oct 2, 2017

@lordgordon Right, but there is a vagrant plugin existing for Windows which provides NFS: https://github.com/winnfsd/vagrant-winnfsd

Unfortunately I've got the same issue, currently. Hang up on "Mounting NFS shared folders". But recently I've increased the harddisk capacity from 40GB to 500GB. Maybe this makes the mounting process incredibly slow. But this is just a guess. Update: Tested with 40GB version. So the size of the virtual hard disk is not the reason.

@giacecco

This comment has been minimized.

giacecco commented Jan 7, 2018

A quick note to thank @rabin-io as the issue is still there on Fedora more than one year later. Other Fedora users may be suffering right now :-)

@subtlegiant

This comment has been minimized.

subtlegiant commented Jan 31, 2018

For those on Fedora running into this issue I was able to resolve doing the following:

  1. Check /etc/exports for duplicate entries and remove any (I just cleared the file).
  2. Restart nfs: sudo systemctl restart nfs
  3. Try doing a vagrant up.

The problem for me was that nfs was failing due to the duplicate entry in the export file. Hope this helps.

@yeongsheng-tan

This comment has been minimized.

yeongsheng-tan commented Mar 24, 2018

@aaronjwood I confirmed VPN is the cause of nfs mount synced_folders issue. I similarly use Juno Pulse.

I tried to run vagrant up via VPN in order to access our RPM repo in our office network, at home, and the obvious routing table changes and new NIC routing interfaces created altered the behaviour of vagrant host to guest networking.

When I switched of/ disconnect from my VPN, the vagrant NFS mount worked (repeatedly tested using vagrant ver 1.9.2, 1.9.8 and 2.0.3 against Virtualbox 5.1.34). However, I can obviously no longer access our office RPM repo and that caused the provisioner to fail, which our provisioning script is written to point our CentOS7 GuestOS to an internal RPM repo.

To get around the above, I disconnect from our VPN, run vagrant up till NFS mount succeeds. At that point, I manually connect to our VPN so that the provisioner can continue to pull in the needed during GuestOS yum install of our internally managed RPM packages.

Thanks for the hint. Not the best solution, but it works and allows me to work from home while continue development.

@abekroenem

This comment has been minimized.

abekroenem commented Mar 26, 2018

I've been stuck in same question, and i solved this by disabling the firewall.

@poncianodiego

This comment has been minimized.

poncianodiego commented Jun 1, 2018

sudo service nfs-kernel-server restart worked for me on Linux Ubuntu 18.04

@Thinkscape I think is kind of the same approach but for linux so thanks for the idea! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment