Behebung des Problems mit dem leeren Bildschirm von Zimbra Webmail nach Eingabe der Anmeldedaten

Wenn Zimbra Webmail Ihren Benutzernamen und Ihr Passwort akzeptiert, aber anschließend eine leere Seite, einen Ladebildschirm oder ein leeres Postfachfenster anzeigt, gehen Sie vorerst von einem Fehler nach dem Login aus, bis Sie das Gegenteil bestätigen können. Die Anmeldedaten wurden möglicherweise akzeptiert, während der Webclient seine Benutzeroberfläche nicht laden oder die Postfachdaten nicht abrufen kann. Ein leerer Bildschirm allein gibt die Ursache nicht an und beweist nicht, dass das Postfach beschädigt ist.

Das nützliche Ergebnis ist eine reproduzierbare Diagnose: Ermitteln Sie, ob der Fehler einen Browser, einen Benutzer, einen Mailbox-Server oder alle Benutzer betrifft; identifizieren Sie die erste fehlgeschlagene Anfrage oder den ersten fehlgeschlagenen Serverprotokolleintrag; und nehmen Sie dann die kleinste Änderung vor, die zu den vorliegenden Informationen passt. Die folgenden Schritte trennen Browserprüfungen von Administratorarbeiten, sodass Sie beurteilen können, ob der Zugriff tatsächlich wiederhergestellt ist, bevor Sie die Serverkonfiguration ändern.

Zunächst sollten Sie klären, was „nach dem Login leer“ bedeutet.

Notieren Sie, was unmittelbar nach der Auswahl von „Anmelden“ geschieht. Ändert sich die Adresse zur Mailbox-URL? Bleibt die Seite weiß, wird ein Ladekreis angezeigt, erscheint eine Netzwerkfehlermeldung oder werden die Menüs mit einer leeren Nachrichtenliste dargestellt? Kann sich ein anderer Benutzer gleichzeitig anmelden? Tritt der Fehler beim selben Benutzer in einem privaten Browserfenster oder auf einem anderen Gerät auf?

Diese Details grenzen die Fehlersuche ein. Wenn nur ein Browser ausfällt, liegt die Ursache wahrscheinlich im lokalen Browserstatus oder einer Browsererweiterung. Wenn ein Konto browserübergreifend nicht funktioniert, während andere Konten funktionieren, überprüfen Sie das Postfach, die Einstellungen, die Freigaben und die Postfachprotokolle dieses Benutzers. Wenn mehrere Benutzer gleichzeitig betroffen sind, untersuchen Sie den Webclient-Dienst, den Proxy, mailboxd und kürzlich vorgenommene Serveränderungen. Dies sind diagnostische Hinweise, aber kein Beweis. Vorgehensweise: Notieren Sie Uhrzeit, betroffene(s) Konto(s), Browser, genaue Bildschirmanzeige und ob sich die URL geändert hat; geben Sie keine Passwörter oder Session-Cookies an.

Was kann ein Benutzer gefahrlos ausprobieren?

1. Testen Sie es in einem privaten Fenster oder mit einem anderen unterstützten Browser.

Öffnen Sie die Zimbra-URL in einem privaten oder Inkognito-Fenster und melden Sie sich einmal an. Funktioniert es dort, deaktivieren Sie vorübergehend Browsererweiterungen, die Seiten, Skripte, Cookies oder das Datenschutzverhalten verändern, und testen Sie anschließend Ihr normales Profil erneut. Verwenden Sie zum Vergleich einen zweiten Browser. Dies kann profilspezifische Probleme aufdecken, behebt aber kein serverseitiges Problem, das alle Browser betrifft.

Vorgehensweise: Vergleichen Sie dasselbe Konto und Netzwerk im privaten Browserfenster und im normalen Browser. Falls beide Versuche an derselben Stelle fehlschlagen, beenden Sie den Browserwechsel und senden Sie dem Administrator Zeitstempel und Ergebnis.

2. Löschen Sie nur die Daten der Zimbra-Website, wenn der Test im privaten Fenster funktioniert.

Veraltete Cookies oder zwischengespeicherte Webclient-Daten können nach einem Server-Update oder einer Änderung der Anmeldeinformationen zu inkonsistenten Browsersitzungen führen. Falls das private Fenster funktioniert, löschen Sie bitte nur die Cookies und zwischengespeicherten Website-Daten für den Zimbra-Hostnamen, öffnen Sie die Website anschließend erneut und melden Sie sich an. Dadurch werden Sie abgemeldet und Ihre lokalen Website-Einstellungen können verloren gehen. Löschen Sie daher nicht alle Browserdaten, es sei denn, Ihr Administrator fordert Sie dazu auf.

Vorgehen: Stellen Sie sicher, dass Sie die korrekte Webmail-Adresse kennen und die erforderliche Zwei-Faktor-Authentifizierung durchführen können, bevor Sie die Daten löschen. Falls in einer neuen Sitzung eine leere Seite erscheint, notieren Sie sich die genaue Uhrzeit und die Browserversion; wiederholtes Löschen des Caches ist in diesem Fall unwahrscheinlich.

3. Prüfen Sie, ob der Fehler auf ein bestimmtes Konto zurückzuführen ist.

Wenn andere Benutzer Zimbra öffnen können, ein Konto jedoch nicht, melden Sie dies bitte dem Administrator. Auf der Zimbra-Seite zur Fehlerbehebung bei einem hängenden Anmeldebildschirm wird die Überprüfung der Postfachprotokolle beschrieben. In älteren Fällen kann auch getestet werden, ob die anfängliche Suche im Posteingang die Ursache ist. Die Seite befindet sich noch in Bearbeitung und die Beispiele sind veraltet; das Ändern von Postfacheinstellungen oder das Verschieben von E-Mails behebt das Problem nicht immer.

Vorgehen: Bitten Sie den Administrator, kontospezifische Fehler zu überprüfen, bevor Sie Einstellungen, Freigaben oder Nachrichten ändern. Löschen Sie E-Mails oder freigegebene Ordner nicht als erste Maßnahme. Das ältere Verfahren sollte nur dann in Betracht gezogen werden, wenn Protokolle und ein kontrollierter Test auf ein Problem beim Laden des Postfachs hinweisen und der Administrator dokumentiert hat, wie die ursprünglichen Einstellungen wiederhergestellt werden können.

Was sollte der Zimbra-Administrator zuerst überprüfen?

Beginnen Sie mit der Ermittlung des Ereigniszeitpunkts und des betroffenen Bereichs und korrelieren Sie anschließend die Anmeldung mit den Zimbra-Protokollen. Die offizielle Zimbra-Fehlerbehebungsseite für eine hängende Anmeldung empfiehlt, mit den Protokollen zu beginnen mailbox.logund anschließend weitere relevante Protokolle zu überprüfen. Die Zimbra-Protokollreferenz listet die Protokolle /opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.log, und auf zmmailboxd.out, weist jedoch darauf hin, dass die Speicherorte der Protokolle von der jeweiligen Bereitstellung abhängen.

Auf dem Server, der die betroffene Anfrage bearbeitet, kann ein Administrator die relevanten Protokolle überwachen, während er das Problem reproduziert:

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

Verwenden Sie ausschließlich die in Ihrer Bereitstellung vorhandenen Pfade. In einer Installation mit mehreren Servern können sich die Proxy- und Mailbox-Protokolle auf unterschiedlichen Hosts befinden. Beenden Sie die Live-Protokollierung nach einer erfolgreichen Reproduktion mit Strg+C. Vorgehensweise: Korrelieren Sie einen Zeitstempel mit der Clientanfrage und suchen Sie nach einer erfolgreichen Authentifizierung, gefolgt von einer fehlgeschlagenen Mailbox-, Proxy- oder Webclient-Anfrage. Teilen Sie einen kurzen, redigierten Auszug anstelle des vollständigen Protokolls mit personenbezogenen Daten.

Quellen: Zimbras Artikel zur Fehlerbehebung nach dem Login und Zimbras Logdatei-Referenz .

Wie verändern Proxy- und Mailbox-Fehler die Diagnose?

Wenn Benutzer über den Zimbra-Proxy auf Zimbra zugreifen, sollten sie sowohl die Proxy- als auch die Mailbox-Server-Protokolle überprüfen. Die Zimbra-Dokumentation zur Proxy-Fehlerbehebung bezeichnet nginx.logdiese nginx.access.logals Proxy-Protokolle. Dort werden 502- und 503-Fehler als Upstream- oder Dienstfehler beschrieben; laut Dokumentation tritt ein 503-Fehler häufig auf, wenn der Jetty-Mailboxd-Prozess nicht verfügbar ist. Eine 5xx-Fehlermeldung ist ein aussagekräftigerer Hinweis als eine leere Seite allein, die genaue Anfrage und der Host sind aber dennoch wichtig.

Vorgehensweise: Suchen Sie die erste fehlgeschlagene Anfrage und ihren Antwortcode im Zugriffsprotokoll und gleichen Sie diese gleichzeitig mit dem Proxy-Fehlerprotokoll und dem Postfachprotokoll ab. Überprüfen Sie die Namensauflösung, die Netzwerkverfügbarkeit und den Zustand des betreffenden Postfachhosts nur dann, wenn die Protokolle auf einen Routing- oder Upstream-Fehler hinweisen. Vermeiden Sie es, alle Zimbra-Dienste neu zu starten, nur weil ein Benutzer eine leere Seite meldet.

Um den Servicestatus zu überprüfen, kann ein Administrator das Zimbra-Steuerungsprogramm verwenden:

su - zimbra
zmcontrol status

Der Status „Wird ausgeführt“ garantiert nicht, dass jede Webclient-Anfrage erfolgreich ist. Verwenden Sie ihn als einen von mehreren Datenpunkten zusammen mit dem Anfragestatus und den Mailbox-Protokollen. Weitere Informationen finden Sie in der Zimbra-Referenz zur Proxy-Fehlerbehebung .

Wann handelt es sich um ein versionsspezifisches Webclient-Problem?

Das Zimbra-Wiki dokumentiert Fälle, in denen nach Upgrades auf bestimmte ältere ZCS-Versionen leere Seiten angezeigt wurden. Ein Artikel beschreibt die dort beschriebene Lösung zur Dienstregistrierung für ZCS 8.6 und 8.7.0/8.7.1 und zeigt 404-Fehler vom Webclient. Ein anderer Artikel dokumentiert ein separates Patch-Szenario für 8.8.15 und 9.0.0 mit Fehlern beim Start von mailboxd und 503-Fehlern. Dies sind spezifische, versionsspezifische Fälle und keine allgemeinen Anweisungen für aktuelle Zimbra-Systeme.

Kopieren Sie keine Befehle und löschen Sie keine Serverdateien, nur weil die Symptome ähnlich erscheinen. Bestätigen Sie zunächst die genaue Zimbra-Version, den Patch-Level, die Upgrade-Historie, die HTTP-Antwort und die Fehlersignatur, die im entsprechenden Artikel beschrieben sind. Die Wiki-Einträge sind ältere Fehlerbehebungsseiten, von denen einige als „in Bearbeitung“ gekennzeichnet sind. Maßnahme: Stimmen Fehlersignatur und Version überein, lassen Sie die Lösung von einem Zimbra-Administrator oder Supportmitarbeiter anhand der installierten Version überprüfen, bevor Sie Änderungen vornehmen. Beachten Sie den alten Artikel (ohne Titelseite) und den separaten Fall zu mailboxd/Jetty hinsichtlich ihres jeweiligen Anwendungsbereichs.

Verwenden Sie die Browser-Entwicklertools nur dann, wenn die Serverprotokolle keine eindeutigen Ergebnisse liefern.

Ein Administrator oder Supporttechniker kann die Netzwerk- und Konsoleneinstellungen des Browsers überprüfen, während er das Problem reproduziert. Achten Sie auf fehlerhafte JavaScript- oder Stylesheet-Ressourcen, wiederholte Weiterleitungen, blockierte Anfragen, Warnungen zu gemischten Inhalten und fehlgeschlagene API- oder SOAP-Aufrufe. Eine erfolgreiche Anmeldung, gefolgt von einem 404-Fehler für Webclient-Ressourcen, deutet auf eine andere Fehlerebene hin als ein 502/503-Fehler des E-Mail-Dienstes. Eine JavaScript-Ausnahme kann zwar einen clientseitigen Fehler anzeigen, aber der erste sichtbare Fehler ist nicht immer die eigentliche Ursache.

Maßnahme: Protokollieren Sie den Pfad der fehlgeschlagenen Anfrage, den Statuscode, den Zeitstempel und eine geschwärzte Konsolenmeldung. Geben Sie keine ungefilterte HAR-Datei, keinen Autorisierungsheader, keine Anmeldeantwort, keinen Postfachinhalt und keine Cookies weiter, da diese aktive Sitzungsdaten und private Nachrichten offenlegen können. Falls jede Anfrage erfolgreich beantwortet wird, die Seite aber weiterhin leer bleibt, vergleichen Sie dies mit einem anderen Browser und prüfen Sie auf clientseitige Anpassungen oder versionsspezifische Webclient-Fehler.

Wie überprüft man die Reparatur?

Testen Sie das Ergebnis mit dem betroffenen Benutzer und gegebenenfalls mit einem zweiten Konto. Vergewissern Sie sich nach der Anmeldung, dass die Mailbox-Oberfläche angezeigt wird, Ordner geladen werden und eine kleine Auswahl der letzten Nachrichten erscheint. Öffnen Sie eine Nachricht, navigieren Sie zu einem anderen Ordner und melden Sie sich wie gewohnt ab. Wiederholen Sie den Vorgang anschließend in dem Browser, bei dem der Fehler ursprünglich aufgetreten ist. Bei einer Installation auf mehreren Servern testen Sie die Anwendung über die öffentliche Webmail-URL und nicht nur über den Mailbox-Host.

Eine Reparatur ist nicht automatisch abgeschlossen, nur weil das Anmeldeformular verschwindet. Die Seite sollte nach dem ersten Laden weiterhin nutzbar sein, und die Protokolle sollten den gleichen Fehler nicht mehr anzeigen. Wenn der Bildschirm weiterhin leer ist, prüfen Sie erneut die Indizien: Betrifft es einen oder mehrere Benutzer, einen oder alle Browser, einen oder alle Mailbox-Hosts und welche Anfrage schlägt zuerst fehl? Daran erkennen Sie, wann Sie von der Browserbereinigung zur Untersuchung von Mailbox, Proxy oder versionsspezifischen Problemen übergehen sollten.