Corrigir problema de tela em branco no Zimbra Webmail após inserir as credenciais

Se o Zimbra Webmail aceitar seu nome de usuário e senha, mas exibir uma página em branco, uma tela de carregamento ou uma caixa de correio vazia, considere isso como uma falha de carregamento pós-login até que você possa confirmar o contrário. As credenciais podem ter sido aceitas, mas o cliente web não conseguiu carregar sua interface ou recuperar os dados da caixa de correio. Uma tela em branco por si só não identifica a causa e não comprova que a caixa de correio esteja danificada.

O resultado útil é um diagnóstico repetível: determinar se a falha afeta um navegador, um usuário, um servidor de caixa de correio ou todos os usuários; identificar a primeira solicitação ou entrada de log do servidor com falha; em seguida, aplicar a menor alteração que corresponda à evidência. As etapas abaixo separam as verificações do navegador do trabalho do administrador para que você possa avaliar se o acesso foi realmente recuperado antes de alterar a configuração do servidor.

Primeiro, confirme o que significa "tela em branco após o login".

Registre o que acontece imediatamente após selecionar "Entrar". O endereço muda para a URL da caixa de correio? A página permanece em branco, exibe um indicador de carregamento, mostra um erro de serviço de rede ou renderiza menus com uma lista de mensagens vazia? Outro usuário consegue entrar ao mesmo tempo? O mesmo usuário apresenta a mesma falha em uma janela anônima do navegador ou em um segundo dispositivo?

Esses detalhes ajudam a restringir a causa do problema. Se apenas um navegador apresentar falhas, o estado local do navegador ou uma extensão se tornam as causas mais prováveis. Se uma conta apresentar falhas em todos os navegadores enquanto outras contas funcionam normalmente, verifique a caixa de correio, as preferências, os compartilhamentos e os registros da caixa de correio desse usuário. Se vários usuários apresentarem falhas simultaneamente, investigue o serviço de cliente web, o proxy, o mailboxd e as alterações recentes no servidor. Essas são pistas de diagnóstico, não provas definitivas por si só. Ação: anote a hora, a(s) conta(s) afetada(s), o navegador, a tela exata e se a URL foi alterada; não inclua senhas ou cookies de sessão.

O que um usuário pode tentar com segurança?

1. Teste em uma janela anônima ou em outro navegador compatível.

Abra o URL do Zimbra em uma janela anônima ou privada e faça login uma vez. Se funcionar, desative temporariamente as extensões do navegador que modificam páginas, scripts, cookies ou comportamento de privacidade e, em seguida, teste o perfil normal novamente. Experimente também com um segundo navegador para comparação. Isso pode revelar problemas específicos do perfil, mas não resolve um problema do lado do servidor que afeta todos os navegadores.

Ação: compare a mesma conta e rede na janela anônima e no navegador normal. Se ambas falharem no mesmo ponto, pare de alternar entre os navegadores e envie ao administrador o registro de data e hora e o resultado.

2. Limpe apenas os dados do site Zimbra se o teste em janela privada funcionar.

Um cookie antigo ou um recurso do cliente web em cache pode deixar o navegador com uma sessão inconsistente após uma atualização do servidor ou uma alteração nas configurações de login. Se a janela anônima funcionar, limpe os cookies e os dados em cache do site apenas para o hostname do Zimbra e, em seguida, abra o site novamente e faça login. Isso encerrará sua sessão e poderá remover as preferências locais do site; portanto, evite limpar todos os dados do navegador, a menos que seu administrador solicite.

Ação: verifique se você conhece o endereço de webmail correto e se consegue concluir o login com autenticação de dois fatores antes de limpar os dados. Se a página em branco reaparecer em uma sessão limpa, anote o horário exato e a versão do navegador; limpar o cache repetidamente provavelmente não resolverá o problema.

3. Verifique se a falha ocorre em uma única conta.

Se outros usuários conseguirem acessar o Zimbra, mas uma conta específica não, relate o problema ao administrador. A página de solução de problemas do Zimbra para telas travadas após o login menciona a verificação dos logs da caixa de correio e, em casos mais antigos, a possibilidade de testar se a busca inicial na Caixa de Entrada é o fator causador do problema. A página está marcada como em desenvolvimento e os exemplos são antigos; alterar as preferências da caixa de correio ou mover e-mails não é uma solução universal.

Ação: solicite ao administrador que verifique erros específicos da conta antes de alterar preferências, compartilhamentos ou mensagens. Não exclua e-mails nem remova pastas compartilhadas como primeira medida. O procedimento antigo só deve ser considerado quando os registros e um teste controlado apontarem para um problema de carregamento da caixa de correio e o administrador registrar como restaurar a configuração original.

O que o administrador do Zimbra deve verificar primeiro?

Comece com o horário do evento e o escopo afetado e, em seguida, correlacione o login com os logs do Zimbra. A página oficial de solução de problemas do Zimbra para um login travado recomenda começar com a mailbox.logverificação dos logs e, em seguida, verificar outros logs relevantes. A lista de referência de logs do Zimbra inclui os logs `/ var/logs` /opt/zimbra/log/mailbox.log, ` /var/ logs`, `/var/logs` e `/var/ logs`, alertando que os locais dos logs dependem da implantação.audit.lognginx.access.lognginx.logzmmailboxd.out

No servidor que processa a solicitação afetada, um administrador pode monitorar os logs relevantes enquanto reproduz o problema:

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

Use apenas os caminhos existentes na sua implementação; em uma instalação com vários servidores, os logs do proxy e da caixa de correio podem estar em hosts diferentes. Interrompa a execução do log com Ctrl+C após uma reprodução controlada. Ação: correlacione um carimbo de data/hora com a solicitação do cliente e procure por uma autenticação bem-sucedida seguida por uma falha na solicitação da caixa de correio, do proxy ou do cliente web. Compartilhe um trecho curto e com informações pessoais ocultadas, em vez de um log completo contendo dados pessoais.

Fontes: Artigo de resolução de problemas pós-login do Zimbra e referência de arquivos de log do Zimbra .

Como os erros de proxy e de caixa de correio alteram o diagnóstico?

Se os usuários acessarem o Zimbra por meio do Zimbra Proxy, verifique os logs do proxy, bem como os logs do servidor de caixa de correio. A documentação de solução de problemas do proxy do Zimbra identifica os logs do proxy nginx.logcomo nginx.access.logexemplos. Ela descreve as respostas 502 e 503 como falhas de serviço ou de upstream; suas orientações indicam que um erro 503 geralmente ocorre quando o processo mailboxd do Jetty está indisponível. Uma resposta 5xx é uma pista mais forte do que uma página em branco por si só, mas a solicitação e o host exatos ainda são importantes.

Ação: localize a primeira solicitação com falha e seu código de resposta no log de acesso e, em seguida, compare-os com o erro do proxy e o log da caixa de correio simultaneamente. Verifique a resolução de nomes, a acessibilidade da rede e a integridade do host da caixa de correio específica somente quando os logs apontarem para falhas de roteamento ou de upstream. Evite reiniciar todos os serviços do Zimbra apenas porque um usuário relatou uma página em branco.

Para verificar o status do serviço, um administrador pode usar o utilitário de controle do Zimbra:

su - zimbra
zmcontrol status

O status "Em execução" não garante que todas as solicitações do cliente web sejam bem-sucedidas. Use-o como um dado adicional, juntamente com o status da solicitação e os registros da caixa de correio. Consulte a documentação de solução de problemas de proxy do Zimbra .

Quando é que este é um problema específico da versão do cliente web?

O wiki do Zimbra documenta casos históricos de páginas em branco após atualizações para versões antigas específicas do ZCS. Um artigo afirma que a solução de registro de serviço se aplica ao ZCS 8.6 e 8.7.0/8.7.1 e mostra respostas 404 do cliente web. Outro artigo documenta um cenário separado com patches para as versões 8.8.15 e 9.0.0, com erros de inicialização do mailboxd e respostas 503. Esses são casos específicos de versões, e não instruções gerais para sistemas Zimbra atuais.

Não copie os comandos nem exclua arquivos do servidor apenas porque os sintomas parecem semelhantes. Primeiro, confirme a versão exata do Zimbra, o nível de patch, o histórico de atualizações, a resposta HTTP e a assinatura do erro descritos no artigo relevante. As entradas da wiki são páginas de solução de problemas antigas e algumas estão marcadas como em desenvolvimento. Ação: se a assinatura do erro e a versão coincidirem, peça a um administrador do Zimbra ou a um provedor de suporte que valide a solução na versão instalada antes de fazer alterações. Consulte o artigo antigo sobre páginas em branco e o caso separado do mailboxd/Jetty para verificar o escopo declarado.

Utilize as ferramentas de desenvolvedor do navegador somente quando os registros do servidor forem inconclusivos.

Um administrador ou técnico de suporte pode inspecionar os painéis de Rede e Console do navegador enquanto reproduz o problema. Procure por falhas em arquivos JavaScript ou folhas de estilo, redirecionamentos repetidos, solicitações bloqueadas, avisos de conteúdo misto e falhas em chamadas de API ou SOAP. Um login bem-sucedido seguido por um erro 404 para arquivos do cliente web indica uma camada diferente de um erro 502/503 do serviço de caixa de correio. Uma exceção JavaScript pode identificar uma falha no lado do cliente, mas o primeiro erro visível nem sempre é a causa raiz.

Ação: registre o caminho da solicitação com falha, o código de status, o carimbo de data/hora e uma mensagem de console (com informações confidenciais ocultadas). Não compartilhe um arquivo HAR não filtrado, o cabeçalho de autorização, a resposta de login, o conteúdo da caixa de correio ou o cookie: esses dados podem expor credenciais de sessão ativa e mensagens privadas. Se todas as solicitações forem bem-sucedidas, mas a página ainda estiver em branco, compare com outro navegador e verifique se há alguma personalização no lado do cliente ou um defeito específico da versão do cliente web.

Como você verifica o reparo?

Teste o resultado com o usuário afetado e, se necessário, com uma segunda conta. Após o login, confirme se a interface da caixa de correio é exibida, as pastas são carregadas e um pequeno conjunto de mensagens recentes aparece. Abra uma mensagem, navegue para outra pasta e faça logout normalmente. Em seguida, repita o processo no navegador que apresentou a falha inicialmente. Para uma implantação com vários servidores, teste através do URL público do webmail, em vez de apenas a partir do servidor da caixa de correio.

O simples desaparecimento do formulário de login não confirma a correção do problema. A página deve permanecer utilizável após o carregamento inicial, e os registros não devem mais mostrar a mesma solicitação com falha. Se a tela ainda estiver em branco, volte às evidências: um usuário ou vários, um navegador ou todos, um host de caixa de correio ou todos os hosts, e qual solicitação falhou primeiro. Isso indicará quando passar da limpeza do navegador para a investigação específica da caixa de correio, do proxy ou da versão.