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

opscode-centos-7.1 Virtualbox box not able to NFS mount #388

Closed
andytson opened this issue Jul 2, 2015 · 5 comments · Fixed by #617
Closed

opscode-centos-7.1 Virtualbox box not able to NFS mount #388

andytson opened this issue Jul 2, 2015 · 5 comments · Fixed by #617
Assignees

Comments

@andytson
Copy link
Contributor

andytson commented Jul 2, 2015

It seems a change has been done in a build of opscode-centos-7.1 that is causing for some reason, the private network static ip to not be assigned before vagrant mounts nfs. This causes nfs to fail.

Checking the ip address assignment after the failure shows the static ip isn't assigned. An ifdown and ifup of the private network adapter introduces the static IP.

This wasn't an issue in an earlier opscode-centos-7.1 build (if you did one before that, or it was just me manually building the working one before you released it), nor opscode-centos-7.0.

Using vboxsf, the static ip is assigned to the private network adapter after boot.

Steps to recreate

  • import opscode-centos-7.1
  • vagrant init opscode-centos-7.1
  • edit Vagrantfile to add a private network with a static ip of 33.33.33.15, and add a synced folder with NFS
  • vagrant up

causes:

==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
Password:
==> default: Mounting NFS shared folders...
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:'/Users/andy' /vagrant

Stdout from the command:



Stderr from the command:

mount.nfs: access denied by server while mounting 33.33.33.1:/Users/andy
@davemac30
Copy link

I believe this is similar to a problem I am having with private_network using chef/centos-7.1.

When my machine first boots, it get it's private network interface (enp0s8, in my case) configured as expected:

$ vagrant ssh -c "ip a s enp0s8"
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:26:7d:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.33.10/24 brd 192.168.33.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe26:7d7e/64 scope link 
       valid_lft forever preferred_lft forever

A few seconds later, however, the i/f's ipv4 config is gone:

$ vagrant ssh -c "ip a s enp0s8"
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:26:7d:7e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe26:7d7e/64 scope link 
       valid_lft forever preferred_lft forever

I believe this is something to do with the way vagrant configures the private_network dynamically, when it first brings the box up, not being compatible with NetworkManager. Even though the static config created by vagrant (/etc/sysconfig/network-scripts/ifcfg-enp0s8) contains the line "NM_CONTROLLED=no", NetworkManager seems to be aware of the interface:

# nmcli c
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  edbeb169-7e0e-4596-af02-b81bd9b502c4  802-3-ethernet  enp0s8 
enp0s3              3c36b8c2-334b-57c7-91b6-4401f3489c69  802-3-ethernet  enp0s3

journalctl shows that NetworkManager trying to do DHCP on the interface, which of course fails. Eventually NetworkManager marks the interface disconnected.

Restarting NetworkManager and the network makes everything ok, presumably because configs are loaded from /etc/sysconfig/network-scripts. Likewise a reboot clears it.

I don't think this is a problem with the box, rather it's a shortcoming of vagrant's approach to dynamic configuration of a network i/f when NetworkManager is active.

@cheeseplus
Copy link
Contributor

Does this condition still exist with the latest (2.2.2) release? Also is this a bento specific issue or a general vagrant issue?

@rickard-von-essen
Copy link
Collaborator

Can't reproduce this with bento/centos-7.1 (v2.2.2) and Vagrant 1.7.4.

@cheeseplus
Copy link
Contributor

In that case closing for now, feel free to re-open should the condition arise again.

@legal90
Copy link
Contributor

legal90 commented Jun 18, 2016

@cheeseplus @rickard-von-essen It seems like we have a similar issue with parallels provider, with a 100% reproduction scenario: Parallels/vagrant-parallels#265

It was fixed in Boxcutter by boxcutter/centos@be4174e. I'll send a PR soon.


Could be reproduced with bento/centos-7.2 v2.2.7:

Vagrant.configure("2") do |config|
  config.vm.box = "bento/centos-7.2"
  config.vm.network "private_network", ip: "10.37.132.10"
  config.vm.network "private_network", ip: "10.37.132.20"
end
$ vagrant up --provider=parallels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants