ownCloudで「WebDAVインターフェースが壊れています」エラーを修正する

ownCloudがブラウザで読み込まれたものの、管理ページに「WebDAVインターフェースが壊れています」と表示される場合、ファイルのアップロード、デスクトップ同期、およびファイルアプリも動作しない可能性があります。この警告は症状を示すものであり、診断結果ではありません。DAVエンドポイントにアクセスできない、正しく書き換えられていない、プロキシまたはセキュリティルールによってブロックされている、あるいはownCloudが自身の公開URLを呼び出している際にアクセスできない、といった原因が考えられます。

このガイドは、ownCloud Classic Server のインストールに適用されます。ownCloud Infinite Scale はアーキテクチャとデプロイメント モデルが異なるため、Classic Server の Apache 設定を Infinite Scale のデプロイメントに適用しないでください。以下の公式ページでは、ownCloud Server 10.15 および 10.16、ならびに Classic Server 11.0 について説明しています。チェックでは、ドキュメントに記載されている WebDAV ルートと Apache の要件を使用しますが、管理者への警告内容はリリースによって異なる場合があります。

図の説明：以下のインターフェースと端末の画像は概略図です。ホスト名、ステータス行、および表示されている値はプレースホルダーであり、実際のインストール状況やテスト実行結果を示すものではありません。

WebDAVの警告は何を意味しますか？

WebDAVは、ownCloudが同期クライアントや関連するファイル操作のためにファイルを一覧表示および管理するために使用するHTTPベースのインターフェースです。ブラウザでのログインは、Webインターフェースが応答することを確認するだけであり、WebDAVリクエストがパス、メソッド、認証ヘッダー、HTTPS接続がそのままの状態でownCloudに到達したことを保証するものではありません。

まず、障害が外部要因によるものか、ownCloudの自己診断機能のみに起因するものかを特定します。同期クライアントのエラーや認証済みWebDAVリクエストの失敗は、DAVルートまたは認証の問題を示しています。クライアントは正常に動作しているにもかかわらず管理者警告が表示される場合は、サーバー自体がTLS証明書を含め、パブリックホスト名を解決してアクセスできるかどうかをテストしてください。

ステップ1：正確なURLを記録し、WebDAVを直接テストする

ユーザーがブラウザに入力するホスト名とインストールパスと同じものを使用してください。ルートドメインへのインストールの場合、現在のクラシックサーバーDAVルートは通常、次の形式に従います。

https://cloud.example.com/remote.php/dav/files/USERNAME/

ownCloudが特定のパスより下にインストールされている場合は、そのパスを の前に含めてください/remote.php（例：）https://example.com/owncloud/remote.php/dav/files/USERNAME/。アカウント名とURLはご自身のものを使用してください。架空のホスト名をテストしたり、すべてのインストールで同じサブディレクトリが使用されると想定したりしないでください。

クライアントマシンから、認証済みのPROPFINDリクエストを送信します。cURLを使用する場合、ユーザー名のみを渡すと、コマンドにパスワードを含める代わりにパスワードの入力を求められます。

curl -i --user USERNAME -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/remote.php/dav/files/USERNAME/'

有効な認証済み WebDAV レスポンスは、一般的に HTTP を使用します207 Multi-Status。 は401、単に認証情報が受け入れられなかったことを意味する場合があります404。 は、多くの場合、間違ったルートまたはプロキシ パスの書き換えを示しています。 は、403アクセス ルール、WAF、またはサーバー ポリシーを示唆しています。 または301は302、クライアントまたは自己チェックが想定どおりにリダイレクトに従わなかったことを示している可能性があります。設定を変更する前に、レスポンス ヘッダーとサーバー ログを確認してください。コマンド出力を共有する前に、ユーザー名、Cookie、トークン、およびパブリック IP を削除してください。

ステップ2：サーバーが自身の公開URLにアクセスできるかどうかを確認する

一部のセットアップチェックでは、ownCloudサーバーから設定済みのパブリックアドレスにリクエストが送信されます。ノートパソコンからだけでなく、そのサーバーからも基本的なDNSおよびHTTPSチェックを実行してください。

getent hosts cloud.example.com
curl -I https://cloud.example.com/status.php

ホスト名はサーバーから到達可能なアドレスに解決され、HTTPSリクエストは証明書名、信頼チェーン、または接続エラーなしで完了する必要があります。DNSがNATリフレクションをサポートしないファイアウォール（ヘアピンNATとも呼ばれます）を経由してサーバーを指している場合、外部クライアントは動作するものの、内部の自己チェックが失敗する可能性があります。スプリットDNS、リバースプロキシへの内部ルート、またはプロバイダ側のネットワーク調整が適切な場合があります。ネットワーク設計に最も適した最小限の変更を行ってください。

信頼済みドメインエントリは、ownCloud への受信リクエストを許可するホストリストです。ドキュメントに記載されている設定手順に従って、ユーザーが実際に使用するホスト名のみを追加してください。推測で任意の内部アドレスを追加しないでください。このoverwrite.cli.url設定は、一部の構成でコマンドライン/バックグラウンドコンテキストで使用される URL を制御するものであり、DNS、ルーティング、または TLS の修正の代わりとなるものではありません。いずれかの設定を変更する前に、警告の内容を実際に確認してください。

ステップ3：Apacheのリライト設定とディレクトリ設定を確認する

Apache インストールの場合、ownCloud の手動設定ガイドではmod_rewrite、AllowOverride All同梱の を使用する際に ownCloud ディレクトリに対して.htaccess、および Apache 独自の DAV モジュールがアプリケーション ルートを乗っ取らないようにする DAV 関連の Apache 設定を に指定するよう求めています。カスタマイズされたサイトにサンプル全体を貼り付けるのではなく、仮想ホストとディレクトリ ブロックを公式ガイドと比較してください。

DebianまたはUbuntuでは、ロードされているリライトモジュールとApacheの設定構文を確認してください。

sudo apachectl -M | grep rewrite
sudo apachectl -t

リライトがない場合は、 を使用して有効にしてからsudo a2enmod rewrite、構成を再度検証し、構文チェックに合格した後にのみ Apache をリロードしてください。<Directory>パスが実際の ownCloud の Web ルートと一致していること、および構成の上位でオーバーライドが無効になっていないことを確認してください。ownCloud が生成した を.htaccess一般的なリライト レシピで手動で置き換えることは避けてください。カスタム ルールは、アプリケーションのルートを壊したり、アップグレード中に失われたりする可能性があります。

ステップ4：リバースプロキシ、WAFルール、認証ヘッダーを確認する

エンドポイントがWebサーバーに直接アクセスした場合は正常に動作するのに、公開URL経由でアクセスすると失敗する場合は、リバースプロキシまたはロードバランサーを調べてください。完全な/remote.php/dav/パスが保持され、期待されるホスト情報とHTTPS情報が転送され、必要に応じて、、、などのWebDAVメソッドが許可されていることを確認してくださいPROPFIND。インストールプレフィックスを削除したり、DAVリクエストを別のバックエンドに送信したりするプロキシは、ファイル操作が失敗しているにもかかわらず、Web UIが正常に見える場合がありますOPTIONS。PUTMOVE

リクエストが失敗した時点で、プロキシ、Apache/Nginx、ownCloud のログを確認してください。Web アプリケーション ファイアウォールまたは ModSecurity ルールによって、メソッドまたはリクエスト ボディが拒否される場合があります。正確なルール ID を特定し、影響を受ける ownCloud ルートまたはリクエストに対して限定的な例外を作成してから、再テストしてください。警告を解消するためだけに WAF をグローバルに無効にしないでください。FastCGI/PHP ハンドラーの背後でのみ DAV 認証が失敗する場合は、認証ヘッダーが PHP に渡されていることを確認してください。ownCloud の設定に関する注意事項に、この種の問題が記載されています。

ステップ5：TLSとリダイレクトを検証する

WebDAVクライアントは、ブラウザと同様に有効なHTTPSに依存しています。証明書がホスト名に対して有効であり、必要な中間証明書が含まれており、ownCloudの自己チェックを実行するサーバー環境によって信頼されていることを確認してください。ブラウザは、cURLやPHPが報告する証明書の問題を隠蔽したり、個別に信頼したりする場合があります。解決策として証明書の検証を無効にしないでください。

リダイレクトループ、予期しないHTTPからHTTPSへのリダイレクト、またはDAVルートからログインページや一般的なホームページへのリダイレクトがないか確認してください。ブラウザのベースURLへのリダイレクトは正常な場合もありますが、DAVリクエストは最終的にメソッドとAuthorizationヘッダーを保持したままアプリケーションエンドポイントに到達するはずです。プロキシがTLSを終端する場合は、ownCloudがプロキシのドキュメントに記載されている構成に従って、正しい転送プロトコルとホストを受信して​​いることを確認してください。

両側から修正内容を確認してください。

対象となる変更を行うたびに、複数のレイヤーを一度に変更するのではなく、同じチェックを繰り返してください。

• クライアントから、文書化されたDAV URLに対して認証を行い、応答が期待されるWebDAV応答（通常は207 Multi-StatusPROPFINDの場合）であることを確認します。
• ownCloudホストから、パブリックホスト名が解決され、TLS検証エラーなしにHTTPSがインスタンスに到達することを確認してください。
• ownCloudの管理画面の概要を再度確認し、ログを調べて、新しいDAV、プロキシ、または認証エラーがないか確認してください。
• ウェブインターフェースまたはサポートされている同期クライアントで、小さなファイルのアップロード、名前変更、ダウンロードをテストしてください。

クライアントからのリクエストは正常に動作するのに警告が残る場合は、サーバー自身のDNS、ルーティング、証明書の信頼性、および設定されている公開URLを確認してください。自己チェックとクライアントの両方が失敗する場合は、まずエンドポイントパス、書き換えルール、プロキシルーティング、リクエストメソッド、および認証転送を確認してください。サーバーがホスティングプロバイダによって管理されている場合は、タイムスタンプ、匿名化されたHTTPステータス、リクエストされたパス、および一致するログエントリをサポートに送信してください。パスワードや機密情報を含む設定は送信しないでください。

バージョン固有の指示については、ownCloud Server 10.15 Apache インストールガイド、ownCloud Classic WebDAV アクセスに関するドキュメント、およびWebDAV 認証に関する ownCloud 構成ノートと、ご使用の環境を比較してください。インストールされているリリースとデプロイメントの種類に応じたマニュアルに従ってください。