Восстановление синхронизации ownCloud WebDAV путем поиска поврежденного маршрута.

Устраните предупреждение «Интерфейс WebDAV, похоже, не работает», убедившись, что конечная точка DAV ownCloud доступна и что ваш веб-сервер перенаправляет запросы WebDAV, включая соответствующий метод PROPFIND, в PHP-приложение ownCloud. Правильное изменение зависит от того, какой сервер обрабатывает публичный URL: Apache, Nginx или обратный прокси; протестируйте конечную точку перед редактированием конфигурации, чтобы исправить неисправный слой.

Выясните, что именно проверяет это предупреждение.

Административный инструмент проверки ownCloud Classic выдает это предупреждение, когда проверка синхронизации файлов не может использовать интерфейс WebDAV. Во многих случаях это проблема веб-сервера или пути запроса, а не доказательство повреждения файлов или базы данных. В официальном справочнике предупреждений 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-адрес клиента и новый URL-адрес DAV как взаимозаменяемые в любой конфигурации.

Отправьте аутентифицированный PROPFINDзапрос с нулевой глубиной аутентификации. В этой команде замените примерный host/path и имя пользователя. 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 и процесс обновления поддерживают эти правила. Если AllowOverride Noneэто препятствует чтению Apache, либо разрешите необходимые переопределения для каталога ownCloud, либо переместите эквивалентные правила в конфигурацию виртуального хоста. Первый вариант проще в обслуживании для типичного отдельного сайта ownCloud; централизованные правила виртуального хоста могут быть предпочтительнее, когда политика требует настройки вне каталогов приложений.

Не вставляйте стандартный блок перезаписи поверх работающей конфигурации. Убедитесь, что mod_rewriteон включен, сайт указывает на правильный корневой каталог документов ownCloud и запросы достигают /remote.php/davобработчика PHP. После изменения конфигурации Apache запустите проверку конфигурации перед перезагрузкой. В ownCloud Classic 11 на основе Docker образ управляет встроенной конфигурацией Apache; используйте поддерживаемые образом механизмы конфигурации и среды вместо редактирования сгенерированных файлов внутри работающего контейнера. См. документацию по устранению неполадок ownCloud Server 11 .

Nginx: используйте конфигурацию сервера ownCloud.

Nginx не читает .htaccessфайлы Apache. Если Nginx напрямую обслуживает ownCloud, используйте конфигурацию Nginx, соответствующую вашей версии ownCloud и пути установки, включая обработку расположения PHP и маршрутизацию, связанную с DAV. Нестандартное минимальное расположение PHP может обслуживать веб-интерфейс, оставляя его /remote.php/davс ошибкой 404 или передавая его неправильному обработчику. Сравните ваш активный блок сервера с документацией по установке ownCloud 10.16 от поставщика , затем протестируйте конфигурацию и перезагрузите Nginx. Точные директивы зависят от дистрибутива, сокета PHP-FPM и от того, находится ли ownCloud в корне домена или в подкаталоге.

Обратный прокси: сохранение пути, метода и общедоступного URL-адреса.

Если прокси-сервер завершает HTTPS-запрос или направляет подпуть, например /cloud, , убедитесь, что он перенаправляет весь DAV-путь на бэкэнд и разрешает методы WebDAV, такие как PROPFIND, PUT, MOVE, и DELETE. Прокси-сервер или брандмауэр веб-приложений могут блокировать метод, даже если конечная точка PHP указана правильно. Сравните запрос, отправленный через публичный URL, с запросом, отправленным напрямую на бэкэнд из доверенной сети; если прямой доступ возвращает код 207, а публичный запрос завершается неудачей, сосредоточьтесь на маршруте прокси-сервера, фильтрации методов, перенаправлениях и заголовках авторизации.

Устанавливайте в ownCloud только trusted_proxiesфактические адреса прокси-серверов. Если автоматическое определение URL-адреса не удается, параметры overwritehost, overwriteprotocol, и overwritewebrootмогут описывать публичный URL-адрес, но они не исправляют заблокированный метод DAV или отсутствующий маршрут PHP. Неправильное доверие к прокси-серверу может привести к подделке заголовков client-address. Используйте официальные рекомендации по настройке обратного прокси-сервера для вашей топологии.

Разделяйте обнаружение DAV и доступ к файлам.

URL -адреса /.well-known/caldavи /.well-known/carddavпомогают клиентам календаря и контактов обнаруживать конечные точки сервисов. Они должны перенаправлять на конечную точку DAV ownCloud, но сбой там вызывает отдельное предупреждение, отличное от ошибки проверки синхронизации файлов WebDAV. Исправление только этих перенаправлений обнаружения может не устранить предупреждение о синхронизации. Для Apache правила ownCloud, поставляемые с веб-сервером, могут обрабатывать обнаружение, если они включены; для развертывания Nginx и подкаталогов требуется соответствующая конфигурация сервера. Проверяйте каждый URL-адрес и его целевой адрес перенаправления независимо, следуя официальным рекомендациям ownCloud по предупреждениям .

Проверьте ремонт

Повторите проверку аутентификации PROPFINDпо общедоступному URL-адресу DAV и убедитесь, что она возвращает ошибку 207 Multi-Status. Затем обновите страницу администрирования ownCloud и запустите небольшой тест синхронизации с настольным клиентом. Если запрос по-прежнему завершается неудачей, сравните HTTP-статус и метку времени с логами веб-сервера, прокси, PHP и ownCloud. В документации ownCloud для Docker отмечается, что логи приложений могут находиться в смонтированном каталоге логов, в то время как логи Apache и PHP отправляются в выходной каталог контейнера; docker compose logs owncloudэто может помочь обнаружить эти ошибки.

Текущие руководства ownCloud охватывают как Classic 11.0, так и 10.16, и процесс установки различается в зависимости от версии; в документации Classic 11 в качестве поддерживаемого метода установки указан Docker. Используйте руководство для развернутой версии и избегайте слепого применения старых фрагментов кода Apache или Nginx к более новой конфигурации контейнера или прокси.