Los permisos de un archivo son solo la última comprobación. Varias otras cosas pueden negar la escritura mientras el archivo en sí parece perfectamente correcto, y eso es lo que hace este caso tan desconcertante.

1. Un directorio superior

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

Cada directorio de la ruta necesita permiso de ejecución para que usted alcance el archivo. namei imprime la cadena entera con sus permisos, y la fila culpable suele saltar a la vista.

2. Es el proceso, no usted

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

Su shell es usted; el servidor web es www-data. Probar con el usuario correcto es la diferencia entre un arreglo de cinco minutos y una tarde entera.

3. SELinux, en RHEL, Alma y 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
Las denegaciones de SELinux no aparecen en absoluto en el registro de la aplicación. Si los permisos están bien y la escritura falla igual en una de esas distribuciones, casi siempre es por esto.

4. Inmutable, o montado en solo lectura

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 sistema de archivos remontado en solo lectura es el núcleo protegiendo un disco que se muere. Mire dmesg -T | tail antes que nada: eso es un problema de hardware, no de permisos.

Luego póngalo bien

No 777. La propiedad y el bit de grupo son las herramientas correctas: vea la propiedad, umask y la trampa del grupo.