Zimbra Webメールの認証情報入力後に画面が真っ白になる問題を修正する

Zimbra Webmailがユーザー名とパスワードを受け付けた後、空白ページ、読み込み画面、または空のメールボックスフレームを表示する場合は、他に原因が確認できるまでは、ログイン後の読み込みエラーとして扱ってください。認証情報は受け付けられているものの、Webクライアントがインターフェースを読み込んだり、メールボックスデータを取得したりする際にエラーが発生している可能性があります。空白画面が表示されるだけでは原因を特定できず、メールボックスが破損していることを証明するものでもありません。

有用な結果は、再現可能な診断です。障害が特定のブラウザ、特定のユーザー、特定のメールボックスサーバー、またはすべてのユーザーに影響しているかどうかを判断し、最初に失敗したリクエストまたはサーバーログエントリを特定し、証拠に合致する最小限の変更を適用します。以下の手順では、ブラウザのチェックと管理者の作業を分離することで、サーバー構成を変更する前にアクセスが実際に回復したかどうかを判断できます。

まず、「ログイン後に空白になる」とはどういう意味か確認してください。

「サインイン」を選択した直後に何が起こるかを記録してください。アドレスはメールボックスのURLに変わりますか？ページは真っ白なままですか？スピナーが表示されますか？ネットワークサービスエラーが表示されますか？それとも空のメッセージリストを含むメニューが表示されますか？他のユーザーが同時にサインインできますか？同じユーザーがプライベートブラウザーウィンドウまたは別のデバイスで同じエラーを起こしますか？

これらの詳細情報によって、障害の原因を絞り込むことができます。 1 つのブラウザのみが失敗する場合は、ローカル ブラウザの状態または拡張機能が原因である可能性が高くなります。 他のアカウントは正常に動作しているのに、1 つのアカウントが複数のブラウザで失敗する場合は、そのユーザーのメールボックス、設定、共有、およびメールボックス ログを確認してください。 多くのユーザーが同時に失敗する場合は、Web クライアント サービス、プロキシ、mailboxd、および最近のサーバーの変更を調査してください。 これらは診断の手がかりであり、それ自体で証明されるものではありません。 対処方法: 時刻、影響を受けたアカウント、ブラウザ、正確な画面、および URL が変更されたかどうかを記録してください。パスワードやセッション Cookie は含めないでください。

ユーザーは安全に何を試すことができるでしょうか？

1. プライベートウィンドウまたは別のサポートされているブラウザでテストしてください。

ZimbraのURLをプライベートウィンドウまたはシークレットウィンドウで開き、一度サインインしてください。そこで正常に動作する場合は、ページ、スクリプト、Cookie、またはプライバシー動作を変更するブラウザ拡張機能を一時的に無効にしてから、通常のプロファイルを再度テストしてください。比較のために、別のブラウザでも試してみてください。これにより、プロファイル固有の問題が明らかになる場合がありますが、すべてのブラウザに影響するサーバー側の問題は解決されません。

対処方法：プライベートウィンドウと通常のブラウザで、同じアカウントとネットワークを比較してください。両方で同じ箇所でエラーが発生した場合は、ブラウザの切り替えを停止し、タイムスタンプと結果を管理者に送信してください。

2. プライベートウィンドウでのテストが成功した場合のみ、Zimbraサイトのデータのみをクリアします。

古いCookieやキャッシュされたWebクライアントアセットは、サーバーの更新やサインイン方法の変更後にブラウザのセッションに矛盾を生じさせる可能性があります。プライベートウィンドウが正常に動作する場合は、Zimbraホスト名のみのCookieとキャッシュされたサイトデータをクリアしてから、サイトを再度開き、サインインしてください。この操作を行うとログアウトされ、ローカルサイトの設定が削除される可能性があるため、管理者から指示がない限り、ブラウザのすべてのデータをクリアしないでください。

対処法：データ消去を行う前に、正しいウェブメールアドレスを確認し、必要な多要素認証をすべて完了できることを確認してください。クリーンなセッションでも空白ページが表示される場合は、正確な時刻とブラウザのバージョンを記録してください。キャッシュを繰り返しクリアしても解決する可能性は低いでしょう。

3. 失敗が1つのアカウントにのみ関連しているかどうかを確認する

他のユーザーはZimbraを開くことができるのに、特定のアカウントだけが開けない場合は、その状況を管理者に報告してください。ログイン後の画面でフリーズした場合のZimbraのトラブルシューティングページでは、メールボックスログの確認方法や、古いケースでは受信トレイへの最初のメールボックス検索が原因かどうかをテストする方法が説明されています。このページは現在作成中であり、例も古いものです。メールボックスの設定を変更したり、メールを移動したりしても、必ずしも解決するとは限りません。

対処方法：設定、共有フォルダ、またはメッセージを変更する前に、管理者にアカウント固有のエラーを調査するよう依頼してください。最初の対応として、メールを削除したり、共有フォルダを削除したりしないでください。以前の手順は、ログと制御されたテストでメールボックスの読み込みの問題が示され、管理者が元の設定に戻す方法を記録している場合にのみ検討できます。

Zimbra管理者はまず何をチェックすべきでしょうか？

イベント発生時刻と影響を受ける範囲から始め、サインインを Zimbra のログと関連付けます。ログインが停止したままの場合の Zimbra 公式トラブルシューティングページでは、まず を確認しmailbox.log、次に他の関連ログを確認することを推奨しています。Zimbra のログリファレンスには/opt/zimbra/log/mailbox.log、audit.log、nginx.access.log、nginx.log、 がリストされていzmmailboxd.outますが、ログの場所はデプロイメントによって異なると注意されています。

影響を受けるリクエストを処理するサーバー上で、管理者は問題の再現中に、関連するログを監視することができます。

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

デプロイメントに存在するパスのみを使用してください。マルチサーバー構成の場合、プロキシとメールボックスのログは異なるホストにある可能性があります。再現手順を1回実行したら、Ctrl+Cでライブテイルを停止してください。対処方法：1つのタイムスタンプをクライアント要求と関連付け、認証成功の後にメールボックス、プロキシ、またはWebクライアント要求の失敗が続くかどうかを確認してください。個人データを含む完全なログではなく、編集済みの短い抜粋を共有してください。

出典: Zimbra のログイン後のトラブルシューティング記事およびZimbra のログファイルリファレンス。

プロキシやメールボックスのエラーは、診断結果にどのような影響を与えるのでしょうか？

ユーザーが Zimbra Proxy 経由で Zimbra にアクセスしている場合は、プロキシ ログとメールボックス サーバーのログを確認してください。Zimbra のプロキシ トラブルシューティング リファレンスではnginx.log、nginx.access.logプロキシ ログとして と が識別されています。502 および 503 レスポンスは、アップストリームまたはサービスの障害として説明されています。ガイダンスによると、503 は Jetty の mailboxd プロセスが利用できない場合によく発生します。5xx レスポンスは、空白ページ単独よりも強力な手がかりとなりますが、正確なリクエストとホストも依然として重要です。

対処方法：アクセスログから最初の失敗したリクエストとその応答コードを特定し、プロキシエラーログとメールボックスログと照合します。ログがルーティングまたはアップストリームの障害を示している場合にのみ、名前解決、ネットワーク到達可能性、および特定のメールボックスホストの状態を確認します。1人のユーザーが空のページを報告したという理由だけで、すべてのZimbraサービスを再起動することは避けてください。

サービスの状態を確認するには、管理者はZimbraコントロールユーティリティを使用できます。

su - zimbra
zmcontrol status

「実行中」ステータスは、すべてのWebクライアントリクエストの成功を保証するものではありません。リクエストステータスやメールボックスログと併せて、データポイントの一つとしてご利用ください。詳細については、Zimbraのプロキシトラブルシューティングリファレンスを参照してください。

これは、どのような場合にバージョン固有のWebクライアントの問題となるのでしょうか？

ZimbraのWikiには、特定の古いZCSリリースへのアップグレード後に発生した空白ページに関する過去の事例が記載されています。ある記事では、サービス登録の修正策がZCS 8.6および8.7.0/8.7.1に適用され、Webクライアントから404応答が返されることを示しています。別の記事では、mailboxdの起動エラーと503応答が発生した8.8.15および9.0.0パッチ適用時のシナリオについて説明しています。これらはバージョン固有の限定的な事例であり、現在のZimbraシステムに対する一般的な手順ではありません。

症状が似ているからといって、コマンドをコピーしたり、サーバーファイルを削除したりしないでください。まず、関連する記事に記載されている Zimbra の正確なバージョン、パッチレベル、アップグレード履歴、HTTP レスポンス、およびエラーシグネチャを確認してください。Wiki エントリは古いトラブルシューティングページであり、一部は作業中とマークされています。対処方法: エラーシグネチャとバージョンが一致する場合は、変更を加える前に、Zimbra 管理者またはサポートプロバイダーにインストール済みのビルドに対して解決策を検証してもらってください。過去の空白ページの記事と、mailboxd/Jetty の個別のケースについて、その範囲を確認してください。

サーバーログが決定的な情報を提供しない場合にのみ、ブラウザの開発者ツールを使用してください。

管理者またはサポート担当者は、問題の再現中にブラウザのネットワークパネルとコンソールパネルを検査できます。JavaScriptまたはスタイルシートアセットの失敗、繰り返しのリダイレクト、ブロックされたリクエスト、混合コンテンツの警告、APIまたはSOAP呼び出しの失敗などを確認してください。Webクライアントアセットへのログインが成功した後に404エラーが発生する場合は、メールボックスサービスからの502/503エラーとは異なるレイヤーの問題を示しています。JavaScript例外はクライアント側の障害を示す可能性がありますが、最初に表示されるエラーが必ずしも根本原因とは限りません。

対処方法：失敗したリクエストのパス、ステータスコード、タイムスタンプ、および編集済みのコンソールメッセージを記録してください。フィルタリングされていないHARファイル、認証ヘッダー、ログイン応答、メールボックスの内容、またはCookieは共有しないでください。これらはアクティブなセッション認証情報やプライベートメッセージを漏洩させる可能性があります。すべてのリクエストが正常に返されたにもかかわらずページが空白のままの場合は、別のブラウザと比較し、クライアント側のカスタマイズまたはリリース固有のWebクライアントの不具合を確認してください。

修理の検証方法を教えてください。

影響を受けたユーザーと、必要に応じて別のアカウントを使用して結果をテストしてください。サインイン後、メールボックスのインターフェースが表示され、フォルダーが読み込まれ、最近のメッセージが少量表示されることを確認してください。メッセージを1つ開き、別のフォルダーに移動してから、通常どおりサインアウトします。次に、最初にエラーが発生したブラウザーで同じ手順を繰り返します。マルチサーバー環境の場合は、メールボックスホストからだけでなく、パブリックWebメールのURLからもテストしてください。

ログインフォームが消えたからといって、修復が完了したとは限りません。ページは最初の読み込み後も使用可能な状態を維持し、ログに同じリクエストの失敗が記録されなくなる必要があります。画面が依然として空白の場合は、証拠となる情報に戻ってください。ユーザーが1人か複数人か、ブラウザが1つかすべてか、メールボックスホストが1つかすべてか、そして最初に失敗したリクエストはどれかを確認してください。これにより、ブラウザのクリーンアップからメールボックス、プロキシ、またはバージョン固有の調査へと移行すべきタイミングが分かります。