Risolvere il problema della schermata vuota di Zimbra Webmail dopo l'inserimento delle credenziali

Se Zimbra Webmail accetta nome utente e password ma poi mostra una pagina vuota, una schermata di caricamento o una casella di posta vuota, consideralo come un errore di caricamento post-accesso finché non hai conferma del contrario. Le credenziali potrebbero essere state accettate, ma il client web non riesce a caricare la sua interfaccia o a recuperare i dati della casella di posta. Una schermata vuota da sola non identifica la causa e non dimostra che la casella di posta sia danneggiata.

Il risultato utile è una diagnosi ripetibile: determinare se l'errore interessa un browser, un utente, un server di posta o tutti gli utenti; identificare la prima richiesta non riuscita o la prima voce del registro del server; quindi applicare la modifica minima che corrisponda alle prove. I passaggi seguenti separano i controlli del browser dalle attività di amministrazione, in modo da poter valutare se l'accesso è stato effettivamente ripristinato prima di modificare la configurazione del server.

Innanzitutto, chiarisci cosa significa "schermo vuoto dopo l'accesso".

Annota cosa succede immediatamente dopo aver selezionato "Accedi". L'indirizzo cambia e diventa l'URL della casella di posta? La pagina rimane bianca, mostra un'icona di caricamento, visualizza un errore del servizio di rete o mostra i menu con un elenco di messaggi vuoto? Un altro utente riesce ad accedere contemporaneamente? Lo stesso utente riscontra lo stesso problema in una finestra di navigazione in incognito o su un secondo dispositivo?

Questi dettagli restringono il campo delle possibili cause. Se il problema si verifica con un solo browser, è più probabile che il problema sia legato allo stato locale del browser o a un'estensione. Se un account non funziona su tutti i browser mentre gli altri funzionano correttamente, controlla la casella di posta, le preferenze, le condivisioni e i registri della casella di posta di quell'utente. Se il problema si verifica contemporaneamente per molti utenti, esamina il servizio client web, il proxy, mailboxd e le recenti modifiche al server. Questi sono indizi diagnostici, non prove sufficienti da soli. Azione: annota l'ora, l'account o gli account interessati, il browser, la schermata esatta e se l'URL è cambiato; non includere password o cookie di sessione.

Cosa può provare un utente in tutta sicurezza?

1. Prova una finestra di navigazione in incognito o un altro browser supportato.

Apri l'URL di Zimbra in una finestra di navigazione privata o in incognito ed effettua l'accesso una volta. Se funziona, disabilita temporaneamente le estensioni del browser che modificano pagine, script, cookie o impostazioni sulla privacy, quindi prova nuovamente ad accedere con il profilo normale. Per confronto, prova anche con un secondo browser che stai utilizzando. Questo può rivelare problemi specifici del profilo, ma non risolve un problema lato server che interessa tutti i browser.

Azione: confrontare lo stesso account e la stessa rete nella finestra di navigazione in incognito e nel browser normale. Se entrambi falliscono nello stesso punto, interrompere il ciclo dei browser e inviare all'amministratore data e ora e risultato.

2. Se il test in modalità privata funziona, cancella solo i dati del sito Zimbra.

Un cookie obsoleto o una risorsa del client web memorizzata nella cache possono causare instabilità nella sessione del browser dopo un aggiornamento del server o una modifica delle credenziali di accesso. Se la finestra di navigazione in incognito funziona, cancella i cookie e i dati del sito memorizzati nella cache solo per l'hostname di Zimbra, quindi riapri il sito ed effettua l'accesso. Questa operazione ti disconnetterà e potrebbe rimuovere le preferenze locali del sito, quindi evita di cancellare tutti i dati del browser a meno che non ti venga richiesto dall'amministratore.

Azione: verifica di conoscere l'indirizzo webmail corretto e di poter completare l'eventuale autenticazione a più fattori richiesta prima di cancellare i dati. Se la pagina vuota ricompare in una sessione pulita, annota l'ora esatta e la versione del browser; la cancellazione ripetuta della cache difficilmente risolverà il problema.

3. Verificare se l'errore segue un account

Se altri utenti riescono ad aprire Zimbra ma un account non ci riesce, segnalate il problema all'amministratore. La pagina di risoluzione dei problemi di Zimbra relativa alla schermata di accesso bloccata suggerisce di controllare i registri delle caselle di posta e, nei casi meno recenti, di verificare se la causa del problema risiede nella ricerca iniziale nella Posta in arrivo. La pagina è ancora in fase di sviluppo e gli esempi sono datati; la modifica delle preferenze della casella di posta o lo spostamento della posta non rappresentano una soluzione universale.

Azione: chiedere all'amministratore di esaminare gli errori specifici dell'account prima di modificare preferenze, condivisioni o messaggi. Non eliminare le email né rimuovere le cartelle condivise come prima soluzione. La procedura precedente può essere presa in considerazione solo se i log e un test controllato indicano un problema di caricamento della casella di posta e l'amministratore ha documentato la procedura per ripristinare l'impostazione originale.

Cosa dovrebbe controllare per prima cosa l'amministratore di Zimbra?

Iniziate dall'ora dell'evento e dall'ambito interessato, quindi correlate l'accesso con i log di Zimbra. La pagina ufficiale di risoluzione dei problemi di Zimbra per un accesso bloccato consiglia di iniziare da mailbox.loge poi di controllare altri log pertinenti. Il riferimento ai log di Zimbra elenca /opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.log, e zmmailboxd.out, avvertendo tuttavia che la posizione dei log dipende dalla distribuzione.

Sul server che gestisce la richiesta interessata, un amministratore può monitorare i log pertinenti durante la riproduzione del problema:

su - zimbra
tail -f /opt/zimbra/log/mailbox.log /opt/zimbra/log/nginx.access.log /opt/zimbra/log/nginx.log

Utilizzare solo i percorsi esistenti nella propria implementazione; in un'installazione multi-server, i log del proxy e della casella di posta potrebbero trovarsi su host diversi. Interrompere la visualizzazione in tempo reale con Ctrl+C dopo una riproduzione controllata. Azione: correlare un timestamp con la richiesta del client e cercare un'autenticazione riuscita seguita da una richiesta di casella di posta, proxy o client web non riuscita. Condividere un breve estratto anonimizzato anziché un log completo contenente dati personali.

Fonti: articolo di Zimbra sulla risoluzione dei problemi post-accesso e documentazione di Zimbra sui file di registro .

In che modo gli errori relativi al proxy e alla casella di posta elettronica modificano la diagnosi?

Se gli utenti accedono a Zimbra tramite Zimbra Proxy, è necessario esaminare sia i log del proxy che quelli del server di posta. La documentazione di Zimbra sulla risoluzione dei problemi del proxy identifica i log del proxy nginx.loge nginx.access.logquelli del server di posta. Descrive le risposte 502 e 503 come errori a monte o del servizio; la guida afferma che un errore 503 si verifica comunemente quando il processo mailboxd di Jetty non è disponibile. Una risposta 5xx è un indizio più affidabile di una pagina vuota, ma la richiesta esatta e l'host rimangono comunque importanti.

Azione: individuare la prima richiesta non riuscita e il relativo codice di risposta nel registro degli accessi, quindi confrontarli contemporaneamente con l'errore del proxy e il registro della casella di posta. Verificare la risoluzione dei nomi, la raggiungibilità della rete e l'integrità dello specifico host della casella di posta solo quando i registri indicano un errore di routing o un problema a monte. Evitare di riavviare tutti i servizi di Zimbra solo perché un utente segnala una pagina vuota.

Per verificare lo stato del servizio, un amministratore può utilizzare l'utility di controllo Zimbra:

su - zimbra
zmcontrol status

Lo stato "In esecuzione" non garantisce che ogni richiesta del client web abbia esito positivo. Utilizzalo come un ulteriore dato, insieme allo stato della richiesta e ai log della casella di posta. Consulta la guida alla risoluzione dei problemi del proxy di Zimbra .

Quando si tratta di un problema specifico della versione del client web?

La wiki di Zimbra documenta casi storici di pagine vuote dopo aggiornamenti a specifiche versioni precedenti di ZCS. Un articolo afferma che la soluzione relativa alla registrazione del servizio si applica a ZCS 8.6 e 8.7.0/8.7.1 e mostra risposte 404 dal client web. Un altro documenta uno scenario separato per le patch 8.8.15 e 9.0.0 con errori di avvio di mailboxd e risposte 503. Si tratta di casi specifici per determinate versioni, non di istruzioni generali per i sistemi Zimbra attuali.

Non copiare i comandi o eliminare i file del server solo perché il sintomo sembra simile. Innanzitutto, verifica la versione esatta di Zimbra, il livello di patch, la cronologia degli aggiornamenti, la risposta HTTP e la firma dell'errore descritti nell'articolo pertinente. Le voci wiki sono pagine di risoluzione dei problemi obsolete e alcune sono contrassegnate come "in fase di sviluppo". Azione: se la firma dell'errore e la versione corrispondono, chiedi a un amministratore Zimbra o a un fornitore di supporto di convalidare la soluzione rispetto alla build installata prima di apportare modifiche. Rivedi l'articolo storico sulla pagina vuota e il caso separato di mailboxd/Jetty per il loro ambito dichiarato.

Utilizza gli strumenti per sviluppatori del browser solo quando i log del server non sono conclusivi.

Un amministratore o un tecnico dell'assistenza può esaminare i pannelli Rete e Console del browser mentre riproduce il problema. È necessario verificare la presenza di errori in JavaScript o nei fogli di stile, reindirizzamenti ripetuti, richieste bloccate, avvisi di contenuto misto e chiamate API o SOAP non riuscite. Un accesso riuscito seguito da un errore 404 per le risorse del client web indica un problema a un livello diverso rispetto a un errore 502/503 proveniente dal servizio di posta elettronica. Un'eccezione JavaScript può identificare un errore lato client, ma il primo errore visibile non è sempre la causa principale.

Azione: registrare il percorso della richiesta non riuscita, il codice di stato, il timestamp e un messaggio della console oscurato. Non condividere file HAR non filtrati, intestazioni di autorizzazione, risposte di accesso, contenuto della casella di posta o cookie: questi possono esporre le credenziali di sessione attive e i messaggi privati. Se tutte le richieste vengono restituite correttamente ma la pagina rimane vuota, confrontare con un altro browser e verificare la presenza di personalizzazioni lato client o di un difetto del client web specifico della versione.

Come si verifica la riparazione?

Verifica il risultato con l'utente interessato e, se necessario, con un secondo account. Dopo aver effettuato l'accesso, conferma che l'interfaccia della casella di posta venga visualizzata correttamente, che le cartelle vengano caricate e che venga visualizzato un piccolo elenco di messaggi recenti. Apri un messaggio, naviga in un'altra cartella ed effettua il logout normalmente. Quindi ripeti la procedura nel browser che inizialmente ha causato l'errore. In caso di implementazione su più server, esegui il test tramite l'URL pubblico della webmail anziché solo dal server della casella di posta.

La risoluzione del problema non è confermata solo perché il modulo di accesso scompare. La pagina dovrebbe rimanere utilizzabile dopo il caricamento iniziale e i log non dovrebbero più mostrare la stessa richiesta non riuscita. Se la schermata è ancora vuota, è necessario esaminare nuovamente le prove: un solo utente o più, un solo browser o tutti, un solo host di posta elettronica o tutti gli host e quale richiesta fallisce per prima. Questo permetterà di capire quando passare dalla pulizia del browser a un'indagine sulla casella di posta elettronica, sul proxy o sulla versione specifica.