Arama Yap Mesaj Senden
Rückruf anfordern
+90
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro

Kontaktieren Sie uns

Standort Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Linux-Berechtigungen und Laravel

Beheben Sie Laravel-500-Fehler durch storage- und bootstrap/cache-Rechte sicher

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.

root@eka:~/application
UnexpectedValueException
The stream or file storage/logs/laravel.log could not be opened
Permission denied
2Zentrale beschreibbare Verzeichnisse
USERTatsächlichen PHP-FPM-Benutzer bestimmen
GROUPDeploy- und Webbenutzer können Gruppe teilen
NO 777Weltweite Schreibrechte sind keine Lösung
01
Technische Diagnose

Vor chmod zuerst den laufenden Benutzer ermitteln

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.

01

Unsichere breite Rechte

Benutzer- und Gruppennamen an Ihren Server anpassen.

Falsch
chmod -R 777 storage bootstrap/cache
Richtig
chown -R deploy:www-data storage bootstrap/cache
chmod -R ug+rwX storage bootstrap/cache
02

Falscher Eigenalleer

Der Webprozess kann möglicherweise nicht in root-Dateien schreiben.

Falsch
root:root storage/logs
Richtig
deploy:www-data storage/logs
03

SELinux-Einschränkung

Unter AlmaLinux/Rocky muss auch der Sicherheitskontext geprüft werden.

Falsch
chmod korrekt ama Permission denied
Richtig
restorecon -Rv storage bootstrap/cache
02
SSH und Terminal

Messen und Logs prüfen, bevor Sie raten

01

PHP-FPM- und Webserver-Benutzer ermitteln

Bestä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
02

Eigenalleer und Rechte prüfen

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
03

Gruppenbasierte sichere Rechte setzen

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 {} \;
04

Laravel-Schreibtest ausführen

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');"
03
Prüfunglierte Umsetzung

Sichere schrittweise Lösungsreihenfolge

01

Schritt 1

Projektktkt und Datenbank sichern und aktuelle Rechte dokumentieren.

02

Schritt 2

Tatsächlichen Benutzer und Gruppe von PHP-FPM, Apache oder LSAPI bestimmen.

03

Schritt 3

Eigenalleer von storage und bootstrap/cache an Deployment-Modell anpassen.

04

Schritt 4

Verzeichnissen Gruppen-Schreib- und Ausführungsrechte, Dateien Gruppen-Schreibrechte geben.

05

Schritt 5

Gegebenenfalls SELinux-Kontexte oder ACL-Regeln prüfen.

06

Schritt 6

Laravel-Log-, Session-, View- und Cache-Schreibvorgänge testen.

04
Fehlerverzeichnis

Ähnliche Fehler der richtigen Ursache zuordnen

4 Einträge
Fehler

Permission denied

Laufzeitbenutzer kann nicht schreiben oder übergeordnetes Verzeichnis nicht betreten.

Fehler

laravel.log could not be opened

storage/logs oder vorhandene Logdatei gehört anderem Benutzer.

Fehler

Please provide a valid cache path

Unterverzeichnisse in storage/framework fehlen oder sind nicht beschreibbar.

Fehler

Operation not permitted

Dateisystem besitzt Immutable-Flags, ACL-, Mount- oder SELinux-Beschränkungen.

Kein passender Fehler gefunden.

Zu vermeiden

Maßnahmen, die das Problem verschlimmern

  • Nicht das gesamte Projektktkt auf 777 setzen.
  • .env und Config-Dateien nicht unnötig für Webbenutzer beschreibbar machen.
  • Bei cPanel/Plesk nicht blind www-data annehmen.
  • Artisan nicht als root ausführen und root-Dateien erzeugen.
Erfolgskontrolle

Woran erkennen Sie die vollständige Behebung?

  • storage/logs/laravel.log lässt sich aktualisieren.
  • Session- und Cache-Treiber schreiben fehlerfrei.
  • view:cache und Optimierungsbefehle funktionieren.
  • Web- und CLI-Benutzer nutzen keine zu breiten Rechte.
05
FAQ

Häufige technische Fragen

Warum wird chmod 777 nicht empfohlen?

Weltweite Schreibrechte erlauben fremden Prozessen Änderungen an Anwendungsdaten. Korrekte Eigenalleer- und Gruppenrechte sind sicherer.

Welcher Benutzer gilt bei cPanel?

Meist gelten der cPanel-Kontobenutzer und das PHP-Handler-Modell. Vor www-data-Befehlen laufende Prozesse prüfen.

Warum gehen Rechte nach Deployment erneut kaputt?

Erzeugt das Deployment Dateien als root oder anderer Benutzer, ändert sich der Eigenalleer erneut. Deployment als Anwendungsbenutzer ausführen und Rechte normalisieren.

06
Themencluster

Verwandte Laravel- und Server-Fehlerleitfäden

Offizielle technische Quellen

Lösungsschritte wurden anhand primärer Dokumentation geprüft

Laravel Deployment PermissionsLaravel Directory StructurePHP Error ConfigurationLaravel Configuration
EKA SOFTWARE- UND INFORMATIONSSYSTEME

Laravel-Rechte mit korrekten Eigenalleern und Gruppen statt chmod 777 lösen

Wir setzen dauerhafte Lösungen um, indem wir Laravel, PHP-FPM, Nginx, Apache, MySQL, cPanel und Plesk gemeinsam mit den Logs prüfen.

Technischen Support erhaltenÜber WhatsApp schreiben
Top