Ich bin neu in Laravel. Ich habe versucht, http://localhost/test/public/
zu öffnen, und bekam es
Fehler im Ausnahmehandler.
Ich googelte herum und änderte die Erlaubnis des Speicherverzeichnisses mit chmod -R 777 app/storage
, aber ohne Erfolg.
Ich änderte debug=>true
in app.php
und besuchte die Seite und erhielt Fehler im Ausnahmehandler:
Der Stream oder die Datei "/var/www/html/test/app/storage/logs/laravel.log" konnte nicht geöffnet werden: Fehler beim Öffnen des Streams: Berechtigung verweigert in /var/www/html/test/bootstrap/compiled.php:8423
Dann habe ich die Berechtigungen des Speicherverzeichnisses mit dem Befehl chmod -R 644 app/storage
geändert und der Fehler 'Fehler im Ausnahmehandler' war verschwunden und eine Seite wurde geladen. Aber dort bekomme ich das:
file_put_contents (/var/www/html/laravel/app/storage/meta/services.json): Stream konnte nicht geöffnet werden: Berechtigung verweigert
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!
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.
<?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.
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.
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
).
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:
root
als Name, der zuerst installiert wurdeyour-user-name
als Standardbesitzer, der tatsächlich auf der Site schreibt/liest.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.