Les permissions d'un fichier ne sont que la dernière vérification. Plusieurs autres choses peuvent refuser l'écriture alors que le fichier lui-même a l'air parfaitement correct, et c'est ce qui rend l'affaire si déroutante.

1. Un répertoire parent

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

Chaque répertoire du chemin a besoin du droit d'exécution pour que vous atteigniez le fichier. namei imprime toute la chaîne avec ses permissions, et la ligne fautive saute d'ordinaire aux yeux.

2. C'est le processus, pas vous

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

Votre shell, c'est vous ; le serveur web, c'est www-data. Tester sous le bon utilisateur, c'est la différence entre cinq minutes et un après-midi.

3. SELinux, sur RHEL, Alma et 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
Les refus de SELinux n'apparaissent pas du tout dans le journal de l'application. Si les permissions sont bonnes et que l'écriture échoue quand même sur l'une de ces distributions, c'est presque toujours la raison.

4. Immuable, ou monté en lecture seule

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
Un système de fichiers remonté en lecture seule, c'est le noyau qui protège un disque en train de lâcher. Regardez dmesg -T | tail avant toute chose : c'est un problème de matériel, pas de permissions.

Puis le régler correctement

Pas 777. La propriété et le bit de groupe sont les bons outils - voyez la propriété, umask et le piège du groupe.