Il messaggio WordPress non hai i permessi per accedere a questa pagina compare quando l’utente autenticato non possiede la capability richiesta oppure WordPress non riesce a leggere correttamente ruolo, prefisso delle tabelle o contesto multisito.
Questa guida approfondisce WordPress non hai i permessi per accedere con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
L’errore è applicativo e non coincide con i permessi Unix dei file. Impostare 777 non modifica i privilegi dell’utente WordPress.
Può apparire dopo una migrazione, una modifica del prefisso database, l’attivazione di un plugin, la rimozione di un ruolo o l’accesso a una pagina admin non più registrata.
Come riconoscere il problema
- L’utente entra in wp-admin ma una pagina è negata.
- L’amministratore perde alcune funzioni.
- Il problema nasce dopo migrazione database.
- Il menu del plugin è visibile ma non accessibile.
- In multisito l’utente entra nel sito sbagliato.
Cause più frequenti
1. Ruolo o capability mancanti
L’utente non possiede il privilegio richiesto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Prefisso tabelle cambiato
Le chiavi user_roles o capabilities conservano il vecchio prefisso. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Plugin disattivato o aggiornato
La pagina admin o la capability non vengono registrate. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Multisito
Ruoli e appartenenza al sito non corrispondono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Utente corrotto
Metadati duplicati o mancanti impediscono il riconoscimento. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. URL amministrativa obsoleta
Un bookmark punta a una pagina rimossa o rinominata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Verifica il ruolo. Usa WP-CLI o Utenti senza modifiche dirette casuali. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla la pagina richiesta. Identifica `page=` e plugin responsabile. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Leggi table_prefix. Confronta wp-config.php e tabelle reali. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla usermeta. Cerca capabilities e user_level col prefisso corretto. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Disattiva il plugin sospetto in staging. Verifica conflitti e registrazione menu. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla multisito. Assicurati che l’utente sia assegnato al sito. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta un secondo amministratore. Determina se il problema è dell’utente o globale. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Assegna il ruolo corretto. Usa WP-CLI o interfaccia e il minimo privilegio necessario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi le chiavi usermeta. Solo dopo backup e conferma del prefisso. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riattiva o aggiorna il plugin. Ripristina la pagina amministrativa compatibile. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiungi l’utente al sito multisito. Non confondere super admin e amministratore locale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ricrea l’utente se necessario. Trasferisci i contenuti e rimuovi l’account corrotto soltanto dopo verifica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna il collegamento. Usa il menu attuale invece di URL obsolete. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Controlla sicurezza. Verifica che il cambio di privilegi non derivi da compromissione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- L’utente accede solo alle pagine previste.
- Le capability sono coerenti.
- Il prefisso corrisponde.
- Multisito assegna il sito corretto.
- Nessun privilegio eccessivo è stato aggiunto.
Prevenzione
- Conserva backup database.
- Documenta il prefisso.
- Gestisci ruoli con strumenti affidabili.
- Testa migrazioni.
- Monitora cambi amministratori.
Errori da evitare
- Non usare 777.
- Non modificare usermeta senza backup.
- Non rendere tutti amministratori.
- Non cancellare il plugin prima di identificare la pagina.
- Non ignorare un cambio privilegi inatteso.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- utente e ruolo
- URL admin
- prefisso tabelle
- orario
- plugin o migrazione recente
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su WordPress non hai i permessi per accedere
È un problema dei permessi file?
No, il messaggio riguarda normalmente ruolo e capability di WordPress.
Posso modificare direttamente wp_usermeta?
Solo con backup e conoscendo prefisso e struttura corretti.
Perché accade dopo una migrazione?
Il prefisso delle tabelle o le chiavi capabilities possono non essere allineati.
Un plugin può causarlo?
Sì, se cambia capability o non registra più la pagina amministrativa.
Devo assegnare Administrator?
Solo se il ruolo è realmente necessario; applica il principio del minimo privilegio.