Napraw błąd „Interfejs WebDAV jest uszkodzony” w ownCloud

Jeśli ownCloud uruchamia się w przeglądarce, ale na stronie administratora pojawia się komunikat „Interfejs WebDAV jest uszkodzony”, przesyłanie plików, synchronizacja pulpitu i aplikacja Pliki również mogą nie działać. Ostrzeżenie jest objawem, a nie diagnozą: punkt końcowy DAV może być niedostępny, niepoprawnie przepisany, zablokowany przez serwer proxy lub regułę bezpieczeństwa albo niedostępny, gdy ownCloud wywołuje swój własny publiczny adres URL.

Niniejszy przewodnik dotyczy instalacji ownCloud Classic Server. ownCloud Infinite Scale ma inną architekturę i model wdrożenia, dlatego nie należy stosować ustawień Classic Server Apache do wdrożenia Infinite Scale. Oficjalne strony podane poniżej dotyczą ownCloud Server 10.15 i 10.16, a także Classic Server 11.0; kontrole korzystają z udokumentowanych tras WebDAV i wymagań Apache, a dokładne ostrzeżenie administratora może się różnić w zależności od wersji.

Uwaga dotycząca ilustracji: Poniższe obrazy interfejsu i terminala to przykłady schematyczne. Nazwy hostów, linie statusu i wyświetlane wartości to symbole zastępcze, a nie przechwycona instalacja ani informacja o uruchomieniu testu.

Co oznacza ostrzeżenie WebDAV?

WebDAV to oparty na protokole HTTP interfejs, którego ownCloud używa do wyświetlania listy plików i zarządzania nimi dla klientów synchronizacji oraz do powiązanych operacji na plikach. Logowanie w przeglądarce potwierdza jedynie odpowiedź interfejsu internetowego. Nie potwierdza ono, że żądanie WebDAV dociera do ownCloud z nienaruszonym ścieżką, metodą, nagłówkami uwierzytelniania i połączeniem HTTPS.

Zacznij od ustalenia, czy awaria jest zewnętrzna, czy dotyczy tylko autotestu ownCloud. Błąd klienta synchronizacji i nieudane uwierzytelnione żądanie WebDAV wskazują na trasę DAV lub uwierzytelnianie. Jeśli klienci działają, ale ostrzeżenie administratora nadal się wyświetla, sprawdź, czy sam serwer może rozwiązać i dotrzeć do publicznej nazwy hosta, w tym do certyfikatu TLS.

Krok 1: Zapisz dokładny adres URL i przetestuj bezpośrednio WebDAV

Użyj tej samej nazwy hosta i ścieżki instalacji, które użytkownicy wpisują w przeglądarce. W przypadku instalacji w domenie głównej, bieżąca ścieżka DAV serwera Classic Server zazwyczaj wygląda następująco:

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

Jeśli ownCloud jest zainstalowany w ścieżce, uwzględnij tę ścieżkę przed /remote.php, na przykład https://example.com/owncloud/remote.php/dav/files/USERNAME/. Użyj własnej nazwy konta i adresu URL. Nie testuj wymyślonej nazwy hosta ani nie zakładaj, że każda instalacja korzysta z tego samego podkatalogu.

Z komputera klienckiego wyślij uwierzytelnione żądanie PROPFIND. W cURL, zamiast umieszczać je w poleceniu, wystarczy przekazać nazwę użytkownika i podać hasło:

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

Prawidłowa, uwierzytelniona odpowiedź WebDAV zazwyczaj korzysta z protokołu HTTP 207 Multi-Status. Znak „A” 401może po prostu oznaczać, że dane uwierzytelniające nie zostały zaakceptowane; „A” 404często wskazuje na nieprawidłową trasę lub przepisanie ścieżki proxy; „A” 403sugeruje regułę dostępu, WAF lub politykę serwera; a „L” 301lub 302„L” może wskazywać na przekierowanie, którego klient lub autotest nie wykonuje zgodnie z oczekiwaniami. Przed zmianą konfiguracji należy przeczytać nagłówki odpowiedzi i logi serwera. Przed udostępnieniem wyników polecenia należy usunąć nazwy użytkowników, pliki cookie, tokeny i publiczne adresy IP.

Krok 2: Sprawdź, czy serwer może dotrzeć do własnego publicznego adresu URL

Niektóre kontrole konfiguracji wysyłają żądanie z serwera ownCloud z powrotem na jego skonfigurowany adres publiczny. Przeprowadź podstawowe kontrole DNS i HTTPS z tego serwera, nie tylko z laptopa:

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

Nazwa hosta powinna odpowiadać adresowi dostępnemu z serwera, a żądanie HTTPS powinno zostać zrealizowane bez błędu nazwy certyfikatu, łańcucha zaufania ani połączenia. Jeśli DNS skieruje serwer z powrotem przez zaporę sieciową, która nie obsługuje odbicia NAT (tzw. hairpin NAT), zewnętrzny klient może działać, podczas gdy wewnętrzne autotestowanie zakończy się niepowodzeniem. Odpowiednie może być rozdzielenie DNS, wewnętrzna trasa do odwrotnego serwera proxy lub modyfikacja sieci po stronie dostawcy; wprowadź najwęższą zmianę, która odpowiada projektowi Twojej sieci.

Wpis zaufanej domeny to lista dozwolonych hostów dla przychodzących żądań ownCloud. Dodawaj tylko nazwy hostów, których użytkownicy faktycznie używają, postępując zgodnie z udokumentowaną procedurą konfiguracji. Nie dodawaj dowolnych adresów wewnętrznych na zasadzie zgadywania. To overwrite.cli.urlustawienie kontroluje adres URL używany przez wiersz poleceń/konteksty w tle w niektórych konfiguracjach; nie zastępuje ono naprawy DNS, routingu ani TLS. Przed zmianą któregokolwiek z ustawień sprawdź, co faktycznie oznacza ostrzeżenie.

Krok 3: Sprawdź ustawienia przepisywania i katalogów Apache

W przypadku instalacji Apache, ręczny przewodnik konfiguracji ownCloud zaleca użycie mod_rewrite, AllowOverride Alldla katalogu ownCloud, gdy korzysta się z dostarczonego .htaccess, oraz ustawienie Apache związane z DAV, które zapobiega przejęciu trasy aplikacji przez własny moduł DAV Apache. Porównaj swój blok wirtualnego hosta i katalogu z oficjalnym przewodnikiem, zamiast wklejać cały przykład na dostosowaną witrynę.

W systemie Debian lub Ubuntu sprawdź załadowany moduł przepisywania i składnię konfiguracji Apache:

sudo apachectl -M | grep rewrite
sudo apachectl -t

Jeśli przepisywanie jest niedostępne, włącz je za pomocą sudo a2enmod rewrite, a następnie ponownie sprawdź konfigurację i przeładuj Apache dopiero po pomyślnym sprawdzeniu składni. Upewnij się, że ścieżka <Directory>jest zgodna z rzeczywistym katalogiem głównym ownCloud i że nadpisywanie nie jest wyłączone na wyższych poziomach konfiguracji. Unikaj ręcznego zastępowania wygenerowanych reguł ownCloud .htaccessogólną recepturą przepisywania; niestandardowe reguły mogą zaburzyć trasy aplikacji lub zostać utracone podczas aktualizacji.

Krok 4: Sprawdź serwery proxy odwrotne, reguły WAF i nagłówki uwierzytelniania

Jeśli punkt końcowy działa po wywołaniu bezpośrednio z serwera WWW, ale zawodzi poprzez publiczny adres URL, należy sprawdzić serwer proxy odwrotny lub moduł równoważenia obciążenia. Upewnij się, że zachowuje on pełną /remote.php/dav/ścieżkę, przekazuje oczekiwane informacje o hoście i protokole HTTPS oraz zezwala na metody WebDAV, takie jak PROPFIND, OPTIONS, PUTi , MOVEtam gdzie jest to wymagane. Serwer proxy, który usuwa prefiks instalacji lub wysyła żądania DAV do innego zaplecza, może sprawić, że interfejs użytkownika w przeglądarce będzie wyglądał na sprawny, podczas gdy operacje na plikach zawiodą.

Przejrzyj logi proxy, Apache/Nginx i ownCloud w momencie nieudanego żądania. Zapora sieciowa aplikacji internetowej lub reguła ModSecurity może odrzucić metodę lub treść żądania. Zidentyfikuj dokładny identyfikator reguły i utwórz wąski wyjątek dla danej trasy lub żądania ownCloud, a następnie przetestuj ponownie. Nie wyłączaj globalnie WAF tylko po to, aby usunąć ostrzeżenie. Jeśli uwierzytelnianie DAV nie powiedzie się tylko za obsługą FastCGI/PHP, sprawdź, czy nagłówek autoryzacji jest przekazywany do PHP; informacje o tym typie problemu znajdują się w uwagach dotyczących konfiguracji ownCloud.

Krok 5: Sprawdź poprawność protokołu TLS i przekierowań

Klienci WebDAV, podobnie jak przeglądarki, polegają na prawidłowym protokole HTTPS. Sprawdź, czy certyfikat jest prawidłowy dla nazwy hosta, zawiera wymagane certyfikaty pośrednie i jest zaufany w środowisku serwera, na którym działa autotest ownCloud. Przeglądarka może ukryć lub oddzielnie zaufać problemowi z certyfikatem, który zgłasza cURL lub PHP. Nie wyłączaj weryfikacji certyfikatów jako rozwiązania.

Sprawdź pętle przekierowań, nieoczekiwane przekierowania HTTP-HTTPS lub przekierowanie ze ścieżki DAV na stronę logowania lub ogólną stronę główną. Przekierowanie może być normalne dla podstawowego adresu URL przeglądarki, ale żądanie DAV powinno ostatecznie dotrzeć do punktu końcowego aplikacji z zachowaną metodą i nagłówkiem autoryzacji. Jeśli serwer proxy zakończy TLS, upewnij się, że ownCloud otrzymuje prawidłowy przekazywany protokół i hosta zgodnie z udokumentowaną konfiguracją serwera proxy.

Sprawdź poprawność z obu stron

Po każdej planowanej zmianie powtarzaj te same kontrole, zamiast zmieniać kilka warstw naraz:

• Po stronie klienta należy uwierzytelnić się do udokumentowanego adresu URL DAV i potwierdzić, że odpowiedź jest oczekiwaną odpowiedzią WebDAV, zwykle 207 Multi-Statusw przypadku protokołu PROPFIND.
• Na hoście ownCloud sprawdź, czy publiczna nazwa hosta została rozwiązana i protokół HTTPS dotarł do instancji bez błędu walidacji TLS.
• Sprawdź ponownie podgląd administratora ownCloud i przejrzyj logi pod kątem nowych błędów DAV, proxy lub uwierzytelniania.
• Przetestuj przesyłanie, zmianę nazwy i pobieranie małych plików w interfejsie internetowym lub obsługiwanym kliencie synchronizacji.

Jeśli żądania klienta działają, ale ostrzeżenie nadal występuje, skup się na własnym systemie DNS serwera, routingu, zaufaniu certyfikatów i skonfigurowanym publicznym adresie URL. Jeśli zarówno autotest, jak i klienci zawiodą, skup się najpierw na ścieżce punktu końcowego, regułach przepisywania, routingu proxy, metodach żądań i przekazywaniu uwierzytelniania. Jeśli serwer jest zarządzany przez dostawcę hostingu, wyślij do działu pomocy technicznej znacznik czasu, zdezynfekowany status HTTP, żądaną ścieżkę i pasujący wpis w dzienniku; nie wysyłaj haseł ani konfiguracji zawierającej poufne informacje.

W przypadku dyrektyw specyficznych dla danej wersji porównaj swoje wdrożenie z podręcznikiem instalacji serwera ownCloud 10.15 Apache , dokumentacją dostępu ownCloud Classic WebDAV oraz notatkami konfiguracyjnymi ownCloud dotyczącymi uwierzytelniania WebDAV . Postępuj zgodnie z instrukcją dla zainstalowanej wersji i typu wdrożenia.