bootsnap: Errno::EACCES: Permission denied

For me, I removed bootsnap gem from the Gemfile as well as a line of code loading bootsnap from boot.rb. The problem solved.

You can’t just chown -R $appuser tmp/cache before starting?

@niyando we added the ec2 user to the same group as the user who creates the app. Credit goes to @a14m.

This is the ebextensions file:

commands:
  25_add_ec2_user_to_webapp_group:
    command: "usermod -a -G webapp ec2-user"
  30_create_post_deploy_dir:
    command: "mkdir /opt/elasticbeanstalk/hooks/appdeploy/post"
    ignoreErrors: true
 files:
  "/opt/elasticbeanstalk/hooks/appdeploy/post/99_grant_group_ownership_over_new_app_version":
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/usr/bin/env bash
      chmod -R g=u /var/app/current

I get this error with a Rails app deployed via AWS ElasticBeanstalk whenever I want to run a rails/rake command on the EC2 instance. I couldn’t find a work-around so far.

This worked for me:

changed gemfile to gem 'bootsnap', '>= 1.1.0', '< 1.4.2', require: false

then run

bundle install
sudo chmod 777 -R /srv/www/appname/tmp/
rake tmp:cache:clear
restart application

I had this issue (Permission denied - bs_fetch:atomic_write_cache_file:open) when upgrading my project to Rails 5.2 on Ubuntu and Nginx. Changing permissions of cache/bootsnap-compile-cache to 777 solved the problem - although it doesn’t sound right.

On our production environment the Rails app runs as a Systemd service under a user with limited system access. If I run the console as our devops user the file permissions of the cache change and errors start popping up.

My workaround is that I skip Bootsnap in production console using:

boot.rb

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)

require 'bundler/setup'

# Gather environment information
in_console = (ARGV & ['c', 'console']).any?
in_development = ENV['RAILS_ENV'] != 'production'

# Do not use bootsnap in production console to prevent cache file permission issues
if in_development || !in_console
  require 'bootsnap/setup'
end

It is difficult to detect console mode so early on in the Rails initialization process, but this allows us to use Bootsnap until I find a better way to work around the file permission issue.

I get these on a regular basis. I noticted it’s triggered by updating certain gems, especially gems with C extensions. The permission error also seems to be related to the Ruby VM memory and not the file system.

Anyway, after clearing the bootsnap-compile-cache directory the error always goes away (until the next bundle update 😉)

As a workaround, I was able to run rails console on AWS Beanstalk by issuing the following commands:

eb ssh
cd /var/app/current
sudo su -
RAILS_ENV=production bundle exec rails console

@burke I did some deeper digging and it feels like that my problem might be related to umasks. I can reproduce it like this:

1. Delete bootsnap-compile-cache directory
2. Restart nginx application process so that the cache is generated
3. Start the Rails console from another user within the same group

This way the files are generated with wrong permissions, which is not the case when I exchange steps 2 + 3. The nginx application process and normal user have different umasks which explains the problem.

I am not sure how to fix this, it feels like that our whole server setup is just messed up. On the other hand, it might be possible to bypass umask configurations as described in https://stackoverflow.com/a/39737630/745266 , but I am not sure if this is actually a good practice or not.

One thing:

If your cache was already populated; that is, all of those 00, 01, etc. directories already existed – and then you ran the application as a different user without write permission to those directories – I can see this happening.

I get these on a regular basis. I noticted it’s triggered by updating certain gems, especially gems with C extensions. The permission error also seems to be related to the Ruby VM memory and not the file system.

Anyway, after clearing the bootsnap-compile-cache directory the error always goes away (until the next bundle update 😉)

This worked for me. Thank you @daniel-rikowski 😃

@burke Thank you very much, with this fix I was able to deploy bootsnap to our production system! After deleting the cache from a previous deployment, everything seems to work now! Awesome work!

I just released 1.1.7, which writes caches with 0775 and 0644. We could probably catch that error in ruby-land and raise a more descriptive error but I’m going to wait and see if anyone else complains now that group-writability is toggled on.