158 29/03/2026 07/04/2026 5 min

Diagnosi probabile

Quando un file o una directory su Linux “non si apre”, “non si salva” o fa fallire un servizio, la causa più comune è un problema di permessi, ownership o umask. In pratica, l’utente o il processo che deve leggere, scrivere o eseguire quel percorso non ha i diritti necessari, oppure li ha in modo troppo permissivo e questo crea errori o rischi di sicurezza.

Il caso tipico riguarda siti web, backup, script PHP, cron, upload, log e directory condivise. Sintomi frequenti: Permission denied, pagine bianche, upload falliti, errori 403, servizio che non parte dopo una modifica, file creati con proprietario sbagliato, o directory che non si riescono a attraversare perché manca il bit di esecuzione su una cartella.

Un’altra causa frequente è la corruzione “logica” dei permessi dopo migrazioni, restore da backup, deploy con utente diverso, estrazioni di archivi ZIP/TAR o sincronizzazioni via FTP/SFTP. In questi casi il contenuto è presente, ma il sistema non lo considera utilizzabile dal processo corretto.

Verifiche immediate

  1. Identifica il file o la directory coinvolta e controlla i permessi attuali con ls -ld e ls -l. Esempio: ls -ld /percorso/cartella e ls -l /percorso/file. Esito atteso: vedi proprietario, gruppo e maschera dei permessi in formato leggibile.
  2. Verifica con quale utente gira il servizio o lo script. Per un web server può essere www-data, apache, nginx, oppure un utente del pannello hosting. Con ps aux | grep nome-servizio o dal pannello di controllo puoi capire quale account deve avere accesso. Esito atteso: l’utente del processo è noto e coerente con la directory da usare.
  3. Controlla se il problema è lettura, scrittura o esecuzione. Su una directory, il bit di esecuzione è necessario per entrarci; su un file eseguibile, serve anche il bit di esecuzione. Un controllo rapido è namei -l /percorso/completo, che mostra i permessi lungo tutto il percorso. Esito atteso: nessun anello della catena blocca l’accesso.
  4. Se il file è usato da un sito o da un servizio, controlla anche i log per un errore preciso. Per esempio: journalctl -u nome-servizio -n 50 --no-pager oppure i log di Apache/Nginx/PHP. Esito atteso: trovi una riga con Permission denied, open() failed, cannot write o simile.

Soluzione consigliata passo-passo

  1. Fai un backup della situazione attuale prima di modificare. Se devi correggere ownership o permessi su più file, annota prima lo stato con: 
    ls -ld /percorso/cartella
ls -l /percorso/cartella | head
    Questo ti permette di tornare indietro se la correzione non è quella giusta.
  2. Correggi il proprietario e il gruppo solo se sono sbagliati. Ad esempio, per una directory web che deve appartenere a un utente specifico: 
    chown -R utente:gruppo /percorso/cartella
    Usa questa operazione con cautela, perché applicata alla radice sbagliata può cambiare troppi file. Dopo il cambio, verifica con ls -ld /percorso/cartella che il proprietario sia corretto.
  3. Imposta permessi coerenti e non troppo larghi. In molti casi una directory web funziona bene con 755 e i file con 644. Esempio: 
    find /percorso/cartella -type d -exec chmod 755 {} \
;
find /percorso/cartella -type f -exec chmod 644 {} \
;
    Esito atteso: le directory risultano attraversabili e i file leggibili dal servizio corretto. Se hai file eseguibili, non applicare 644 a tutto indiscriminatamente.
  4. Se il servizio deve scrivere in una directory, crea una struttura separata e assegna permessi minimi solo dove serve. Per esempio, directory di upload o cache possono richiedere scrittura al processo web. In quel caso controlla la cartella specifica e non tutto il sito. È più sicuro limitare l’area scrivibile invece di rendere tutto modificabile.
  5. Se il problema è di gruppo, puoi usare il gruppo corretto e, dove serve, il setgid sulla cartella per ereditare il gruppo: 
    chgrp -R gruppo /percorso/cartella
chmod 2775 /percorso/cartella
    Questo è utile in ambienti condivisi o con deploy multipli. Dopo la modifica, crea un file di test e verifica che erediti il gruppo atteso.
  6. Verifica l’effetto della umask se il problema si ripresenta dopo ogni nuovo file creato. Un processo con umask troppo restrittiva o troppo aperta può generare file non coerenti. Se gestisci uno script o un servizio, controlla come viene avviato e con quali valori eredita i permessi. In ambienti hosting, spesso il problema non è il file vecchio, ma quelli nuovi creati da cron, PHP-FPM o deploy automation.
  7. Ritest finale: prova l’azione che falliva prima, ad esempio aprire la pagina, salvare un file, eseguire uno script o riavviare il servizio. Se il problema era su un sito, verifica anche il log subito dopo l’operazione per confermare che l’errore sia sparito.

Controlli finali / rollback

  1. Controllo finale minimo: ripeti ls -ld e ls -l sul percorso interessato e conferma che proprietario, gruppo e permessi siano coerenti con l’uso reale. Esito atteso: nessun permesso eccessivo, nessun blocco di accesso.
  2. Se hai modificato più file di quanti previsto o il servizio continua a fallire, ripristina lo stato annotato prima del fix oppure limita la correzione alla sola directory che genera l’errore. Il rollback più sicuro è tornare ai permessi precedenti sui soli percorsi toccati.
  3. Se dopo il fix il problema persiste, non allargare i permessi in modo casuale: controlla anche ACL, SELinux/AppArmor, mount options e il contesto del servizio. In molti casi il sintomo sembra un problema di chmod, ma la causa reale è un blocco aggiuntivo a livello di sicurezza o filesystem.
Regola pratica: correggi il minimo indispensabile, verifica subito, poi estendi solo se il test conferma che il problema era davvero quel percorso.

Nel dubbio, parti sempre da una diagnosi puntuale: chi deve accedere, a cosa, con quale operazione e su quale percorso. Questo evita fix troppo aggressivi che risolvono un sintomo ma introducono un rischio di sicurezza o un nuovo malfunzionamento.

Checklist rapida

  • Controlla proprietario, gruppo e permessi con ls -ld.
  • Individua l’utente del servizio che deve accedere al percorso.
  • Correggi prima ownership, poi permessi, solo sul path necessario.
  • Testa di nuovo l’azione che falliva e leggi i log.
  • Se non basta, verifica ACL, SELinux/AppArmor e mount options.

Assunzione: il problema riguarda un ambiente Linux standard, con accesso shell o pannello di controllo e senza vincoli particolari di policy aziendali.