file_put_contents (meta/services.json): impossible d'ouvrir le flux: autorisation refusée
Je suis nouveau à Laravel. J'essayais d'ouvrir http://localhost/test/public/ et je me suis
Erreur dans le gestionnaire d'exceptions.
J'ai cherché sur Google et changé l'autorisation du répertoire de stockage en utilisant chmod -R 777 app/storage mais en vain.
J'ai changé debug=>true dans app.php et visité la page et j'ai obtenu une erreur dans le gestionnaire d'exceptions:
Le flux ou le fichier "/var/www/html/test/app/storage/logs/laravel.log" Impossible d'ouvrir: échec de l'ouverture du flux: autorisation refusée dans /var/www/html/test/bootstrap/compiled.php:8423
Ensuite, j'ai modifié les autorisations du répertoire de stockage à l'aide de la commande chmod -R 644 app/storage. L'erreur «Erreur dans le gestionnaire d'exceptions» a disparu et une page est chargée. Mais là je reçois ceci:
file_put_contents (/var/www/html/laravel/app/storage/meta/services.json): impossible d'ouvrir le flux: autorisation refusée
Suggestion de vsmoraes a travaillé pour moi:
Laravel> = 5.4
php artisan cache:clear
chmod -R 777 storage/
composer dump-autoload
Laravel <5.4
php artisan cache:clear
chmod -R 777 app/storage
composer dump-autoload
REMARQUE: NE LE FAITES PAS SUR UN SERVEUR DISTANT (PRODUCTION DEV OR)
Lorsque j'ai posé cette question, il s'agissait d'un problème sur mon hôte local, qui s'exécutait sur une machine virtuelle. Je pensais donc que l'installation d'un 777 était suffisamment sûre, mais les gens ont raison de dire qu'ils devraient rechercher une solution différente. Essayez d'abord le 775
Pour les googleurs qui ont été confrontés à ce problème avec Laravel 5.
Il s'agit d'un problème d'autorisation provoqué par différents utilisateurs essayant d'écrire dans le même fichier journal dans le dossier storage/logs avec des autorisations différentes.
Ce qui se passe, c’est que votre configuration laravel est probablement configurée pour enregistrer les erreurs tous les jours. Par conséquent, votre serveur Web (Apache/nginx) peut créer ce fichier sous un utilisateur par défaut, selon votre environnement. Il peut s’agir de quelque chose comme _www sous OSX ou www-data sur * les systèmes NIX, le problème survient lorsque vous avez peut-être exécuté certaines commandes et obtenu des erreurs. L’artisan écrira donc ce fichier, mais avec un utilisateur différent, car PHP sur le terminal est exécuté par un autre utilisateur. en fait votre utilisateur de connexion, vous pouvez le vérifier en lançant cette commande:
php -i | grep USER
Si votre utilisateur de connexion a créé ce fichier journal sur votre serveur Web, vous ne pourrez pas y écrire d'erreurs, et inversement, car laravel écrit les fichiers journaux avec les autorisations 655 par défaut, ce qui permet uniquement au propriétaire de l'écrire.
Pour corriger ce problème temporaire, vous devez attribuer manuellement les autorisations pour le groupe 664 à ce fichier afin que votre utilisateur de connexion et votre serveur Web puissent écrire dans ce fichier journal.
Pour éviter ce problème de façon permanente, vous souhaiterez peut-être configurer des autorisations appropriées lors de la création d'un nouveau fichier dans le répertoire storage/logs en héritant des autorisations du répertoire dans lequel cette réponse https://unix.stackexchange.com/a/ 115632 peut vous aider à résoudre ce problème.
Pour tous ceux qui utilisent Laravel 5, Homestead et Mac, essayez ceci:
mkdir storage/framework/views
Vous ne devriez pas donner 777 permissions. C'est un risque pour la sécurité . Pour les utilisateurs Ubuntu, dans Laravel 5, je propose de changer de propriétaire de manière récursive pour le stockage de répertoire
Essayez ce qui suit:
Sudo chown -R www-data:www-data storage
Dans les systèmes basés sur Ubuntu, www-data est un utilisateur Apache.
quelques fois, SELINUX a causé ce problème; vous pouvez désactiver selinux avec cette commande.
Sudo setenforce 0
Problème résolu
php artisan cache:clear
Sudo chmod -R 777 vendor storage
cela active l'autorisation d'écriture sur l'application, la structure et les journaux
Pour les utilisateurs de vagabonds, la solution est la suivante:
(dans le vagabond) cache artisan php: effacer
(à l'extérieur du vagabond) chmod -R 777 app/storage
(in vagrant) composer dump-autoload
Assurez-vous que vous chmod dans votre environnement local et non pas dans vagabond est important ici!
NE JAMAIS DONNER LA PERMISSION 777!
allez dans le répertoire du projet laravel sur votre terminal et écrivez:
Sudo chown -R your-user:www-data /path/to/your/laravel/project/
Sudo find /same/path/ -type f -exec chmod 664 {} \;
Sudo find /same/path/ -type d -exec chmod 775 {} \;
Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache
De cette façon, vous faites de votre utilisateur le propriétaire et lui donnez des privilèges:
1 Execute, 2 Write, 4 Read
1 + 2 + 4 = 7 signifie (rwx)
2 + 4 = 6 signifie (rw)
Enfin, pour l'accès au stockage, ug + rwx signifie que vous donnez à l'utilisateur et au groupe une
Réessayez avec chmod -R 755 /var/www/html/test/app/storage. Utilisez avec Sudo pour Operation not permitted dans chmod. Utilisez Vérifier l'autorisation du propriétaire si l'erreur persiste.
Conformément à Laravel 5.4 qui est le dernier en date, j’écris ceci. Si vous rencontrez un problème de ce type, vous devez modifier l’autorisation. N'ECOUTEZ personne qui vous ait demandé de définir 777 pour un répertoire. Il y a un problème de sécurité. Modifier l'autorisation du dossier de stockage comme ceci
Sudo chmod -R 775 storage
Changer l'autorisation du dossier d'amorçage comme ceci
Sudo chmod -R 775 bootstrap/cache
Maintenant, assurez-vous d’exécuter les deux commandes à partir de votre répertoire d’application. Vous ne rencontrerez plus de problèmes de permission à l'avenir. Le 775 ne compromet aucune sécurité de votre machine.
Suggérez la permission correcte, si pour Apache,
Sudo chown -R Apache:apache apppath/app/storage
Si vous avez Laravel 5 et si vous cherchez une solution permanente, utilisez à la fois la ligne de commande php artisan et le serveur Apache comme suit:
Sudo chmod -R 777 vendor storageecho "umask 000" | Sudo tee -a /etc/resolv.confSudo service Apache2 restart
Voir explication détaillée ici .
POUR TOUTE PERSONNE QUI FONCTIONNE AVEC UN SE SOUS SELINUX: Voici comment autoriser httpd à écrire dans le dossier de stockage laravel:
Sudo semanage fcontext -a -t httpd_sys_rw_content_t '/path/to/www/storage(/.*)?'
Ensuite, pour appliquer les modifications immédiatement:
Sudo restorecon -F -r '/path/to/www/storage'
SELinux peut être pénible à gérer, mais si elle est présente, je vous conseille vivement de l’apprendre plutôt que de la contourner entièrement.
Xampp pour utilisation:
cd /Applications/XAMPP/htdocs
chmod -R 775 test/app/storage
rm storage/logs/laravel.log
résolu ceci pour moi
Si vous utilisez laradock, essayez chown -R laradock:www-data ./storage dans votre conteneur d'espace de travail.
Chaque fois que je change d'app.php, je reçois une permission refusée d'écrire sur bootstrap/cache/services.json. J'ai donc corrigé cela:
chmod -R 777 bootstrap/cache/
Dans mon cas, la solution consistait à modifier les autorisations en répertoires app/storage/framework/views et app/storage/logs.
J'ai eu les mêmes erreurs dans mon projet ...
Mais j'ai découvert que j'avais oublié de mettreenctypedans mon formulaire.
<form method="#" action="#" enctype="multipart/form-data">
J'espère que ça aide quelque part quelque part ...
Si quelqu'un d'autre rencontre un problème similaire avec une erreur d'autorisations de fichier fopen, mais qu'il est sage de ne pas aveuglément chmod 777, voici ma suggestion.
Vérifiez la commande que vous utilisez pour les autorisations nécessaires à Apache:
fopen('filepath/filename.pdf', 'r');
Le 'r' signifie ouvert en lecture seule, et si vous ne modifiez pas le fichier, vous devez le définir comme. Cela signifie qu'Apache/www-data nécessite au moins une autorisation de lecture sur ce fichier. Si le fichier est créé via laravel, il sera déjà doté d'une autorisation de lecture.
Si pour une raison quelconque vous devez écrire dans le fichier:
fopen('filepath/filename.pdf', 'r+');
Assurez-vous ensuite qu'Apache dispose également des autorisations nécessaires pour écrire dans le fichier.
J'avais un problème similaire. (Autorisation refusée alors que les autorisations étaient correctement configurées) avec Laravel 5.2 et 5.5
Le problème était que SELinux était activé, ce qui empêchait Apache d'écrire des fichiers, même avec le mode 777. Voir Résoudre la réponse 500 Laravel (Uncaught UnexpectedValueException: Laravel.log) pour la question et la réponse.
Peut-être que cela résout le problème pour vous également.
Alors que je travaillais sur Windows 10 avec Laragon et Laravel 4, il me semblait impossible de modifier les autorisations manuellement, car l’exécution des commandes chmod- dans le terminal Laragon n’avait aucun effet.
Cependant, il était possible dans ce terminal d’aller dans le dossier de stockage et d’ajouter manuellement les dossiers désirés comme ceci:
cd app/storage
mkdir cache
mkdir meta
mkdir views
mkdir sessions
La commande cd- du terminal vous amène au dossier (vous devrez peut-être ajuster ce chemin en fonction de la structure de votre fichier). La commande mkdir- créera le répertoire avec le nom donné.
Je n'ai pas eu l'occasion de tester cette approche dans Laravel 5, mais je m'attends à ce qu'une approche similaire fonctionne.
Bien sûr, il pourrait y avoir une meilleure solution, mais au moins, cette solution était raisonnable pour mon cas (correction de l'erreur: file_put_contents(/var/www/html/laravel/app/storage/meta/services.json): failed to open stream).
Il suffit de démarrer votre serveur en utilisant artisian
php artisian serve
Accédez ensuite à votre projet à partir de l'URL spécifiée:
Après beaucoup d'essais et d'erreurs avec les permissions de répertoire, je me suis retrouvé avec une épiphanie ... il ne restait plus d'espace sur la partition du disque. Je voulais juste partager pour nous assurer que personne d’autre n’est assez stupide pour continuer à chercher la solution dans le mauvais sens.
Sous Linux, vous pouvez utiliser df -h pour vérifier la taille de votre disque et votre espace libre.
Fixer l’autorisation à 777 est une très mauvaise idée!
... mais
Si vous obtenez une erreur d'autorisation liée au dossier "stockage" c'est ce qui a fonctionné pour moi:
1) Définissez "stockage" et ses sous-dossiers avec la permission de 777 avec
Sudo chmod -R 777 storage/2) Dans le navigateur, allez à la page d'accueil de laravel laravel/public/(laravel créera les fichiers de stockage initiaux nécessaires)
3) Renvoyer l'autorisation 775 sécurisée au stockage et à ses sous-dossiers
Sudo chmod -R 775 storage/
Ce problème est en fait causé par différents utilisateurs qui veulent write/read fichier mais qui ont été refusés parce qu'ils sont propriétaires différents. Peut-être que vous en tant que "root" avez installé Laravel avant de vous connecter à votre site en tant qu'utilisateur "laravel", où "laravel" est le propriétaire par défaut. Ainsi, lorsque l'utilisateur 'laravel' souhaite lire/écrire tous les fichiers du disque par défaut, ce fichier est la propriété de 'root'.
Pour résoudre ce problème, vous pouvez suivre comme suit:
Sudo chown -hR your-user-name /root /nameforlder
ou dans mon cas
Sudo chown -hR igmcoid /root /sublaravel
Note de bas de page:
rootcomme nom premier propriétaire qui a installé avantyour-user-nameen tant que propriétaire par défaut qui écrit/lit dans le site.namefoldercomme nom de dossier pour lequel vous souhaitez modifier la propriété.
J'ai le même problème lorsque je cours vagabond sur mac. a résolu le problème en modifiant l'utilisateur du serveur Apache dans le fichier https.conf:
# check user for php
[vagrant] ubuntu ~ $ php -i | grep USER
USER => ubuntu
$_SERVER['USER'] => ubuntu
[vagrant] ubuntu ~ $
Exécutez Apache sous l'utilisateur php au lieu du démon utilisateur pour résoudre le problème d'accès aux fichiers avec php
# change default Apache user from daemon to php user
Sudo sed -i 's/User daemon/User ubuntu/g' /opt/lampp/etc/httpd.conf
Sudo sed -i 's/Group daemon/Group ubuntu/g' /opt/lampp/etc/httpd.conf
maintenant, le fichier de cache créé par PHP peut être lu et édité par Apache sans afficher d'erreur d'erreur d'autorisation d'accès.