壊れたルートを見つけてownCloud WebDAV同期を復元する

「WebDAVインターフェースが壊れているようです」という警告を解決するには、ownCloudのDAVエンドポイントにアクセス可能であること、およびWebサーバーがWebDAVリクエスト（PROPFINDメソッドを含む）をownCloudのPHPアプリケーションに転送していることを確認してください。適切な変更方法は、公開URLをApache、Nginx、またはリバースプロキシのいずれが処理しているかによって異なります。設定を編集する前にエンドポイントをテストして、問題のあるレイヤーを修正してください。

警告が実際に何をテストしているのかを調べてください。

ownCloud Classic の管理者チェッカーは、ファイル同期チェックで WebDAV インターフェイスを使用できない場合にこの警告を報告します。多くの場合、これは Web サーバーまたはリクエスト パスの問題であり、ファイルやデータベースが破損していることを示すものではありません。ownCloud Server 11 の公式警告リファレンスでは、この警告はサービス検出チェック/.well-known/caldavとは別に説明されています。/.well-known/carddav

公開インストールパスに一致する DAV エンドポイントを使用してください。ドメイン ルートでは、エンドポイントは通常 ですhttps://cloud.example.com/remote.php/dav。サブディレクトリにインストールする場合は、たとえば を含めてくださいhttps://cloud.example.com/owncloud/remote.php/dav。ownCloud Classic 10.16 では、一部のデスクトップおよびファイル マネージャー接続の互換性 URL もドキュメント化されています/remote.php/webdav。古いクライアント URL と新しい DAV エンドポイントを、すべての構成で互換性があるものとして扱わないでください。

認証済みPROPFINDリクエストを深さゼロで送信します。このコマンドでは、サンプルホスト/パスとユーザー名を置き換えてください。ユーザー名のみが指定されているため、curl はパスワードの入力を求めます-u。

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

WebDAV の応答が成功した場合、通常は です207 Multi-Status。その他の応答は手がかりとして解釈してください。301または302はリダイレクトまたは正規 URL の問題を示しています。 は401認証が受け入れられなかったことを意味します。404は多くの場合、パスまたは PHP リライトが ownCloud に到達しなかったことを意味します。 または405は、501サーバー、プロキシ、またはセキュリティ レイヤーが DAV メソッドを拒否したことを示唆しています。ブラウザがログイン ページを表示する URL を開いたとしても、 がPROPFIND機能していることを証明するものではありません。

ウェブサーバーのレイアウトによる修正を選択してください

Apache: ownCloudのリライトルールをアクティブに保つ

標準的なApacheインストールの場合、まずownCloudが提供する.htaccessファイルが存在すること、およびApacheがインストールディレクトリ内の書き換えディレクティブを許可していることを確認してください。ownCloudインストーラーとアップグレードプロセスはこれらのルールを管理します。ApacheAllowOverride Noneがこれらのルールを読み取れない場合は、ownCloudディレクトリに必要なオーバーライドを許可するか、同等のルールを仮想ホスト構成に移動してください。一般的な単一のownCloudサイトでは、前者のほうが管理が容易です。ポリシーでアプリケーションディレクトリ外の構成が必要な場合は、中央の仮想ホストルールの方が望ましい場合があります。

動作中の設定の上に汎用的な書き換えブロックを貼り付けないでください。mod_rewrite有効になっていること、サイトが正しいownCloudドキュメントルートを指していること、およびリクエストが/remote.php/davPHPハンドラーに到達できることを確認してください。Apacheの設定を変更した後は、再読み込みする前に設定テストを実行してください。DockerベースのownCloud Classic 11では、イメージが組み込みのApache設定を管理します。実行中のコンテナ内で生成されたファイルを編集するのではなく、イメージでサポートされている設定および環境メカニズムを使用してください。ownCloud Server 11のトラブルシューティングドキュメントを参照してください。

Nginx: ownCloudサーバー構成を使用する

Nginx は Apache ファイルを読み込みません.htaccess。Nginx が ownCloud を直接提供している場合は、php ロケーション処理や DAV 関連のルーティングを含め、ownCloud のバージョンとインストール パスに一致する Nginx 設定を使用してください。カスタムの最小限の PHP ロケーションでは、Web インターフェイスは提供されるものの、/remote.php/dav404 エラーとして表示されたり、誤ったハンドラーに渡されたりする可能性があります。アクティブなサーバー ブロックをベンダーのownCloud 10.16 インストール ドキュメントと比較し、設定をテストして Nginx を再起動してください。正確なディレクティブは、ディストリビューション、PHP-FPM ソケット、ownCloud がドメイン ルートにあるかサブ ディレクトリにあるかによって異なります。

リバースプロキシ：パス、メソッド、および公開URLを保持する

プロキシが HTTPS を終端したり、 などのサブパスをルーティングしたりする場合は/cloud、DAV パス全体をバックエンドに転送し、PROPFIND、PUT、MOVE、などの WebDAV メソッドを許可していることを確認してくださいDELETE。プロキシまたは Web アプリケーション ファイアウォールは、PHP エンドポイントが正しい場合でもメソッドをブロックする可能性があります。パブリック URL 経由で送信されたリクエストと、信頼できるネットワークからバックエンドに直接送信されたリクエストを比較してください。直接アクセスで 207 が返されるのにパブリック リクエストが失敗する場合は、プロキシ ルート、メソッド フィルタリング、リダイレクト、および認証ヘッダーに注目してください。

ownCloud の設定は、trusted_proxies実際のプロキシ アドレスのみにしてください。自動 URL 検出が失敗した場合、、、overwritehostおよびoverwriteprotocolのoverwritewebroot設定で公開 URL を記述できますが、ブロックされた DAV メソッドや欠落した PHP ルートを修復することはできません。プロキシの信頼設定が正しくないと、偽のクライアント アドレス ヘッダーが使用される可能性があります。ご使用のトポロジーに合わせて、公式のリバース プロキシ設定ガイドを参照してください。

DAV検出とファイルアクセスは分離しておく

これら/.well-known/caldavの/.well-known/carddavURL は、カレンダーおよび連絡先クライアントがサービスエンドポイントを検出するのに役立ちます。これらの URL は ownCloud の DAV エンドポイントにルーティングされるはずですが、そこでエラーが発生すると、ファイル同期 WebDAV チェックの不具合とは別の警告が表示されます。検出リダイレクトのみを修正しても、同期警告が解消されない場合があります。Apache の場合、ownCloud に同梱されているルールが有効になっていると検出を処理できます。Nginx およびサブディレクトリのデプロイメントでは、サーバー構成を一致させる必要があります。ownCloudの公式警告ガイダンスに従って、各 URL とそのリダイレクト先を個別に確認してください。

修理を確認する

PROPFIND公開 DAV URL に対して認証テストを再度実行し、 が返されることを確認します207 Multi-Status。次に、ownCloud 管理ページを更新し、デスクトップクライアントで簡単な同期テストを実行します。リクエストがまだ失敗する場合は、HTTP ステータスとタイムスタンプを、Web サーバー、プロキシ、PHP、および ownCloud のログと比較します。Docker では、ownCloud のドキュメントに、アプリケーション ログはマウントされたログ ディレクトリにある可能性があり、Apache と PHP のログはコンテナ出力に送信されると記載されています。 は、docker compose logs owncloudこれらのエラーの特定に役立ちます。

ownCloudの現在のマニュアルはClassic 11.0と10.16の両方に対応しており、インストール手順はリリースによって異なります。Classic 11のドキュメントでは、サポートされているインストール方法としてDockerが明記されています。デプロイ済みのバージョンのマニュアルを参照し、古いApacheやNginxのコードスニペットを新しいコンテナやプロキシ設定に安易に適用しないようにしてください。