2012-01-13 22 views
10

La aplicación funciona bien en desarrollo pero en producción obtengo el error Errno :: EACCES Permission Denied cuando trato de cargar un archivo usando Carrierwave. Estoy seguro de que tiene algo que ver con los permisos. ¿Cómo puedo configurar los permisos para permitir cargas de archivos?Rails 3. getting Errno :: EACCES Permiso Denegado al cargar archivos en producción

pdf_uploader.rb

def store_dir 
    "#{Rails.root}/uploads/#{model.id}" 
end 

def cache_dir 
    "#{Rails.root}/tmp/uploads/cache/#{model.id}" 
end 
+1

es este heroku o un servicio diferente? –

+0

es una aplicación que usa ActiveAdmin. Utiliza CarrierWave para subir archivos. Yo uso Apache y Passenger. – leonel

+1

Obtenía 'Errno :: EACCESS' en'/uploads' .. mi solución era agregar '# {Rails.root}/public /' al método 'store_dir'. :) Espero que ayude a alguien! – RGB

Respuesta

15
chmod -R 777 PATH_TO_APP/uploads 
chmod -R 777 PATH_TO_APP/tmp 
+9

no es tan peligroso? – leonel

+0

No, es normal hacer que dichos directorios puedan escribirse para otros usuarios. – alexkv

+0

cómo asegurar que este directorio tenga los permisos apropiados para las aplicaciones de producción que se implementan usando capistrano? – Danny

2

Uhm he estado teniendo el mismo problema con un servidor de Ubuntu. Cargar un archivo con carrierwave y luego tratar de leerlo con roo (una joya para archivos de Excel).

Errno::EACCES in IngestionController#upload 
Permission denied 

Los permisos se han modificado en 777 en ese directorio y el archivo se crea correctamente. Creo que el problema es al leer la ruta de la tienda.

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. 

Aunque todo funciona bien cuando se ejecuta la misma aplicación en mi mac.

+0

En mi caso, era un problema con roo ser honestos. Lo expliqué todo aquí: http://stackoverflow.com/questions/11015448/errnoeacces-in-controllerupload-rails-roo-carrierwave-on-ubuntu/11023278# 11023278 – Hiromichan

2

Por lo que yo sé que hay dos cosas que pueden estar pasando aquí:

1) El directorio que guarda las imágenes de que no tiene privilegios de lectura/escritura para otros usuarios.

Fijar:

terminal de

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

o si va a guardar tus imágenes en un directorio privado:

$ chmod -R 666 private/uploads 

estamos usando 666 sobre 777. 666 permite privilegios de lectura y escritura en un directorio, y carrierwave necesita escribir sus imágenes. 777 permite ejecutar los privilegios de lectura, escritura y . En otras palabras, un programa desagradable podría ser subido a su servidor disfrazada de una imagen si está utilizando 777. A pesar de que la extensión de la lista blanca carrierwave resuelve este problema, siempre se debe utilizar más de 666 777.

2) No está utilizando cadenas de comillas dobles en el método store_dir.

Fijar:

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 

Sólo quiero señalar cuán sutil es esto. ¡Usted necesita cadenas entre comillas dobles y Rails.root! yo estaba haciendo esto:

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

y no funcionaba en absoluto. Tan sutil La comunidad debe abordar esto.

0

Tenemos que conceder permisos para acceder al directorio requerido para el usuario root del sistema

sudo chmod 777 -R your_project_directory_to_be_access 

Por razones de seguridad, sólo tener en su mente:

chmod 777 da a todo el mundo leer, escribir y ejecutar derechos que para la mayoría de los problemas es definitivamente demasiado.