Fix the ownCloud Blank Page / White Screen of Death: Choose the Right Recovery Path

Start by deciding what kind of blank page you actually have

An ownCloud “white screen of death” is a symptom, not a diagnosis. The best fix depends on whether the browser received a server error, received valid HTML but failed to load JavaScript or CSS, or reached a reverse proxy that could not reach ownCloud at all.

That distinction matters because the trade-offs are very different. Disabling a third-party app is relatively low risk when a PHP exception names that app. Changing file ownership across an entire installation is much more invasive and should not be the first response to a JavaScript error. Likewise, restarting every service may briefly hide a problem without telling you whether it came from PHP, a proxy, an upgrade, or an app.

This guide covers ownCloud Classic. As of the current ownCloud Classic 11 documentation, version 11 is supported as a Docker-based deployment, with the operating system, PHP runtime, database, and Apache inside the ownCloud-provided containers. Older 10.x installations may still use a traditional web-server and PHP-FPM layout. Use the command branch that matches your deployment. See the ownCloud Classic 11 system requirements.

1. Is the blank page returning HTTP 500, or is the browser failing after HTTP 200?

Open the browser developer tools and inspect both the Network and Console tabs. Also test the endpoint from a terminal:

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

Caption: A server-side 500 response points toward ownCloud, PHP, the database, or the web stack rather than a simple browser-rendering problem.

If the main document returns 500 or 502/503, prioritize server and proxy logs. If the main document returns 200 but JavaScript bundles fail with 404, 403, or script exceptions, prioritize asset paths, reverse-proxy rewriting, themes, cache, or app compatibility. If only one browser is affected, test a private window and another supported browser before changing the server.

2. Did the problem start after an ownCloud or PHP upgrade?

This is one of the highest-value questions because it can immediately narrow the fault domain. ownCloud's current release notes state that ownCloud Classic 11 raised the minimum PHP version to PHP 8.3, and ownCloud Classic 11 is Docker-only. A legacy ownCloud 10.x installation follows different PHP compatibility rules, so do not copy PHP advice from another major release.

For a traditional ownCloud 10.x installation, run the command from the ownCloud directory:

sudo -u www-data ./occ status
php -v

For ownCloud Classic 11, run OCC through the Compose deployment:

docker compose exec owncloud occ status
docker compose exec owncloud php -v

Caption: Checking the installed ownCloud and PHP versions is especially important when the white screen began immediately after an upgrade.

Compare the result with the release notes for the version you actually run. The official ownCloud release notes are the right source for current minimum versions and breaking changes. A downgrade is not a safe generic fix: ownCloud documentation warns that downgrading is unsupported because it can corrupt data.

3. Which log gives you the first concrete error?

Logs are usually more useful than trial-and-error configuration changes. ownCloud's administration manual recommends the ownCloud log for diagnosing problems; by default, the log is stored in the configured data directory unless a different logfile is set.

On a traditional installation, examples include:

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

On ownCloud Classic 11, inspect the Compose services instead:

docker compose logs --tail=200 owncloud
docker compose ps

Caption: A PHP fatal error or stack trace that names an app or class gives a much safer troubleshooting target than changing unrelated server settings.

Look for the first fatal exception around the failed request, not only the final cascade of errors. Common categories include a missing PHP class, an incompatible app, database connection failure, unreadable configuration, missing code files, or an exception during an unfinished upgrade.

ownCloud's logging documentation says DEBUG logging can help during diagnosis but produces substantial output and can affect performance. If you temporarily raise the log level, return it to a less verbose value after collecting the evidence. See ownCloud logging configuration.

4. Should you disable a third-party app?

Choose this path when the error names a non-core app, when the blank page started after installing or updating an app, or when the failure appeared during an ownCloud upgrade. ownCloud's troubleshooting guidance explicitly recommends disabling third-party apps for troubleshooting and before upgrades.

List apps first. On ownCloud 10.x:

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

On ownCloud 11:

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

Caption: Disabling only the app implicated by logs is less disruptive than disabling many components or changing the full web stack.

The trade-off is functionality: users lose that app until it is updated or re-enabled. This is usually preferable to disabling core ownCloud services. The OCC documentation also notes that several core apps cannot be disabled, including DAV, FederatedFileSharing, Files, and Files_External. Review the official general troubleshooting guidance and the OCC command reference.

5. When are permissions worth fixing?

Permissions are a strong suspect when the log contains Permission denied, a recent deployment copied app/config files as the wrong user, or an upgrade replaced files with incorrect ownership. They are a weak suspect when the only evidence is a browser-side JavaScript error.

大規模な修復作業を行う前に、システムをメンテナンスモードにしてください。ownCloud 11の場合：

docker compose exec owncloud occ maintenance:mode --on

従来の10.x展開の場合：

sudo -u www-data ./occ maintenance:mode --on

キャプション：メンテナンスモードでは、ログの証拠によって既に裏付けられている所有権エラーやファイル権限エラーを調査する際に、ユーザーの操作が制限されます。

包括的な再帰処理を実行したり、無関係なリリースから権限レシピをコピーしたりしないでくださいchmod 777。現在のownCloud 11マニュアルには、Dockerマウントされたディレクトリに手動で追加されたファイルの所有権とモード（apps所有config権www-data:root、アプリファイル0644、アプリディレクトリ0751、追加された設定ファイル）が具体的に記載されています0644。また、0640手動で変更されたファイルとについて.htaccessも記載されています。リリース固有のリファレンスとしては、ownCloud 11の手動アップグレードに関するドキュメントを.user.ini参照してください。

6. PHPモジュール、OPcache、またはメモリ設定を変更する必要がありますか？

ログや互換性チェックで指摘された場合のみ対処してください。この方法は、問題のあるアプリケーションを1つ無効化するよりも影響範囲が広くなります。必要なPHP拡張機能が不足しているとコードの実行が妨げられる可能性があり、PHPの設定が不正だとホスト上のすべてのPHPアプリケーションに影響を与える可能性があります。

従来のホスト管理型PHPスタックの場合、Webランタイムが実際に何をロードしているかを確認してください。

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

キャプション：PHPモジュールとOPcacheのチェックは、サーバーログに不足している拡張機能や実行時の非互換性が報告された場合に役立ちますが、証拠なしに最初に変更するべきではありません。

ownCloud 11では、公式イメージがPHPランタイムを管理しているため、ホストPHPパッケージを変更するのは一般的に適切な方法ではありません。ownCloudのドキュメントでは、OPcacheはDockerイメージでデフォルトで有効になっていると記載されています。ownCloudのメモリキャッシュに関するドキュメントを参照してください。

レガシーインストール環境でPHPファイルを手動で置き換えた後、OPcacheが古いと疑われる場合は、PHP-FPMまたは関連するWeb/PHPサービスを再起動することで、プロセスローカルのオペコードキャッシュをクリアできます。ただし、再起動後には処理が一時的に中断され、キャッシュがコールド状態になるため、パフォーマンスが低下します。この操作は、根本的なファイルを修正した後に行うべきであり、エラーの原因を特定する代わりに行うべきではありません。

7. アップグレードが中断されたか、コアファイルに矛盾が生じていますか？

アップグレード中またはアップグレード直後に白いページが表示された場合は、まずアップグレードの状態を確認してください。ownCloudの公式アップグレードドキュメントでは、データベースを手動で操作するのではなく、OCCを使用してアップグレードおよび修復を行うことを推奨しています。

ownCloud 11の場合：

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

ownCloud 10.x の場合は、ウェブサーバーユーザーで同等の OCC コマンドを使用してください。

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

キャプション：OCC修復は、中断されたり一貫性のないアップグレードに適していますが、整合性チェックは、変更された、または欠落している署名付きコアファイルを特定できます。

コード整合性の結果には解釈が必要です。ownCloud のドキュメントではINVALID_HASH、、、FILE_MISSINGおよびをEXTRA_FILE個別の条件として扱っています。警告を消すために編集しないでくださいsignature.json。現在の ownCloud 11 のドキュメントでは、インストール、更新、および有効化の際にサードパーティ アプリの署名が必須となっています。ownCloudのコード署名に関するドキュメントを参照してください。

8. 修正が正しく行われたことをどのように確認すべきですか？

良好な復旧とは、単に「ページが白くなくなった」という状態ではありません。リクエストパス全体を検証してください。

• ownCloudのメインページは、500/502/503ではなく、期待されるHTTPステータスを返します。
• ブラウザの開発者ツールでは、繰り返し発生する致命的なJavaScriptエラーやコアバンドルの欠落は確認されません。
• ownCloudのログには、同じリクエストに対する新たな致命的な例外がすぐに記録されるわけではありません。
• occ statusインストール済みのインスタンスが報告され、予期せぬアップグレードの必要性は発生していません。
• メンテナンスが完了すると、メンテナンスモードは無効になります。
• テストユーザーはログインしてファイルページを開くことができます。

ownCloud 11の場合：

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

キャプション：復旧は両方のレイヤーで確認する必要があります。ownCloudインターフェースがロードされ、サーバー側のステータスとHTTPチェックが正常な状態を維持していることが条件です。

どの解決策がリスクと利益のバランスが最も優れているか？

ownCloudで白い画面が表示されたときにやってはいけないこと

• display_errors公開されている本番環境でPHPを有効にして、ブラウザにスタックトレースを表示させるのは避けてください。代わりにサーバーログを使用してください。
• ownCloudツリー全体を、再帰的にワールド書き込み可能なパーミッションに設定しないでください。
• 互換性のある環境にサポートされているバックアップを復元する場合を除き、ownCloudをダウングレードして迅速なロールバックを行わないでください。
• データディレクトリ、アプリデータ、データベーステーブル、キャッシュディレクトリを無作為に削除しないでください。
• 特定のアプリだけを分離できる場合は、すべてのアプリを一度に無効化しないでください。
• 署名済みのコアファイルを編集したり、signature.json単に整合性エラーを抑制するためだけに編集したりしないでください。

実験を続けるのではなく、段階的に進めるべきタイミングはいつでしょうか？

ログにデータベースの破損、暗号化キーの問題、クリーンな復元後のコア整合性障害の繰り返し、またはドキュメント化されたOCCワークフローでは完了できないアップグレード状態が示された場合は、変更を停止してください。また、空白ページが本番クラスタに影響を与え、データの一貫性を損なうことなく単一ノードを隔離できない場合は、エスカレーションしてください。

サポートケースを開く前に、ownCloudでは構成レポートと関連ログを収集することを推奨しています。ownCloud 10.xの場合、ドキュメントに記載されているコマンドは次のとおりです。

sudo -u www-data ./occ configreport:generate > config_report.txt

デプロイメントに適した OCC 実行方法を使用し、出力結果を組織外に共有する前に機密情報が含まれていないか確認してください。ownCloudのログおよび構成収集ガイドには、サポートエンジニアが通常必要とする情報が説明されています。

公式資料

• ownCloud Classic 11 一般的なトラブルシューティング
• ownCloud Classic 11のシステム要件
• ownCloud Server リリースノート
• ownCloud Classic 11 手動アップグレード
• ownCloudのログ記録設定