I permessi di un file sono soltanto l'ultimo controllo. Diverse altre cose possono negare la scrittura mentre il file in sé sembra perfettamente a posto, ed è questo a rendere il caso tanto sconcertante.

1. Una directory superiore

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

Ogni directory del percorso ha bisogno del permesso di esecuzione perché lei arrivi al file. namei stampa tutta la catena con i suoi permessi, e la riga colpevole di solito salta all'occhio.

2. È il processo, non lei

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

La sua shell è lei; il server web è www-data. Provare con l'utente giusto è la differenza fra una soluzione da cinque minuti e un pomeriggio intero.

3. SELinux, su RHEL, Alma e 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
I dinieghi di SELinux non compaiono affatto nel log dell'applicazione. Se i permessi sono giusti e la scrittura fallisce comunque su una di quelle distribuzioni, il motivo è quasi sempre questo.

4. Immutabile, o montato in sola lettura

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 filesystem rimontato in sola lettura è il kernel che protegge un disco che sta cedendo. Guardi dmesg -T | tail prima di ogni altra cosa: quello è un problema di hardware, non di permessi.

Poi lo imposti come si deve

Non 777. Gli strumenti giusti sono la proprietà e il bit di gruppo - veda proprietà, umask e la trappola del gruppo.