10

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
leonel
  • 10,106
  • 21
  • 85
  • 129

4 Answers4

17
chmod -R 777 PATH_TO_APP/uploads 
chmod -R 777 PATH_TO_APP/tmp 
alexkv
  • 5,144
  • 2
  • 21
  • 18
  • No, it's normal to make such directories writable for other users. – alexkv Jan 13 '12 at 21:17
  • how to ensure this directory has appropriate permissions for production apps being deployed using capistrano? – Danny Feb 14 '13 at 20:37
  • 7
    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. – rderoldan1 Oct 22 '13 at 15:01
  • 5
    I'd use `666` over `777`. Never, ever, ever use `777` and you should be fine. – Starkers Apr 07 '14 at 11:57
  • 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. – Alric Mar 24 '15 at 04:29
  • 7
    It is not normal to do this. You're setting every file as executable, readable, and writeable by anyone. – Incognito Jun 16 '15 at 17:25
  • 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! – Jeremy Davis Aug 24 '18 at 05:55
4

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.

Starkers
  • 10,273
  • 21
  • 95
  • 158
2

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.

Hiromichan
  • 76
  • 7
  • In my case it was an issue with roo to be hones.. I explained everything here: http://stackoverflow.com/questions/11015448/errnoeacces-in-controllerupload-rails-roo-carrierwave-on-ubuntu/11023278#11023278 – Hiromichan Jun 14 '12 at 11:17
-1

We need to grant permissions to access the required directory for the system root user

sudo chmod 777 -R your_project_directory_to_be_access

For security reasons, just keep in your mind:

chmod 777 gives everybody read, write and execute rights which for most problems is definitively too much.

Jai Chauhan
  • 4,035
  • 3
  • 36
  • 62