Il sintomo arriva quasi sempre allo stesso modo. Il sito apre una pagina bianca, oppure il backend restituisce 503. Nel log di Plesk compare una riga secca: "Permission denied".
Il primo istinto è guardare il codice PHP. Spesso è un falso bersaglio. In questi casi il problema nasce tra pannello, PHP-FPM e permessi dell’utente del sito.
Questo articolo parte da un caso reale. Il dominio gira su Plesk, usa PHP-FPM, e dopo un cambio di tema o una migrazione alcuni file diventano leggibili solo dal proprietario sbagliato. Il risultato è immediato: errori 500 o 503, ma il sito in sé non è rotto. È il modello di esecuzione a esserlo.
Prerequisiti
- Accesso SSH come root o amministratore del server.
- Accesso al dominio nel pannello Plesk.
- Conoscenza del percorso del sito, di solito sotto /var/www/vhosts/.
- Un editor base e i comandi grep, stat, ps, ls.
Note: i percorsi possono cambiare tra Plesk, cPanel, DirectAdmin e FastPanel. La logica di diagnosi resta la stessa: capire con quale utente gira PHP e chi possiede i file.
Step 1: partire dal log giusto e leggere l’errore esatto
Serve un punto di partenza concreto. Non aprire subito tutti i file del sito. Prima individua il log che mostra il fallimento reale. Su Plesk, i più utili sono il log error del dominio e il log PHP-FPM del pool.
Guarda prima il dominio interessato:
tail -n 50 /var/www/vhosts/system/tuodominio.it/logs/error_log# Output: una riga con 500/503, oppure un messaggio come "Permission denied" o "Primary script unknown".
Se il dominio usa PHP-FPM, controlla anche il log del servizio:
journalctl -u plesk-php82-fpm -n 80 --no-pager# Output: errori di accesso a file, socket o directory del vhost.
Warning: non fermarti al primo errore visibile nel browser. Se il log mostra "Permission denied" su un file di cache, il colpevole può essere una directory padre con permessi errati.
Step 2: verificare con quale utente gira il pool PHP-FPM
Il punto centrale è questo: PHP-FPM può girare come utente del sito, ma il pannello può avere impostazioni che forzano una modalità diversa. Se il sito è stato migrato, è facile ritrovarsi con un pool che usa un utente e file che appartengono a un altro.
Controlla il processo attivo:
ps -eo user,pid,cmd | grep '[p]hp-fpm'# Output: righe con l’utente del pool, per esempio tuoutente o psacln.
Controlla anche la configurazione del dominio:
grep -R "php_handler_type\|pool\|fpm" /var/www/vhosts/system/tuodominio.it/conf/ 2>/dev/null# Output: riferimenti al handler PHP e alla configurazione del pool.
Se trovi un pool dedicato, verifica il file del pool. Su Plesk, spesso è sotto un percorso simile a questo:
grep -R "^user =\|^group =\|^listen =" /opt/plesk/php/8.2/etc/php-fpm.d/ 2>/dev/null# Output: utente, gruppo e socket usati dal pool PHP-FPM.
Note: se il pool gira come utente corretto ma i file appartengono a root o a un vecchio account, il pannello non può “aggiustare” da solo il problema. Va corretto lato filesystem.
Step 3: confrontare proprietario, gruppo e permessi del sito
Qui si trova spesso il vero guasto. Un deploy manuale, un restore parziale o un plugin possono cambiare owner e mode. Il sito continua a esistere, ma PHP-FPM non riesce più a leggere i file o a scrivere in cache e upload.
Controlla un file rappresentativo e una directory scrivibile:
stat -c '%U %G %a %n' /var/www/vhosts/tuodominio.it/httpdocs/index.php
stat -c '%U %G %a %n' /var/www/vhosts/tuodominio.it/httpdocs/wp-content# Output: proprietario, gruppo e permessi numerici dei due path.
Se il sito usa WordPress o un’app simile, verifica anche le directory di scrittura:
find /var/www/vhosts/tuodominio.it/httpdocs -maxdepth 2 -type d -name cache -o -name uploads -o -name tmp# Output: elenco delle directory che PHP deve scrivere.
La regola pratica è semplice. I file devono essere leggibili dall’utente del sito. Le directory di upload e cache devono essere scrivibili dal medesimo utente, non da root.
Warning: evitare chmod 777. Risolve il sintomo per pochi minuti e apre un buco inutile. Il problema vero è quasi sempre un owner sbagliato o una modalità incoerente.
Step 4: correggere ownership e permessi senza rompere il pannello
Qui serve precisione. Su Plesk, cambiare tutto con un chown casuale può rompere integrazioni del pannello. La correzione deve allineare i file all’utente corretto del dominio.
Prima identifica l’utente del dominio dal pannello o dalla configurazione locale, poi applica il fix su file e directory principali:
chown -R tuoutente:psacln /var/www/vhosts/tuodominio.it/httpdocs
find /var/www/vhosts/tuodominio.it/httpdocs -type d -exec chmod 750 {} \;
find /var/www/vhosts/tuodominio.it/httpdocs -type f -exec chmod 640 {} \;# Output: nessun output se i comandi riescono; i permessi diventano coerenti con l’utente del sito.
Se l’app ha directory che devono essere scrivibili, alza solo quelle:
chmod 770 /var/www/vhosts/tuodominio.it/httpdocs/wp-content/uploads
chmod 770 /var/www/vhosts/tuodominio.it/httpdocs/wp-content/cache# Output: directory di scrittura accessibili al pool PHP-FPM del dominio.
Se il problema nasce dopo una migrazione, controlla anche i symlink. Un link che punta fuori dal vhost può funzionare da shell e fallire via FPM per restrizioni del pannello.
Step 5: controllare open_basedir e vincoli del pannello
Molti errori di accesso non dipendono dai permessi classici. Dipendono dai vincoli del pannello. Su Plesk, open_basedir può bloccare l’accesso a percorsi fuori dal perimetro consentito. Il messaggio può sembrare un permesso negato, ma la causa è diversa.
Recupera i limiti PHP del dominio:
plesk bin domain -i tuodominio.it | grep -i "open_basedir\|php"# Output: impostazioni PHP e restrizioni del dominio.
Se vedi percorsi esterni al vhost, verifica che l’app non li stia usando per cache, sessioni o upload temporanei:
grep -R "session.save_path\|upload_tmp_dir\|cache_dir" /var/www/vhosts/tuodominio.it/httpdocs 2>/dev/null# Output: eventuali directory fuori perimetro o non scrivibili.
Note: in hosting multi-tenant, il pannello può essere più restrittivo del server. Non è un difetto. È una protezione. Il fix corretto consiste nel portare i path dentro il vhost o nel rivedere il template PHP del dominio.
Step 6: validare il socket PHP-FPM e i tempi di risposta
A volte il sito non fallisce per permessi, ma per un socket non raggiungibile. Il risultato lato browser è simile. Il log può mostrare timeout o un 503 dopo pochi secondi.
Controlla il socket del pool e la sua presenza:
ls -l /var/www/vhosts/system/tuodominio.it/php-fpm.sock
ss -xl | grep php-fpm# Output: socket presente e in ascolto, oppure assente se il servizio è fermo o mal configurato.
Se il pool è saturo, osserva i parametri più importanti:
grep -R "pm.max_children\|pm.max_requests\|pm.start_servers" /opt/plesk/php/8.2/etc/php-fpm.d/ 2>/dev/null# Output: limiti del pool, utili per capire se il problema è capacità e non permessi.
Un pool con pochi processi e molte richieste contemporanee può produrre errori ambigui. Prima di toccare i limiti, risolvi l’ownership. Poi valuta la capacità.
Verifica finale
Dopo la correzione, serve una prova pulita. Non basta ricaricare la homepage. Devi verificare che il dominio risponda, che PHP legga i file corretti e che il backend scriva dove deve.
Fai un test HTTP e uno sul file di prova:
curl -I https://tuodominio.it
php -r 'echo file_exists("/var/www/vhosts/tuodominio.it/httpdocs/index.php") ? "ok\n" : "no\n";'# Output: header HTTP 200 o 301 atteso, e risposta "ok" dal controllo file.
Se hai un file di test temporaneo, verifica anche la lettura via web. In alternativa, controlla il log dopo il primo accesso:
tail -n 20 /var/www/vhosts/system/tuodominio.it/logs/error_log# Output: assenza di nuovi "Permission denied".
Checklist rapida finale:
- Il pool PHP-FPM usa l’utente del dominio.
- I file del sito sono posseduti dall’utente corretto.
- Le directory di upload e cache sono scrivibili.
- open_basedir non blocca path esterni.
- Il socket PHP-FPM esiste e il servizio risponde.
Troubleshooting
1) "Primary script unknown"
Causa: il socket PHP-FPM o il path del documento non coincide con il vhost reale.
Fix:
grep -R "document_root\|proxy:fcgi\|php-fpm.sock" /var/www/vhosts/system/tuodominio.it/conf/ 2>/dev/null
systemctl restart plesk-php82-fpm# Output: il path del sito e il socket tornano coerenti.
2) "Permission denied: access to /var/www/vhosts/..."
Causa: owner o gruppo del vhost non corrispondono all’utente del pool.
Fix:
chown -R tuoutente:psacln /var/www/vhosts/tuodominio.it/httpdocs
find /var/www/vhosts/tuodominio.it/httpdocs -type d -exec chmod 750 {} \;
find /var/www/vhosts/tuodominio.it/httpdocs -type f -exec chmod 640 {} \;# Output: PHP-FPM torna a leggere i file del sito.
3) "open_basedir restriction in effect"
Causa: l’app usa un percorso fuori dal perimetro consentito dal pannello.
Fix:
plesk bin subscription -u tuodominio.it -php-settings "open_basedir=""
plesk bin service_node --reconfigure tuodominio.it# Output: il vincolo viene riallineato, oppure il path dell’app va spostato dentro il vhost.
Conclusione
Quando Plesk mostra un errore di permessi, il problema raramente è solo nel codice. Più spesso è il triangolo tra utente del sito, pool PHP-FPM e policy del pannello.
Il passo successivo concreto è standardizzare il deploy. Usa sempre lo stesso utente, lo stesso gruppo e una checklist post-upload con stat, curl e controllo del log. Così il prossimo "Permission denied" lo chiudi in pochi minuti, non dopo ore.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.