Unknown permission problem

[akitaonrails]

I have this repo defining a Vagrantfile and Chef cookbooks. When I enable cachier, it blows up like this:

tar: utils: Cannot change ownership to uid 0, gid 0: Operation not permitted
tar: Exiting with failure status due to previous errors
---- End output of cd /var/chef/cache ; mkdir -p 'redis-2.6.14' ; tar zxf 'redis-2.6.14.tar.gz' --strip-components=1 -C 'redis-2.6.14' ----
Ran cd /var/chef/cache ; mkdir -p 'redis-2.6.14' ; tar zxf 'redis-2.6.14.tar.gz' --strip-components=1 -C 'redis-2.6.14' returned 2
DEBUG ssh: Exit status: 1

I'm running OS X Mavericks, with the VMWare provider. Tried synced_folder both with and without NFS enabled, no difference.

[fgrehm]

Sorry but I don't own a Mac neither a VMWare provider =/

@tmatilai IIRC you are a Mac user and you also use the provider right? Would you mind jumping in on this one? ;)

[tmatilai]

Yes I do. But it will take a couple of hours before I can take a closer look...

[tmatilai]

The issue here is:

• When tar x is executed as a root, GNU tar defaults to --same-owner to set the owner of the extracted files to the same as in the tarball
• chown operation is not allowed and fails in Fusion's shared folders (vmhgfs). Virtualbox just ignores it.

I didn't have time now to test with that repo or even cookbook, but NFS seems to also work just fine (it also ignores the chown). But note that you need to enable it for the cachier mount, not for /vagrant. I.e. add config.cache.enable_nfs = true to the Vagrantfile.

Unfortunately I don't see anything that vagrant-cachier could do here. The readme already recommends using NFS with VMware providers. Maybe we should link this issue there too?

As the redisio cookbooks seems to support only Linux distros, it could probably add --no-same-owner option (which is GNU tar specific) to the tar call.

A quick google search gives hints that the issue has been in hgfs for a long time, so I don't have high hopes that they would change the behavior.

[fgrehm]

@tmatilai tks for digging into this! :)

@akitaonrails would you mind giving a go at enabling NFS for the cache buckets to check if things work fine? I suspect that you should be fine by setting config.cache.enable_nfs = true as @tmatilai said. I noticed you have enabled NFS for /vagrant but you didn't try enabling it for the cache. Just make sure you nuke your ~/.vagrant.d/cache/precise64_vmware before recreating the machine to start fresh ;)

[akitaonrails]

Thanks! enable_nfs was the missing link. It's working well now!

[fgrehm]

awesome :)

[JacobSanford]

1 year+ late, but I ran into this on Mavericks and is almost certainly related to OSX/nfs squashing root permissions. It isn't restricted to vagrant-cachier, but appears due to NFS silliness. See:

http://serverfault.com/questions/487862/vagrant-os-x-host-nfs-share-permissions-error-failed-to-set-owner-to-1000

A fix for this is to include _no_rootsquash in your NFS export options:

export_options => ['no_root_squash']

Although based on advice here: http://drpebcak.svbtle.com/nfs-configuration-with-vagrant

I typically use :

export_options: ['async', 'insecure', 'no_subtree_check', 'no_acl', 'no_root_squash']

Some of those are defaults in V3, but it is nice to be sure. Hope this helps future frustrated people like myself.