Rails 3. l'obtention de Errno::EACCES l'Autorisation Refusée lors du téléchargement de fichiers sur la production

L'application fonctionne très bien dans le développement, mais dans la production-je obtenir Errno::EACCES Permission Denied erreur quand j'essaie de télécharger un fichier à l'aide de Carrierwave. Je suis sûr qu'il a quelque chose à voir avec les autorisations. Comment puis-je définir les autorisations pour permettre l'upload de fichiers?

pdf_uploader.rb

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

def cache_dir
  "#{Rails.root}/tmp/uploads/cache/#{model.id}"
end
est-ce heroku ou d'un autre service?
c'est une application à l'aide de ActiveAdmin. Il utilise CarrierWave pour l'upload de fichiers. J'utilise Apache et le Passager.
J'ai été faire Errno::EACCESS sur /uploads.. ma solution était d'ajouter #{Rails.root}/public/ à la store_dir méthode. 🙂 J'espère que l'aide à quelqu'un!

OriginalL'auteur leonel | 2012-01-13

  1. 15
    chmod -R 777 PATH_TO_APP/uploads 
chmod -R 777 PATH_TO_APP/tmp
    n'est-ce pas dangereux?
    Non, c'est normal de faire ce genre de répertoire accessible en écriture pour les autres utilisateurs.
    Il est dangereux, parce que permettre à tous les utilisateurs aussi inconnu tout fait, alors que la véritable solution est de changer l'utilisateur et les groupes de votre dossier app à apache d'utilisateur et de groupe, dans la plupart des cas, est www-data.
    Je voudrais utiliser 666 sur 777. Jamais, jamais, jamais utiliser 777 et vous devriez être bien.
    Il n'est pas normal de le faire. La configuration de chaque fichier exécutable, lisible et accessible en écriture par tout le monde.

    OriginalL'auteur alexkv

  2. 3

    Autant que je sache, il y a deux choses qui peuvent se passer ici:

    1) Le répertoire que vous êtes en train d'enregistrer vos images n'ont pas de privilèges de lecture/écriture pour les autres utilisateurs.

    À corriger:

    terminal

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

    ou si vous êtes en train d'enregistrer vos images dans un répertoire privé: 

    $ chmod -R 666 private/uploads

    Nous utilisons plus de 666 777. 666 permet de lire et d'écrire des privilèges à un répertoire, et carrierwave doit écrire ses images. 777 permet de lire, d'écrire des privilèges et pour des fichiers exécutables à être exécuté! En d'autres termes, un programme méchant pourrait être téléchargés sur votre serveur déguisé en image si vous utilisez 777. Même si carrierwave de l'extension de white-list permet de résoudre ce problème, vous devez toujours utiliser plus de 666 777.

    2) Vous n'êtes pas à l'aide de chaînes entre guillemets doubles dans la store_dir méthode.

    À corriger:

    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

    Veux juste souligner la subtilité c'est. Vous besoin de chaînes entre guillemets doubles et Rails.root! J'ai fait ça:

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

    et il ne fonctionnait pas à tous. De manière subtile. La communauté devrait aborder cette question.

    OriginalL'auteur Starkers

  3. 2

    Uhm, j'ai eu le même problème avec un serveur ubuntu. Le téléchargement d'un fichier avec carrierwave et puis d'essayer de la lire avec roo (un bijou pour les fichiers excel).

    Errno::EACCES in IngestionController#upload
Permission denied

    Autorisations ont été chmod de 777 sur le répertoire et le fichier est créé sur ok. Je crois que les questions lors de la lecture du chemin d'accès au magasin.

    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.

    Bien que tout fonctionne bien lors de l'exécution de la même application sur mon mac.

    Dans mon cas c'était un problème avec roo pour être pierres à aiguiser.. j'ai tout expliqué ici: stackoverflow.com/questions/11015448/...

    OriginalL'auteur Hiromichan

  4. -1

    Nous avons besoin d'accorder des autorisations pour accéder le répertoire requis pour le système de l'utilisateur root

    sudo chmod 777 -R your_project_directory_to_be_access

    Pour des raisons de sécurité, il suffit de garder dans votre esprit:

    chmod 777 donne à tout le monde de lire, d'écrire et d'exécuter des droits qui, pour la plupart des problèmes est définitivement trop.

    OriginalL'auteur Jai Kumar Rajput