8

I have a vagrant box with chef provisioner. Everything works fine except when there are operation on NFS resources. For example, I have the following synced folders:

"host_path": "/Users/User/devbox/vdd/data",
        "guest_path": "/var/www",
        "type": "nfs"

And in the vagrant file:

 # Synced Folders.
    config_json["vm"]["synced_folders"].each do |folder|
      case folder["type"]
      when "nfs"
        config.vm.synced_folder folder["host_path"], folder["guest_path"], type: "nfs"
        # This uses uid and gid of the user that started vagrant.
        config.nfs.map_uid = Process.uid
        config.nfs.map_gid = Process.gid

and I also have a chef recipe that executes a create action on an nfs resource:

directory "/var/www" do
  owner "vagrant"
  group "vagrant"
end

However, I keep getting the following error:

 default: Error executing action `create` on resource 'directory[/var/www]'
==> default: ================================================================================
==> default: 
==> default: 
==> default: Errno::EPERM
==> default: ------------
==> default: Operation not permitted - /var/www
==> default: 
==> default: 
==> default: Resource Declaration:
==> default: ---------------------
==> default: # In /tmp/vagrant-chef-3/chef-solo-2/cookbooks/vdd/recipes/apache.rb
==> default: 
==> default:   1: directory "/var/www" do
==> default:   2:   owner "vagrant"
==> default:   3:   group "vagrant"
==> default:   4: end
==> default:   5: 
==> default: 
==> default: 
==> default: 
==> default: 
==> default: Compiled Resource:

The only way to get rid of the problem (and keep the nfs) is by the following:

  1. Change nfs to default.

  2. run vagrant reload --provision

  3. change default back to nfs

  4. run vagrant reload

I have search and tried various suggested solution but nothing worked for me thus far.

awm
  • 1,130
  • 3
  • 17
  • 37
  • What does the ownership and modes look like when it fails? – coderanger Jan 26 '15 at 21:15
  • 1
    is this what you're asking for: `drwxr-xr-x 7 501 dialout 238 Jan 26 19:41 www` / – awm Jan 28 '15 at 21:41
  • 1
    So the only way to get nfs to work is to add `nfs: true, :linux__nfs_options => ["no_root_squash", "rw","no_subtree_check"],:map_uid => 0, :map_gid => 0` but then the permissions and ownership are not right. – awm Jan 29 '15 at 16:49
  • I have this kind of error also (without chef), by creating folders in a bash provision script. The owners look the same and I can't change it ! – nha Jul 21 '15 at 15:19
  • This helped me solve this problem: https://stackoverflow.com/questions/56959305/vagrant-failing-on-mounting-nfs-due-to-macos-catalina-beta-update – lukassteiner Jul 12 '21 at 10:55

3 Answers3

6

The Operation not permitted problem is common with a lot of questions asked on StackOverflow, and in about every case I looked at, it's because the virtual machine (Vagrant box) is trying to do file permissions operations (chmod, chown, chgrp, etc.) in a directory that is linked (via NFS or something else) to a filesystem on the host OS (your main computer). I don't want to bore you with the details, but this will throw an error for some of the people, some of the time; and be no problem for other people, other times. Your workaround in the comments illustrates this point!

If you're one of those affected by this problem, you have to make sure that your file shares are not needed as anything other than a read-only file structure in the guest OS; and anything that needs to change or write to those files, such as php composer.phar install (or other things that change/set up/write stuff) should take place and be executed directly on the host computer.

As a final note, Vagrant boxes (virtual machines) are meant to be disposable and destroyable on a moment's notice; and the fact that you're running code from the virtual machine to cause files that are probably permanently needed as part of your project defies this strategy at face value.

Alternate Solution:

Alternately, if you need to run code in the virtualized environment (the Vagrant box, if you will) which needs unfettered access to the permissions capabilities of that guest OS, simply do so in a location of its directory tree which is untouched by the local-to-guest "folder source" to "folder target" mapping. You can tell which folders are in this range with the mount command from the Vagrant box, if it's Linux-based.

  • Coming back to this after long time, is it possible to use chef to execute instructions on the host machine? I understand that they should be destroyable but doing operations on shared resources such as file system is one of the values of using vagrant. PS. I was able to fix the problem by doing the mounting after the provisioner has been done. – awm Feb 10 '17 at 17:14
  • The host machine is, in most cases, "holy ground." It's the developer's environment where source files are kept and which operate (and co-exist) with many tools and resources that are not meant to be shared with other team members on a given project because they are not part and parcel to those various projects. Therefore, chef (and other such things) should limit their operations to the ephemeral guest environments and not be allowed to intrude on the "holy ground" of the host OS (and its source files). – unrivaledcreations Feb 21 '17 at 15:46
1

this is more of an important comment than an answer. in my vagrant configuration I 'accidentally (misunderstanding-ly)' ran $ sudo vagrant up before (correctly running $ vagrant destroy dev- this then made some local (host) fileshare changes as # root, when I re-ran $ vagrant up the new couldn't use the folders # root had made"vagrant up" (even though I had no more vm's)

^
|
hard to explain easy to actually understand

TL;DR if you use sudo with vagrant you need to manually remove/chown residual changes on the host as NOT sudo

ConnerMan
  • 111
  • 2
1

I was able to fix this issue by telling vagrant to mount the nfs resource after the provisioning by passing the after: :provision, option. Here is the line of code in my vagrantfile:

config.bindfs.bind_folder "/var/nfs-#{i}", folder["guest_path"], after: :provision, perms: "u=rwX:g=rwX:o=rD", o: 'nonempty'
awm
  • 1,130
  • 3
  • 17
  • 37