ownCloudのファイルアップロードが99%でフリーズする問題を解決する：実践的なトラブルシューティングガイド

ownCloudへのアップロードが99%まで進んだ後にフリーズしたように見える場合、アップロードを繰り返し開始しても通常は解決しません。その時点では、ブラウザは既にファイルのほとんど、あるいは全てを転送している一方で、サーバーは最後のチャンクの受信、チャンクの組み立て、完了したファイルの転送先への移動、メタデータの更新、ロックの解除といった処理をまだ完了していない可能性があります。パーセンテージだけでは原因を特定できないため、最も迅速な方法は、サーバー側の証拠を一定の順序で確認することです。

このガイドは、2026年10月時点で入手可能なownCloud Server 11.0の最新管理ドキュメントに基づいています。多くのownCloud Classic環境にも同様の考え方が適用されますが、古いリリースでは設定パスやDockerの動作が異なる場合があります。制限を変更する前に、インストールされているバージョンとデプロイ方法を確認してください。

クイック診断チェックリスト

1. 一度再現し、すぐにログを検査する。

問題が確実に再現するファイルを使って、一度だけ制御されたアップロードを実行し、その正確な時刻を記録してください。次に、そのタイムスタンプ付近のownCloudログ、PHPログ、およびWebサーバーのエラーログを調べてください。最初に複数の設定変更を行わないでください。そうすると、実際にどのレイヤーで問題が発生したのかを特定するのが難しくなります。

ownCloud の公式トラブルシューティング ドキュメントでは、PHP、Apache、ownCloud のログを最初に確認することを明示的に推奨しています。標準の Docker デプロイメントでは、ownCloud は Apache と PHP の出力がコンテナの stdout/stderr を介してルーティングされることを文書化しており、コンテナのログを . で追跡することを推奨していますdocker compose logs owncloud -f。

ownCloudのログは、管理画面からも取得できます。ownCloudのログと設定ガイドには、「設定」>「管理」>「一般」の手順が記載されており、occ configreport:generateより詳細な設定レポートが必要な場合のオプションも提供されています。

どのようなログメッセージを探すべきでしょうか？

失敗したリクエストに関連付けられた最初のエラーに注目し、その後に続くすべての警告に注目しないでください。有用なカテゴリには、リクエストのタイムアウト、ストレージ不足、一時ファイルの作成または名前変更の失敗、権限エラー、WebDAV 例外、HTTP 413/502/504 レスポンス、ファイルロックの失敗などがあります。ownCloud のログレベルを一時的に DEBUG に上げた場合は、その後通常のレベルに戻してください。ownCloud では、詳細なログ記録はサーバーのパフォーマンスに影響を与える可能性があると注意喚起しています。公式のログ設定リファレンスを参照してください。

2. 一時保管場所と最終保管場所の両方で空きスペースを確認する

これは、99% の停止状態における最も重要なチェック項目の 1 つです。ownCloud Server 11.0 では、アップロードには複数の一時領域が使用される可能性があると説明されています。PHP アップロード一時ディレクトリにはアクティブなチャンクを格納するための空き容量が必要であり、ユーザーアップロードディレクトリはアップロードが完了するまでファイルのチャンクを収集します。

ownCloudのビッグファイルアップロードに関するドキュメントによると、一時的なPHP領域は、同時アップロード数にチャンクサイズを掛けた値程度に計画する必要があります。特に大きな単一ファイルの場合、ユーザーのアップロードディレクトリには、最終的なファイルサイズと同程度の容量が一時的に必要となります。これは、ファイルの組み立てが完了するまでチャンクがそこに保持されるためです。アップロードが完了すると、ownCloudはチャンクを最終的な保存先に書き込み、その後削除します。

データディレクトリ、PHP一時ディレクトリ、および.hppで設定された場所を含むファイルシステムを確認してくださいOWNCLOUD_DAV_CHUNK_BASE_DIR。また、特に外部ストレージがターゲットの場合は、実際の保存先も確認してください。サーバーには十分な空き容量があって/も、別のデータボリュームがいっぱいになっている場合があります。

アップロードを完了させるために、ownCloudのデータディレクトリにファイルを手動で移動したり、ディレクトリからファイルを移動したりしないでください。ownCloudは、データディレクトリはアプリケーション専用であり、直接変更すると同期やデータベースの不整合が発生する可能性があると警告しています。

3. 技術的制限を引き上げる前に、割り当て量を確認してください。

アップロード準備領域に十分な空き容量があっても、ユーザー割り当て制限によって大きな最終ファイルのアップロードがブロックされる場合があります。影響を受けているユーザーの割り当て制限、および必要に応じて外部ストレージマウントの容量とアクセス権限を確認してください。十分な空き容量がある別のアカウントまたは宛先に同じファイルをアップロードしてみるのも有効なテストです。エラーがファイルではなくユーザーまたはフォルダに起因する場合は、割り当て制限またはストレージポリシーが問題の原因としてより上位に挙げられます。

4. PHPとownCloudのアップロード設定を確認する

ログがリクエストサイズまたは実行制限を示している場合は、ランダムなファイル内の値が有効であると想定するのではなく、有効な PHP 設定を確認してください。一般的なディレクティブには、、、、、、およびなどがphp.iniあります。post_max_sizeupload_max_filesizeupload_tmp_dirmax_input_timemax_execution_timememory_limit

サポートされているDocker版ownCloud Server 11.0構成の場合、ドキュメントではこれらを環境変数 、OWNCLOUD_MAX_UPLOAD、OWNCLOUD_TEMP_DIRECTORY、、 にマッピングしています。これは、ownCloudがDocker構成を使用するデプロイメントでは、古いPHPやカスタマイズパターンに頼るのではなくOWNCLOUD_MAX_INPUT_TIME、提供されている環境変数を使用する必要があると述べているため重要です。OWNCLOUD_MAX_EXECUTION_TIMEOWNCLOUD_MEMORY_LIMIT.htaccess

すべての制限値を極端に大きな数値に設定するのは避けてください。より適切な目標値は、想定される最大ファイルサイズと、運用上の安全対策を維持しつつ、許容される最低接続速度に対応できる値です。

5. アップロードが遅い場合はセッションの有効期間を確認する

ownCloudはsession_lifetime、この値を想定される最長アップロード時間よりも短くしてはならないと明確に警告しています。カスタマイズしている場合は、想定される最長アップロードに必要な秒数以上に設定するか、不要なカスタム値を削除して、サポートされているデフォルトの動作に戻してください。

これは、500MBのファイルは正常に処理されるのに、数ギガバイトのファイルはほぼ同じ経過時間後に繰り返し処理に失敗する場合に特に確認する価値があります。

6. リバースプロキシまたはCDNを個別にテストする

ownCloudのビッグファイルに関するドキュメントには、クライアント側のプロキシやCloudflareなどのサービスがアップロードを制限する可能性があると記載されています。つまり、ownCloud/PHPスタックが完全に設定されていても、別のホップでリクエストボディが制限されたり、長いリクエストがバッファリングされたり、アイドル状態の接続が閉じられたり、ownCloudがアップロードを組み立てている間にタイムアウトしたりすることで、失敗する可能性があるということです。

アーキテクチャ上、安全な管理テストが可能な場合は、通常の公開ルートとリバースプロキシまたはCDNを経由しないパスの両方で同じアップロードを比較してください。直接パスが成功した場合は、その中継局の公式ドキュメントで、リクエストサイズ、アップロードタイムアウト、バッファリング、WebDAVの動作を確認してください。このテストのためだけにTLSを弱体化させたり、バックエンドを公開したりしないでください。

7. 最終処理中にアップロードが失敗した場合、ファイルのロックを確認する

トランザクションファイルロックはデフォルトで有効になっており、ファイルの同時変更からファイルを保護します。ownCloudのドキュメントによると、チャンクアップロードの組み立て時にもこの機能が重要になります。負荷の高いサーバーでは、ロックの問題が発生すると、転送は完了したものの、正常にコミットできなかったという状況が発生する可能性があります。

このサブシステムを変更する前に、トランザクションファイルロックに関するドキュメントを確認してください。ownCloudでは、負荷の高いワークロードのロックには、データベースロックに頼るのではなく、メモリキャッシュバックエンドを使用することを推奨しています。クラスタ構成のデプロイメントでは、すべてのアプリケーションノードが同じロック状態を参照する必要があるため、共有Redisロックが特に重要になります。

チャンク処理が有効になっていない場合、パブリックフォルダへの非常に長いアップロードには特別なケースが存在します。ownCloudによると、1時間以上かかるアップロードには十分な大きさのロックが必要になる場合がありますOWNCLOUD_FILELOCKING_TTL。そうでない場合、Redisのガベージコレクションによって操作開始時に取得したロックが削除される可能性があります。アップロードパスがこのシナリオに合致しない限り、この設定を変更しないでください。

8．変更を加えるたびに、体系的に再テストを行う。

特定された問題を修正したら、同じファイル、アカウント、宛先、ブラウザ、ネットワークパスを使用して再試行してください。その後、次の3点を確認してください。処理が完了していること、宛先に想定どおりのサイズのファイルが作成されていること、そしてログにそのリクエストに関する新しいエラーが含まれていないこと。

適切な手順としては、まず小さなファイル、次に中程度のファイル、そして最後に最初に失敗したファイルサイズでテストを行うと良いでしょう。小さなファイルは常に成功するものの、ある一定のサイズを超えると失敗が発生する場合は、ストレージ容量とサイズ制限に注目してください。一定の期間後に失敗が発生する場合は、セッションとタイムアウトに注目してください。失敗が特定のホスト名またはネットワークパスでのみ発生する場合は、プロキシとロードバランサーに注目してください。

やってはいけないこと

• ログを確認せずに、数ギガバイトのアップロードを繰り返し試みないでください。チャンクのアップロード失敗が繰り返されると、時間がかかり、一時的にストレージ容量を消費する可能性があります。
• ownCloudのデータディレクトリを手動で変更しないでください。ownCloud、WebDAV、またはサポートされている管理ツールを使用してください。
• まず最初にファイルロックを無効にしないでください。ロックはデータの整合性を保護するものです。代わりにバックエンドの診断を行ってください。
• PHPの設定が1つの設定ファイルに記載されているからといって、必ずしも有効であるとは限りません。コンテナ、PHP-FPM、Apacheモジュール、複数のINIファイルが存在する場合、有効な設定は異なる可能性があります。
• タイムアウト値を無期限に延長しないでください。リクエストを閉じているレイヤーを特定し、サポートされている最大アップロード量に適した制限値を設定してください。

実践的な意思決定プロセス

短い手順が必要な場合は、以下の順序で実行してください。まず問題を再現し、ownCloud/PHP/Webサーバーのログを読み、データ、一時ファイル、チャンクのストレージを確認し、クォータを検証し、有効なアップロードと時間設定を確認し、セッションの有効期間を検査し、リバースプロキシ/CDNをバイパスまたは検査し、最後にトランザクションロックを調査します。この順序は、リスクの高い構成変更を行う前に、証拠と最も可能性の高いインフラストラクチャの制約を優先します。

重要な点は、「99パーセント」自体はエラーコードではないということです。これは、ユーザーが問題に気づいた場所を示すものであり、どのコンポーネントが原因かを示すものではありません。確実な解決策は、アップロード失敗時のタイムスタンプを、サーバー上のストレージ、タイムアウト、プロキシ、セッション、またはロックの証拠と照合することです。