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

"Mounting NFS shared folders..." hangs #245

Closed
marcvangend opened this Issue Sep 16, 2015 · 44 comments

Comments

Projects
None yet
@marcvangend
Copy link

marcvangend commented Sep 16, 2015

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 geerlingguy added the docs label Sep 19, 2015

@geerlingguy

This comment has been minimized.

Copy link
Owner

geerlingguy commented Sep 19, 2015

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

This comment has been minimized.

Copy link
Author

marcvangend commented Sep 20, 2015

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

This comment has been minimized.

Copy link

micheal-cooper commented Sep 21, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Sep 21, 2015

@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

This comment has been minimized.

Copy link

micheal-cooper commented Sep 21, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Sep 21, 2015

@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

This comment has been minimized.

Copy link

micheal-cooper commented Sep 22, 2015

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

This comment has been minimized.

Copy link

micheal-cooper commented Sep 22, 2015

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

This comment has been minimized.

Copy link

kostajh commented Sep 23, 2015

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

This comment has been minimized.

Copy link
Contributor

iainhouston commented Sep 28, 2015

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

This comment has been minimized.

Copy link
Contributor

bleen commented Oct 12, 2015

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

This comment has been minimized.

Copy link

stevekarsch commented Oct 28, 2015

@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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Oct 28, 2015

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

This comment has been minimized.

Copy link

kostajh commented Oct 29, 2015

@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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Oct 30, 2015

@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

This comment has been minimized.

Copy link

bithead42 commented Nov 2, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 7, 2015

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

This comment has been minimized.

Copy link

melvin-ibuildings commented Nov 7, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 8, 2015

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 geerlingguy added the linux label Nov 8, 2015

@geerlingguy

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 8, 2015

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

This comment has been minimized.

Copy link

kostajh commented Nov 9, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 9, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 9, 2015

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

This comment has been minimized.

Copy link
Collaborator

oxyc commented Nov 10, 2015

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 10, 2015

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

@geerlingguy

This comment has been minimized.

Copy link
Owner

geerlingguy commented Nov 11, 2015

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

This comment has been minimized.

Copy link

dasginganinja commented Dec 3, 2015

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

This comment has been minimized.

Copy link

jamesrward commented Feb 26, 2016

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Feb 29, 2016

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

This comment has been minimized.

Copy link

jamesrward commented Feb 29, 2016

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Feb 29, 2016

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

This comment has been minimized.

Copy link

jamesrward commented Feb 29, 2016

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

This comment has been minimized.

Copy link

kmoll commented Apr 20, 2016

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

This comment has been minimized.

Copy link

kmoll commented Apr 20, 2016

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

This comment has been minimized.

Copy link

skippednote commented May 4, 2016

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

@fredrikekelund

This comment has been minimized.

Copy link

fredrikekelund commented Sep 23, 2016

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

This comment has been minimized.

Copy link

richard-scott commented Jan 10, 2017

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

This comment has been minimized.

Copy link

adrinux commented Jan 24, 2017

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

This comment has been minimized.

Copy link
Owner

geerlingguy commented Jan 24, 2017

@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

This comment has been minimized.

Copy link

chadfurman commented May 27, 2017

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

This comment has been minimized.

Copy link

jozzya commented Jun 13, 2017

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

This comment has been minimized.

@oxyc

This comment has been minimized.

Copy link
Collaborator

oxyc commented Jun 13, 2017

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

@wheatpenny

This comment has been minimized.

Copy link

wheatpenny commented Jul 18, 2017

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

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