Error with installing bundler

I’m trying to run some builds that were previously running, however I’m receiving the following error when the bundler gem is attempting to be installed.

#!/bin/bash -eo pipefail
gem install bundler rake
Fetching: bundler-1.16.0.gem (100%)
ERROR:  While executing gem ... (Errno::EACCES)
    Permission denied @ rb_sysopen - /usr/local/bundle/cache/bundler-1.16.0.gem
Exited with code 1

I’ve tried clearing the caches and re-running, and the problem is persisting.
Builds were previously running with the same circle ci configuration, so nothing has changed there.

Any thoughts on what else I can try to get around this problem.

1 Like

I’ve started getting the exact same problem today but with Brakeman gem:

gem install brakeman bundler-audit reek rubocop rubocop-rspec
Fetching: brakeman-4.0.1.gem (100%)
ERROR:  While executing gem ... (Errno::EACCES)
    Permission denied @ rb_sysopen - /usr/local/bundle/cache/brakeman-4.0.1.gem
Exited with code 1

Running gem install with sudo fixes the problem for me.

Same here. Builds were working last evening (timestamp: 2017-11-10T23:59:33+0000) and now we’re seeing the Permission denied error when trying to install bundler as a run command:

      - run:
          name: Install latest Bundler
          command: gem install bundler

Needing to sudo seems like a Bad Idea™ given our build all happens in Circle 2.0, on docker images.

Halp?

Thanks all for reporting. We found the issue, and this should now be fixed. Please let us know if you are still encountering this issue.

Unfortunately the issue is still persisting for us.

We have also tried clearing caches in case that would cause the problem to linger.

We can occasionally get it to work, but it involves retrying many times, and as our build is in a workflow, occasionally some tasks will pass and others will fail with the same error.

Is there anything else that we can try?

if this is fixed, I just tried to re-run and now I’m getting error below. It now fails before gem install bundler.

#!/bin/bash -eo pipefail
curl -sS https://getcomposer.org/installer | sudo php – --install- dir=/usr/local/bin --filename=composer
curl: (35) Unknown SSL protocol error in connection to getcomposer.org:443
Exited with code 35

my config is:

  - run: sudo apt-get update
  - run: sudo apt-get install curl php5-cli git
  - run: curl -sS https://getcomposer.org/installer | sudo php -- --install- dir=/usr/local/bin --filename=composer
  - run: ./composer install
  - run: gem install bundler
  - run: bundle install --jobs=3 --retry=3 --deployment
  - run: make unit

Same issue.

We’re still seeing the same error. I tried pushing a new commit; same thing. Tried “rebuilding without cache”; same thing. Suggestions?

Hey ya’ll, Sorry for the trouble.

We deployed a fix about an hour ago, but if this issue still affects you there are two options:

  • For installing gems use, sudo gem install instead
  • Use an older sha of the image such as:
    build:
      docker:
      - image: circleci/ruby@sha256:abc6306af73f787394b7cb496eeda424f5497a5227027615120b4b79aa2dede0
    

Please let me know if this issue still persists for you.

Again, sorry for any trouble!

What ended up working for me was this:

        - run:
          name: Bundle Install
          command: |
            sudo gem install bundler -v 1.15.4 # <-- wut
            bundle install --path vendor/bundle --jobs 4 --retry 3
1 Like

What’s the ruby version of the image in your post?
We are using circleci/ruby:2.4.2

circleci/ruby:2.4.1-node-browsers has no problem at all. circleci/ruby:2.4.2-node-browsers need the fix mentioned above

I’ve gone with adding sudo gem install bundler, and that seems to be giving the more consistent result for us right now.

I’ll look to revert back later in the week, as I’d prefer not to use sudo where we don’t need to

Although we deployed new images this morning here, it may take some time to get through the system since some dockers are still running with the old sha cached.

You could work around this by specifying the sha, also adding sudo works, but I suggest you don’t “gem install bundler” at all since we pre-install a stable version for you. If they happen to release a broken version and you install the latest, your builds will start failing for no reason. This happens often enough that we started pinning the version of bundler on our 2.0 images, which lead to this issue.

2 Likes

I’ve removed the command to install bundler and that looks to be working well for us.

I think another poster mentioned that they got a similar issue installing brakeman. We also install that, but that hasn’t caused an issue for us at all.

Thanks for the help!

1 Like

I suggest you don’t “gem install bundler” at all since we pre-install a stable version for you.

We didn’t always do this, but started to during the 1.16. pre releases for… some reason I no longer remember. In truth, I think we be better served by pinning to the same bundler version that Heroku installs on their heroku-16 stack. That or move to use Heroku’s docker images as our starting point. Anyhow, thanks for getting this fixed and keeping us updated!

1 Like

Glad to hear things are working again.

I get the same issue when running bundle install with the iOS Xcode 9.3.1 image, but not the iOS Xcode 9.0 one. Versions in between have not been tested.

It appears to be the result of bad permission setting given that running export BUNDLE_PATH=~/.gems while ssh’d in fixes the issue, however this is not a good solution as it doesn’t persist between build steps and may cause other issues. Changing either where gems are installed or the permissions of the current path should resolve it.

Please fix this ASAP. I’m surprised that this has gone unnoticed for such a long period of time.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.