vagrant up tries sudo for nfs_prune when /etc/exports not readable

[robnagler]

/etc/exports was not readable by world so nfs_prune asked for sudo to read it. The problem is that there were no folders synced in this Vagrantfile. More importantly, sudo is not allowed. There's no way to tell vagrant to not edit /etc/exports in this case. nfs_export is only valid for setting up sync folders, but not for nfs_prune on boot.

Vagrant version

Vagrant 2.2.1

Host operating system

CentOS 7

Guest operating system

Fedora 27

Vagrantfile

Vagrant.configure("2") do |config|
    config.vm.box = "fedora/27-cloud-base"
    config.vm.hostname = "v.radia.run"
    config.vm.network "private_network", ip: "10.10.10.10"
    config.vm.provider "virtualbox" do |v|

        # https://stackoverflow.com/a/36959857/3075806
        v.customize ["setextradata", :id, "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled", "0"]
        # If you see network restart or performance issues, try this:
        # https://github.com/mitchellh/vagrant/issues/8373
        # v.customize ["modifyvm", :id, "--nictype1", "virtio"]
        #
        # 8192 needed for compiling some the larger codes
        v.memory = 8192
        v.cpus = 4
    end
    # Create a disk for docker
    config.persistent_storage.enabled = true
    # so doesn't write signature
    config.persistent_storage.format = false
    # Clearer to add host name to file so that it can be distinguished
    # in VirtualBox Media Manager, which only shows file name, not full path.
    config.persistent_storage.location = "/home/nagler/v/v-docker.vdi"
    # so doesn't modify /etc/fstab
    config.persistent_storage.mount = false
    # use whole disk
    config.persistent_storage.partition = false
    config.persistent_storage.size = 102400
    config.persistent_storage.use_lvm = true
    config.persistent_storage.volgroupname = "docker"

    config.ssh.forward_x11 = false
    config.vbguest.auto_update = false
    # https://stackoverflow.com/a/33137719/3075806
    # Undo mapping of hostname to 127.0.0.1
    config.vm.provision "shell",
        inline: "sed -i '/127.0.0.1.*v.radia.run/d' /etc/hosts"
    config.vm.synced_folder ".", "/vagrant", disabled: true
end

Debug output

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'fedora/27-cloud-base' is up to date...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
[sudo] password for nagler:

Expected behavior

Not ask for sudo

Actual behavior

Asked for sudo.

Steps to reproduce

1. chmod 600 /etc/exports
2. vagrant up

References

n/a

[briancain]

Hey there @robnagler - I tried reproducing this and could not:

vagrant@vagrant:~/test$ sudo !!
sudo chmod 600 /etc/exports
vagrant@vagrant:~/test$ ls -lah /etc/exports
-rw------- 1 root root 389 Aug  3  2017 /etc/exports
vagrant@vagrant:~/test$ vagrant up fedora
Bringing machine 'fedora' up with 'virtualbox' provider...
==> fedora: Importing base box 'fedora/27-cloud-base'...
==> fedora: Matching MAC address for NAT networking...
==> fedora: Checking if box 'fedora/27-cloud-base' is up to date...
==> fedora: Setting the name of the VM: test_fedora_1543870666071_50494
==> fedora: Clearing any previously set network interfaces...
==> fedora: Preparing network interfaces based on configuration...
    fedora: Adapter 1: nat
==> fedora: Forwarding ports...
    fedora: 22 (guest) => 2222 (host) (adapter 1)
==> fedora: Booting VM...
==> fedora: Waiting for machine to boot. This may take a few minutes...
    fedora: SSH address: 127.0.0.1:2222
    fedora: SSH username: vagrant
    fedora: SSH auth method: private key
    fedora:
    fedora: Vagrant insecure key detected. Vagrant will automatically replace
    fedora: this with a newly generated keypair for better security.
    fedora:
    fedora: Inserting generated public key within guest...
    fedora: Removing insecure key from the guest if it's present...
    fedora: Key inserted! Disconnecting and reconnecting using new SSH key...
==> fedora: Machine booted and ready!
==> fedora: Checking for guest additions in VM...
    fedora: No guest additions were detected on the base box for this VM! Guest
    fedora: additions are required for forwarded ports, shared folders, host only
    fedora: networking, and more. If SSH fails on this machine, please install
    fedora: the guest additions and repackage the box to continue.
    fedora:
    fedora: This is not an error message; everything may continue to work properly,
    fedora: in which case you may ignore this message.
==> fedora: Rsyncing folder: /home/vagrant/test/ => /vagrant
vagrant@vagrant:~/test$

Please provide a full debug log so we can get a better idea of what's going on, thanks!

[robnagler]

Hi @briancain Thanks for looking at this.

In your example, you need to clear the sudo state before starting vagrant:

sudo chmod 600 /etc/exports
sudo -k
ls -lah /etc/exports
vagrant up fedora

At this point, you should see the sudo prompt to read /etc/exports.

[briancain]

@robnagler - Same result. Again, without a debug log it's difficult for us to figure out what's going on.

vagrant@vagrant:~/test$ sudo -k
vagrant@vagrant:~/test$ ls -lah /etc/exports
-rw------- 1 root root 389 Aug  3  2017 /etc/exports
vagrant@vagrant:~/test$ vagrant up fedora
Bringing machine 'fedora' up with 'virtualbox' provider...
==> fedora: Importing base box 'fedora/27-cloud-base'...
==> fedora: Matching MAC address for NAT networking...
==> fedora: Checking if box 'fedora/27-cloud-base' is up to date...
==> fedora: Setting the name of the VM: test_fedora_1543875678947_74537
==> fedora: Vagrant has detected a configuration issue which exposes a
==> fedora: vulnerability with the installed version of VirtualBox. The
==> fedora: current guest is configured to use an E1000 NIC type for a
==> fedora: network adapter which is vulnerable in this version of VirtualBox.
==> fedora: Ensure the guest is trusted to use this configuration or update
==> fedora: the NIC type using one of the methods below:
==> fedora:
==> fedora:   https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
==> fedora:   https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
==> fedora: Clearing any previously set network interfaces...
==> fedora: Preparing network interfaces based on configuration...
    fedora: Adapter 1: nat
==> fedora: Forwarding ports...
    fedora: 22 (guest) => 2222 (host) (adapter 1)
==> fedora: Booting VM...
==> fedora: Waiting for machine to boot. This may take a few minutes...
    fedora: SSH address: 127.0.0.1:2222
    fedora: SSH username: vagrant
    fedora: SSH auth method: private key
    fedora:
    fedora: Vagrant insecure key detected. Vagrant will automatically replace
    fedora: this with a newly generated keypair for better security.
    fedora:
    fedora: Inserting generated public key within guest...
    fedora: Removing insecure key from the guest if it's present...
    fedora: Key inserted! Disconnecting and reconnecting using new SSH key...
==> fedora: Machine booted and ready!
==> fedora: Checking for guest additions in VM...
    fedora: No guest additions were detected on the base box for this VM! Guest
    fedora: additions are required for forwarded ports, shared folders, host only
    fedora: networking, and more. If SSH fails on this machine, please install
    fedora: the guest additions and repackage the box to continue.
    fedora:
    fedora: This is not an error message; everything may continue to work properly,
    fedora: in which case you may ignore this message.
==> fedora: Rsyncing folder: /home/vagrant/test/ => /vagrant

I have no nfs folder defined in my Vagrantfile (same as your example in the issue) so it would be good to see where the sudo prompt is coming from.

[robnagler]

Here's the debug log: nagler.log.gz

I could not simply vagrant up fedora and had to do a vagrant init first. Here's the Vagrantfile: Vagrantfile.gz

[briancain]

@robnagler - Ah ok, so it looks like this won't happen on the first up of a guest unless there are other guests already running, just an FYI. I was able to reproduce it once I had another guest running.

[robnagler]

Thanks for figuring it out.

[jonr667]

I am experiencing the same issue. When I started using NFS shares I started experiencing occasions where the VM would stop responding to 'ls' and other file system access level commands. Turns out if you have ANY Vagrant VM's running with NFS then every time you start/stop another Vagrant VM that is NOT using NFS it prunes the mounts and kills off NFS for the VM's that do use it. This is even true across different users. I'm guessing the nfs_prune function looks for any instances of Vagrant based NFS exports existing and if it finds them, even if they are unrelated to the current VM it is trying to instantiate, than it goes ahead and prunes them essentially freezing any VM's that are reliant upon them.

Seems like a fix would need to entail tagging the NFS exports by VM and only having a VM prune it's own exports.

[chrisroberts]

As a work around to prevent the error until a proper solution is in place, you can disable NFS modifications using the nfs_export option in your Vagrantfile:

https://www.vagrantup.com/docs/synced-folders/nfs#nfs_export