cPanel vs Plesk: PHP-FPM e permessi sito bloccati

Quando un sito ospitato su cPanel, Plesk, DirectAdmin o FastPanel inizia a mostrare errori 403, 500, pagine bianche o upload che falliscono, spesso il problema non è “PHP” in senso generico. Il punto vero è come il pannello gestisce PHP-FPM, con quale utente gira il sito e quanto spazio di manovra lascia su permessi, pool e ownership dei file.

Qui il confronto utile non è tra “pannello A contro pannello B” in astratto, ma tra due approcci operativi: da una parte il modello più isolato, in cui ogni sito lavora con un proprio utente e un proprio pool PHP-FPM; dall’altra il modello più semplice o più centralizzato, in cui il pannello tende a ridurre la complessità ma anche il controllo fine sui permessi. Scegliere l’uno o l’altro dipende dal tipo di hosting, dal numero di siti, dal livello di rischio accettabile e da quanto spesso devi fare troubleshooting.

Il problema reale: non è solo PHP, sono i vincoli del pannello

Molti errori apparentemente “di PHP” nascono da un conflitto tra tre livelli:

• Il pannello, che decide come creare utenti, vhost, pool e cron.
• Il web server, che legge i file con un determinato utente di esecuzione.
• Il filesystem, che applica ownership e permessi coerenti o incoerenti.

Se questi tre livelli non sono allineati, succedono scenari molto comuni:

• il sito funziona in lettura ma non riesce a scrivere in uploads o cache;
• un aggiornamento WordPress fallisce perché il processo PHP non ha i permessi corretti;
• un backup genera file creati come root e poi il sito non riesce più a modificarli;
• un pool PHP-FPM resta attivo ma risponde con errori 503 o 500 perché l’utente del pool non coincide con quello atteso dal sito.

In hosting condiviso o gestito, il pannello tende a prevenire gli errori più comuni. In VPS o server multi-sito, invece, il margine di intervento è maggiore, ma anche il rischio di configurare male i permessi aumenta. Per questo l’approccio giusto non è “più libertà è sempre meglio”, ma “più libertà solo quando serve davvero”.

Approccio 1: utente separato per sito con PHP-FPM dedicato

Questo è l’approccio più adatto quando vuoi isolamento, tracciabilità e riduzione dell’impatto tra siti. Ogni dominio o account ha un proprio utente Unix, un proprio pool PHP-FPM e, spesso, una propria home separata. È il modello che molti hosting moderni spingono come impostazione predefinita.

Quando conviene

• Gestisci più siti di clienti diversi e vuoi evitare che un account possa leggere o modificare i file di un altro.
• Hai WordPress, WooCommerce, PrestaShop o altri CMS con frequenti scritture su cache, media e log.
• Vuoi capire con precisione quale sito consuma CPU, memoria o processi PHP.
• Devi applicare permessi stretti senza dover ricorrere a workaround fragili come 777 o gruppi condivisi troppo larghi.

Vantaggi pratici

Con PHP-FPM dedicato per utente, il processo PHP gira con l’utente del sito o con un utente molto vicino a esso. Questo rende più semplice avere ownership coerente dei file e riduce i casi in cui il sito “vede” i propri file ma non riesce a scrivere nelle directory necessarie.

In pratica puoi ottenere una situazione del tipo:

• file del sito di proprietà dell’utente corretto;
• cartelle 755 e file 644 nella maggior parte dei casi;
• scrittura possibile solo dove serve davvero;
• log più chiari quando un pool va in errore.

È anche il modello che aiuta di più in caso di incidente: se un sito viene compromesso, il danno tende a restare confinato al suo utente e al suo pool.

Limiti da conoscere

Il rovescio della medaglia è che la configurazione può essere più rigida. Se carichi file via FTP con un utente, ma poi un cron o un processo esterno li genera con un altro utente, iniziano i conflitti. Inoltre, alcuni pannelli applicano regole proprie su directory temporanee, socket PHP-FPM, log e rewrite che non sempre sono intuitive.

Un altro limite è la manutenzione: più pool separati significano più punti da monitorare. Se hai molti siti, il numero di configurazioni PHP, versioni e override può crescere rapidamente.

Esempio pratico di verifica

Prima di cambiare permessi o pool, conviene verificare chi esegue i processi. In molti pannelli puoi farlo dalla dashboard dei servizi, ma una verifica rapida via shell è spesso il modo più preciso.

Su Linux, i controlli tipici sono questi:

ps aux | grep php-fpm
systemctl status php-fpm
systemctl status php8.1-fpm
systemctl status php8.2-fpm

Per vedere quali pool sono attivi e con quale utente lavorano:

grep -R "^user\|^group\|^listen\|^pm\." /etc/php/*/fpm/pool.d/

Un pool ben configurato può apparire così:

[site1]
user = site1
group = site1
listen = /run/php/site1.sock
pm = ondemand
pm.max_children = 8

Se invece trovi un pool che gira con un utente generico non coerente con l’account del sito, è facile che compaiano errori di scrittura o file creati con ownership inattesa.

Approccio 2: gestione più centralizzata e permessi “semplificati”

Questo approccio compare spesso in ambienti dove il pannello tende a semplificare tutto per l’utente finale. È meno isolato, più rapido da comprendere e, in alcuni casi, più comodo per chi gestisce pochi siti o un solo progetto.

Quando conviene

• Hai un solo sito o pochissimi siti sullo stesso account.
• Non vuoi gestire pool multipli, regole di ownership articolate o utenti separati per ogni progetto.
• Il team tecnico è ridotto e serve una gestione semplice, con minori possibilità di errore operativa.
• Stai lavorando in un ambiente temporaneo, di test o di staging, dove il rischio di isolamento è meno critico.

Vantaggi pratici

Il vantaggio principale è la semplicità. Meno utenti, meno pool, meno configurazioni da sincronizzare. In alcuni casi questo riduce i tempi di setup e rende più facile il supporto per chi non vive di amministrazione server ogni giorno.

Se il pannello imposta un flusso più lineare, puoi concentrarti su contenuti, plugin, tema e deploy, senza dover verificare ogni volta quale utente stia scrivendo nella cache. Per un sito piccolo, questa semplicità può essere un vantaggio reale.

Limiti da conoscere

Il problema è che la semplificazione può nascondere i conflitti finché non esplodono. Se un processo gira con un utente poco adatto, potresti ritrovarti con file creati da un owner inatteso, cron che falliscono o directory che il sito non può più aggiornare.

Inoltre, quando l’isolamento è minore, un errore di configurazione può diventare più pericoloso: un permesso troppo largo o una directory condivisa male può generare effetti collaterali tra siti diversi.

Scenario tipico

Un caso frequente è il seguente: un sito WordPress viene aggiornato da un plugin o da un comando manuale via SSH, alcuni file finiscono con ownership root:root, poi il pannello e PHP-FPM continuano a servire il sito, ma il backend non riesce più a scrivere in wp-content/uploads o wp-content/cache. Il frontend sembra funzionare, ma gli upload falliscono o gli aggiornamenti si bloccano.

In un ambiente centralizzato, il fix spesso è semplice ma va fatto con attenzione: ripristinare ownership e permessi coerenti con l’utente del sito.

chown -R site1:site1 /home/site1/public_html
find /home/site1/public_html -type d -exec chmod 755 {} \;
find /home/site1/public_html -type f -exec chmod 644 {} \;

Attenzione però: questi comandi vanno adattati al pannello e alla struttura reale delle directory. In alcuni casi il pannello usa percorsi diversi, come /var/www/vhosts/, /home/USERNAME/domains/ o strutture proprietarie.

Il confronto vero: sicurezza, manutenzione e diagnostica

Se devi scegliere tra i due approcci, la domanda corretta è: mi serve più isolamento o più semplicità?

Ecco una lettura pratica:

• Isolamento e sicurezza: vince il modello con utente separato e PHP-FPM dedicato.
• Semplicità operativa: vince il modello più centralizzato, se i siti sono pochi e il rischio è basso.
• Troubleshooting: il modello separato è più leggibile quando sai usare log, ownership e pool; il modello semplice è più rapido se il problema è banale e non vuoi inseguire troppi dettagli.
• Scalabilità: il modello separato regge meglio più siti e più clienti, ma richiede disciplina.

In un blog tecnico o in una piccola agenzia, il modello con utente separato è spesso la scelta migliore. In un sito personale o in una VM di prova, il modello più semplice può bastare e far risparmiare tempo.

Come capire chi sta eseguendo PHP davvero

Prima di cambiare permessi o pool, conviene verificare chi esegue i processi. In molti pannelli puoi farlo dalla dashboard dei servizi, ma una verifica rapida via shell è spesso il modo più preciso.

Su Linux, i controlli tipici sono questi:

ps aux | grep php-fpm
systemctl status php-fpm
systemctl status php8.1-fpm
systemctl status php8.2-fpm

Per vedere quali pool sono attivi e con quale utente lavorano:

grep -R "^user\|^group\|^listen\|^pm\." /etc/php/*/fpm/pool.d/

Se il pannello usa socket Unix, puoi verificare anche i permessi del socket:

ls -l /run/php/
ls -l /var/run/php/

Un socket con permessi troppo restrittivi può impedire al web server di parlare con PHP-FPM, generando errori 502 o 503. Un socket troppo aperto, invece, è un rischio inutile.

cPanel: isolamento forte, ma con logiche proprie

Su cPanel, il comportamento dipende molto da come è stato configurato il server. In molti ambienti moderni trovi PHP-FPM per account, con utente dedicato e gestione abbastanza pulita delle versioni PHP tramite MultiPHP Manager. Il vantaggio è che ogni account ha il proprio contesto e il pannello tende a mantenere una buona coerenza tra dominio, utente e document root.

Un flusso tipico è questo:

• l’account cPanel ha un utente Unix dedicato;
• il dominio punta a una document root sotto la home dell’account;
• PHP-FPM crea un pool associato all’account;
• i file devono restare coerenti con quell’utente.

Quando qualcosa si rompe, spesso il problema è uno di questi:

• permessi alterati da upload manuali o restore;
• cron configurati con utente diverso;
• plugin che scrivono in directory non previste;
• versione PHP cambiata ma pool o cache non allineati.

In cPanel è utile controllare anche la configurazione del dominio e la versione PHP assegnata. Se il sito sembra usare la versione sbagliata, verifica da MultiPHP Manager e, se presente, anche da MultiPHP INI Editor. Una variazione di versione può cambiare estensioni disponibili, limiti di memoria e comportamento di FPM.

Plesk: più controllo per dominio, ma attenzione alle estensioni

Plesk è spesso apprezzato perché espone in modo chiaro la gestione del dominio, della versione PHP e delle impostazioni PHP-FPM. In molti casi puoi scegliere se eseguire PHP come FPM application served by Apache o con altre modalità supportate dal pannello.

Il vantaggio pratico è che puoi intervenire con precisione su ogni dominio, ma devi sapere cosa stai toccando. Plesk tende a semplificare l’interfaccia, però dietro le quinte ci sono ancora utenti, permessi e configurazioni separate. Se un sito non scrive in una directory, conviene verificare:

• l’utente del subscription o del dominio;
• la modalità PHP selezionata;
• la document root effettiva;
• le impostazioni di open_basedir e sicurezza del dominio.

Un esempio tipico in Plesk è il classico errore di upload che non salva file in httpdocs/wp-content/uploads. In questi casi, oltre ai permessi, può intervenire anche una restrizione di open_basedir o una configurazione PHP-FPM non coerente con il percorso del sito.

Se necessario, controlla il log di dominio e il log PHP-FPM associato. Spesso il pannello mostra il percorso esatto del file di log, e quello è il posto migliore per capire se il processo non ha accesso a una directory o se sta fallendo per un problema di configurazione.

DirectAdmin: leggero, ma richiede disciplina sui permessi

DirectAdmin è spesso scelto per la sua leggerezza. In ambienti ben impostati può offrire una gestione pulita di utenti e domini, con una struttura semplice da amministrare. Proprio per questo, però, la disciplina sui permessi è fondamentale: se il server viene usato in modo “artigianale”, i problemi emergono presto.

Con DirectAdmin, i casi più comuni sono:

• domini multipli sotto lo stesso utente;
• script lanciati da cron con ownership incoerente;
• script di deploy che cambiano permessi in modo errato;
• cache e directory temporanee con proprietà sbagliata.

La regola pratica è sempre la stessa: evita di mescolare utenti e lascia che il pannello gestisca, per quanto possibile, la struttura degli account. Se devi intervenire manualmente, documenta il percorso preciso e l’utente corretto del dominio.

Un controllo utile è verificare i log del dominio e la configurazione FPM, soprattutto quando il sito mostra 500 dopo un cambio di tema o plugin. Spesso il problema non è il codice in sé, ma un file creato con owner sbagliato o una directory cache non scrivibile.

FastPanel: comodo per setup rapidi, ma va capito il modello di esecuzione

FastPanel punta molto sulla rapidità di configurazione. È utile quando vuoi mettere online siti senza perdere tempo in troppi passaggi, ma proprio per questo è importante capire come il pannello gestisce utenti, directory e PHP-FPM. Nei setup veloci, infatti, è facile dare per scontato che tutto sia “già giusto”, quando in realtà il sito potrebbe avere problemi di permessi o di esecuzione.

In particolare, controlla sempre:

• l’utente del sito;
• il percorso della document root;
• la versione PHP assegnata;
• il comportamento di FPM rispetto ai socket e ai permessi.

Se un sito in FastPanel non riesce a caricare immagini o a scrivere file temporanei, il problema è spesso nella relazione tra utente del processo e proprietà delle cartelle. Anche qui, il fix più efficace è quasi sempre ripristinare coerenza tra account e filesystem.

Permessi corretti: la base per evitare 403, 500 e upload bloccati

Molti amministratori cercano la soluzione nel pannello, ma la base resta il filesystem. In un hosting ben gestito, i valori tipici sono questi:

• 755 per le directory;
• 644 per i file;
• utente e gruppo coerenti con il dominio;
• nessun file del sito creato da root se non strettamente necessario.

Un errore 403 può dipendere da permessi troppo restrittivi o da una document root sbagliata. Un errore 500 può essere generato da un file .htaccess errato, da un pool FPM mal configurato o da un problema di ownership. Gli upload bloccati, invece, spesso sono un segnale chiaro che la directory di destinazione non è scrivibile dall’utente che esegue PHP.

Per diagnosticare velocemente, usa una sequenza pratica:

1. controlla i log del pannello e del dominio;
2. verifica l’utente che esegue PHP-FPM;
3. controlla ownership e permessi della document root;
4. prova un file di test con scrittura minima;
5. verifica se il problema colpisce solo una directory o tutto il sito.

Comandi utili per il troubleshooting

namei -l /home/site1/public_html/wp-content/uploads
stat /home/site1/public_html/wp-content/uploads
find /home/site1/public_html -maxdepth 2 -type d -printf '%u:%g %m %p\n' | head

Il comando namei -l è particolarmente utile perché mostra i permessi di ogni segmento del percorso. Se una sola directory intermedia è sbagliata, l’upload fallisce anche se il resto sembra corretto.

Quando il problema è il cron, non il web server

Un errore molto comune è attribuire tutto a PHP-FPM quando in realtà è un cron che ha creato file con owner sbagliato o che non ha accesso alle stesse variabili del web server. Questo accade spesso con backup, import, cache e job pianificati.

Se un cron deve lavorare sul sito, eseguilo con l’utente corretto o tramite il meccanismo previsto dal pannello. Esempio:

crontab -u site1 -e

Oppure, in ambienti dove il pannello gestisce i job, verifica che il cron sia associato al dominio giusto e non a un utente generico. Un cron lanciato come root può risolvere un problema nell’immediato, ma spesso ne crea altri più difficili da diagnosticare.

Configurazioni reali di PHP-FPM: cosa guardare

Quando il pannello consente di intervenire sulla configurazione FPM, i parametri più importanti sono quasi sempre questi:

• user e group del pool;
• listen su socket o porta TCP;
• pm con modalità ondemand, dynamic o static;
• pm.max_children;
• pm.max_requests;
• request_terminate_timeout;
• eventuali limiti di memoria e timeout nel file php.ini o nel pannello.

Un esempio realistico per un sito WordPress medio potrebbe essere:

[site1]
user = site1
group = site1
listen = /run/php/site1.sock
listen.owner = site1
listen.group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
request_terminate_timeout = 120s

Questa configurazione è solo un esempio, ma mostra il principio: il pool deve essere coerente con il sito e con il web server che lo serve. Se il socket non è leggibile dal server web, il sito non risponde. Se pm.max_children è troppo basso, il sito rallenta o va in coda. Se è troppo alto, rischi di saturare la RAM.

Errore 403, 500 o upload bloccato: come leggere il sintomo

Un buon troubleshooting parte dal sintomo, ma non si ferma lì.

• 403 Forbidden: spesso document root sbagliata, permessi directory errati, regole di accesso, .htaccess o restrizioni del pannello.
• 500 Internal Server Error: file di configurazione PHP o web server errati, permessi sbagliati, errore nel codice, pool FPM non raggiungibile.
• Upload bloccati: ownership incoerente, directory non scrivibile, open_basedir o quota disco piena.
• Pagine bianche: fatal error PHP, memoria insufficiente, estensioni mancanti o FPM che termina il processo.

Il punto importante è che il pannello può amplificare o ridurre questi problemi. Un pannello ben strutturato ti aiuta a capire rapidamente dove sta il guasto. Un pannello configurato male, o usato senza disciplina sui permessi, rende tutto più opaco.

Quale pannello scegliere se il tuo obiettivo è evitare blocchi

Se il tuo obiettivo principale è ridurre i blocchi operativi, la scelta non dipende solo dal nome del pannello ma dal modello di gestione che vuoi adottare.

In generale:

• cPanel è molto forte quando vuoi una gestione standardizzata, utenti separati e un ecosistema maturo.
• Plesk è ottimo quando vuoi controllo per dominio e una UI chiara per PHP e FPM.
• DirectAdmin premia chi vuole leggerezza e sa mantenere disciplina su utenti e filesystem.
• FastPanel è comodo per setup rapidi, ma richiede comunque attenzione al modello di esecuzione.

La vera domanda, però, resta questa: il pannello mi aiuta a mantenere coerenza tra utente, pool e permessi? Se la risposta è sì, sei sulla strada giusta. Se la risposta è no, prima o poi compariranno 403, 500 o upload bloccati.

Regola pratica finale

Se un sito scrive file, usa un utente dedicato e un pool PHP-FPM coerente. Se un sito è piccolo e non critico, puoi semplificare, ma non perdere mai il controllo di ownership e permessi.

In altre parole: non scegliere il pannello più “facile” in assoluto, scegli il modello che ti permette di diagnosticare velocemente i problemi quando arrivano. Perché in hosting, quando il sito si blocca, la differenza tra un setup ordinato e uno confuso si misura in minuti, non in teoria.