Przywróć synchronizację ownCloud WebDAV, znajdując uszkodzoną trasę

Napraw ostrzeżenie „Interfejs WebDAV wydaje się być uszkodzony”, upewniając się, że punkt końcowy DAV ownCloud jest osiągalny i że serwer WWW przekazuje żądania WebDAV, łącznie z metodą PROPFIND, do aplikacji PHP ownCloud. Prawidłowa zmiana zależy od tego, czy publiczny adres URL obsługuje Apache, Nginx, czy odwrotny serwer proxy; przetestuj punkt końcowy przed edycją konfiguracji, aby naprawić wadliwą warstwę.

Dowiedz się, co tak naprawdę testuje ostrzeżenie

Kontroler administratora ownCloud Classic zgłasza to ostrzeżenie, gdy kontrola synchronizacji plików nie może użyć interfejsu WebDAV. W wielu przypadkach jest to problem z serwerem WWW lub ścieżką żądania, a nie dowód uszkodzenia plików lub bazy danych. Oficjalny dokument informacyjny dotyczący ostrzeżeń ownCloud Server 11 opisuje je oddzielnie od kontroli wykrywania usług /.well-known/caldav./.well-known/carddav

Użyj punktu końcowego DAV zgodnego z publiczną ścieżką instalacji. W katalogu głównym domeny punkt końcowy to zazwyczaj https://cloud.example.com/remote.php/dav; jeśli instalujesz go w podkatalogu, uwzględnij go, na przykład https://cloud.example.com/owncloud/remote.php/dav. W przypadku ownCloud Classic 10.16 dokumentuje również adres URL zgodności /remote.php/webdavdla niektórych połączeń z pulpitem i menedżerem plików. Nie traktuj starszego adresu URL klienta i nowszego punktu końcowego DAV zamiennie w każdej konfiguracji.

Wyślij uwierzytelnione PROPFINDżądanie z zerową głębokością. W tym poleceniu zastąp przykładowy host/ścieżkę i nazwę użytkownika. Curl poprosi o podanie hasła, ponieważ do -u:

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

Pomyślna odpowiedź WebDAV to zazwyczaj 207 Multi-Status… Interpretuj inne odpowiedzi jako wskazówki: 301lub 302wskazuje na problem z przekierowaniem lub kanonicznym adresem URL; 401oznacza, że ​​uwierzytelnienie nie zostało zaakceptowane; 404często oznacza, że ​​ścieżka lub przepisanie PHP nie dotarło do ownCloud; i 405lub 501sugeruje, że serwer, serwer proxy lub warstwa zabezpieczeń odrzuciła metodę DAV. Otwarcie adresu URL ze stroną logowania w przeglądarce nie dowodzi, że to PROPFINDdziała.

Wybierz poprawkę według układu serwera WWW

Apache: zachowaj aktywne reguły przepisywania ownCloud

W przypadku standardowej instalacji Apache należy najpierw sprawdzić, czy plik dostarczony przez ownCloud .htaccessjest obecny i czy Apache zezwala na dyrektywy przepisywania w katalogu instalacyjnym. Instalator i proces aktualizacji ownCloud utrzymują te reguły. Jeśli AllowOverride NoneApache nie może ich odczytać, należy zezwolić na wymagane nadpisania dla katalogu ownCloud lub przenieść równoważne reguły do ​​konfiguracji hosta wirtualnego. Pierwsza opcja jest łatwiejsza w utrzymaniu w przypadku typowej pojedynczej witryny ownCloud; centralne reguły hosta wirtualnego mogą być preferowane, gdy polityka wymaga konfiguracji poza katalogami aplikacji.

Nie wklejaj ogólnego bloku przepisywania na działającą konfigurację. Upewnij się, że mod_rewritejest włączona, witryna wskazuje na prawidłowy katalog główny dokumentu ownCloud i żąda /remote.php/davdostępu do procedury obsługi PHP. Po zmianie konfiguracji Apache, uruchom test konfiguracji przed jej ponownym załadowaniem. W ownCloud Classic 11 opartym na Dockerze, obraz zarządza osadzoną konfiguracją Apache; użyj obsługiwanych przez obraz mechanizmów konfiguracji i środowiska zamiast edytować wygenerowane pliki w działającym kontenerze. Zapoznaj się z dokumentacją rozwiązywania problemów z ownCloud Server 11 .

Nginx: użyj konfiguracji serwera ownCloud

Nginx nie odczytuje .htaccessplików Apache. Jeśli Nginx obsługuje bezpośrednio ownCloud, należy użyć konfiguracji Nginx odpowiadającej wersji ownCloud i ścieżce instalacji, w tym obsłudze lokalizacji PHP i routingu związanego z DAV. Niestandardowa minimalna lokalizacja PHP może obsługiwać interfejs webowy, pozostawiając błąd 404 lub przekazując go do niewłaściwego programu obsługi. Porównaj aktywny blok serwera z dokumentacją instalacyjną ownCloud 10.16/remote.php/dav dostawcy , a następnie przetestuj konfigurację i przeładuj Nginx. Dokładne instrukcje zależą od dystrybucji, gniazda PHP-FPM oraz tego, czy ownCloud znajduje się w katalogu głównym domeny, czy w podkatalogu.

Odwrotny serwer proxy: zachowaj ścieżkę, metodę i publiczny adres URL

Jeśli serwer proxy kończy protokół HTTPS lub kieruje podścieżkę, taką jak /cloud, sprawdź, czy przekazuje całą ścieżkę DAV do zaplecza i zezwala na metody WebDAV, takie jak PROPFIND, PUT, MOVEi DELETE. Serwer proxy lub zapora aplikacji webowej może zablokować metodę nawet wtedy, gdy punkt końcowy PHP jest poprawny. Porównaj żądanie wysłane przez publiczny adres URL z żądaniem wysłanym bezpośrednio do zaplecza z zaufanej sieci; jeśli dostęp bezpośredni zwróci błąd 207, ale żądanie publiczne zakończy się niepowodzeniem, skup się na ścieżce proxy, filtrowaniu metod, przekierowaniach i nagłówkach autoryzacji.

Ustaw w OwnCloud tylko trusted_proxiesrzeczywiste adresy proxy. Jeśli automatyczne wykrywanie adresu URL się nie powiedzie, ustawienia overwritehost, overwriteprotocol, i overwritewebrootmogą opisywać publiczny adres URL, ale nie naprawiają zablokowanej metody DAV ani brakującej trasy PHP. Nieprawidłowe zaufanie do proxy może umożliwić podszywanie się pod nagłówki adresów klientów. Skorzystaj z oficjalnych wskazówek dotyczących konfiguracji odwrotnego proxy dla swojej topologii.

Oddziel wykrywanie DAV od dostępu do plików

Adresy URL /.well-known/caldavi /.well-known/carddavpomagają klientom kalendarza i kontaktów w wykrywaniu punktów końcowych usługi. Powinny one kierować ruch do punktu końcowego DAV ownCloud, ale w przypadku awarii generowane jest oddzielne ostrzeżenie dotyczące niedziałającego sprawdzania WebDAV synchronizacji plików. Naprawa tylko tych przekierowań wykrywania może nie usunąć ostrzeżenia synchronizacji. W przypadku serwera Apache, reguły wbudowane w ownCloud mogą obsługiwać wykrywanie po włączeniu; wdrożenia Nginx i podkatalogów wymagają odpowiedniej konfiguracji serwera. Sprawdź każdy adres URL i jego cel przekierowania niezależnie, postępując zgodnie z oficjalnymi wytycznymi dotyczącymi ostrzeżeń ownCloud .

Sprawdź naprawę

Powtórz test uwierzytelnienia PROPFINDdla publicznego adresu URL DAV i potwierdź, że zwraca 207 Multi-Status. Następnie odśwież stronę administracyjną ownCloud i przeprowadź krótki test synchronizacji z klientem stacjonarnym. Jeśli żądanie nadal się nie powiedzie, porównaj status HTTP i znacznik czasu z logami serwera WWW, proxy, PHP i ownCloud. W Dockerze, dokumentacja ownCloud informuje, że logi aplikacji mogą znajdować się w zamontowanym katalogu logów, podczas gdy logi Apache i PHP są wysyłane do wyjścia kontenera; docker compose logs owncloudmoże to pomóc w zlokalizowaniu tych błędów.

Aktualne instrukcje ownCloud obejmują zarówno Classic 11.0, jak i 10.16, a sposób instalacji różni się w zależności od wersji; dokumentacja Classic 11 określa Dockera jako obsługiwaną metodę instalacji. Należy korzystać z instrukcji dla wdrożonej wersji i unikać bezmyślnego stosowania starych fragmentów kodu Apache lub Nginx w nowszej konfiguracji kontenera lub serwera proxy.