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:
Change nfs
to default
.
run vagrant reload --provision
change default
back to nfs
run vagrant reload
I have search and tried various suggested solution but nothing worked for me thus far.
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.
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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With