Permission denied #237

heffergm · 2014-11-17T21:42:39Z

I'm a little mystified by this. I'd been using vagrant-berkshelf 2.x for a while without issue. Having upgraded to 4.0.0, I'm in the following situation:

the initial vagrant up proceeds without issue, however if I halt and then restart the box, or try to reprovision it, I get the following error:

Vendoring yum-epel (0.5.1) to /Users/grant/.berkshelf/vagrant-berkshelf/shelves/berkshelf20141117-36310-1or3u6-default/yum-epel

    stderr: /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `initialize': Permission denied @ rb_sysopen - /Users/grant/.berkshelf/vagrant-berkshelf/shelves/berkshelf20141117-36310-1or3u6-default/pelias/.git/objects/02/6d813fd34b114e7deae1eb2c98afed1c1e7f13 (Errno::EACCES)
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `open'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `block in copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1401:in `open'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1401:in `copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:483:in `copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:400:in `block in cp'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1579:in `block in fu_each_src_dest'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1595:in `fu_each_src_dest0'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1577:in `fu_each_src_dest'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:399:in `cp'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:88:in `block in sync'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:71:in `each'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:71:in `sync'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb:617:in `block in vendor'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/tmpdir.rb:88:in `mktmpdir'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb:577:in `vendor'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:387:in `vendor'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:52:in `dispatch'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:27:in `execute!'
    from /opt/chefdk/embedded/apps/berkshelf/bin/berks:5:in `<top (required)>'
    from /opt/chefdk/bin/berks:38:in `load'
    from /opt/chefdk/bin/berks:38:in `<main>'

If I rm -rf /Users/grant/.berkshelf/vagrant-berkshelf, I can run successfully, but again, subsequent attempts will fail.

Any idea what's going on? No commands are being run with sudo or as different users, etc. The perms on the files that I get the access error for are 444, owner/group as I'd expect.

... and it would appear that a chmod -R 755 ~/.berkshelf/vagrant-berkshelf/ resolves the problem.

The text was updated successfully, but these errors were encountered:

sethvargo · 2014-11-17T21:54:28Z

What's your umask?

heffergm · 2014-11-17T22:31:36Z

~$ umask
0022

sethvargo · 2014-11-17T22:49:30Z

Hrm.... This is definitely a permissions issue between the VM and the host, but I'm not really sure why.

heffergm · 2014-11-17T23:24:34Z

So the local env is homebrew/rbenv, and I've gotten around chefdk and local gems conflicts by putting /opt/chefdk/bin first in my path, but otherwise nothing springs to mind.

joelhandwell · 2014-11-18T00:42:32Z

Recently I updated ChefDK from 0.2 to 0.3.5. and also getting similar error.
I'm running with ChefDK 0.3.5 with vagrant-berkshelf 4.0.0. both on Fedora 20 and Windows 7.
as @heffergm says, after I run chmod -R 755 ~/.berkshelf/vagrant-berkshelf/, I can run vagrant provision --provision-with chef_solo successfully, but after running, if I do vagrant provision --provision-with chef_solo again without chmod -R 755 ~/.berkshelf/vagrant-berkshelf/, I'm getting same error.
I got same error as @heffergm got in Windows 7.
Following is the error I got in fedora, (It's similar but the error says I'm not using ChefDK, though I have installed it with)

[Joel@fedora-vagrant]$ vagrant provision --provision-with chef_solo
==> default: Loading Berkshelf datafile...
...
Vendoring yum-mysql-community (0.1.10) to /home/Joel/.berkshelf/vagrant-berkshelf/shelves/berkshelf20141117-22625-1d34b0l-default/yum-mysql-community

    stderr: /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `initialize': Permission denied @ rb_sysopen - /home/Joel/.berkshelf/vagrant-berkshelf/shelves/berkshelf20141117-22625-1d34b0l-default/uv_apache/.git/objects/01/8f5ba47c1fee9601a966e2a42a56ac755019fa (Errno::EACCES)
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `open'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `block in copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1401:in `open'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1401:in `copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:483:in `copy_file'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:400:in `block in cp'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1579:in `block in fu_each_src_dest'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1595:in `fu_each_src_dest0'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1577:in `fu_each_src_dest'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:399:in `cp'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:88:in `block in sync'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:71:in `each'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/file_syncer.rb:71:in `sync'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb:617:in `block in vendor'
    from /opt/chefdk/embedded/lib/ruby/2.1.0/tmpdir.rb:88:in `mktmpdir'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb:577:in `vendor'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:387:in `vendor'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:52:in `dispatch'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/cli.rb:27:in `execute!'
    from /opt/chefdk/embedded/apps/berkshelf/bin/berks:5:in `<top (required)>'
    from /usr/bin/berks:38:in `load'
    from /usr/bin/berks:38:in `<main>'


It appears that you are not using the ChefDK. Please note that Vagrant Berkshelf
works best when used with the ChefDK, and other installation methods are not
officially supported.

Please download and install the latest version of the ChefDK from:

    https://downloads.getchef.com/chef-dk

and follow the installation instructions. Do not forget to add the ChefDK to
your PATH.

sethvargo · 2014-11-18T01:42:32Z

I see .git in both those stack traces. It's unclear to me why there's a .git directory in there...

heffergm · 2014-11-18T11:50:39Z

My project is here if you'd care to give it a look: https://github.com/pelias/vagrant

I'm also using ChefDK 0.3.5 and vagrant-berkshelf 4.0.0.

joelhandwell · 2014-11-18T15:18:56Z

the cookbook uv_apache is a wrapper cookbook of apache2 community cookbook. In Berksfile, the wrapper cookbook is seen like this "uv_apache", path: 'cookbooks/uv_apache'. And this cookbook is managed by git in Vagrant shared folder.

heffergm · 2014-11-18T16:12:04Z

I went ahead an moved some things, namely nesting the actually cookbook under cookbooks/ rather than having it in the top level, and things work now. I gather the contents of .git was being pulled in by berkshelf and the resultant permissions on those files were not as expected.

ericcitaire · 2014-11-26T17:54:42Z

Quick workaround in /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb, add '.git' in sync exclusion :

FileSyncer.sync(scratch, destination, exclude: ['**/metadata.rb', '.git'])

sethvargo · 2014-11-26T18:50:52Z

This is fixed in Berkshelf as of berkshelf/berkshelf#1342 and will be fixed when a new version of Berkshelf + ChefDK are released.

brk3 · 2014-12-02T15:44:17Z

In case it helps anyone, the above workaround didn't work for me, needed:

FileSyncer.sync(scratch, destination, exclude: ['**/metadata.rb', '**/.git'])

franklinwise · 2015-01-26T23:47:18Z

This is not an edge case. When can we see a new release of Berkshelf + ChefDK?

sethvargo · 2015-01-26T23:56:53Z

@franklinwise unfortunately we have no control over the release cycles of ChefDK. Berkshelf is already out and updated.

franklinwise · 2015-01-27T00:40:00Z

@sethvargo - understand, thanks

gionn · 2015-02-04T11:28:45Z

new Chef-DK 0.4.0 is out but this fix isn't included, isn't it?

quietcat · 2015-02-04T18:12:11Z

It seems to happen when there are git repos in cookbook subfolders. Building on @ericcitaire and @brk3 comments I changed '.git' to '**/.git' in EXCLUDED_VCS_FILES_WHEN_VENDORING = ['.arch-ids', '{arch}', '.bzr', '.bzrignore', '.bzrtags', 'CVS', '.cvsignore', '_darcs', '.git', '.hg', '.hgignore', '.hgrags', 'RCS', 'SCCS', '.svn'].freeze line in /opt/chefdk/embedded/apps/berkshelf/lib/berkshelf/berksfile.rb

josacar · 2015-02-08T13:46:09Z

Same happens to me after upgrading to chefdk 0.4.0

joaocunha · 2015-02-10T00:14:09Z

Had the same issue after restarting the computer. The workaround was:

vagrant destroy --force
rm -rf ~/.berkshelf
#@quietcat's change in berksfile.rb
vagrant up

Worth mentioning my vagrant up build was failing due to network errors, so a VPN played a big role.

I wonder if it has to do with restarting without vagrant halt'ing?

acorncom · 2015-02-19T05:22:12Z

joelhandwell's script referenced above works for me.

I'm using chefdk 0.4.0, Vagrant 1.7.2 and vagrant-berkshelf 4.0.3

levmichael3 · 2015-02-19T10:11:12Z

@joaocunha and @quietcat it worked for me as well, thanks!
Instead of deleteing the berkshelf shelf each time and run provision making the '**/.git' change made the trick.

ERROR was about the 'sendmail' community cookbook:

stderr: /opt/chefdk/embedded/lib/ruby/2.1.0/fileutils.rb:1402:in `initialize': Permission denied @ rb_sysopen - /home/****/.berkshelf/vagrant-berkshelf/shelves/berkshelf20150217-4295-1fixznz-default/sendmail/.git/objects/21/ffa1b33b817de42e4f2b20adf69c801594b217 (Errno::EACCES)

chicobico · 2015-04-12T15:48:23Z

Thx for the quick fix.
With '**/.git' it works.

mrjcleaver · 2015-06-14T13:29:58Z

+1 for @quietcat 's #237 (comment) working

sethvargo mentioned this issue Nov 18, 2014

After converge failure get error messaging I have the wrong berks version #238

Closed

joelhandwell mentioned this issue Nov 26, 2014

Don't vendor .git directory berkshelf/berkshelf#1346

Closed

sethvargo closed this as completed Nov 26, 2014

sethvargo mentioned this issue Dec 2, 2014

Updating Vagrant's Berkshelf fails #243

Closed

CharlesTBetz mentioned this issue Apr 14, 2015

fix chefdk issue dm-academy/Calavera#16

Closed

berkshelf locked and limited conversation to collaborators Jun 16, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Permission denied #237

Permission denied #237

heffergm commented Nov 17, 2014

sethvargo commented Nov 17, 2014

heffergm commented Nov 17, 2014

sethvargo commented Nov 17, 2014

heffergm commented Nov 17, 2014

joelhandwell commented Nov 18, 2014

sethvargo commented Nov 18, 2014

heffergm commented Nov 18, 2014

joelhandwell commented Nov 18, 2014

heffergm commented Nov 18, 2014

ericcitaire commented Nov 26, 2014

sethvargo commented Nov 26, 2014

brk3 commented Dec 2, 2014

franklinwise commented Jan 26, 2015

sethvargo commented Jan 26, 2015

franklinwise commented Jan 27, 2015

gionn commented Feb 4, 2015

quietcat commented Feb 4, 2015

josacar commented Feb 8, 2015

joaocunha commented Feb 10, 2015

acorncom commented Feb 19, 2015

levmichael3 commented Feb 19, 2015

chicobico commented Apr 12, 2015

mrjcleaver commented Jun 14, 2015

Permission denied #237

Permission denied #237

Comments

heffergm commented Nov 17, 2014

sethvargo commented Nov 17, 2014

heffergm commented Nov 17, 2014

sethvargo commented Nov 17, 2014

heffergm commented Nov 17, 2014

joelhandwell commented Nov 18, 2014

sethvargo commented Nov 18, 2014

heffergm commented Nov 18, 2014

joelhandwell commented Nov 18, 2014

heffergm commented Nov 18, 2014

ericcitaire commented Nov 26, 2014

sethvargo commented Nov 26, 2014

brk3 commented Dec 2, 2014

franklinwise commented Jan 26, 2015

sethvargo commented Jan 26, 2015

franklinwise commented Jan 27, 2015

gionn commented Feb 4, 2015

quietcat commented Feb 4, 2015

josacar commented Feb 8, 2015

joaocunha commented Feb 10, 2015

acorncom commented Feb 19, 2015

levmichael3 commented Feb 19, 2015

chicobico commented Apr 12, 2015

mrjcleaver commented Jun 14, 2015