file_put_contents (meta/services.json): Stream konnte nicht geöffnet werden: Berechtigung abgelehnt

Vorschlag von vsmoraes arbeitete für mich:

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

HINWEIS: NICHT AUF FERNER SERVER (DEV OR PRODUKTION)

Als ich diese Frage stellte, war dies ein Problem auf meinem localhost, der in einer virtuellen Maschine ausgeführt wurde. Ich dachte, es wäre sicher genug, eine 777 einzurichten, aber die Leute haben recht, wenn sie sagen, dass Sie nach einer anderen Lösung suchen sollten. Versuchen Sie es zuerst mit 775

Für Googler, die mit Laravel 5 dieses Problem hatten. 

Dies ist ein Berechtigungsproblem, das durch verschiedene Benutzer verursacht wird, die versuchen, in derselben Protokolldatei im Ordner storage/logs mit unterschiedlichen Berechtigungen zu schreiben.

Was passiert ist, ist Ihre Konfiguration wahrscheinlich so eingerichtet, dass Fehler täglich protokolliert werden. Daher kann Ihr Webserver (Apache/nginx) diese Datei unter einem Standardbenutzer erstellen. Abhängig von Ihrer Umgebung kann dies _www unter OSX oder www-data auf * NIX-Systemen sein Das Problem tritt auf, wenn Sie möglicherweise einige handwerkliche Befehle ausgeführt haben und einige Fehler aufgetreten sind. Der Handwerker schreibt diese Datei jedoch mit einem anderen Benutzer, da PHP auf dem Terminal von einem anderen Benutzer ausgeführt wird Führen Sie diesen Befehl aus, indem Sie diesen Befehl ausführen: 

php -i | grep USER

Wenn Ihr Anmeldebenutzer diese Protokolldatei auf Ihrem Webserver erstellt hat, können Sie keine Fehler in die Protokolldatei schreiben und umgekehrt, da laravel Protokolldateien standardmäßig mit 655-Berechtigungen schreibt, wodurch der Eigentümer nur darin schreiben kann.

Um dieses temporäre Problem zu beheben, müssen Sie der Gruppe 664 manuell Berechtigungen für diese Datei erteilen, damit sowohl Ihr Anmeldebenutzer als auch Ihr Webserver-Benutzer in diese Protokolldatei schreiben können.

Um dieses Problem dauerhaft zu vermeiden, sollten Sie beim Erstellen einer neuen Datei im Verzeichnis storage/logs die richtigen Berechtigungen einrichten, indem Sie die Berechtigungen aus dem Verzeichnis dieser Antwort erben https://unix.stackexchange.com/a/115632 can helfen Sie, damit fertig zu werden.

Für alle, die Laravel 5, Homestead und Mac verwenden, versuchen Sie Folgendes:

mkdir storage/framework/views

Sie sollten 777 Berechtigungen nicht erteilen. Für Ubuntu-Benutzer möchte ich in Laravel 5 den Besitzer für die Verzeichnisspeicherung rekursiv wechseln:

Probieren Sie folgendes aus:

Sudo chown -R www-data:www-data storage

In Ubuntu-basierten Systemen sind www-data Apache-Benutzer.

manchmal hat SELINUX dieses Problem verursacht; Sie können Selinux mit diesem Befehl deaktivieren.

Sudo setenforce 0

Problem gelöst 

php artisan cache:clear
Sudo chmod -R 777 vendor storage

dies ermöglicht die Schreibberechtigung für App, Framework und Protokolle

Für Vagabundnutzer ist die Lösung:

(in vagrant) PHP-Handwerker-Cache: klar 

(außerhalb von vagrant) chmod -R 777 app/storage 

(in vagrant) komponist dump-autoload

Hier ist es wichtig, dass Sie in Ihrem lokalen Umfeld chmodeln und nicht in Vagrant!

NIEMALS ES ERLAUBEN 777!

gehen Sie in das Verzeichnis des Laravel-Projekts auf Ihrem Terminal und schreiben Sie:

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

Auf diese Weise machen Sie Ihren Benutzer zum Eigentümer und geben Privilegien:
1 Ausführen, 2 Schreiben, 4 Lesen
1 + 2 + 4 = 7 bedeutet (rwx)
2 + 4 = 6 bedeutet (rw)
Für den Speicherzugriff bedeutet ug + rwx, dass Sie dem Benutzer und der Gruppe eine 7 geben

Versuchen Sie es erneut mit chmod -R 755 /var/www/html/test/app/storage. Verwendung mit Sudo für Operation not permitted in chmod. Verwenden Sie Eigentümerberechtigung prüfen, wenn der Fehler immer noch vorliegt.

Laut Laravel 5.4, dem neuesten Stand, während ich dies schreibe, müssen Sie die Berechtigung ändern, wenn Sie ein solches Problem haben. HÖREN SIE KEINEM MITGLIED, WENN SIE 777 FÜR JEDES VERZEICHNIS SETZEN. Es gibt ein Sicherheitsproblem. Ändern Sie die Berechtigung des Speicherordners auf diese Weise

Sudo chmod -R 775 storage

Ändern Sie die Berechtigung für den Bootstrap-Ordner wie folgt

Sudo chmod -R 775 bootstrap/cache

Stellen Sie jetzt sicher, dass Sie beide Befehle aus Ihrem Anwendungsverzeichnis ausführen. Sie werden in Zukunft keine Probleme bezüglich der Erlaubnis haben. 775 gefährdet nicht die Sicherheit Ihres Computers. 

Schlagen Sie die richtige Erlaubnis für Apache vor.

Sudo chown -R Apache:apache apppath/app/storage

Wenn Sie Laravel 5 haben und eine dauerhafte Lösung suchen, verwenden Sie sowohl die php artisan-Befehlszeilenverwendung als auch den Apache-Server:

Sudo chmod -R 777 vendor storage
echo "umask 000" | Sudo tee -a /etc/resolv.conf
Sudo service Apache2 restart

Siehe ausführliche Erklärung hier .

FÜR JEDER, DER EINES OS MIT SELINUX LÄUFT: Die Schreibweise von httpd in den laravel-Speicherordner ist korrekt:

Sudo semanage fcontext -a -t httpd_sys_rw_content_t '/path/to/www/storage(/.*)?'

Dann die Änderungen sofort übernehmen:

Sudo restorecon -F -r '/path/to/www/storage'

SELinux kann ein Schmerz sein, mit dem man fertig werden muss, aber wenn es vorhanden ist, dann würde ich STRONGLY BERATEN, dass Sie es lernen, anstatt es vollständig zu umgehen. 

Ich hatte das gleiche Problem und die folgenden Schritte halfen mir, das Problem zu beheben.

1. Finden Sie heraus, welcher Apache-Benutzer eine test.php-Datei mit dem Code im öffentlichen Ordner erstellt hat

<?php echo exec('whoami'); ?>

Führen Sie die Datei über den Webbrowser aus. Es würde den Apache-Benutzer geben. In meinem Fall ist es ec2-user, da ich die aws mit cronjob in /etc/cron.d/ installiert habe. Es könnte ein anderer Benutzer für andere sein.

2. Führen Sie den folgenden Befehl in der Befehlszeile aus.

Sudo chown -R ec2-user:<usergroup> /app-path/public

Sie müssen hier den richtigen "Benutzer" und die richtige "Benutzergruppe" identifizieren und verwenden.

Xampp zur Verwendung:

cd /Applications/XAMPP/htdocs  
chmod -R 775 test/app/storage

rm storage/logs/laravel.log  

gelöst für mich 

Wenn Sie Laradock verwenden, versuchen Sie chown -R laradock:www-data ./storage in Ihrem Arbeitsbereichscontainer

Jedes Mal, wenn ich app.php ändere, bekomme ich eine Erlaubnis, die das Schreiben von bootstrap/cache/services.json verweigert.

chmod -R 777 bootstrap/cache/

In meinem Fall bestand die Lösung darin, die Berechtigung für app/storage/framework/views und app/storage/logs-Verzeichnisse zu ändern.

Ich habe die gleichen Fehler in meinem Projekt ...
Aber ich fand heraus, dass ich vergessen habe, enctype in meine Form zu setzen.

<form method="#" action="#" enctype="multipart/form-data">

Hoffentlich hilft es irgendwo irgendwie ...

Wenn jemand anderes auf ein ähnliches Problem mit fopen Dateiberechtigungsfehlern stößt, ist es jedoch klug genug, nicht blind chmod 777 hier ist mein Vorschlag.

Überprüfen Sie den von Ihnen verwendeten Befehl auf Berechtigungen, die Apache benötigt:

fopen('filepath/filename.pdf', 'r');

Das 'r' bedeutet, dass nur Lesezugriff möglich ist. Wenn Sie die Datei nicht bearbeiten, sollten Sie sie als gesetzt festlegen. Das bedeutet, dass Apache/www-data mindestens Leseberechtigung für diese Datei benötigt. Wenn die Datei über Laravel erstellt wird, verfügt sie bereits über Leseberechtigung.

Wenn Sie aus irgendeinem Grund in die Datei schreiben müssen:

fopen('filepath/filename.pdf', 'r+');

Stellen Sie dann sicher, dass Apache auch über Berechtigungen zum Schreiben in die Datei verfügt.

http://php.net/manual/de/function.fopen.php

Ich hatte ein ähnliches Problem. (Berechtigung verweigert, während die Berechtigungen korrekt konfiguriert wurden) mit Laravel 5.2 und 5.5

Das Problem war, dass SELinux aktiviert war, wodurch Apache auch im 777-Modus keine Dateien schreiben konnte. Siehe Lösen Sie 500 Antwort Laravel (Nicht erfasste UnexpectedValueException: Laravel.log) für die Frage und Antwort.

Vielleicht löst das auch das Problem für Sie. 

Bei der Arbeit unter Windows 10 mit Laragon und Laravel 4 schien es mir keine Möglichkeit zu geben, die Berechtigungen manuell zu ändern, da die Ausführung von chmod- Befehlen im Laragon-in-built-terminal keine Auswirkungen hatte.

In diesem Terminal war es jedoch möglich, in den Speicherordner zu wechseln und die gewünschten Ordner wie folgt manuell hinzuzufügen:

cd app/storage
mkdir cache
mkdir meta
mkdir views
mkdir sessions

Der Befehl cd- im Terminal bringt Sie in den Ordner (möglicherweise müssen Sie diesen Pfad an Ihre Dateistruktur anpassen). Der Befehl mkdir- erstellt das Verzeichnis mit dem angegebenen Namen.

Ich hatte keine Gelegenheit, diesen Ansatz in Laravel 5 zu testen, aber ich erwarte, dass ein ähnlicher Ansatz funktionieren sollte.

Natürlich könnte es einen besseren Weg geben, aber zumindest war dies eine vernünftige Lösung für meine Situation (Behebung des Fehlers: file_put_contents(/var/www/html/laravel/app/storage/meta/services.json): failed to open stream).

Starten Sie einfach Ihren Server mit artisian

php artisian serve

Greifen Sie dann über die angegebene URL auf Ihr Projekt zu:

Nach vielem Ausprobieren mit Verzeichnisberechtigungen bekam ich eine Epiphanie ... auf der Partition der Festplatte war kein Platz mehr. Ich wollte nur teilen, um sicher zu gehen, dass niemand sonst dumm genug ist, die Lösung in die falsche Richtung zu suchen.

In Linux können Sie df -h verwenden, um die Festplattengröße und den freien Speicherplatz zu überprüfen.

Die Erlaubnis auf 777 zu setzen ist definitiv eine schreckliche Idee!

... aber

Wenn Sie einen Erlaubnisfehler in Verbindung mit dem "Speicher" -Ordner erhalten, funktionierte das für mich:

1) Setzen Sie die Berechtigung "Speicher" und die zugehörigen Unterordner auf 777 mit 

Sudo chmod -R 777 storage/

2) Im Browser auf die Laravel-Homepage gehen Laravel/public/(Laravel erstellt die erforderlichen Anfangsspeicherdateien)

3) Geben Sie die sichere 775-Berechtigung an den Speicher und dessen Unterordner zurück

Sudo chmod -R 775 storage/

Dieses Problem wurde tatsächlich von verschiedenen Benutzern verursacht, die write/read-Datei ablehnen, aber den Zugriff verweigern, da dies zu unterschiedlichen Inhabern führt. Vielleicht haben Sie als "root" Laravel installiert, bevor Sie sich dann als "Laravel" -Anwender in Ihre Site einloggen, wo "Laravel" der Standardbesitzer ist. Wenn der Benutzer 'laravel' standardmäßig alle Dateien auf der Festplatte lesen/schreiben möchte, um abgelehnt zu werden, kann dies dazu führen, dass diese Datei Eigentümer von 'root' ist.

Um dieses Problem zu lösen, können Sie folgendermaßen vorgehen:

Sudo chown -hR your-user-name /root /nameforlder

oder in meinem Fall

Sudo chown -hR igmcoid /root /sublaravel

Fußnote:

1. root als Name, der zuerst installiert wurde
2. your-user-name als Standardbesitzer, der tatsächlich auf der Site schreibt/liest.
3. namefolder als Namensordner, in dem Sie den Eigentümer ändern möchten.

Ich habe das gleiche Problem, wenn ich Vagrant auf einem Mac ausführt. Das Problem wurde gelöst, indem der Benutzer des Apache-Servers in der Datei https.conf geändert wurde:

# check user for php
[vagrant] ubuntu ~ $ php -i | grep USER
USER => ubuntu
$_SERVER['USER'] => ubuntu
[vagrant] ubuntu ~ $ 

Führen Sie Apache unter PHP-Benutzer anstelle des Benutzer-Daemons aus, um das Dateizugriffsproblem mit PHP zu beheben

# 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

jetzt kann die von PHP erstellte Cache-Datei von Apache gelesen und bearbeitet werden, ohne dass ein Zugriffsberechtigungsfehler angezeigt wird.