Vagrant: Problem with NFS Shared Folder Permissions on Mac OS X (El Capitan)

[jamiejackson]

I've got a colleague who updated to El Capitan and started having problems. The first thing I advised was to:

• vagrant destroy
• Upgrade to Virtualbox (from 4.? to 5.0.4)
• Upgrade Vagrant (from 1.7.2 to 1.7.4)

...which led to new problems.

When the app (the one we're using Vagrant for) starts running in Vagrant, and tries to write to the share, it fails, due to permissions problems.

Looking at the share from _within_ the VM, it's got 504:20 ownership--the user's uid and gid in the _host_ (which isn't right).

Here's the Vagrantfile snippet:

    if OS.windows?
      config.vm.synced_folder "#{host_www_dir}",
        "#{vm_shared_www_dir}",
        type: "nfs"
    elsif OS.mac?
      config.vm.synced_folder "#{host_www_dir}",
        "#{vm_shared_www_dir}",
        nfs: true,
        :bsd__nfs_options => ["-maproot=0:0"]
    elsif OS.linux?
      config.vm.synced_folder "#{host_www_dir}",
        "#{vm_shared_www_dir}",
        nfs: true,
        :linux__nfs_options => ["no_root_squash"],
        :map_uid => 0,
        :map_gid => 0
    else
      puts "Could not determine host OS or OS not accounted for."
      exit 1
    end

And here's what ends up in /etc/exports:

# VAGRANT-BEGIN: 504 4d4cc5d5-4b2b-4fe1-8187-9e928c512ba7
"/Users/jd/Sites" 192.168.56.10 --maproot=0:0 -mapall=504:20
# VAGRANT-END: 504 4d4cc5d5-4b2b-4fe1-8187-9e928c512ba7

(Granted, I don't know what I'm doing, but) for kicks, I tried :bsd__nfs_options => ["-maproot=0:0","-mapall=0:0], which just resulted in the following (and also didn't work):

# VAGRANT-BEGIN: 504 4d4cc5d5-4b2b-4fe1-8187-9e928c512ba7
"/Users/jd/Sites" 192.168.56.10 --maproot=0:0 --mapall=0:0 -mapall=504:20
# VAGRANT-END: 504 4d4cc5d5-4b2b-4fe1-8187-9e928c512ba7

Any idea what's going on?

[kornushkin]

I have similar problem after update to El Capitan (couple days ago). Something wrong with NFS in El Capitan.
If I enable NFS in Vagrantfile:

  config.vm.synced_folder ".", "/vagrant", id: "application", :nfs => true

It crashes on vagrant up:

==> machine1: 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' 192.168.33.1:'/Users/apple/PhpstormProjects/hansa' /vagrant

Stdout from the command:



Stderr from the command:

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

If I remove :nfs => true option

config.vm.synced_folder ".", "/vagrant", id: "application"

Vagrant is booting normally. But the synced folder performance is really sucks.

Please leave a comment here if you find something to resolve our problems.

[deefour]

I thought I'd comment on my experience with NFS shared folders not mounting. I started having issues with El Capitan, Vagrant 1.7.4, and Virtualbox 5.

I rolled back Vagrant to 1.7.0, and Virtualbox to 4.3.30, and based on comments in an older issue about NFS issues here, ran the following

vagrant plugin install vagrant-vbguest

I then destroyed my box, provisioned a new one, and although I didn't see the NFS shared folders listed out between the two lines below as I usually did, the folders were in fact properly linked.

==> default: Mounting NFS shared folders...
==> default: Mounting shared folders...

[kornushkin]

check your /etc/hosts. I just add "127.0.0.1 localhost" (it was removed previously from /etc/host) and restart my machine - everything is working now.

[cedricpim]

Any more details regarding this issue? I am also having the same problem with synced folders:

No NFS client was detected as installed in your guest machine. This
is required for NFS synced folders to work. In addition to this, Vagrant
doesn't know how to automatically install NFS for your machine, so
you must do this manually.

If this message is erroneous, you may disable this check by setting
`config.nfs.verify_installed` to `false` in your Vagrantfile.

El capitan, virtualbox 5 and vagrant 1.7.4

[deefour]

@cedricpim Revert back to virtualbox 4 and vagrant 1.7.0

[cedricpim]

@deefour thanks. I was hoping to start using these new releases but i guess i will need to wait :)

[DanyC97]

oh.... anyone has any idea where the problem might be? vbox or ...?

[asgorobets]

Downgrading to Vbox 4 and vagrant 1.7.0 worked indeed.
127.0.0.1 localhost entry was in my /etc/hosts file and it made no difference.

[miguno]

Same problem here. Downgrading to VirtualBox 4 and Vagrant 1.7.0 as a crude workaround fixed the issue.

[jamiejackson]

I don't have access to the machine anymore, but a couple things I noticed:

• The number of dashes before the command line switches is different for the ones automatically added and the ones I specified (whose syntax I stole off other examples.) Maybe it needs another dash.
• My colleague ended up getting a whole new machine. He moved his old directory to the new machine and continued to have problems. We started with a brand new Sites directory and a fresh SVN checkout, and that fixed it.

[breinerm]

I am having the same problem. any workaround?

[torenware]

Also using El Capitan (10.11.1), and locking up when NFS tries to mount. Downgrading to 1.70 and VB 4.3 did not help with this.

I did find an issue on Super User that may be useful in figuring this out. That SU question includes diagnostic issue from the guest that's locking up:

[pid 26767] open("/vagrant/some/file", O_RDWR|O_CREAT, 0666) = 5
[pid 26767] fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 26767] lseek(5, 0, SEEK_CUR)      = 0
[pid 26767] chmod("/vagrant/some/file", 0777) = 0
[pid 26767] flock(5, LOCK_EX

Hopefully Mitch or someone else who knows the internals will see this.

[torenware]

I've just run this with VAGRANT_DEBUG=INFO. I include the section where vagrant is trying to set up the NFS mount. The hang actually occurs shortly after the mount attempt.

Here's the relevant part of the log:

 INFO host: Execute capability: nfs_installed [#<Vagrant::Environment: /Users/rtoren/projects/nfs-test>] (darwin)
 INFO nfs: Using NFS, preparing NFS settings by reading host IP and machine IP
 INFO subprocess: Starting process: ["/usr/local/bin/VBoxManage", "showvminfo", "10105afe-cd4c-41e9-925e-c43ea2e04fa4", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
 INFO subprocess: Starting process: ["/usr/local/bin/VBoxManage", "list", "hostonlyifs"]
 INFO subprocess: Command not in installer, restoring original environment...
 INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::PrepareNFSSettings:0x00000100a061e8>
 INFO synced_folders: Invoking synced folder enable: nfs
 INFO ssh: SSH is ready!
 INFO ssh: Execute:  (sudo=false)
 INFO ssh: SSH is ready!
 INFO ssh: Execute:  (sudo=false)
 INFO guest: Execute capability: nfs_client_installed [#<Vagrant::Machine: nfs-test (VagrantPlugins::ProviderVirtualBox::Provider)>] (ubuntu)
 INFO ssh: Execute: test -x /sbin/mount.nfs (sudo=false)
 INFO environment: Acquired process lock: dotlock
 INFO environment: Released process lock: dotlock
 INFO environment: Acquired process lock: nfs-export
 INFO interface: info: Exporting NFS shared folders...
 INFO interface: info: ==> nfs-test: Exporting NFS shared folders...
==> nfs-test: Exporting NFS shared folders...
 INFO host: Execute capability: nfs_export [#<Vagrant::Environment: /Users/rtoren/projects/nfs-test>, #<Vagrant::UI::Prefixed:0x000001031c0990 @logger=#<Log4r::Logger:0x000001031c08f0 @fullname="vagrant::ui::interface", @outputters=[], @additive=true, @name="interface", @path="vagrant::ui", @parent=#<Log4r::Logger:0x0000010180b450 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x00000101826f70 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x00000101826ea8>, @name="stderr", @level=0, @formatter=#<Log4r::DefaultFormatter:0x00000101829130 @depth=7>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000010180aaa0 @level=0, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @opts={}, @stdin=#<IO:<STDIN>>, @stdout=#<IO:<STDOUT>>, @stderr=#<IO:<STDERR>>, @prefix=:"nfs-test", @ui=#<Vagrant::UI::Colored:0x00000101a8a528 @logger=#<Log4r::Logger:0x00000101a8a4d8 @fullname="vagrant::ui::interface", @outputters=[], @additive=true, @name="interface", @path="vagrant::ui", @parent=#<Log4r::Logger:0x0000010180b450 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x00000101826f70 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x00000101826ea8>, @name="stderr", @level=0, @formatter=#<Log4r::DefaultFormatter:0x00000101829130 @depth=7>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000010180aaa0 @level=0, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @opts={:color=>:default}, @stdin=#<IO:<STDIN>>, @stdout=#<IO:<STDOUT>>, @stderr=#<IO:<STDERR>>, @lock=#<Mutex:0x00000101acb3e8>>>, "10105afe-cd4c-41e9-925e-c43ea2e04fa4", ["192.168.88.88"], {"/var/www"=>{:type=>:nfs, :rsync__auto=>"true", :rsync__exclude=>nil, :rsync__args=>["--verbose", "--archive", "--delete", "-z", "--chmod=ugo=rwX"], :id=>nil, :create=>true, :mount_options=>[], :guestpath=>"/var/www", :hostpath=>"/Users/rtoren/sites/nfs-test", :disabled=>false, :map_uid=>501, :map_gid=>20, :nfs_udp=>true, :nfs_version=>3, :uuid=>"2192377906"}}] (darwin)
 INFO host: Execute capability: nfs_exports_template [#<Vagrant::Environment: /Users/rtoren/projects/nfs-test>] (darwin)
 INFO host: Execute capability: nfs_restart_command [#<Vagrant::Environment: /Users/rtoren/projects/nfs-test>] (darwin)
 INFO subprocess: Starting process: ["/sbin/nfsd", "checkexports"]
 INFO subprocess: Command not in installer, restoring original environment...
 INFO bsd: Exporting the following for NFS...
 INFO bsd: NFS DIR: ["/Users/rtoren/sites/nfs-test"]
 INFO bsd: NFS OPTS: {:type=>:nfs, :rsync__auto=>"true", :rsync__exclude=>nil, :rsync__args=>["--verbose", "--archive", "--delete", "-z", "--chmod=ugo=rwX"], :id=>nil, :create=>true, :mount_options=>[], :guestpath=>"/var/www", :hostpath=>"/Users/rtoren/sites/nfs-test", :disabled=>false, :map_uid=>501, :map_gid=>20, :nfs_udp=>true, :nfs_version=>3, :uuid=>"2192377906", :bsd__nfs_options=>["alldirs", "mapall=501:20"], :bsd__compiled_nfs_options=>"-alldirs -mapall=501:20"}
 INFO interface: info: Preparing to edit /etc/exports. Administrator privileges will be required...
 INFO interface: info: ==> nfs-test: Preparing to edit /etc/exports. Administrator privileges will be required...
==> nfs-test: Preparing to edit /etc/exports. Administrator privileges will be required...
Password:
 INFO environment: Released process lock: nfs-export
 INFO environment: Acquired process lock: dotlock
 INFO environment: Released process lock: dotlock
 INFO interface: info: Mounting NFS shared folders...
 INFO interface: info: ==> nfs-test: Mounting NFS shared folders...
==> nfs-test: Mounting NFS shared folders...
 INFO ssh: SSH is ready!
 INFO ssh: Execute:  (sudo=false)
 INFO guest: Execute capability: mount_nfs_folder [#<Vagrant::Machine: nfs-test (VagrantPlugins::ProviderVirtualBox::Provider)>, "192.168.88.1", {"/var/www"=>{:type=>:nfs, :rsync__auto=>"true", :rsync__exclude=>nil, :rsync__args=>["--verbose", "--archive", "--delete", "-z", "--chmod=ugo=rwX"], :id=>nil, :create=>true, :mount_options=>[], :guestpath=>"/var/www", :hostpath=>"/Users/rtoren/sites/nfs-test", :disabled=>false, :map_uid=>501, :map_gid=>20, :nfs_udp=>true, :nfs_version=>3, :uuid=>"2192377906"}}] (ubuntu)
 INFO ssh: SSH is ready!
 INFO ssh: Execute:  (sudo=false)
 INFO guest: Execute capability: shell_expand_guest_path [#<Vagrant::Machine: nfs-test (VagrantPlugins::ProviderVirtualBox::Provider)>, "/var/www"] (ubuntu)
 INFO ssh: Execute: echo; printf /var/www (sudo=false)
 INFO ssh: Execute: mkdir -p /var/www (sudo=true)
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-TJ3C27VRtj/agent.1033
 INFO ssh: Execute: mount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www (sudo=true)
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-TJ3C27VRtj/agent.1033

at this point, vagrant hangs.

If I change the the mount type to the default (i.e., VirtualBox's shared mount), things work.

[torenware]

Spoke too soon: after about 5 minutes or so, the log entry continued as so:

 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 '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www

Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: Connection timed out
>
 INFO ssh: Execute: mount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www (sudo=true)
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-TJ3C27VRtj/agent.1033
 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 '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www

Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: Connection timed out
>
 INFO ssh: Execute: mount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www (sudo=true)
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-TJ3C27VRtj/agent.1033

After about 10 more minutes, Vagrant bails, with a stack trace:

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

ERROR vagrant: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:236:in `execute'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/communicator.rb:246:in `sudo'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/linux/cap/mount_nfs.rb:31:in `block (2 levels) in mount_nfs_folder'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/retryable.rb:17:in `retryable'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/linux/cap/mount_nfs.rb:30:in `block in mount_nfs_folder'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/linux/cap/mount_nfs.rb:10:in `each'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/linux/cap/mount_nfs.rb:10:in `mount_nfs_folder'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/capability_host.rb:111:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/capability_host.rb:111:in `capability'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/guest.rb:43:in `capability'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/synced_folders/nfs/synced_folder.rb:104:in `enable'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/synced_folders.rb:92:in `block in call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/synced_folders.rb:89:in `each'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/synced_folders.rb:89:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:160:in `handle'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:42:in `block in call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:516:in `lock'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:41:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/env_set.rb:19:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/provision.rb:80:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/set_name.rb:50:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/box_check_outdated.rb:68:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:214:in `action_raw'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:191:in `block in action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:516:in `lock'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in `action'
/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
 INFO interface: error: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www

Stdout from the command:



Stderr from the command:

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

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

mount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www

Stdout from the command:



Stderr from the command:

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

 INFO interface: Machine: error-exit ["Vagrant::Errors::LinuxNFSMountFailed", "The following SSH command responded with a non-zero exit status.\nVagrant assumes that this means the command failed!\n\nmount -o '' 192.168.88.1:'/Users/rtoren/sites/nfs-test' /var/www\n\nStdout from the command:\n\n\n\nStderr from the command:\n\nstdin: is not a tty\nmount.nfs: Connection timed out\n"]

[fabianhenzler]

so is it an OSX issue? because on my iMac at home with 10.11.1 it seems to work. On my MacBook with 10.11.1 same issues with NFS

[mkscs]

This works for me on Mac
... , type: "nfs", bsd__nfs_options: ["maproot=0:0"],mount_options: ["..."]

[fabianhenzler]

for me it was just having 127.0.0.1 localhost in the /etc/hosts

[lmammino]

For me the only thing that worked was downgrading to Virtualbox 4.3 and vagrant 1.7.0... That's very annoying...

[wunc]

Maybe try tcp instead of udp? Mine is working on my MacBook with OS X 10.11.2, Vagrant 1.8.1.

type: 'nfs', mount_options: ['rw', 'vers=3', 'tcp', 'fsc', 'actimeo=2']

If that doesn't work, maybe check to see if there's anything useful in the Mac's system logs (Console). Maybe it has something to do with the new SIP in El Cap?

[jvnike]

We were experiencing the issues mentioned above once on El Capitan with an nfs mount into VirtualBox --> CoreOS. We implemented the mount options provided by wunc and this fixed the problem. Thanks for sharing.
Vbox 5.0.18 Vagrant 1.8.1
type: 'nfs', mount_options: ['rw', 'vers=3', 'tcp', 'fsc', 'actimeo=2']

[duydnguyen07]

I second wunc suggestion. I added the above options to my Vagrantfile and it worked perfectly.

OSX 10.11.5 Vbox 5.0.22 Vagrant 1.8.4

[malikkotob]

I'm able to get through all of the mounting no problem, but the end result is a permissions issue. When I manually add a file to my shared folder outside of the VM it doesn't appear within the VM. When I try manually writing to the shared folder within the VM it says permission denied. Anyone run into that? Running osx mavericks, when I run nfs status it says 'command not found'.

[ryanneufeld]

I encountered this yesterday after upgrading vagrant and virtualbox to 1.8.4 and 5.0.24 respectively.

My findings are that while the debug logs show the mounts failed. When running the same command manually, the command succeeds and the mount is present.

I tried manually running the command shown in this gist (and it worked manually, but not when bringing up the vm). https://gist.github.com/f05ab2fda11328cdc75f668e5bab285e

I'm using the following:

config.vm.synced_folder '.', '/vagrant', id: "vagrant", :nfs => true, :mount_options => ['rw', 'vers=3', 'tcp', 'fsc', 'actimeo=2']

[giannello]

Same issue as @ryanneufeld here. Two different laptops with Vagrant 1.8.4, VirtualBox 5.0.24, OSX Yosemite, guest OS is Ubuntu 14.04.
Mounting the folder manually with mount -o vers=3,udp '192.168.50.1:/Users/XXX/shared' '/mnt/shared' via ssh works fine. We tried downgrading to Vagrant 1.8.3 and VirtualBox 5.0.18 and the same problem happens. Changing the mount options didn't help.

[pcamen]

We've got three developers using a VM with various versions of vagrant fro 1.8.1 to 1.8.4 and virtual box from 5.0.22 to 5.0.24. Two do not have this problem but I alone do. When we add the TCP option, it works fine. The other Mac developer is on El Capitan; I am on Yosemite. But I've got older versions of the VM that work fine with udp, or perhaps the recipes were inadvertantly specify tcp for some reason.

I'd love to find the underlying OS issue that is causing this. Seems logical that it is something coming from the Mac side. I tried setting up nfsd to accept both tcp and udp connections ('nfsd -t - u') but this made no difference.

[asoki]

i experiencing this problem with vagrant 1.8.3 and 1.8.4
downgrading to vagrant 1.8.1 solved the problem for me.
host: osx 10.10.5
guest: debian wheezy

here the debug output of vagrant 1.8.1 and 1.8.3 for comparison.
the main difference seems to be that vagrant 1.8.1 tries to mount repeatedly and the third try succeeds, while vagrant 1.8.3+ gives up after the first failure.

vagrant 1.8.1 log:

DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: echo; printf /redacted/path/to/mountpoint (sudo=false)
DEBUG ssh: Exit status: 0
DEBUG ssh: stdout: 
/redacted/path/to/mountpoint
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mkdir -p /redacted/path/to/mountpoint (sudo=true)
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o 'vers=3,udp' 192.168.116.1:'/Users/redacted/path/to/share' /redacted/path/to/mountpoint (sudo=true)
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' 192.168.116.1:'/Users/redacted/path/to/share' /redacted/path/to/mountpoint

Stdout from the command:



Stderr from the command:

mount.nfs: requested NFS version or transport protocol is not supported
>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o 'vers=3,udp' 192.168.116.1:'/Users/redacted/path/to/share' /redacted/path/to/mountpoint (sudo=true)
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' 192.168.116.1:'/Users/redacted/path/to/share' /redacted/path/to/mountpoint

Stdout from the command:



Stderr from the command:

mount.nfs: requested NFS version or transport protocol is not supported
>
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mount -o 'vers=3,udp' 192.168.116.1:'/Users/redacted/path/to/share' /redacted/path/to/mountpoint (sudo=true)
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: if command -v /sbin/init &>/dev/null && /sbin/init --version | grep upstart &>/dev/null; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT='/redacted/path/to/mountpoint'
fi
 (sudo=true)
DEBUG ssh: stderr: /sbin/init: invalid option -- '-'

DEBUG ssh: stderr: Usage: init {-e VAR[=VAL] | [-t SECONDS] {0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}

DEBUG ssh: Exit status: 0
 INFO synced_folders: Invoking synced folder enable: vmware
DEBUG ssh: Checking whether SSH is ready...
DEBUG ssh: Re-using SSH connection.
 INFO ssh: SSH is ready!
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute:  (sudo=false)
DEBUG ssh: Exit status: 0
DEBUG guest: Searching for cap: verify_vmware_hgfs

vagrant-1.8.3 log:

DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: echo; printf /redacted/path/to/mountpoint (sudo=false)
DEBUG ssh: Exit status: 0
DEBUG ssh: stdout: 
/redacted/path/to/mountpoint
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mkdir -p '/redacted/path/to/mountpoint'
mount -o vers=3,udp '192.168.116.1:/Users/redacted/path/to/share' '/redacted/path/to/mountpoint'
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT='/redacted/path/to/mountpoint'
fi
 (sudo=true)
DEBUG ssh: stderr: mount.nfs: requested NFS version or transport protocol is not supported

DEBUG ssh: stdout: /sbin/init

DEBUG ssh: stderr: /sbin/init: invalid option -- '-'

DEBUG ssh: stderr: Usage: init {-e VAR[=VAL] | [-t SECONDS] {0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}

DEBUG ssh: Exit status: 0
 INFO synced_folders: Invoking synced folder enable: vmware
DEBUG ssh: Checking whether SSH is ready...
DEBUG ssh: Re-using SSH connection.
 INFO ssh: SSH is ready!
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute:  (sudo=false)
DEBUG ssh: Exit status: 0
DEBUG guest: Searching for cap: verify_vmware_hgfs

[chrisRidgers]

I cannot express how grateful I am that @asoki s post exists.

God damn that was a long few hours.

[infovore]

Thanks, @asoki. A downgrade to 1.8.1 from 1.8.4 solved this for me.

[antoinefabrice]

Hello,
No need to downgrade VirtualBox or Vagrant. The problem is from the Mac firewall.
tail -f /var/log/appfirewall.log
<Info>: nfsd: Deny UDP CONNECT ...
I just allow "nfsd" in Preference -> Security -> Gate Keeper -> Options and it's working.

[onlyanegg]

I'm also seeing @asoki's errors. It would be nice if these were raised to an error or warning rather than debug. Maybe there's another bug report for that?

[rozagh]

We have the same issue with NFS files locking after upgrading our OSx to Sierra.
I had virtual box 5.0.2 and vagrant 1.7.4 and I tried upgrading to virtualbox 5.1.10 and vagratn 1.8.7 but still the same issue.
this is the nfs definition line
devd.vm.synced_folder ".", "/vagrant", type: "nfs", mount_options: ['rw', 'vers=3', 'tcp']

Has anyone tried downgrading to solve this problem in Sierra? VirtualBox 4 are not supported now so I hesitate to downgrade.

[pcamen]

The issue seems to be the Vagrant version. I also recently upgrade to Sierra and had the same issue. Once I downgraded from the latest available Vagrant version (as of last week) to Vagrant 1.8.1 everything worked fine. I am currently running Virtualbox 5.0.10.

[antoinefabrice]

Hello rozagh, pcamen,
Have you allowed the application "nfsd" in Preference -> Security -> Gate Keeper -> Options ?

[lightster]

Edit: This issue is so sporadic. After rebooting my Mac, my NFS mount won't let files be deleted sometimes. If I edit and save the file from my VM, it saves successfully and _then_ I can delete it.

Outdated
Yet another possibility: If you use an encrypted sparsebundle on macOS as a mounted directory in your Vagrant VM, you may get permission denied errors when writing to the mounted directory (even with root/sudo). I switched to an unencrypted sparsebundle to fix the issue (since my drive is encrypted anyhow).

[crashev]

There is something broken either in Vagrant or in Sierra NFSD, some files can be deleted from within guest linux os, some can not. Hope this will be fixed soon.

[rozagh]

@antoinefabrice is this a preference of Mac OS? I don't see GateKeeper anywhere.
Update:
I started using VitualBox 5.0.30 and Vagrant 1.8.1 and at first it seemed to resolve the locking issue in some level. But I still have issues with symlinks which cannot be cleaned up and my environment not working fully. I have to keep going to host machine clean up some of the build dirs and run build again inside vm.

[danielmitd]

Same over here with vagrant 1.9, virtualbox 5.1 and Sierra. After adding the mount option lookupcache=none it works just fine but in terms of performance this screws up everything. In my case even vboxfs would be faster and it does not have permission issues.

[whizkid79]

Same here. Vagrant 1.8.1 with Parallels 12.1.1 and Sierra. The lookupcache=none seems to work, but is too slow to be usable.
The only change introducing this issue for me was upgrading to Sierra, so the root cause is probably the nfsd from macos.

[danielmitd]

The only change introducing this issue for me was upgrading to Sierra, so the root cause is probably the nfsd from macos.

Looking into the code changes of nfsd between the two releases, I think it's not related to nfsd itself. Or at least I don't see it.

• https://opensource.apple.com/release/os-x-1012.html
• https://opensource.apple.com/release/os-x-1011.html

[rozagh]

Can we reopen this issue? Or should we report a new bug?

[crashev]

@rozagh I've already opened a new ticket at https://github.com/mitchellh/vagrant/issues/8061

[mowings]

Just a note -- you can get some temporary relief from this issue by running ls -laR on the osx host. This seems to do some kind of cache invalidation on the osx host, and will fix the delete issue -- at least until it reoccurs. This definitely a sierra issue.

[peterdragon]

Another workaround is to use sshfs plugin for vagrant
https://github.com/dustymabe/vagrant-sshfs
Slower than NFS but it works

$ vagrant plugin install vagrant-sshfs
change the Vagrantfile
config.vm.synced_folder "/Users/someuser/shared", "/home/vagrant/shared", type: "sshfs"
$ vagrant reload

[henriquecholo]

@peterdragon finally it works. Is there any chance to work with nfs?

[tripsjgh]

I was also having this issue on El Capitan and Sierra.

In my case doing some digging, it turned out that Vagrant was not respecting the following line in my configuration:

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

This resulted in there being no interface with that address (confirmed via ifconfig -a in my VagrantBox) while the output of showmount -e showed that "192.168.33.10" was the only ip allowed to mount:

Exports list on localhost:
/Users/cjackson/vagrant/temp        192.168.33.10
/Users/cjackson/vagrant/foo/devtools 192.168.33.10
/Users/cjackson/vagrant/foo/app1 192.168.33.10

Updating the configuration to include "auto_config: false" fixed the issue in my case and allowed continued use of NSF synced folders on macOS El Capitain and Sierra hosts; the guest in my case is CentOS.

config.vm.network "private_network", ip: "192.168.33.10", auto_config: false

[abhiyaantrix]

hey, we were facing the same problem. But there is a solution, no need to revert any upgrades to vagrant or virtualbox. Thanks to all the previous posts (solutions) here and some other reading, I solved it like this.

macOS Sierra 10.12.3, Vagrant 1.9.1, Version 5.1.14 r112924

In Vagrantfile (if not already)
config.vm.network :private_network, ip: '192.168.XX.XX', auto_config: false
config.vm.synced_folder '.', '/app', nfs: true

Run this command in terminal to disable Gatekeeper on macOS Sierra
sudo spctl --master-disable

And now things should work smoothly.

[patriziotomato]

Not sure why, but maybe this can also help. My setup on El Capitan is

config.vm.synced_folder ".", "/vagrant", id: "vagrant-root", nfs_export: false,
    type: 'nfs', mount_options: ['rw', 'vers=3', 'tcp', 'fsc', 'actimeo=2']

After first attempt to boot, I needed to completely restart my host to make the changes apply. Then it booted smoothly without any further change. So, worth to restart maybe.

[larmedina75]

The solution here: https://www.comoinstalarlinux.com/error-en-vagrant-al-montar-directorio-compartido-con-nfs/

Just modify your Vagrantfile to change sync-directory to use NFS 4 and do not use UDP, see details in the link. I do this and works fine.

[liquidice]

Until Apple fixes this and If for some reason one doesn't want NFS4, it may be most convenient to setup a trigger. The following will automatically run ls -alR > /dev/null before vagrant mounts the shared NFS folder.

$ vagrant plugin install vagrant-triggers

Then in your Vagrantfile merge this trigger code:

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

  config.vm.provider "virtualbox" do |vb, override|

    # Counter OS X Sierra NFS write error bug.
    override.trigger.before [:up, :resume] do
        run "./scripts/sierra_nfs_fix.sh"
    end
  end
end

./scripts/sierra_nfs_fix.sh contains the following:

#!/bin/bash

# Counters OS X Sierra NFS write error bug. https://github.com/mitchellh/vagrant/issues/6360
if [[ $OSTYPE =~ 'darwin16' ]]; then
    echo "Detected OS X Sierra, applying NFS bug counter measures."
    ls -alR www > /dev/null
fi

[marcofranssen]

Is there any definitive fix for this issue?

We are still facing issues with all things mentioned above where the /vagrant folder isn't owned by the vagrant:vagrant user and group.

Event though we have set the gid and uid to 1000 which equals to the vagrant user on the VM.

Host OS: MacOS Sierra
Guest OS: Ubuntu 14.04

[liquidice]

@marcofranssen, map_uid and map_gid are not intended to change the owner or group of the shared files within vagrant. See https://www.vagrantup.com/docs/synced-folders/nfs.html#map_uid

[emileber]

Related Stack Overflow question

[snfnwgi]

default: 5986 (guest) => 55986 (host) (adapter 1)

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: WinRM address: 127.0.0.1:55985
default: WinRM username: IEUser
default: WinRM execution_time_limit: PT2H
default: WinRM transport: plaintext
==> 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...
==> default: Mounting NFS shared folders...
Vagrant attempted to execute the capability 'mount_nfs_folder'
on the detect guest OS 'windows', but the guest doesn't
support that capability. This capability is required for your
configuration of Vagrant. Please either reconfigure Vagrant to
avoid this capability or fix the issue by creating the capability.

[chrisRidgers]

looks at ticket open date

o_O

If this is an apple/ sierra / NFS issue shouldn't this have been resolved by now?

[chrisRidgers]

@snfnwgi i suspect you should probably open up a separate ticket as it doesn't immediately look related to this.

[chrisRidgers]

Looking back at the comments I can't actually tell if this is resolved or not.

Theres a referenced merge and the issue is closed but comments have carried on for so long beyond that it's unclear.

@sethvargo you closed this, was this known to be fixed and is that still the case? I keep getting notifications on this issue and it looks like people are still looking for a fix.

[snfnwgi]

@chrisRidgers Excuse me, I do not understand what you mean, can you elaborate on it?

[chrisRidgers]

@snfnwgi

Your issue looks like its related to your guest OS not supporting NFS while your configuration is trying to use it.

This thread is for an issue involving Mac OS file permissions and NFS.

If you've got a new issue, then open up a new ticket so it doesn't get lost inside this one.

[chrisRidgers]

@snfnwgi also this thread is technically closed, so its unlikely it will receive much attention.

[snfnwgi]

I was running on the MAC windows, so we can not use NFS @chrisRidgers

[chrisRidgers]

@snfnwgi create a new ticket.

[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.