Laravel benötigt Schreibrechte des Webserver-Prozesses für Logs, Sitzungen, kompilierte Views und Cache-Dateien in storage und bootstrap/cache. Die Lösung ist nicht chmod 777, sondern korrekte Eigenalleer- und Gruppenrechte.
UnexpectedValueException
The stream or file storage/logs/laravel.log could not be opened
Permission denied
Die Laravel-Deployment-Dokumentation verlangt Schreibrechte des Webserver-Prozesses für storage und bootstrap/cache. Der Benutzer unterscheidet sich je nach cPanel, Plesk, Nginx, Apache und PHP-FPM; daher gibt es keinen universellen chown-Befehl.
Benutzer- und Gruppennamen an Ihren Server anpassen.
chmod -R 777 storage bootstrap/cachechown -R deploy:www-data storage bootstrap/cache
chmod -R ug+rwX storage bootstrap/cacheDer Webprozess kann möglicherweise nicht in root-Dateien schreiben.
root:root storage/logsdeploy:www-data storage/logsUnter AlmaLinux/Rocky muss auch der Sicherheitskontext geprüft werden.
chmod korrekt ama Permission deniedrestorecon -Rv storage bootstrap/cacheBestätigt den tatsächlichen Prozess statt chown-Ziele zu raten.
ps -eo user,group,comm,args | grep -E 'php-fpm|apache2|httpd|lsphp' | grep -v grep
grep -R '^user\|^group' /etc/php/*/fpm/pool.d /etc/php-fpm.d 2>/dev/null
Zeigt auch fehlende Ausführungsrechte in übergeordneten Verzeichnissen.
namei -l storage/logs/laravel.log 2>/dev/null || true
find storage bootstrap/cache -maxdepth 2 -printf "%M %u:%g %p\n" | head -n 100
deploy und www-data durch echte Benutzer/Gruppe ersetzen.
chown -R deploy:www-data storage bootstrap/cache
find storage bootstrap/cache -type d -exec chmod 2775 {} \;
find storage bootstrap/cache -type f -exec chmod 664 {} \;
Wenn CLI- und Webbenutzer abweichen, zusätzlich per HTTP prüfen.
php artisan optimize:clear
php artisan view:cache
php artisan tinker --execute="logger()->info('izin testi');"
Projektktkt und Datenbank sichern und aktuelle Rechte dokumentieren.
Tatsächlichen Benutzer und Gruppe von PHP-FPM, Apache oder LSAPI bestimmen.
Eigenalleer von storage und bootstrap/cache an Deployment-Modell anpassen.
Verzeichnissen Gruppen-Schreib- und Ausführungsrechte, Dateien Gruppen-Schreibrechte geben.
Gegebenenfalls SELinux-Kontexte oder ACL-Regeln prüfen.
Laravel-Log-, Session-, View- und Cache-Schreibvorgänge testen.
Laufzeitbenutzer kann nicht schreiben oder übergeordnetes Verzeichnis nicht betreten.
storage/logs oder vorhandene Logdatei gehört anderem Benutzer.
Unterverzeichnisse in storage/framework fehlen oder sind nicht beschreibbar.
Dateisystem besitzt Immutable-Flags, ACL-, Mount- oder SELinux-Beschränkungen.
Kein passender Fehler gefunden.
Weltweite Schreibrechte erlauben fremden Prozessen Änderungen an Anwendungsdaten. Korrekte Eigenalleer- und Gruppenrechte sind sicherer.
Meist gelten der cPanel-Kontobenutzer und das PHP-Handler-Modell. Vor www-data-Befehlen laufende Prozesse prüfen.
Erzeugt das Deployment Dateien als root oder anderer Benutzer, ändert sich der Eigenalleer erneut. Deployment als Anwendungsbenutzer ausführen und Rechte normalisieren.
Wir setzen dauerhafte Lösungen um, indem wir Laravel, PHP-FPM, Nginx, Apache, MySQL, cPanel und Plesk gemeinsam mit den Logs prüfen.