Last modified: 2014-07-04 00:48:15 UTC
err: /Stage[main]/Multiwiki/File[/vagrant/settings.d/multiwiki]/owner: change from 502 to vagrant failed: Failed to set owner to '1001': Operation not permitted - /vagrant/settings.d/multiwiki Bryan suggested that it might be a permissions issue with the mount. I'm using OSX, which uses NFS. vagrant@mediawiki-vagrant:/vagrant/settings.d$ ls -l ... drwxr-xr-x 2 502 www-data 68 Jun 27 23:54 multiwiki drwxr-xr-x 14 502 dialout 476 Jun 27 23:53 puppet-managed ... On my actual OS: $ ls -l ... drwxr-xr-x 2 km _appstore 68 Jun 27 16:54 multiwiki/ drwxr-xr-x 14 km staff 476 Jun 27 16:53 puppet-managed/ ...
I think this is caused by the nfs provider and an OSX host system. NFS requires that the user and group ids exist on both the client and the server. On the Ubuntu guest, normal user uids start at 1001, on OSX they start at 501. See http://digiactive.com.au/blog/2014/01/18/fixing-permissions-on-vagrant-nfs-synced-folders/ for a more detailed description and one possible work around (vagrant-bindfs plugin).
Change 142768 had a related patch set uploaded by BryanDavis: Stop setting owner/group on files in /vagrant/settings.d https://gerrit.wikimedia.org/r/142768
Vagrant attempts to eliminate this uid/gid mapping problem by using the `-mapall` option for the nfs export. On my host (OSX 10.8.5; Vagrant 1.6.3), the export looks like this: "/path/to/vagrant" 10.11.12.13 -alldirs -mapall=501:20 This feature was added in https://github.com/mitchellh/vagrant/commit/46c462d322d633e01c788a75948a764c94365c4d (Vagrant 0.5.0) On the Ubuntu guest the mount looks ok too: 10.11.12.1:/path/to/vagrant on /vagrant type nfs (rw,vers=3,udp,addr=10.11.12.1) I even tried creating a user on the host system with uid 1001, but to no avail. Ori reports that it works fine for him :(
Ori corrected his report to say that nfs in general works fine for him, but the centralauth/multiwiki classes have the same problem reported by Kunal. The patch in I3228ab4 works for me but does cause some puppet permission change spam on repeated `vagrant provision` calls. If we end up creating an installer to setup the initial Vagrant environment, using the vagrant-bindfs plugin might be the cleanest long term solution for issues like this. I have been using vagrant-bindfs in a Vagrant VM that I use for scap testing and it seems to work well for allowing the guest VM to set file ownership as it sees fit without conflicting with the host OS.
Change 142768 merged by jenkins-bot: Stop setting owner/group on files in /vagrant/settings.d https://gerrit.wikimedia.org/r/142768
