Die Rechte einer Datei sind nur die letzte Prüfung. Mehrere andere Dinge können das Schreiben verweigern, während die Datei selbst völlig richtig aussieht - und genau das macht diesen Fall so verwirrend.

1. Ein übergeordnetes Verzeichnis

namei -l /var/www/site/storage/logs/app.log

Jedes Verzeichnis im Pfad braucht Ausführungsrecht, damit Sie zur Datei kommen. namei druckt die ganze Kette mit ihren Rechten, und die schuldige Zeile springt meist ins Auge.

2. Es ist der Prozess, nicht Sie

ps aux | grep php-fpm | head -3            # which user is it running as
sudo -u www-data test -w /var/www/site/storage && echo writable || echo NOT

Ihre Shell sind Sie; der Webserver ist www-data. Als der richtige Benutzer zu testen ist der Unterschied zwischen fünf Minuten und einem Nachmittag.

3. SELinux, auf RHEL, Alma und Rocky

ls -Z /var/www/site/storage
sudo ausearch -m avc -ts recent | tail
sudo chcon -R -t httpd_sys_rw_content_t /var/www/site/storage
sudo setsebool -P httpd_can_network_connect on
SELinux-Verweigerungen tauchen im Anwendungslog überhaupt nicht auf. Stimmen die Rechte und scheitert das Schreiben auf einer dieser Distributionen trotzdem, liegt es fast immer daran.

4. Unveränderlich, oder nur lesend eingehängt

lsattr /var/www/site/config.php     # ----i--------- means immutable
sudo chattr -i /var/www/site/config.php
mount | grep " / "                  # ro means read-only, often after a disk error
Ein Dateisystem, das nur lesend neu eingehängt wurde, ist der Kernel, der eine sterbende Platte schützt. Schauen Sie zuerst in dmesg -T | tail - das ist ein Hardwareproblem, kein Rechteproblem.

Dann richtig setzen

Nicht 777. Eigentum und das Gruppenbit sind die richtigen Werkzeuge - siehe Eigentümer, umask und die Gruppenfalle.