"Mounting NFS shared folders..." hangs

[marcvangend]

Potential Fixes

From various discussions in this issue, it seems the following fixes may make NFS synced folders work correctly for any flavor of Linux:

1. If you get a warning like It appears your machine doesn't support NFS, make sure you have NFS installed. For example, on Ubuntu 15.10, sudo apt-get install -y nfs-server.
2. Install the vagrant-vbguest plugin (which will update the Guest Additions inside the VM). Note that this indicates I may just need to rebuild the base boxes for VirtualBox 5.0.8, since the latest versions of the boxes were built with 5.0.4).
3. Make sure the vboxnet interfaces are not being blocked by your system firewall. For Fedora (and many flavors of Linux), check out this guide for more: Get Vagrant's NFS working under Fedora 20.
4. Add mount_options: ['vers=3'] to your synced folder definition in config.yml.

Original Issue

I had an NFS problem which I managed to solve, so I just want to share the solution here in case it helps anyone.

My system is running Arch Linux. To get the NFS shares working properly I obviously had to install the nfs-utils package and get the nfs server running: systemctl enable nfs-server && systemctl start nfs-server. But that wasn't enough. As it turned out, I also needed to install the net-tools package, which contains tools like ifconfig.

[geerlingguy]

I'd like to add some more notes in the docs on setup, because it's not always obvious what people need to do to get NFS going.

[marcvangend]

I think you're right... And it's hard to write docs that cover every possible situation! Arch Linux is probably a bit unusual, compared to other distro's, for not installing not-tools by default - I realize that. All I can do is write it down and hope that others will not have to spend the same time looking for a solution.

[micheal-cooper]

Same problem on Yosemite Mac OS 10.10.5, with
Vagrant 1.7.4
ansible 1.9.3
VirtualBox 5.0.4

I have installed vagrant plugins
vagrant-hostsupdater
vagrant-auto_network
vagrant-nfs_guest

To sudoers, I added:

Cmnd_Alias VAGRANT_EXPORTS_ADD = /usr/bin/tee -a /etc/exports
Cmnd_Alias VAGRANT_NFSD = /sbin/nfsd restart
Cmnd_Alias VAGRANT_EXPORTS_REMOVE = /usr/bin/sed -E -e /*/ d -ibak /etc/exports
%admin ALL=(root) NOPASSWD: VAGRANT_EXPORTS_ADD, VAGRANT_NFSD, VAGRANT_EXPORTS_REMOVE

I have confirmed that nfsd is running in Activity Monitor and that I can use sudo without password.

The vagrant up just hangs at

==> wwstage.drupalvm: Preparing to edit /etc/exports. Administrator privileges will be required...
==> wwstage.drupalvm: Mounting NFS shared folders...

It is timing out, ending with the following error:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o '' 192.168.88.1:'/Users/michealcooper/Code/wwstage.github.xeno' /var/www/wwstage.github.xeno
Stdout from the command:
Stderr from the command:
stdin: is not a tty
mount.nfs: Connection timed out

I suspect it needs a password but cannot ask, but maybe it is Time Zone?

I spent more than a day trying different Drupal local dev environ solutions. I settled on DrupalVM because of the elegance of using vagrant, the developer' s involvement in Drupal core, options like Solr, and the directions for using a pre-existing codebase. I then spent another day wrestling with DrupalVM and Git and trying to get things together, so I would rather not give up and go back to MAMP, so I there is a solution.

---

While it was stalled, I used a different term tab to vagrant ssh in and look at the logs, but I don't see anything particularly interesting.

Time Zone?

The VM's auth.log shows Sep 21 22:44:21 ubuntu sudo: pam_unix(sudo:session): session opened for user root by (uid=0), but I am in Okinawa, where the time zone is JST, so it should say Sep 22 7:44.

Could the fact that the VM is 9 hours behind the host affect the creation of the NFS shares? I would think so.

When I do /var/log$ sudo tail syslog, I see that it is trying to nudge the time up, but the gap is too great:

Sep 21 22:18:33 ubuntu kernel: [   17.578888] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Sep 21 22:18:35 ubuntu ntpdate[693]: step time server 91.189.94.4 offset 1.564148 sec
Sep 21 22:18:35 ubuntu kernel: [   18.582398] NFS: Registering the id_resolver key type
Sep 21 22:18:35 ubuntu kernel: [   18.582407] Key type id_resolver registered
Sep 21 22:18:35 ubuntu kernel: [   18.582408] Key type id_legacy registered
Sep 21 22:18:48 ubuntu ntpdate[1547]: adjust time server 91.189.94.4 offset -0.001986 sec
Sep 21 22:18:58 ubuntu ntpdate[1557]: adjust time server 91.189.94.4 offset 0.000764 sec
Sep 21 22:19:13 ubuntu ntpdate[1567]: adjust time server 91.189.94.4 offset -0.001453 sec
Sep 21 22:19:25 ubuntu ntpdate[1578]: adjust time server 91.189.94.4 offset 0.000050 sec
Sep 21 22:19:58 ubuntu ntpdate[1588]: step time server 91.189.94.4 offset -0.000175 sec

I found http://jeremykendall.net/2014/10/06/forcing-an-ntp-update/ but am not sure how to work it. I am not familiar enough with Ubuntu or Vagrant.

---

My config.yml, with "xyz" and "mysite" used for anonymity::

---
# `vagrant_box` can also be set to geerlingguy/centos6, geerlingguy/centos7,
# geerlingguy/ubuntu1204, parallels/ubuntu-14.04, etc.
vagrant_box: geerlingguy/ubuntu1404
vagrant_user: vagrant
# If you need to run multiple instances of Drupal VM, set a unique hostname,
# machine name, and IP address for each instance.
vagrant_hostname: mysite.drupalvm.dev
vagrant_machine_name: mysite.drupalvm
vagrant_ip: 192.168.88.90
# Allow Drupal VM to be accessed via a public network interface on your host.
# Vagrant boxes are insecure by default, so be careful. You've been warned!
# See: https://docs.vagrantup.com/v2/networking/public_network.html
vagrant_public_ip: ""
# A list of synced folders, with the keys 'local_path', 'destination', 'id', and
# a 'type' of [nfs|rsync|smb] (leave empty for slow native shares). See
# http://docs.drupalvm.com/en/latest/extras/syncing-folders/ for more info.
vagrant_synced_folders:
  # The first synced folder will be used for the default Drupal installation, if
  # build_makefile: is 'true'.
  - local_path: ~/Code/mysite.github.xyz
    destination: /var/www/mysite.github.xyz
    type: nfs
    create: true
# Memory and CPU to use for this VM.
vagrant_memory: 1024
vagrant_cpus: 2
# Set this to false if you are using a different site deployment strategy and
# would like to configure 'vagrant_synced_folders' and 'apache_vhosts' manually.
build_makefile: false
drush_makefile_path: /vagrant/drupal.make.yml
# Set this to false if you don't need to install drupal (using the drupal_*
# settings below), but instead copy down a database (e.g. using drush sql-sync).
install_site: false
# Settings for building a Drupal site from a makefile (if 'build_makefile:'
# is 'true').
drupal_major_version: 8
drupal_core_path: "/var/www/drupal"
drupal_domain: "drupalvm.dev"
drupal_site_name: "Drupal"
drupal_install_profile: standard
drupal_enable_modules: [ 'devel' ]
drupal_account_name: admin
drupal_account_pass: admin
drupal_mysql_user: drupal
drupal_mysql_password: drupal
drupal_mysql_database: drupal
# Additional arguments or options to pass to `drush site-install`.
drupal_site_install_extra_args: []
# Cron jobs are added to the root user's crontab. Keys include name (required),
# minute, hour, day, weekday, month, job (required), and state.
drupalvm_cron_jobs: []
  # - {
  #   name: "Drupal Cron",
  #   minute: "*/30",
  #   job: "drush -r {{ drupal_core_path }} core-cron"
  # }
# Drupal VM automatically creates a drush alias file in your ~/.drush folder if
# this variable is 'true'.
configure_local_drush_aliases: true
# Apache VirtualHosts. Add one for each site you are running inside the VM. For
# multisite deployments, you can point multiple servernames at one documentroot.
# View the geerlingguy.apache Ansible Role README for more options.
apache_vhosts:
  - servername: "mysite.drupalvm.dev"
    documentroot: "/var/www/mysite.github.xyz"
  - servername: "xhprof.drupalvm.dev"
    documentroot: "/usr/share/php/xhprof_html"
  - servername: "pimpmylog.drupalvm.dev"
    documentroot: "/usr/share/php/pimpmylog"
apache_remove_default_vhost: true
apache_mods_enabled:
  - expires.load
  - ssl.load
  - rewrite.load
# MySQL Databases and users. If build_makefile: is true, first database will
# be used for the makefile-built site.
mysql_databases:
  - name: "{{ drupal_mysql_database }}"
    encoding: utf8
    collation: utf8_general_ci
mysql_users:
  - name: "{{ drupal_mysql_user }}"
    host: "%"
    password: "{{ drupal_mysql_password }}"
    priv: "{{ drupal_mysql_database }}.*:ALL"
# Comment out any extra utilities you don't want to install. If you don't want
# to install *any* extras, make set this value to an empty set, e.g. `[]`.
installed_extras:
  - adminer
  - mailhog
  - memcached
  # - nodejs
  - pimpmylog
  # - ruby
  # - selenium
  # - solr
  - varnish
  - xdebug
  - xhprof
# Add any extra apt or yum packages you would like installed.
extra_packages:
  - unzip
# `nodejs` must be in installed_extras for this to work.
nodejs_version: "0.12"
nodejs_npm_global_packages: []
# `ruby` must be in installed_extras for this to work.
ruby_install_gems: []
# You can configure almost anything else on the server in the rest of this file.
extra_security_enabled: false
drush_version: master
drush_keep_updated: true
drush_composer_cli_options: "--prefer-dist --no-interaction"
firewall_allowed_tcp_ports:
  - "22"
  - "25"
  - "80"
  - "81"
  - "443"
  - "4444"
  - "8025"
  - "8080"
  - "8443"
  - "8983"
firewall_log_dropped_packets: false
# PHP Configuration. Currently-supported versions: 5.5, 5.6, 7.0 (experimental).
php_version: "5.6"
php_memory_limit: "192M"
php_display_errors: "On"
php_display_startup_errors: "On"
php_realpath_cache_size: "1024K"
php_sendmail_path: "/usr/sbin/ssmtp -t"
php_opcache_enabled_in_ini: true
php_opcache_memory_consumption: "192"
php_opcache_max_accelerated_files: 4096
php_max_input_vars: "4000"
composer_path: /usr/bin/composer
composer_home_path: '/home/vagrant/.composer'
# composer_global_packages:
#   - { name: phpunit/phpunit, release: '@stable' }
# MySQL Configuration.
mysql_root_password: root
mysql_slow_query_log_enabled: true
mysql_slow_query_time: 2
mysql_wait_timeout: 300
adminer_add_apache_config: true
# Varnish Configuration.
varnish_listen_port: "81"
varnish_default_vcl_template_path: templates/drupalvm.vcl.j2
varnish_default_backend_host: "127.0.0.1"
varnish_default_backend_port: "80"
# Pimp my Log settings.
pimpmylog_install_dir: /usr/share/php/pimpmylog
pimpmylog_grant_all_privs: true
# XDebug configuration. XDebug is disabled by default for better performance.
php_xdebug_default_enable: 0
php_xdebug_coverage_enable: 0
php_xdebug_cli_enable: 0
php_xdebug_remote_enable: 1
php_xdebug_remote_connect_back: 1
# Use PHPSTORM for PHPStorm, sublime.xdebug for Sublime Text.
php_xdebug_idekey: PHPSTORM
php_xdebug_max_nesting_level: 256
# Solr Configuration (if enabled above).
solr_version: "4.10.4"
solr_xms: "64M"
solr_xmx: "128M"
# Selenium configuration
selenium_version: 2.46.0

---

CLI feedback after vagrant up

---
mecmbp112:mysite.drupalvm michealcooper$ vagrant up
Bringing machine 'mysite.drupalvm' up with 'virtualbox' provider...
==> mysite.drupalvm: Importing base box 'geerlingguy/ubuntu1404'...
==> mysite.drupalvm: Matching MAC address for NAT networking...
==> mysite.drupalvm: Checking if box 'geerlingguy/ubuntu1404' is up to date...
==> mysite.drupalvm: Setting the name of the VM: mysite.drupalvm.dev
==> mysite.drupalvm: Clearing any previously set network interfaces...
==> mysite.drupalvm: Preparing network interfaces based on configuration...
    mysite.drupalvm: Adapter 1: nat
    mysite.drupalvm: Adapter 2: hostonly
==> mysite.drupalvm: Forwarding ports...
    mysite.drupalvm: 22 => 2222 (adapter 1)
==> mysite.drupalvm: Running 'pre-boot' VM customizations...
==> mysite.drupalvm: Booting VM...
==> mysite.drupalvm: Waiting for machine to boot. This may take a few minutes...
    mysite.drupalvm: SSH address: 127.0.0.1:2222
    mysite.drupalvm: SSH username: vagrant
    mysite.drupalvm: SSH auth method: private key
    mysite.drupalvm: Warning: Connection timeout. Retrying...
==> mysite.drupalvm: Machine booted and ready!
GuestAdditions 5.0.4 running --- OK.
==> mysite.drupalvm: Checking for guest additions in VM...
==> mysite.drupalvm: Checking for host entries
==> mysite.drupalvm: adding to (/etc/hosts) : 192.168.88.90  mysite.drupalvm.dev  # VAGRANT: 62e94148c98005bfb175498d1ebb9d1f (mysite.drupalvm) / ee9e70b0-b9b8-4809-bca9-99f8f32c3d45
==> mysite.drupalvm: adding to (/etc/hosts) : 192.168.88.90  mysite.drupalvm.dev  # VAGRANT: 62e94148c98005bfb175498d1ebb9d1f (mysite.drupalvm) / ee9e70b0-b9b8-4809-bca9-99f8f32c3d45
==> mysite.drupalvm: adding to (/etc/hosts) : 192.168.88.90  xhprof.drupalvm.dev  # VAGRANT: 62e94148c98005bfb175498d1ebb9d1f (mysite.drupalvm) / ee9e70b0-b9b8-4809-bca9-99f8f32c3d45
==> mysite.drupalvm: adding to (/etc/hosts) : 192.168.88.90  pimpmylog.drupalvm.dev  # VAGRANT: 62e94148c98005bfb175498d1ebb9d1f (mysite.drupalvm) / ee9e70b0-b9b8-4809-bca9-99f8f32c3d45
==> mysite.drupalvm: Setting hostname...
==> mysite.drupalvm: Configuring and enabling network interfaces...
==> mysite.drupalvm: Exporting NFS shared folders...
==> mysite.drupalvm: Preparing to edit /etc/exports. Administrator privileges will be required...
==> mysite.drupalvm: Mounting NFS shared folders...

[geerlingguy]

@micheal-cooper - For the time being, please try just removing type: nfs from the vagrant_synced_folders item, and make sure everything else builds correctly. I'll try to see if time problems could be the culprit. I know it was a problem when using Gluster, but I've never tested time offsets and NFS.

[micheal-cooper]

Wow. I was just adding info to the post. Did not expect a response that quickly, again because I am accustomed to being in a different time zone from everyone else. Thank you. Will try that right away.

[geerlingguy]

@micheal-cooper - Ha! Timezones and I are a little funny... I work on a project two hours back, with developers in 8 different timezones, so depending on the day of the week, I might be checking GitHub issues almost any time of the day!

[micheal-cooper]

Thanks for the attention. Giving up on NFS worked, but I hope my info will help to get more insight on this issue. I read all the posts and pages about it, both on your Github Issues pages and on other places. This dev solution is so good that I would not want such persistent problems to discourage people from using it.

[micheal-cooper]

Looks like NTP was not running, and the TimeZone was wrong. I set the correct timezone set with sudo dpkg-reconfigure tzdata (which opens an interactive setup), but the net says that export TZ=America/New_York with the right TimeZone works.

Even then, the time quickly went out of sync, ntpdate said "no server", and there was no /etc/ntp or ntp process running, so did sudo apt-get install ntp and checked the newly-created /etc/ntp.

[kostajh]

I'm seeing the same issue with Mounting NFS shared folders hanging on Fedora 22. I already had net-tools installed, nfs-server enabled and running, etc.

[iainhouston]

I think this is a firewall issue - i.e. that the nfs mounts can't complete when host and virtual machine are waiting on each other.

This occurred to me as I was able to fire up drupal-vm OK the other day. Since then I'd spent some time in Starbucks and so had turned my Mac's firewall on. Today vagrant up was hanging on the nfs mounts.

After I turned off my Mac's firewall - relying on my router's firewall instead - the nfs mounts completed properly with vagrant up

(For paranoia's sake I powered down the VirtualBox; vagrant destroyed the vm; deleted the sync'd directories drupal and html as well. Probably not necessary.

[bleen]

I am seeing vagrant up hang on Mounting NFS shared folders as well (El Capitain & Yosemte). For me the culprit is Cisco's AnyConnect VPN client (v. 4.0.00048). As long as I run vagrant up before connecting to VPN everything works fine. I'm not really expecting anyone to spend time trying to fix this (as I blame Cisco) but I wanted to put the note in case it helps someone else...

[stevekarsch]

@bleen Thanks for the reminder about the AnyConnect VPN client. That was the issue for me as well. Note that quitting the client isn't enough...I had to restart my machine and then vagrant up again.

[geerlingguy]

AnyConnect-- — I've seen the same thing in the past, because AnyConnect basically blows out your hosts file and local networking configuration and replaces it with Ciscos (many other things besides local development environments can be broken because of this).

Also, to anyone subscribed to this issue; does the information in https://nateofnine.com/2015/10/25/drupalvm-nfs-on-ubuntu/ help any?

[kostajh]

@geerlingguy re-running vagrant plugin install vagrant-vbguest (I had done it once before setting up Drupal VM for the first time) seems to have fixed the issue! nfs mounts now work on Fedora 22.

[geerlingguy]

@kostajh - In that case, I think it's important that we add this information to the docs for NFS, because you're the fifth person who's reported this fix works great for Linux flavors!

[bithead42]

Twas the firewall for me. Running arno-iptables, adding the vboxnet# interface to the internal interface list and it's network to internal nets took care of the problem. I tried installing the vagrant-vbguest plugin and it failed claiming I was missing zlib, although zlibc is installed. My host is a new Jessie installation with packages only installed from official sources (so my VBox and Vagrant are a bit behind the recommended versions, requiring "unsanctioned" deb files). Might be related to the plugin errors, but with the firewall fix, I'm up and running now.

[geerlingguy]

So in summary (I finally got my own Fedora 22 workstation set up; Arch and Ubuntu are soon to come), it looks like there are two main fixes:

1. Install the vagrant-vbguest plugin (which will update the Guest Additions inside the VM). Note that this indicates I may just need to rebuild the base boxes for VirtualBox 5.0.8, since the latest versions of the boxes were built with 5.0.4).
2. Make sure the vboxnet interfaces are not being blocked by your system firewall. For Fedora (and many flavors of Linux), check out this guide for more: Get Vagrant's NFS working under Fedora 20.

Between this and #301, I think I'm getting much further down the path of making Linux-based Drupal VM usage a bit more intuitive out-of-the-box! Just need to add a new linux.md section in the Docs.

[melvin-ibuildings]

For me the problems where neither 1 or 2.

For me the version of nfs seemed to be the problem so adding

    mount_options: ['vers=3']

To the configuration file

# A list of synced folders, with the keys 'local_path', 'destination', 'id', and
# a 'type' of [nfs|rsync|smb] (leave empty for slow native shares). See
# http://docs.drupalvm.com/en/latest/extras/syncing-folders/ for more info.
vagrant_synced_folders:
  # The first synced folder will be used for the default Drupal installation, if
  # build_makefile: is 'true'.
  - local_path: ./
    destination: /var/www
    type: nfs
    create: true
    mount_options: ['vers=3']

did the trick.
I work from ubuntu 14.04 LTS.

Not sure if any other people have the same problem but maybe you could add that piece of advise to the linux.md as well.

[geerlingguy]

After a good deal of troubleshooting, I finally found that on Fedora 22, I had to mount the NFS share setting the NFS version to 3. From inside the VM:

sudo mount -o 'vers=3' 192.168.88.1:'/home/jgeerling/Sites/drupalvm' /var/www

All other methods resulted in the error:

stdin: is not a tty
mount.nfs: access denied by server while mounting 192.168.88.1:/home/jgeerling/Sites/drupalvm

kalamuna/kalastack#92 ultimately led me down the path of investigating NFS versions, and the fix in my case was to explicitly set the NFS version in the synced_folders configuration like so:

vagrant_synced_folders:
  - local_path: ~/Sites/drupalvm
    destination: /var/www
    type: nfs
    create: true
    mount_options: ['vers=3']

[geerlingguy]

Haha, and I just realized I basically wrote the exact same thing as @melvin-ibuildings in the prior comment. So yes, this is something that we should definitely document in a new 'Linux' section. I can also see if it might make sense to default to vers=3 if it works OOTB with Mac OS X and most flavors of Linux.

[kostajh]

I haven't found that I've needed vers=3, for what it's worth. This is on Fedora 22.

Jeff Geerling writes:

Haha, and I just realized I basically wrote the exact same thing as @melvin-ibuildings in the prior comment. So yes, this is something that we should definitely document in a new 'Linux' section. I can also see if it might make sense to default to vers=3 if it works OOTB with Mac OS X and most flavors of Linux.

---

Reply to this email directly or view it on GitHub:
#245 (comment)

@kostajh | kosta@kostaharlan.net

[geerlingguy]

More notes from Ubuntu 15.10-land... VirtualBox at least works out of the gate (unlike Fedora 22), but it looks like NFS isn't available by default, so I got the following message on first vagrant up:

It appears your machine doesn't support NFS, or there is not an
adapter to enable NFS on this machine for Vagrant. Please verify
that `nfsd` is installed on your machine, and try again. If you're
on Windows, NFS isn't supported. If the problem persists, please
contact Vagrant support.

I ran sudo apt-get install nfs-server to install NFS server, then did vagrant halt && vagrant up and everything was fine.

[geerlingguy]

I've summarized all the potential fixes in the original post at the top of this thread, and will hopefully get some time to wrap it all into a Linux docs guide... and investigate setting the NFS version default to 3.

[oxyc]

Currently working on a WP project and this post in Roots forum regarding their VM caught my eye. Just thought to post it here in case it helps someone.

They also linked here: hashicorp/vagrant#6423 (comment)

[geerlingguy]

hashicorp/vagrant#6423 looks to be related in some circumstances, for sure! Thanks for digging that up.

[geerlingguy]

I've added docs for this issue, at least. If others can continue to report any other issues you see that might not be resolved by following the instructions in the docs, please let me know, and I'll try to incorporate them as well. I still need to do more testing in Arch and Debian on my newfangled PC laptop :)

[dasginganinja]

I just ran into this issue on Debian 8 x64. I was getting this message:

It appears your machine doesn't support NFS, or there is not an
adapter to enable NFS on this machine for Vagrant. Please verify
that `nfsd` is installed on your machine, and try again. If you're
on Windows, NFS isn't supported. If the problem persists, please
contact Vagrant support.

In order to get the error to go away I had to run sudo modprobe nfsd to get Vagrant to realize I had nfs-kernel-server installed.

Edit: Or maybe not. I ended up doing a modprobe and then sudo service nfs-kernel-server restart to get it going. The hanging can also be explained by the NFS Server not actually running. 👍

[jamesrward]

Found this thread after hanging on the "Mounting NFS shared folders..." on OSX El Capitan 10.11.3 and noticed that @micheal-cooper was having the same issue on Yosemite with the same IP address setting of 192.168.88.1 so I changed my IP to 192.168.88.89 and NFS mounting works without any issue now.

To confirm I took the example configs and changed the ip address to 192.168.88.1 and sure enough the previously working example config now hangs on "Mounting NFS shared folders...".

Perhaps the warning about IPs ending in .1 needs to be changed to be explicit about this issue on OSX.

[geerlingguy]

The problem with using any .1 IP address is that address is almost always reserved for the network router, and a lot of different things can go wrong when you use it... I don't know if we'd want to add more notes in the docs about it in particular, since it's more a general networking thing, and you kinda have to learn from experience the danger of forcing a .1 :)

[jamesrward]

I understand the general issue with .1 and the warning makes perfect sense but it seems to me this is something more specific about OSX. If this causes the NFS Mounting to hang 100% of the time in OSX then I think we should provide that information when it's detected.

Maybe I'm a misunderstanding the issue but I can confirm my router IP is not 192.168.88.1 in fact it is 10.30.10.1 so it didn't actually collide.

[geerlingguy]

Vagrant itself sets your host's virtual IP to .1 so it can route traffic over the private network inside the VM; this problem also occurs on Linux or Windows if using NFS shares.

[jamesrward]

Makes sense. I would still maintain that if this issue is a specific side-effect of IPs ending in .1 then the warning should include something to that effect or a link to the docs page with that info.

[kmoll]

I was also running into this issue event with adding mount_options: ['vers=3']. I was running on ubuntu host. Turns out it was a firewall issue, but even with opening port 2094 it still wasn't working. I search around and found this and it helped me fix it. It was originally written for an older version of ubuntu (I'm running 14.04 LTS), but it still worked. For people not familiar with iptables, checkout this link

[kmoll]

I do also run DrupalVM on a mac host where I sometimes use Anyconnect and experienced the same issues listed above. I found that instead of having to restart, which I was doing for a while, that you can just add the route back to the table with:
sudo route add --net 192.168.88.0 -netmask 255.255.255.0 -interface vboxnet0 and NFS works again

[skippednote]

sudo route add -net 192.168.88.0 -netmask 255.255.255.0 -interface vboxnet0
It's -net not --net.

[fredrikekelund]

Fedora 24 user here. I'm using the VirtualBox provider, and managed to get the NFS mounts working simply by running sudo systemctl stop firewalld.service. Took me forever to figure that out, I didn't know that Fedora shipped with a firewall by default, and a more ideal solution would probably be to actually configure firewalld to let the Vagrant NFS connection through, but hopefully this could help someone else out.

[richard-scott]

I found that restarting rpcbind fixed my issues... my VM was stuck at mounting NFS, and as soon as I'd restarted the rpcbind service, it instantly sprang into life.

[adrinux]

Am I missing something, or does DrupalVM's own firewall role not open the ports required for the client to mount the NFS shares?

[geerlingguy]

@adrinux - The default firewall config (https://github.com/geerlingguy/drupal-vm/blob/master/default.config.yml#L226-L237) doesn't have 111 or 2049 in it, but Vagrant sets up the correct rules for that share if you have it set as the type for a synced folder.

Note that Vagrant 1.9.1 currently has broken support for NFS in CentOS.

[chadfurman]

I had a similar problem in Ubuntu, Vagrant version 1.9.3, VB version 5.1.22

The problem was that my host's OS has changed the ifconfig to the ip command, and vboxnet0 did not have an ip address.

Solution:

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

There were many other things I tried: starting/stopping the firewall (ufw, iptables, both, neither); adding specific rules to the firewall to allow all traffic to this IP; service start for each of nfs-common, nfs-kernel-server, nfs-server, nfs-client; and clearing out my /etc/exports

It wasn't until I made sure my vboxnet0 had an IP on the host machine that everything worked.

[jozzya]

I had failed mounting nfs shares on Fedora 25 and nfs-utils-2.1.1-5.rc3
SSH'ing into vagrant machine and running mount -o vers=3,udp ... gave me mount.nfs requested NFS version or transport protocol is not supported

The issue is udp is disabled by default from nfs-utils-2.1.1-5.rc2.fc25 onwards.

Fix is

• Edit /etc/sysconfig/nfs, change RPCNFSDARGS="" to RPCNFSDARGS="--udp"
• Restart nfs-service sudo systemctl restart nfs

[oxyc]

Another option is to use TCP http://docs.drupalvm.com/en/latest/getting-started/installation-linux/#nfs-shares-are-slow-or-hang-due-to-udp-protocol

[oxyc]

Probably a good idea to add that error message to do docs though, together with both fixes.

[wheatpenny]

I am using Ubuntu 17.04 (Pop_OS!) and I needed to install net-tools in order to get past the NFS mounting hanging issue.

See hashicorp/vagrant#8626