Résoudre le problème d'écran blanc de Zimbra Webmail après la saisie des identifiants

Si Zimbra Webmail accepte votre nom d'utilisateur et votre mot de passe, mais affiche ensuite une page blanche, un écran de chargement ou une fenêtre de boîte aux lettres vide, considérez cela comme un échec de chargement après connexion jusqu'à confirmation du contraire. Il est possible que les identifiants aient été acceptés alors que le client web n'a pas réussi à charger son interface ou à récupérer les données de la boîte aux lettres. Un écran blanc à lui seul n'identifie pas la cause du problème et ne prouve pas que la boîte aux lettres est endommagée.

L'objectif est d'obtenir un diagnostic reproductible : déterminer si la panne affecte un navigateur, un utilisateur, un serveur de messagerie ou tous les utilisateurs ; identifier la première requête ayant échoué ou l'entrée du journal du serveur ; puis appliquer la modification minimale correspondant à cet échec. Les étapes ci-dessous dissocient les vérifications du navigateur des tâches d'administration, ce qui permet de vérifier si l'accès est effectivement rétabli avant de modifier la configuration du serveur.

Tout d'abord, confirmez ce que signifie « écran vide après la connexion ».

Notez ce qui se passe immédiatement après avoir sélectionné « Se connecter ». L’adresse se transforme-t-elle en URL de la boîte mail ? La page reste-t-elle blanche, affiche-t-elle un indicateur de chargement, une erreur de service réseau ou des menus avec une liste de messages vide ? Un autre utilisateur peut-il se connecter simultanément ? Le même utilisateur rencontre-t-il le même problème dans une fenêtre de navigation privée ou sur un autre appareil ?

Ces détails permettent de cibler le problème. Si un seul navigateur rencontre le problème, il est plus probable qu'il s'agisse de l'état local du navigateur ou d'une extension. Si un compte rencontre le problème sur tous les navigateurs alors que les autres fonctionnent, vérifiez la boîte aux lettres, les préférences, les partages et les journaux de messagerie de cet utilisateur. Si plusieurs utilisateurs rencontrent le même problème, examinez le service client web, le proxy, mailboxd et les modifications récentes du serveur. Ces éléments constituent des indices de diagnostic, mais ne constituent pas une preuve à eux seuls. Action : notez l'heure, le ou les comptes concernés, le navigateur, la page exacte et si l'URL a changé ; ne saisissez pas les mots de passe ni les cookies de session.

Que peut essayer un utilisateur sans risque ?

1. Testez une fenêtre de navigation privée ou un autre navigateur compatible.

Ouvrez l'URL de Zimbra dans une fenêtre de navigation privée ou incognito et connectez-vous une fois. Si la connexion fonctionne, désactivez temporairement les extensions de navigateur qui modifient les pages, les scripts, les cookies ou les paramètres de confidentialité, puis testez à nouveau votre profil habituel. Essayez ensuite avec un autre navigateur que vous utilisez actuellement, à titre de comparaison. Cela peut révéler des problèmes spécifiques à un profil, mais ne résout pas un problème côté serveur affectant tous les navigateurs.

Action : comparer le même compte et le même réseau dans une fenêtre de navigation privée et dans un navigateur classique. Si les deux échouent au même point, cesser d’utiliser plusieurs navigateurs et envoyer à l’administrateur l’horodatage et le résultat.

2. Effacez uniquement les données du site Zimbra si le test en fenêtre privée fonctionne.

Un cookie obsolète ou une ressource client web en cache peut entraîner une session incohérente après une mise à jour du serveur ou une modification des identifiants de connexion. Si la navigation privée fonctionne, effacez les cookies et les données de site en cache uniquement pour le nom d'hôte Zimbra, puis rouvrez le site et connectez-vous. Cette opération vous déconnectera et pourrait supprimer vos préférences locales ; évitez donc d'effacer toutes les données de navigation, sauf si votre administrateur vous le demande.

Action : avant d’effacer les données, vérifiez que vous connaissez l’adresse webmail correcte et que vous pouvez effectuer l’authentification multifacteurs requise. Si la page blanche réapparaît lors d’une nouvelle session, notez l’heure exacte et la version de votre navigateur ; vider le cache à plusieurs reprises ne résoudra probablement pas le problème.

3. Vérifiez si l'échec est lié à un seul compte.

Si d'autres utilisateurs peuvent ouvrir Zimbra mais qu'un compte ne le peut pas, veuillez le signaler à l'administrateur. La page de dépannage de Zimbra concernant le blocage de l'écran après la connexion suggère de consulter les journaux de messagerie et, dans les cas plus anciens, de vérifier si la recherche initiale dans la boîte de réception est à l'origine du problème. Cette page est encore en cours d'élaboration et ses exemples sont anciens ; modifier les préférences de messagerie ou déplacer les messages ne constitue pas une solution universelle.

Action : avant de modifier les préférences, les partages ou les messages, demandez à l’administrateur d’examiner les erreurs spécifiques au compte. Ne supprimez pas les e-mails ni les dossiers partagés dans un premier temps. L’ancienne procédure ne peut être envisagée que si les journaux et un test contrôlé indiquent un problème de chargement de la boîte aux lettres, et si l’administrateur consigne la procédure de restauration de la configuration d’origine.

Que doit vérifier en premier l'administrateur Zimbra ?

Commencez par noter l'heure de l'événement et le périmètre concerné, puis comparez la connexion avec les journaux de Zimbra. La page de dépannage officielle de Zimbra pour les connexions bloquées recommande de commencer par consulter les journaux de Zimbra, mailbox.logpuis d'examiner les autres journaux pertinents. La documentation de référence des journaux de Zimbra mentionne les journaux suivants : [liste des journaux] /opt/zimbra/log/mailbox.log, audit.log[ liste des journaux], [liste nginx.access.logdes journaux nginx.log] et [liste zmmailboxd.outdes journaux]. Tout en précisant que l'emplacement des journaux dépend du déploiement.

Sur le serveur qui traite la requête concernée, un administrateur peut consulter les journaux pertinents tout en reproduisant le problème :

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

Utilisez uniquement les chemins d'accès existants dans votre déploiement ; dans une installation multi-serveurs, les journaux du proxy et de la messagerie peuvent se trouver sur des hôtes différents. Arrêtez l'affichage en direct avec Ctrl+C après une reproduction contrôlée. Action : associez un horodatage à la requête du client et recherchez une authentification réussie suivie d'un échec de requête vers la messagerie, le proxy ou le client web. Partagez un court extrait expurgé plutôt qu'un journal complet contenant des données personnelles.

Sources : l’article de dépannage post-connexion de Zimbra et la référence des fichiers journaux de Zimbra .

Comment les erreurs de proxy et de boîte aux lettres modifient-elles le diagnostic ?

Si les utilisateurs accèdent à Zimbra via un proxy Zimbra, consultez les journaux du proxy ainsi que ceux du serveur de messagerie. La documentation de dépannage du proxy de Zimbra identifie ces journaux nginx.logcomme nginx.access.logfaisant partie des journaux du proxy. Elle décrit les réponses 502 et 503 comme des défaillances en amont ou de service ; elle indique qu'une erreur 503 se produit généralement lorsque le processus mailboxd de Jetty est indisponible. Une réponse 5xx est un indice plus pertinent qu'une page blanche, mais la requête exacte et l'hôte restent importants.

Action : repérez la première requête ayant échoué et son code de réponse dans le journal d’accès, puis faites-les correspondre simultanément à l’erreur de proxy et au journal de messagerie. Vérifiez la résolution de noms, l’accessibilité réseau et l’état du serveur de messagerie concerné uniquement si les journaux indiquent une défaillance de routage ou du serveur en amont. Évitez de redémarrer tous les services Zimbra simplement parce qu’un utilisateur signale une page vide.

Pour consulter l'état du service, un administrateur peut utiliser l'utilitaire de contrôle Zimbra :

su - zimbra
zmcontrol status

L'état « En cours d'exécution » ne garantit pas la réussite de toutes les requêtes du client web. Utilisez-le comme un indicateur parmi d'autres, en complément de l'état des requêtes et des journaux de messagerie. Consultez le guide de dépannage du proxy Zimbra .

Quand s'agit-il d'un problème spécifique à une version du client Web ?

Le wiki de Zimbra documente des cas historiques de page blanche survenus après des mises à niveau vers certaines versions anciennes de ZCS. Un article indique que la solution proposée pour l'enregistrement des services s'applique à ZCS 8.6 et 8.7.0/8.7.1 et illustre les réponses 404 du client web. Un autre documente un scénario distinct de correctif pour les versions 8.8.15 et 9.0.0, avec des erreurs de démarrage de mailboxd et des réponses 503. Il s'agit de cas spécifiques à certaines versions, et non d'instructions générales pour les systèmes Zimbra actuels.

Ne copiez pas leurs commandes et ne supprimez pas les fichiers du serveur simplement parce que le symptôme semble similaire. Vérifiez d'abord la version exacte de Zimbra, le niveau de correctif, l'historique des mises à jour, la réponse HTTP et la signature d'erreur décrites dans l'article correspondant. Les entrées du wiki sont d'anciennes pages de dépannage et certaines sont en cours de rédaction. Action : si la signature d'erreur et la version correspondent, faites valider la solution par un administrateur Zimbra ou un technicien du support avant d'effectuer des modifications. Consultez l'article historique (page blanche) et le cas distinct mailboxd/Jetty pour connaître leur portée.

N’utilisez les outils de développement du navigateur que lorsque les journaux du serveur ne sont pas concluants.

Un administrateur ou un technicien de support peut examiner les panneaux Réseau et Console du navigateur tout en reproduisant le problème. Recherchez les erreurs JavaScript ou les feuilles de style défaillantes, les redirections répétées, les requêtes bloquées, les avertissements de contenu mixte et les échecs d'appels API ou SOAP. Une connexion réussie suivie d'une erreur 404 pour les ressources du client web indique un problème à un niveau différent de celui d'une erreur 502/503 provenant du service de messagerie. Une exception JavaScript peut révéler une défaillance côté client, mais la première erreur visible n'en est pas toujours la cause première.

Action : enregistrez le chemin de la requête ayant échoué, le code d’état, l’horodatage et un message de console expurgé. Ne partagez pas de fichier HAR non filtré, d’en-tête d’autorisation, de réponse de connexion, de contenu de boîte aux lettres ni de cookie : ces éléments peuvent exposer les identifiants de session actifs et les messages privés. Si toutes les requêtes aboutissent mais que la page reste blanche, comparez avec un autre navigateur et vérifiez s’il s’agit d’une personnalisation côté client ou d’un défaut spécifique à cette version du client web.

Comment vérifie-t-on la réparation ?

Testez le résultat avec l'utilisateur concerné et, le cas échéant, avec un second compte. Après la connexion, vérifiez que l'interface de la messagerie s'affiche correctement, que les dossiers se chargent et qu'une sélection de messages récents apparaît. Ouvrez un message, accédez à un autre dossier et déconnectez-vous normalement. Répétez ensuite l'opération dans le navigateur qui a initialement posé problème. Dans le cas d'un déploiement multi-serveurs, effectuez le test via l'URL publique de la messagerie web plutôt que uniquement depuis le serveur de messagerie.

La disparition du formulaire de connexion ne suffit pas à confirmer une réparation. La page doit rester utilisable après le chargement initial et les journaux ne doivent plus afficher la même requête ayant échoué. Si l'écran reste blanc, examinez les éléments suivants : un seul utilisateur ou plusieurs, un seul navigateur ou tous, un seul serveur de messagerie ou tous les serveurs, et quelle requête échoue en premier. Cela vous permettra de déterminer quand passer du nettoyage du navigateur à une investigation spécifique à la messagerie, au proxy ou à la version.