Remediați eroarea „Interfața WebDAV este defectă” în ownCloud

Dacă ownCloud se încarcă într-un browser, dar pagina sa de administrare afișează mesajul „Interfața WebDAV este defectă”, încărcarea fișierelor, sincronizarea desktopului și aplicația Fișiere pot, de asemenea, să eșueze. Avertismentul este un simptom, nu un diagnostic: punctul final DAV poate fi inaccesibil, rescris incorect, blocat de un proxy sau o regulă de securitate sau inaccesibil atunci când ownCloud apelează propriul URL public.

Acest ghid se aplică instalărilor de ownCloud Classic Server. ownCloud Infinite Scale are o arhitectură și un model de implementare diferite, așadar nu aplicați setările Apache pentru Classic Server unei implementări Infinite Scale. Paginile oficiale la care se face trimitere mai jos acoperă ownCloud Server 10.15 și 10.16, plus Classic Server 11.0; verificările utilizează rute WebDAV documentate și cerințe Apache, în timp ce avertismentul exact pentru administratori poate varia în funcție de versiune.

Notă ilustrativă: Imaginile de interfață și terminal de mai jos sunt exemple schematice. Numele de gazdă, liniile de stare și valorile afișate sunt substituenți, nu o instalare capturată sau o afirmație că a fost executat un test.

Ce înseamnă avertismentul WebDAV?

WebDAV este interfața bazată pe HTTP utilizată de ownCloud pentru a lista și gestiona fișierele pentru clienții de sincronizare și operațiunile aferente cu fișierele. O conectare în browser confirmă doar că interfața web răspunde. Nu confirmă că o solicitare WebDAV ajunge la ownCloud cu calea, metoda, anteturile de autentificare și conexiunea HTTPS intacte.

Începeți prin a identifica dacă eroarea este externă sau doar în autoverificarea ownCloud. O eroare a clientului de sincronizare și o solicitare WebDAV autentificată eșuată indică ruta sau autentificarea DAV. Dacă clienții funcționează, dar avertismentul de administrator persistă, testați dacă serverul în sine poate rezolva problema și poate ajunge la numele public de gazdă, inclusiv certificatul său TLS.

Pasul 1: Înregistrați adresa URL exactă și testați direct WebDAV

Folosiți același nume de gazdă și aceeași cale de instalare pe care utilizatorii le introduc într-un browser. Pentru o instalare pe domeniul rădăcină, ruta DAV curentă pentru Classic Server urmează de obicei această formă:

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

Dacă ownCloud este instalat sub o anumită cale, includeți acea cale înainte de /remote.php, de exemplu https://example.com/owncloud/remote.php/dav/files/USERNAME/. Folosiți propriul nume de cont și adresa URL. Nu testați un nume de gazdă inventat și nu presupuneți că fiecare instalare folosește același subdirector.

De pe o mașină client, trimiteți o cerere PROPFIND autentificată. Cu cURL, transmiterea doar a numelui de utilizator solicită parola în loc să o plaseze în comandă:

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

Un răspuns WebDAV autentificat valid utilizează de obicei HTTP 207 Multi-Status. Un 401poate însemna pur și simplu că acreditările nu au fost acceptate; un 404indică adesea o rută greșită sau o rescriere a căii proxy; un 403sugerează o regulă de acces, un WAF sau o politică de server; iar un 301sau 302poate indica o redirecționare pe care clientul sau autoverificarea nu o urmează conform așteptărilor. Citiți anteturile de răspuns și jurnalele serverului înainte de a modifica configurația. Redactați numele de utilizator, cookie-urile, token-urile și IP-urile publice înainte de a partaja ieșirea comenzii.

Pasul 2: Verificați dacă serverul poate accesa propriul URL public

Unele verificări de configurare trimit o solicitare de la serverul ownCloud înapoi la adresa sa publică configurată. Rulați verificări DNS și HTTPS de bază de pe serverul respectiv, nu doar de pe laptop:

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

Numele de gazdă ar trebui să se rezolve la o adresă accesibilă de pe server, iar solicitarea HTTPS ar trebui să se finalizeze fără o eroare de nume de certificat, lanț de încredere sau conexiune. Dacă DNS indică serverul înapoi printr-un firewall care nu acceptă reflexia NAT (numită și NAT hairpin), un client extern poate funcționa în timp ce autoverificarea internă eșuează. DNS-ul divizat, o rută internă către proxy-ul invers sau o ajustare a rețelei la nivelul furnizorului pot fi adecvate; faceți cea mai restrânsă modificare care se potrivește designului rețelei dvs.

O intrare de domeniu de încredere este o listă de gazde permise pentru cererile ownCloud primite. Adăugați doar numele de gazde pe care utilizatorii le folosesc efectiv, urmând procedura de configurare documentată. Nu adăugați adrese interne arbitrare ca o estimare. Setarea overwrite.cli.urlcontrolează adresa URL utilizată de contextele din linia de comandă/fundal în unele configurații; nu înlocuiește remedierea DNS, rutare sau TLS. Confirmați ce spune de fapt avertismentul înainte de a modifica oricare dintre setări.

Pasul 3: Verificați setările de rescriere și directoare Apache

Pentru instalările Apache, ghidul de configurare manuală al ownCloud necesită mod_rewrite, AllowOverride Allpentru directorul ownCloud atunci când se bazează pe fișierul livrat .htaccess, și o setare Apache legată de DAV care evită ca modulul DAV propriu al Apache să preia ruta aplicației. Comparați gazda virtuală și blocul de director cu ghidul oficial, în loc să lipiți un întreg exemplu peste un site personalizat.

Pe Debian sau Ubuntu, verificați modulul de rescriere încărcat și sintaxa de configurare Apache:

sudo apachectl -M | grep rewrite
sudo apachectl -t

Dacă rescrierea lipsește, activați-o cu sudo a2enmod rewrite, apoi validați din nou configurația și reîncărcați Apache numai după ce verificarea sintaxei a trecut. Confirmați că <Directory>ruta se potrivește cu rădăcina web ownCloud reală și că suprascrierile nu sunt dezactivate mai sus în configurație. Evitați înlocuirea manuală a regulilor ownCloud generate .htaccesscu o rețetă generică de rescriere; regulile personalizate pot întrerupe rutele aplicației sau se pot pierde în timpul actualizărilor.

Pasul 4: Verificați proxy-urile inverse, regulile WAF și anteturile de autentificare

Dacă endpoint-ul funcționează atunci când este apelat direct către serverul web, dar eșuează prin URL-ul public, inspectați proxy-ul invers sau echilibratorul de încărcare. Asigurați-vă că păstrează /remote.php/dav/calea completă, redirecționează informațiile așteptate despre gazdă și HTTPS și permite metode WebDAV precum PROPFIND, OPTIONS, PUT, și MOVEacolo unde este necesar. Un proxy care elimină un prefix de instalare sau trimite solicitări DAV către un alt backend poate face ca interfața web să pară sănătoasă în timp ce operațiunile cu fișierele eșuează.

Verificați jurnalele proxy, Apache/Nginx și ownCloud în momentul unei solicitări eșuate. Un firewall de aplicație web sau o regulă ModSecurity pot respinge o metodă sau un corp al solicitării. Identificați ID-ul exact al regulii și creați o excepție restrânsă pentru ruta sau solicitarea ownCloud afectată, apoi retestați. Nu dezactivați WAF global doar pentru a șterge un avertisment. Dacă autentificarea DAV eșuează doar în spatele unui handler FastCGI/PHP, verificați dacă antetul de autorizare este transmis către PHP; notele de configurare ownCloud documentează această clasă de probleme.

Pasul 5: Validați TLS și redirecționările

Clienții WebDAV depind de HTTPS valid, la fel ca browserele. Verificați dacă certificatul este valid pentru numele de gazdă, include certificatele intermediare necesare și este de încredere pentru mediul serverului care rulează autoverificarea ownCloud. Un browser poate ascunde sau poate avea încredere separat într-o problemă de certificat raportată de cURL sau PHP. Nu dezactivați verificarea certificatului ca soluție.

Verificați dacă există bucle de redirecționare, redirecționări HTTP-to-HTTPS neașteptate sau o redirecționare de la ruta DAV către o pagină de conectare sau o pagină principală generică. O redirecționare poate fi normală pentru adresa URL de bază a unui browser, dar solicitarea DAV ar trebui să ajungă în cele din urmă la punctul final al aplicației cu metoda și antetul de autorizare păstrate. Dacă un proxy termină TLS, confirmați că ownCloud primește protocolul și gazda corecte de redirecționare, conform configurației documentate a proxy-ului.

Verificați remedierea din ambele părți

După fiecare modificare specifică, repetați aceleași verificări în loc să modificați mai multe straturi simultan:

• De la un client, autentificați-vă la adresa URL DAV documentată și confirmați că răspunsul este un răspuns WebDAV așteptat, de obicei 207 Multi-Statuspentru PROPFIND.
• De la gazda ownCloud, confirmați că numele public al gazdei este rezolvat și că HTTPS ajunge la instanță fără o eroare de validare TLS.
• Verificați din nou prezentarea generală a administratorului ownCloud și inspectați jurnalele pentru erori noi de DAV, proxy sau autentificare.
• Testați încărcarea, redenumirea și descărcarea unui fișier mic în interfața web sau pe un client de sincronizare acceptat.

Dacă solicitările clientului funcționează, dar avertismentul persistă, concentrați-vă pe DNS-ul propriu al serverului, rutare, încrederea în certificat și URL-ul public configurat. Dacă atât autoverificarea, cât și clienții eșuează, concentrați-vă mai întâi pe calea endpoint-ului, regulile de rescriere, rutarea proxy, metodele de solicitare și redirecționarea autentificării. Când serverul este gestionat de un furnizor de găzduire, trimiteți asistenței marcajul temporal, starea HTTP igienizată, calea solicitată și intrarea de jurnal corespunzătoare; nu trimiteți parole sau configurații care conțin secrete.

Pentru directivele specifice versiunii, comparați implementarea cu ghidul de instalare ownCloud Server 10.15 Apache , documentația de acces ownCloud Classic WebDAV și notele de configurare ownCloud privind autentificarea WebDAV . Urmați manualul pentru versiunea instalată și tipul de implementare.