Skip to content
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 mount fails on subsequent vagrant up commands #1941

Closed
n1vlac opened this issue Jul 17, 2013 · 54 comments
Closed

NFS mount fails on subsequent vagrant up commands #1941

n1vlac opened this issue Jul 17, 2013 · 54 comments

Comments

@n1vlac
Copy link

n1vlac commented Jul 17, 2013

I know there are other issues around this problem, but perhaps my situation is a little different.

So I'm hitting errors on mounting a shared directory. The funny thing is, it WORKS when I create a new VM, though it seems to hit a bunch of errors before somehow finally working. See below:

DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: Exit status: 32
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: Exit status: 32
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: Exit status: 32
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: Exit status: 0
DEBUG ssh: Checking whether SSH is ready...
DEBUG ssh: Re-using SSH connection.
 INFO ssh: SSH is ready!
 INFO guest: Execute capability: shell_expand_guest_path (ubuntu)

But once it's created, on any subsequent vagrant up commands (after I do a halt), it just fails.

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: Exit status: 32
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work (sudo=true)
DEBUG ssh: stderr: stdin: is not a tty

DEBUG ssh: stderr: mount.nfs: access denied by server while mounting 10.98.0.1:/Users/nivlac/work/nucleus

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3 10.98.0.1:'/Users/nivlac/work/nucleus' /home/vagrant/work

I've been using Vagrant for several months now... this error just started happening yesterday.

Vagrant version 1.2.4

@n1vlac
Copy link
Author

n1vlac commented Jul 18, 2013

Addtl info: From /var/log/syslog:

Jul 18 00:58:58 dev-02 kernel: [  324.707810] RPC: server 10.98.0.1 requires stronger authentication.
Jul 18 00:59:00 dev-02 kernel: [  326.743088] RPC: server 10.98.0.1 requires stronger authentication.
Jul 18 00:59:26 dev-02 kernel: [  352.926302] RPC: server 10.98.0.1 requires stronger authentication.
Jul 18 00:59:38 dev-02 kernel: [  364.570143] RPC: server 10.98.0.1 requires stronger authentication.

@millsb
Copy link

millsb commented Jul 18, 2013

I can confirm this problem. Originally thought my NFS problems were fixed by upgrading from 1.2.2 to 1.2.3, only to see the volume fail to mount after the 'up' command was run for the first time. Running Vagrant on OS X 10.8.4 using a precise32 box.

@mitchellh
Copy link
Contributor

I can't reproduce this problem, although I clearly believe it is happening due to the many comments here.

To explain the "errors repeateadly" problem (I realize thats not the bug being reported): Vagrant has to restart the host NFS server. So while exit status 32 happens with mount.nfs, Vagrant retries continuously. So that part is working as expected.

But I'm not seeing this problem right now. Any more info to help me?

@n1vlac
Copy link
Author

n1vlac commented Jul 18, 2013

Thanks for the reply @mitchellh. I'm not sure what other info I should give. If you google the error "rpc server requires strong auth", there's lots of hits but I can't find a solution.

I'll keep digging.

@mitchellh
Copy link
Contributor

I still haven't been able to figure this out. I'm going to need help in order to reproduce this. Have people still been having this problem often? If I can't reproduce this I can't really fix it unfortunately. :(

@lorique
Copy link

lorique commented Oct 9, 2013

I've run into this issue as well, but im getting a different error. My log message is as follows:

"mount.nfs: mount to NFS server '192.168.56.1:/Users/user/mount' failed: timed out, giving up"

Running OSX 10.8.5 with vagrant 1.3.4 and virtualbox 4.2.18.

I am unable to connect to my virtualbox to my host.

@GeoffreyPlitt
Copy link

+1

@leabaertschi
Copy link

Having the same issue running vagrant 1.3.5, VirtualBox 4.2.18 and Mac OS X 10.9.

DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: Exit status: 32
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::LinuxNFSMountFailed: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp' 172.84.98.1:'/path/to/shared/folder' /vagrant

Stdout from the command:



Stderr from the command:

mount.nfs: requested NFS version or transport protocol is not supported

@sebastian-alfers
Copy link

Same for me

@Furizaa
Copy link

Furizaa commented Nov 21, 2013

I can't get it to work on two different machines. Both VirtaulBox 4.3.2, Vagrant 1.3.5 and OSX 10.9

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp' 192.168.240.1:'/Volumes/Media/Code/code/unity/share' /srv/httpd

Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: access denied by server while mounting 192.168.240.1:/Volumes/Media/Code/code/unity/share

Edit: Got it working. I completely removed everything Vagrant and VirtualBox and re-installed both. But I guess the trick was to remove any old exports in /etc/exports and restart nfsd.

@mitchellh
Copy link
Contributor

For the recent commets here: I increased the retry timeout in core and it seems to have gotten rid of these issues for people. It looks like NFS server takes a bit longer to restart sometimes on Mavericks, oddly.

@leabaertschi
Copy link

When will this be released? Or is there another way to get this fix?

@nZac
Copy link

nZac commented Dec 11, 2013

To be clear, the issue is that Mavericks takes longer to start the NFS server resulting in a timeout of mounting those drives?

Just so I understand this better, does vagrant start the NFS server on vagrant up with Mac OS X hosts?

@petkostas
Copy link

Getting the same problem after apt-get upgrade in my Vagrant box (running on Mac OSX Mavericks) any tips would be welcome.

@petkostas
Copy link

Please ignore, updating to the latest vagrant and virtualbox solved the problem.

@therobyouknow
Copy link

Solution for ubuntu 12.04 LTS 64bit as the host machine, nfs common and nfs server both needed to install, also using vagrant 1.3.5 and 4.3.2 of virtualbox (newer version combinations may work)

( faviouz commented in #1534 )

$ sudo apt-get install nfs-common nfs-kernel-server worked for me on Ubuntu 13.10.

therobyouknow commented:

@faviouz - this worked for me too on Ubuntu 12.04 LTS 64bit - thanks both are needed, not just nfs-common. When I had only installed nfs-common, I got this error:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp' 33.33.33.1:'/home/hostmachinevagrantfolder/sites' /var/www

Stdout from the command:

Stderr from the command:

stdin: is not a tty
mount.nfs: requested NFS version or transport protocol is not supported

Once I installed nfs-kernel-server too, this error did not occur

So yes, use:
sudo apt-get install nfs-common nfs-kernel-server

I am using VirtualBox 4.3.2 with Vagrant 1.3.5
Yes I know there are later versions of both but from experience with Mac and Windows, certain version combinations don't work (fatal errors) but I will try the later versions at some point. Sometimes I find that the latest and greatest virtualbox sometimes has regression.

For completeness, a few folks here are going on about repairing /etc/hosts file BUT don't actually say what the repair actually is. OK then, here's what my whole complete /etc/hosts file looks like, here you go! :-

127.0.0.1       localhost
127.0.1.1       rob-ThinkPad-X201s

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

@mikekeilty
Copy link

+1 vagrant version: 1.5.1 VirtualBox version: 4.3.10

Exit status: 32 on mount.nfs

@shishirsharma
Copy link

+1 on vagrant version: 1.5.1 VirtualBox version: 4.3.10

@sobit
Copy link

sobit commented May 5, 2014

For me it was broken /etc/hosts file as well. Accidentally commented line 127.0.0.1 localhost which caused the problem. Uncommenting it was the solution.

@shishirsharma
Copy link

For me it was host only network. vboxnet0
To fix this on mac. Run following on your host (outside of vagrant)

$ sudo ifconfig vboxnet0 down
$ sudo ifconfig vboxnet0 up

@c-castillo
Copy link

adding the line 127.0.0.1 localhost to the /etc/hosts file worked for me as well
I'm with vagrant 1.6.2 and vbox 4.3.10

@sinanm89
Copy link

sinanm89 commented Jun 7, 2014

can confirm @therobyouknow 's answer works on 14.04 x64 as well.

@mogetutu
Copy link

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o 'vers=3,udp' 192.168.33.1:'/Users/mogetutu/Projects/platform' /var/www

Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: Connection timed out

For me unblocking all incoming connections in my firewall settings - OS X did the trick.

@tommcquarrie
Copy link

Tried everything above and could not get mounting to work. Changing the private network ip address seemed to somehow fix it, although not sure why as there shouldn't be any network conflicts.

@therobyouknow
Copy link

@tommcquarrie thanks - glad that worked for you. The following may be of interest, #1744 (comment)

@lambertbeekhuis
Copy link

For me the problems was also caused by the /etc/hosts file of my OSX: I have two vagrant boxes, on different ip-addresses (192.168.56.x and 192.168.55.x). Initially, the both worked, but after restart of my system, I had disable one of these ip-addresses in my hosts file to run a 'vagrant up'.

Can someone explain what is the relation between the hosts file and the mounting of external paths by NFS?

@tristanbes
Copy link

I'm facing the same problem (@phpguru) :

 ('mount.nfs: requested NFS version or transport protocol is not supported')

With:
Vagrant 1.7.2
VirtualBox 4.3.28

OSX 10.10.3

Plugins:
vagrant-cachier (1.2.0)
vagrant-hostmanager (1.5.0)
vagrant-share (1.1.3, system)

I tried on a macbook air with OSX 10.10.3 and it worked with the same settings/versions that on my macbook pro that doesn't. I can't figure out why it's happening to me :/

@j3rrey
Copy link

j3rrey commented Jul 6, 2015

installing these
sudo apt-get install nfs-common nfs-kernel-server
fixed it for me.

@rceee
Copy link

rceee commented Aug 17, 2015

For me it was a malformed PATH variable. Fixing it in the bash config files, then exiting and restarting the shell completely (sourcing will just append) fixed it.

@fireproofsocks
Copy link

Vagrant used to work fine... now "vagrant up" is prompting for a sudo password -- I suspect that might be related to HFS timing out. Concerned that the user on the host system needs sudo...

@yellowmamba
Copy link

I am having the same issue with @tristanbes . I have sudo apt-get install nfs-common nfs-kernel-server run in my guest ubuntu machine, but vagrant reload still spits mount.nfs: requested NFS version or transport protocol is not supported.

@dagonzalezc
Copy link

i have a Mac and had the same problem, the solution for me was changing all the synced_folder in Vagrantfile to nfs_udp:false and nfs: true, everything works in TCP protocol and the default for vagrant is UDP.

@bartmcleod
Copy link

bartmcleod commented Dec 18, 2015

Same problem on a Mac since Monday december 14, 2015 after a system reboot. I thought it had to do with installing VMware 8.0.2, but restoring 8.0.0 did not fix the issue. The issue appears with all my VM's. None of the suggestions listed here helped so far. I also tried to issue the command manually from within the VM, also with tcp, but it did not help. Any mismatch between nfs on the guest and nfs on the host (such as a wrong /etc/hosts file) can trigger the error. The same error could come from a port mismatch for nfs (default is 2049). Just in my case, I wasn't lucky enough to find the cause and I am stuck with machines that do not properly sync their files, because I have to turn off nfs to be able to share any files at all. I re-installed Vagrant, I updated the plugins, I reinstalled VMware, I destroyed and rebuilt the boxes, I installed the nfs server inside the box, nothing helped.

I think it has not so much to do with Vagrant itself, but something seems to have changed in the configuration of nfs on the mac that is now conflicting with the box.

Output from netstat:
tcp6 0 0 .2049 *. LISTEN
tcp4 0 0 .2049 *. LISTEN
udp6 0 0 .2049 *.
udp4 0 0 .2049 *.
Looks like the mac is not listening for udp connections on the default nfs port, but it does not help to connect with tcp from the guest machine.

Edit [May 18, 2016]:
After a long time and lots of similar problems, all related to sharing a file system with a vagrant box with either vboxfs, HGFS or nfs, which all failed with similar errors, I realized the cause might be that I installed sshfs on top of OSX FUSE, as explained here: https://github.com/osxfuse/osxfuse/wiki/SSHFS
I followed their instructions to remove sshfs and straight after that, I could use nfs again with a vagrant box.

It seems to me that many solutions provided on this page may work in some situations, but not in others. As soon as file sharing over ssh fails, you get this weird error message, pointing one in the wrong direction, as if nfs wasn't supported. It may be supported allright, but not working for any of many reasons.

Also, if VMware tools aren't (properly) installed, HGFS will fail because of that. If a synced folder other than default is used, nfs might work, but HGFS will still fail on the default folder. This can be solved by explicitly disabling the default folder like so:
mymachine.vm.synced_folder ".", "/vagrant", disabled: true
If you forget this, but are using a custom synced folder AND VMware tools aren't properly installed, you might see a confusing output like this:
==> mymachine: Exporting NFS shared folders... ==> mymachine: Preparing to edit /etc/exports. Administrator privileges will be required... ==> mymachine: Mounting NFS shared folders... ==> mymachine: Waiting for HGFS kernel module to load... The HGFS kernel module was not found on the running virtual machine. This must be installed for shared folders to work properly. Please install the VMware tools within the guest and try again. Note that the VMware tools installation will succeed even if HGFS fails to properly install. Carefully read the output of the VMware tools installation to verify the HGFS kernel modules were installed properly.

Edit[May 23, 2016] And once more, after a reboot of my MacBook Pro, the same error occurs, and this time, there is no sshfs to uninstall, so I am back to where I started...

Same day:
I finally realized I had to fix the hosts file on the host machine. Indeed, there was no entry 127.0.0.1 locahost After I added it, nfs worked for me too, however, I am still a bit sceptical, since this error just comes and goes as it pleases.

@redrohX
Copy link

redrohX commented Feb 29, 2016

@c-castillo solution works for me. 👍

@tibotiber
Copy link

For me it's similar to @lambertb: with 2 VMs, I had to remove the mapping of the VMs' IP to localhost from /etc/hosts (OS X Yosemite).

@sagotsky
Copy link

Installing nfs-common and nfs-kernel-service wasn't enough for me. I had to start up both services in debian.

@mbifulco
Copy link

mbifulco commented Dec 5, 2016

Just ran into this issue myself, with macOS Sierra as the host OS. Restarting the host seems to have done the trick to fix it for me, but I haven't the slightest clue why.

@fengler-it
Copy link

Had nfs timoeout while trying to mount from guest to ubuntu 16.04.01 host.
After disabling ufw, it worked! :-)

@gkatsanos
Copy link

#1941 (comment) fixed it for me. adding 127.0.0.1 to the hosts file and

$ sudo ifconfig vboxnet0 down
$ sudo ifconfig vboxnet0 up

@nicklaw5
Copy link

nicklaw5 commented Feb 24, 2017

@fengler-it's solution worked for me:

$ sudo ufw disable
$ vagrant up --provision
$ sudo ufw enable

@tecnocat
Copy link

tecnocat commented Mar 7, 2017

For Mac OS Sierra this solve my day! (Vagrant 1.9.2)

#5424 (comment)

@chadfurman
Copy link

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.

I had to run:

ip a add 192.168.33.1/255.255.255.0 dev vboxnet0 before Vagrant could start the NFS share

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.

@leonerd
Copy link

leonerd commented Oct 16, 2017

For another take on this: in current debian it seems that nfs-kernel-server is not sufficient for vagrant any more. I had to remove that in favour of the userland implementation of nfs-server, which made it run happily.

$ vagrant --version
Vagrant 1.9.8

@whalesingswee
Copy link

Would like to add if you're using OSX 10.14 and running this issue, please follow this simple step would help #10234

The Mojave upgrade removes/disables NFS, resulting the /etc/exports being renamed to #/etc/exportsbak

@davthu
Copy link

davthu commented Jan 31, 2019

I updated Vagrant to the latest version and it solved it for me (macOS 10.13.6)

@joriaty-ben
Copy link

joriaty-ben commented Jun 7, 2019

Had the same issue after i tried to upgrade in virtualbox vagrant (stupid). I tried almost everything from above and pretty much from any other forum out there. I the end i got it working half way, but the project files from the vagrant project were not piped in the new environment(still not sure why...). What worked in the end:

  1. delete Virtualbox including ~/'VirtualBox' and ~./.config/VirtualBox.
  2. delete vagrant in /opt/ and /usr/bin
  3. delete in /etc/hosts and /etc/exports all listings which are dependent to your virtualbox/vagrant environment.
  4. Install it all again
  5. If possible git clone your project form an earlier stage to a new dir.
  6. copy your changes from the old files stepwise to the new project.
    Its kinda rollback, but it was the only way i got it working.

@ghost
Copy link

ghost commented Jan 28, 2020

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.

@hashicorp hashicorp locked and limited conversation to collaborators Jan 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests