Vagrant: No guest IP was given to the Vagrant core NFS helper

[nodesocket]

Vagrant version

Vagrant 1.8.1

Host operating system

OS X El Capitan 10.11

Guest operating system

Ubuntu 14.04.4 LTS

Vagrantfile

Vagrant.configure("2") do |config|
    config.vm.box = "Lightning"
    config.vm.network "private_network", type: "dhcp"
    config.ssh.username = "ubuntu"
    config.ssh.port = 2222
    config.ssh.private_key_path = "~/.ssh/lightning"

    config.vm.network "forwarded_port", guest: 80, host: 8888, protocol: "tcp"
    config.vm.network "forwarded_port", guest: 443, host: 4444, protocol: "tcp"
    config.vm.network "forwarded_port", guest: 27017, host: 27017, protocol: "tcp"

    config.nfs.map_uid = Process.uid
    config.nfs.map_gid = Process.gid

    config.vm.synced_folder "~/Sites/Myproject",
                            "/var/www/Myproject",
                            type: "nfs"

    config.vm.synced_folder '.',
                            '/vagrant',
                            disabled: true

    config.vm.provider "virtualbox" do |v|
        v.name = "Lightning"
    end
end

Actual behavior

No guest IP was given to the Vagrant core NFS helper. This is an internal error that should be reported as a bug.

Steps to reproduce

1. vagrant up

[nodesocket]

Any ideas? Blocking me.

[richard-scott]

I've just had the same problem crop up and found that if I change this:

config.vm.network "private_network", type: "dhcp"

to this allocate a static IP:

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

I think the problem is that VirtualBox doesn't have an IP allocated to the MAC address of your VM as you've never booted it, so it has nothing to tell Vagrant about the system.

If you'd setup /vagrant to be available over NFS after the initial "up" then this would be ok as VirtualBox would then have a record of the last provided IP address.

[nodesocket]

@richard-scott thanks for the reply, appreciate it. After making the change you suggested, I am no longer receiving No guest IP was given to the Vagrant core NFS helper. This is an internal error that should be reported as a bug.

But now getting:

default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...

[richard-scott]

Silly question, but have to ask...

Do you have both nfs & rpcbind packages installed on both the host and in the guest VM?

[nodesocket]

Hi @richard-scott.

So just default install of OSX El Capitan. Do I need to brew install anything?

I can run nfsd --version successful.

[richard-scott]

I know nothing about OSX, but try running this after your first failed "vagrant up"

$ showmount -e 127.0.0.1
Export list for 127.0.0.1:
/home/Sandbox/Debian/Test-01 192.168.0.2
$

As you can see, it should show you something like this if its working. If not, it may complain about rpcbind or portmapper not working, in which case you need to enable those services.

If the above works ok, then the host NFS should be fine, and you can concentrate on your Vagrantfile and the Guest OS ensuring that the nfs config options are in the Vagrantfile, and that the correct nfs tools are installed in the Guest OS.

What is the Guest OS?

[richard-scott]

Maybe this will help. It suggests adding the following to the NFS part of your Vagrantfile:

nfs_udp:false

[nodesocket]

@richard-scott found the problem.

The version of the VirtualBox guest OS tools was out of date and caused the problem. The easiest fix was to add the following awesome vagrant plugin:

vagrant plugin install vagrant-vbguest

Then I reverted back to using dhcp for the private network.

config.vm.network "private_network", type: "dhcp"

Then when I ran vagrant up, the plugin did the work of updating VirtualBox guest OS tools automatically.

[juanyque]

Same error reported in #7138.

It work on second vagrant up (vagrant up -> vagrant halt -> vagrant up) https://github.com/mitchellh/vagrant/issues/7138#issuecomment-196786583

[dkinon]

I just experienced this same issue on MacOS Yosemite. I did not have this issue prior to the latest Yosemite software update. My specific system verison is 10.10.5 (14F2511). I tried different versions of vagrant and virtualbox up to the latest versions of both and still experienced the problem. I tried @nodesocket 's workaround first with no success. The workaround mentioned by @juanyque got me past the issue for now. Since I'm doing extra provisioning (using salt module) my second up had to be vagrant up --provision.

[guerrerocarlos]

This fixed it for me:

override.nfs.functional = false

Took it from
https://github.com/hashicorp/vagrant/issues/5401

[nervo]

I'm not a ruby specialist, anyway, having the same issue, i've tried to (kind-of) debug.
Digging into the code, i've realized that there is a "PrepareNFSSettings" class in docker provider (here: https://github.com/hashicorp/vagrant/blob/master/plugins/providers/docker/action/prepare_nfs_settings.rb) which is reponsible to inject host & machine ip to nfs settings.

Adding an ugly puts 'Hello' in its call method (right here: https://github.com/hashicorp/vagrant/blob/master/plugins/providers/docker/action/prepare_nfs_settings.rb#L16), it seems the this method is called during vagrant reload, but NOT during vagrant up.

Can someone confirm ?

[chrisroberts]

Hi there,

Thanks for reporting this bug. I'm sure this was a real issue when originally reported (our fault for not looking sooner!) but there have been multiple Vagrant releases since the original report. I'm going to close this issue now and request you reopen the issue if you're still experiencing this problem. I'm sorry this wasn't looked at earlier :frowning_face:

Cheers!

[Addvilz]

I can confirm this issue is 99.9% caused by old vagrant-vbguest plugin. I could reproduce this in Vagrant 1.8.x, and 2.1.1., however, after upgrade to 2.1.1, seems that vagrant-vbguest was the same old version. Upgrading the plugin by vagrant plugin install vagrant-vbguest fixed the issue.

[hashibot[bot]]

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.