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

macOS host crash with nfs enabled in Vagrant #8331

Closed
lordgordon opened this issue Mar 5, 2017 · 4 comments
Closed

macOS host crash with nfs enabled in Vagrant #8331

lordgordon opened this issue Mar 5, 2017 · 4 comments

Comments

@lordgordon
Copy link

lordgordon commented Mar 5, 2017

Hi there,

I have a very annoying issue with my FreeBSD guest machine. Every time I try to use NFS as shared folder mechanism, my macOS brutally crashes and reboots (kernel panic). This happens after vagrant up and while I'm using the guest. Usually while I'm writing something in the shared folder. I'm not sure this is really a Vagrant issue, but I'm running out of ideas and I need some clues to solve this annoying issue.

Vagrant version

Vagrant 1.9.2 (also occurring with 1.9.1)

Host operating system

macOS Sierra 10.12.3 (16D32)
with VirtualBox 5.1.14 r112924 (Qt5.6.2)

Guest operating system

FreeBSD 11.0-STABLE

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.require_version ">= 1.9"

Vagrant.configure(2) do |config|
  # DEV machine
  config.vm.define "dev", primary: true do |dev|
    dev.vm.box = "freebsd/FreeBSD-11.0-STABLE"

    # Shared Folders
    # NFS
    dev.vm.synced_folder "../", "/vagrant", create: true, :nfs => true,
      :mount_options => ['rw', 'async','vers=3','tcp','nolockd', 'intr', 'soft'],
      :nfs_udp => false,
      :nfs_version => 3,
      id:"vagrant-nfs"
  end

  # SSH config
  config.ssh.shell = "sh"
  config.ssh.insert_key = true

  # specific for FreeBSD
  config.vm.guest = :freebsd
  config.vm.base_mac = "080027D14C66"
  config.vm.hostname = "main"
  config.vm.box_check_update = false
  config.vm.boot_timeout = 1200 

  # Create a forwarded port mapping
  config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.network "forwarded_port", guest: 443, host: 8443
  config.vm.network "forwarded_port", guest: 8000, host: 8000
  config.vm.network "forwarded_port", guest: 8888, host: 8888

  # Create a private network
  config.vm.network "private_network", ip: "192.168.1.42"

  # Provider-specific configuration 
  config.vm.provider "virtualbox" do |vb|
      vb.customize ["modifyvm", :id, "--memory", "512"]
      vb.customize ["modifyvm", :id, "--cpus", "1"]
      vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
      vb.customize ["modifyvm", :id, "--audio", "none"]
      vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
      vb.customize ["modifyvm", :id, "--nictype2", "virtio"]
  end
end

Output and Other Info

macOS's console log doesn't show anything related to nfs around the time of the crash. Unfortunately I don't have any crash report, yet the previous time this issue occurred a crash report was generated by macOS. The cause of the crash was nfsd.

The issue seems to happen randomly. Sometimes I can work for hours. To open this report I replicated the issue disabling almost everything on my mac (no antivirus, no firewalls, no other app running). Here a timeline of the events:

17:51:07 (host) vagrant up
17:51:45 (host) vagrant ssh
17:52:30 (guest) running a build that writes in the shared folder
                files are correctly written in the shared folder and visible by the host
17:53:49 (guest) running a web server that writes logs in the shared folder
~ 17:55  (guest) running a build that writes in the shared folder
              macOS crash
~ 17:57  macOS reboot

Files are correctly shared, both directions, until the crash.

Here the /etc/exports file as generated by Vagrant:

# VAGRANT-BEGIN: 501 002b3f9e-3d24-46f9-b506-044cf5daac1c
"/Users/.../project-root-folder" 192.168.1.42 -alldirs -mapall=501:20
# VAGRANT-END: 501 002b3f9e-3d24-46f9-b506-044cf5daac1c

Expected behavior

The host shouldn't crash while using nfs' synced folders.

Actual behavior

The host crashes and reboots while using nfs' synced folders.

Workaround

I'm currently using rsync but is not an optimal solution.

Steps to reproduce

  1. set up Vagrant as described;
  2. vagrant up; vagrant ssh;
  3. work on the guest machine.

Thank you all.

@AlexandrePieroux
Copy link

AlexandrePieroux commented Mar 5, 2017

I do have the same problem as you stated. I have a C/C++ project that is mounted trough NFS and when I try to compile the program, MacOS crash (kernel panic). Some times it go well and I cannot figure out what is causing this. I even have a more basic vagrant file compared to yours:

Vagrant.configure("2") do |config|

  config.vm.box = "freebsd/FreeBSD-12.0-CURRENT"

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

  config.vm.synced_folder "../DNFC", "/home/vagrant/DNFC", type: "nfs"

  config.vm.provider "virtualbox" do |vb|
    # Customize the amount of memory on the VM:
    vb.cpus = "2"
    vb.memory = "2048"
  end

  config.ssh.shell = "sh"

end

(DNFC is the name of the C/C++ project)

Another strange thing I notice is that vagrant is telling me that the NFS mounting feature on FreeBSD is currently not supported but, in fact, it mount anyway and I do have plain access to my folder. As I said some times it go well and I can compile on the guest and sometimes it cause MacOSX to crash.

@lordgordon
Copy link
Author

I found this discussion on Apple: https://discussions.apple.com/thread/7760267
As soon I have time to replicate the issue I will post to that thread and file a bug to Apple with the kernel panic report.

I suggest you to do the same, as it seems there is no easy solution so far.

Anyway, my Vagrant is not complaining about FreeBSD being unable to mount NFS paths.

@chrisroberts
Copy link
Member

Hi there. This looks to be an upstream bug with MacOS. I'm going to close this issue as there does not appear any action to be taken from Vagrant itself. If I am mistaken and there is a specific issue with Vagrant causing this issue, please feel free to reopen this issue. Thanks!

@ghost
Copy link

ghost commented Apr 2, 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 Apr 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants