Errno::EACCES: Permission denied #77
Comments
|
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 😉) |
|
I was eager to try bootsnap out since the 1.0 release, but I am getting this exact error message after deploying it to a server (powered by Nginx/ Passenger). I have no problems so far locally (Puma web server) in development mode. I would love to get bootsnap running on our servers! |
|
Experiencing the same error.... https://www.dropbox.com/s/rh8t9hzyn3jiv5b/Screenshot%202017-10-31%2004.16.20.png?dl=0 |
|
If anyone is still getting this, I'd be curious to see the trace with 1.1.6.beta3. |
|
@burke |
|
I did some digging but didn't find any smoking gun. So it's failing in this code: tmp_path = mktemp(template);
fd = open(tmp_path, O_WRONLY | O_CREAT, 0644);
if (fd < 0) { /* HITS THIS PATH */
if (mkpath(path, 0755) < 0) { /* RETURNS SUCCESS */
*errno_provenance = (char *)"bs_fetch:atomic_write_cache_file:mkpath";
return -1;
}
fd = open(tmp_path, O_WRONLY | O_CREAT, 0644); /* RETURNS EACCES */
if (fd < 0) {
*errno_provenance = (char *)"bs_fetch:atomic_write_cache_file:open";
return -1;
}
}
dest = strncpy(template, path, MAX_CACHEPATH_SIZE);
strcat(dest, ".tmp.XXXXXX");
tmp_path = mktemp(template);...which means it should be identical to
Then maybe |
|
One thing: If your cache was already populated; that is, all of those |
|
@burke Thank you for the digging, I think your comments are pointing in the right direction: The application's code is used by two different UNIX users within the same group which is why we usually use |
|
Hm, I guess I don't really see why we couldn't make it group-usable. |
|
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. |
|
@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! |
|
Unfortunately I needed to rollback the change, I received the permission errors again. It seems like that bootsnap is behaving correctly but that my server setup is messy. If somebody else has similar problems, I am happy to hear about possible solutions! |
|
You can't just |
|
@burke I did some deeper digging and it feels like that my problem might be related to
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. |
|
Or maybe these permissions should be configurable, similar to https://github.com/carrierwaveuploader/carrierwave#configuring-carrierwave ? |
|
I had a similar problem: I've upgraded to Rails 5.2.0.rc1. The owner of the Changing the permissions of Thanks. |
|
I had this issue ( |
|
I have the same issue since I have two different users, one for the deploy through Capistrano, one to run the apps. |
|
Setting 777 seems to be the easiest solution... I don't know whether this may have security drawbacks. |
|
When running my app with phusion passenger, This probably implies that bootsnap is run for the first time at a lower level in the "passenger stack" before the app gets to switch to We tried to work around this, however, the app cannot really do much to work-around the fact that some files/folders are root-owned, hence permission issues are raised. One useful feature would be to enable a bootsnap configuration for the permissions (or a umask) that the files/folders created or perhaps another flag to not put things there until whatever time later the app changes users. I realize this may not be straightforward. Perhaps a simple solution with some other way to initialize things? We have verified that once the app is running, if we remove the tmp/cache/bootsnap* folders, they will get regenerated (as |
|
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. |
|
For me, I removed bootsnap gem from the |
|
This is an issue for me on Debian 8.x serving a Rails 5.2 app via Puma (managed by systemd). Shouldn't this be re-opened given the ongoing reports? |
|
@einSelbst how did you fix it? |
|
@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: |
|
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'
endIt 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 was on digital ocean, and this link helped me: Than apply the group to permission the folder |
|
As a workaround, I was able to run rails console on AWS Beanstalk by issuing the following commands: |
|
FYI, #255 took care of a similar sounding permission error for us. This was released yesterday in 1.4.3. I deployed with bootsnap 1.4.3, and cleared the cache again ( |
|
This worked for me: changed gemfile to then run |
This worked for me. Thank you @daniel-rikowski :) |
How do we do this could you explain in steps pls |
@Divyanshu810 Go to the parent folder and then: chmod 777 cache/bootsnap-compile-cache |
When we added
bootsnapto our application we started getting the following errors whenever we run anything:Cache path is
/app/tmp/cache/bootsnap-compile-cache, which writable for the processes running tasks.Also, some files are created:
Ruby 2.4.1,
bootsnap1.1.2.The text was updated successfully, but these errors were encountered: