Rails 3. getting Errno::EACCES Permission Denied when uploading files on production

24,641

Solution 1

chmod -R 777 PATH_TO_APP/uploads 
chmod -R 777 PATH_TO_APP/tmp 

Solution 2

As far as I know there are two things that can be going on here:

1) The directory you're saving your images to doesn't have read/write privileges for other users.

To fix:

terminal

$ cd [my_app]
$ chmod -R 666 tmp
$ chmod -R 666 public/uploads

or if you're saving your images in an private directory:

$ chmod -R 666 private/uploads

We're using 666 over 777. 666 allows read and write privileges to a directory, and carrierwave needs to write its images. 777 allows read, write privileges and for executable files to be executed! In other words, a nasty program could be uploaded to your server disguised as an image if you're using 777. Even though carrierwave's extension white-list solves this problem, you should always use 666 over 777.

2) You're not using double quoted strings in the store_dir method.

To fix:

app/example_uploader.rb

class BaseUploader < CarrierWave::Uploader::Base
  # other methods removed for brevity

  def store_dir
    "#{Rails.root}/private/" # works perfectly. Many thanks to @RGB
  end

end

Just want to point out how subtle this is. You need double quoted strings and Rails.root! I was doing this:

def store_dir
    Rails.root + '/private' # raises Errno::EACCES error
end

and it was not working at all. So subtle. The community should address this.

Solution 3

Uhm I have been having the same issue with a ubuntu server. Uploading a file with carrierwave and then trying to read it with roo (a gem for excel files).

Errno::EACCES in IngestionController#upload
Permission denied

Permissions have been chmod-ed to 777 on that directory and the file gets created ok. I believe the issues is when reading the store path.

excelx_file = params[:excel_file]
filex = MetadataUploader.new
filex.store!(excelx_file)
workbook = Excelx.new("#{filex.store_path}") <- This is the actual line throwing the error.

Although everything works ok when executing the same app on my mac.

Share:
24,641
leonel
Author by

leonel

Updated on February 04, 2020

Comments

  • leonel
    leonel over 4 years

    The app works fine in development but in production I get Errno::EACCES Permission Denied error when I try to upload a file using Carrierwave. I'm sure it has something to do with permissions. How can I set the permissions to allow file uploads?

    pdf_uploader.rb

    def store_dir
      "#{Rails.root}/uploads/#{model.id}"
    end
    
    def cache_dir
      "#{Rails.root}/tmp/uploads/cache/#{model.id}"
    end
    
  • alexkv
    alexkv over 12 years
    No, it's normal to make such directories writable for other users.
  • Hiromichan
    Hiromichan almost 12 years
    In my case it was an issue with roo to be hones.. I explained everything here: stackoverflow.com/questions/11015448/…
  • Danny
    Danny over 11 years
    how to ensure this directory has appropriate permissions for production apps being deployed using capistrano?
  • rderoldan1
    rderoldan1 over 10 years
    It is dangerous, because allow all users also unknown made everything, so the real solution is change the user and groups of your app folder to apache user and group, in most cases is www-data.
  • Starkers
    Starkers about 10 years
    I'd use 666 over 777. Never, ever, ever use 777 and you should be fine.
  • Alric
    Alric about 9 years
    Clearly not the case in this situation, but, if you're saving the attachments to a mounted device that doesn't allow the chmod command, e.g., CIFS, test using the "noperm" option in fstab (or however you're mounting). It indicates the "client does not do permission checks." So, if a library runs chmod, it won't get an error with this option.
  • Incognito
    Incognito almost 9 years
    It is not normal to do this. You're setting every file as executable, readable, and writeable by anyone.
  • Jeremy Davis
    Jeremy Davis over 5 years
    This is a terrible suggestion! Whilst it may be ok for someone hacking away in the bedroom, it is NEVER ok to set 777 permissions on anything being served publicly, especially anything in production!