bundle update -> permission denied
Pito
denied error, see transcript at the end.
I posted a question with lots of detail to stackoverflow, so to save
saying it all again, here's the link:
http://stackoverflow.com/questions/5420785/bundler-update-fails-with-mysterious-permission-denied
But since then I have done some more troubleshooting. Here are the
facts:
I am on OS X / Snow Leopard. My Ruby etc are all installed via
macports. As a result, I am running gem from /opt/local/bin/gem. But
because snow leopard came with ruby, there's also a version of gem
here: /usr/bin/gem. I kind of think that is somehow the source of my
problem.
Also as is well known, on mac when I use gem, I need to do sudo gem
install xxx, otherwise it installs stuff in my ~/.gem directory, so I
always do sudo.
To troubleshoot, I totally uninstalled the gem with macports, and then
reinstalled it. This did not help.
I was very tempted to do sudo bundle install but there are severe
warnings in the bundle doc not to do that.
Any help solving this silly problem would be so greatly appreciated!!!
-- Pito
Here's the transcript of what happens right now:
/mydev/ElectionManager(export-work)> bundle install
Fetching source index for http://rubygems.org/
Using rake (0.8.7)
Using Ascii85 (1.0.0)
Installing activesupport (2.3.11) /opt/local/lib/ruby/1.8/fileutils.rb:
243:in `mkdir': Permission denied - /opt/local/lib/ruby/gems/1.8/gems/
activesupport-2.3.11 (Errno::EACCES)
from /opt/local/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir'
from /opt/local/lib/ruby/1.8/fileutils.rb:217:in `mkdir_p'
from /opt/local/lib/ruby/1.8/fileutils.rb:215:in `reverse_each'
from /opt/local/lib/ruby/1.8/fileutils.rb:215:in `mkdir_p'
from /opt/local/lib/ruby/1.8/fileutils.rb:201:in `each'
from /opt/local/lib/ruby/1.8/fileutils.rb:201:in `mkdir_p'
from /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:156:in
`install'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
source.rb:96:in `install'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
installer.rb:55:in `run'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
spec_set.rb:12:in `each'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
spec_set.rb:12:in `each'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
installer.rb:44:in `run'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
installer.rb:8:in `install'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
cli.rb:226:in `install'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
vendor/thor/task.rb:22:in `send'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
vendor/thor/task.rb:22:in `run'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
vendor/thor/invocation.rb:118:in `invoke_task'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
vendor/thor.rb:246:in `dispatch'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/
vendor/thor/base.rb:389:in `start'
from /opt/local/lib/ruby/gems/1.8/gems/bundler-1.0.10/bin/bundle:13
from /opt/local/bin/bundle:19:in `load'
from /opt/local/bin/bundle:19
Andre Arko
> I was very tempted to do sudo bundle install but there are severe
> warnings in the bundle doc not to do that.
`sudo bundle install` will mean that the only user that can start your application or modify it's bundle is root. since that is rarely what you want, we advise against it.
> Any help solving this silly problem would be so greatly appreciated!!!
You have an extremely unusual setup. While bundler is supposed to detect when it needs sudo permissions to install gems automatically, I think something is going wrong due to your setup being unique.
The only reason that "sudo gem install" is suggested on OS X machines is because the default system gems (NOT gems installed via MacPorts or some other way) are owned by root, and there is no way to install them without sudo. Since you are not using system gems, there is no reason for you to need sudo.
I think you can probably work around the problem in one of two ways: either take ownership of /opt/local/lib/ruby/gems/1.8/ and /opt/local/bin/, so you can write to them without sudo, or install you gems with the command `bundle install --path vendor/bundle`. That command will install the gems into the directory vendor/bundle inside your project, and then you won't have permissions issues.
Since Bundler's permission detection is not working in your case, please file a ticket on the Bundler issue tracker following the steps outlined in https://github.com/carlhuda/bundler/blob/master/ISSUES.md.
– Andre
Pito Salas
Thanks for the detailed explanation...
> You have an extremely unusual setup. While bundler is supposed to detect when it needs sudo permissions to install gems automatically, I think something is going wrong due to your setup being unique.
>
Really, I thought I was more or less 'mainstream' for OSX....
> The only reason that "sudo gem install" is suggested on OS X machines is because the default system gems (NOT gems installed via MacPorts or some other way) are owned by root, and there is no way to install them without sudo. Since you are not using system gems, there is no reason for you to need sudo.
>
Yeah also I was worrying because next I want to get RVM hooked up and
things will only get weirded...
> I think you can probably work around the problem in one of two ways: either take ownership of /opt/local/lib/ruby/gems/1.8/ and /opt/local/bin/, so you can write to them without sudo, or install you gems with the command `bundle install --path vendor/bundle`. That command will install the gems into the directory vendor/bundle inside your project, and then you won't have permissions issues.
I seem to have solved it... But I can't say for sure what was wrong.
What I did was, I told port to uninstall rubygems. But then I noticed
that within the port universe /opt... I could still find a rubygems
directory under ruby. So I hard deleted that. And then reinstalled
rubygems with port. And from that point on things started working
again... I can't be positive of this chronology, but maybe there's a
useful clue in that story.
Thanks again!
Pito