ownCloudのアップロードが99%で止まった場合は、これらの制限を確認してください。

ownCloud Files ページの処理が 99% で止まった場合は、再試行する前に、宛先フォルダに完全なファイルが既に存在するかどうかを確認してください。ファイルが見つからない、または不完全な場合は、管理者にユーザー割り当て、PHP 一時ディレクトリと ownCloud チャンクディレクトリの空き容量、PHP および Web サーバーのリクエスト制限を確認するよう依頼してください。99% という表示だけでは、どの部分でエラーが発生したかを特定することはできません。

この実用的なリファレンスでは、ownCloud Server (Classic) 10.16 の Web インターフェイスを介したアップロードについて説明します。Infinite Scale およびデスクトップ同期によるアップロードでは、異なるサーバー パスとログが使用されます。例は公式の 10.16 ドキュメントに準拠しています。設定とファイル パスは、ご自身の環境に合わせてご使用ください。

クイックトリアージ

1. 再試行する前にアップロード状態を確認してください。

アップロードの進行状況が一定になったら、別のタブで宛先フォルダを開くか、ページを更新してください。ファイルが存在する場合は、ローカルのオリジナルファイルとバイトサイズを比較し、ファイルを開いてください。進行状況バーが古いままの完全なファイルは、完了応答が欠落しているか、ブラウザの表示に問題があることを示しています。そのため、2つ目のコピーをアップロードする必要はありません。

ファイルが存在しないか、サイズが小さい場合は、同じフォルダに小さなテストファイルを作成して試してから、可能であれば別のブラウザまたはネットワークから元のファイルを試してください。ファイルサイズ、ユーザー、宛先、おおよその時間、およびテストが失敗したかどうかを記録してください。これらの比較は、単一ファイルまたはクライアントの問題とサーバー全体の問題を区別するのに役立ちます。サーバーが処理中の大きなファイルのアップロードを繰り返しキャンセルして再開することは避けてください。

2. クォータ、一時領域、および権限を確認する

ownCloud管理者に、該当ユーザーのクォータと保存先フォルダの書き込み権限を確認してもらってください。クォータ制限があると、ブラウザがデータの大部分を送信した後でも、新しいファイルが保存されない場合があります。保存先が外部マウントの場合は、そのバックエンドの空き容量と書き込み権限も確認してください。

サーバー上で、データディレクトリおよび関連するすべての一時ディレクトリの空きブロックとinodeを確認してください。inodeとは、ファイルを作成するために使用されるファイルシステムレコードです。ボリュームには空きギガバイトがあっても、inodeが残っていない場合があります。PHPおよびownCloudの設定から実際のパスを使用してください。

df -h /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp
df -i /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp

PHP ファイルは、upload_tmp_dirPHP/Web サーバー アカウントから書き込み可能である必要があります。ownCloud には一時ディレクトリ設定もあり、チャンクのアップロードはデフォルトでユーザーのアップロード ディレクトリにステージングされます。アセンブリ中、ownCloud は最終ファイル サイズとほぼ同等の一時領域を必要とする場合があります。設定により、dav.chunk_base_dirその場所を変更できます。メイン データ ディスクだけでなく、これらのボリュームすべてを確認してください。

3. ファイルのアップロード制限とタイムアウトを合わせる

小さなファイルは動作するが大きなファイルは動作しない場合は、そのサイズを有効なウェブ PHP 設定 (upload_max_filesizeおよび) と比較してください。PHP では がより大きいpost_max_size必要があります。ウェブ サーバーまたは PHP-FPM で使用されている PHP 設定を確認してください。コマンドライン PHP 設定は異なる場合があります。php-FPM 設定では、ownCloud は PHP 設定がだけでなく、または FPM 設定にも属することに注意してください。post_max_sizeupload_max_filesize.user.ini.htaccess

max_input_timeアップロードに時間がかかる場合や、ログにタイムアウトが表示されている場合はPHPの実行タイムアウトも確認してください。サンプル数値をコピーするのではなく、想定されるワークロードに合わせて制限値を設定してください。設定を変更した後は、PHPとWebサーバーを再起動またはリロードしてください。ownCloudの「ビッグファイルアップロード設定」およびPHPのuploadディレクティブのリファレンスを参照してください。

次に、PHP の前にある各 HTTP レイヤーを確認します。Nginx は、client_max_body_size大きすぎるリクエスト ボディを HTTP 413 で拒否します。アップロード パスで使用されるリクエスト サイズに合わせて、十分な値に設定してください。ApacheLimitRequestBodyもmod_reqtimeoutアップロードを制限することができます。ownCloud は、リバース プロキシ、Cloudflare、ホスティング I/O 制限、Apache の request-timeout 設定が大きなアップロードに影響を与える可能性があると特に警告しています。ログで指摘されているレイヤーのみを変更し、最初の解決策としてセキュリティ モジュールをグローバルに無効にすることは避けてください。Nginxの request-body に関する公式ドキュメントを参照してください。

4. ログを使用して障害が発生しているレイヤーを特定する

問題を一度再現し、その時刻を記録してから、同じ時刻のownCloudログとWebサーバーまたはプロキシのエラーログを確認してください。ownCloudログは通常、設定済みのデータディレクトリにあります。実際のパスはで上書きできますconfig.php。クォータ、権限、一時ファイル、ロック、リクエストサイズ、タイムアウトに関するメッセージを検索してください。リクエストがownCloudログに表示されない場合は、まずプロキシまたはWebサーバーを調査してください。

tail -n 100 /path/to/owncloud.log

プレースホルダーを、インストール時に設定されているパスに置き換えてください。このコマンドは最新のログ行のみを表示し、サーバーデータを変更しません。ユーザー名、ファイルパス、IPアドレス、トークンを削除せずに生のログを公開することは避けてください。ownCloudのデバッグドキュメントでログの場所について説明しています。

修正を確認してください

• 小さなファイルを1つアップロードしてから、影響を受けたファイルをもう一度アップロードしてください。
• 保存先のコピーのサイズが想定どおりであり、正しく開くことを確認してください。
• アップロード時に、クォータ、ストレージ、HTTP 413、権限、またはタイムアウトのエラーが発生しないことを確認してください。
• 問題が解決しない場合は、管理者にファイルサイズ、宛先、タイムスタンプ、および該当するログエントリを提供して、リクエストを阻止したレイヤーを特定できるようにしてください。

すべての制限を一度に引き上げたり、リクエスト保護を無効にしたりしないでください。対象を絞った変更を行い、その後、制御された条件下で一度再試行することで、原因の特定が容易になり、サーバー構成の残りの部分もそのまま維持できます。