Restaurați sincronizarea ownCloud WebDAV prin găsirea rutei defecte

Remediați avertismentul „Interfața WebDAV pare a fi defectă” confirmând că endpoint-ul DAV al ownCloud este accesibil și că serverul web redirecționează cererile WebDAV, inclusiv PROPFINDmetoda, către aplicația PHP a ownCloud. Modificarea corectă depinde de dacă Apache, Nginx sau un proxy invers gestionează URL-ul public; testați endpoint-ul înainte de a edita configurația, astfel încât să remediați stratul defect.

Află ce testează de fapt avertismentul

Verificatorul de administrare al ownCloud Classic raportează acest avertisment atunci când verificarea sincronizării fișierelor nu poate utiliza interfața WebDAV. În multe cazuri, este o problemă a serverului web sau a căii de solicitare, nu o dovadă că fișierele sau baza de date sunt deteriorate. Referința oficială de avertisment ownCloud Server 11 o descrie separat de /.well-known/caldavverificarea /.well-known/carddavservice-discovery.

Folosește punctul final DAV care corespunde căii tale publice de instalare. La rădăcina domeniului, punctul final este de obicei https://cloud.example.com/remote.php/dav; când este instalat într-un subdirector, include-l, de exemplu https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 documentează, de asemenea, adresa URL de compatibilitate /remote.php/webdavpentru unele conexiuni desktop și manager de fișiere. Nu trata adresa URL client mai veche și punctul final DAV mai nou ca fiind interschimbabile în fiecare configurație.

Trimiteți o PROPFINDcerere autentificată cu adâncimea zero. În această comandă, înlocuiți exemplul de gazdă/cale și nume de utilizator. Curl solicită parola deoarece doar numele de utilizator este furnizat către -u:

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

Un răspuns WebDAV reușit este de obicei 207 Multi-Status. Interpretați alte răspunsuri ca indicii: 301sau 302indică o problemă de redirecționare sau de URL canonic; 401înseamnă că autentificarea nu a fost acceptată; 404adesea înseamnă că calea sau rescrierea PHP nu a ajuns la ownCloud; și 405sau 501sugerează că un server, proxy sau strat de securitate a respins metoda DAV. Un browser care deschide URL-ul cu o pagină de conectare nu dovedește că PROPFINDfuncționează.

Alegeți soluția în funcție de aspectul serverului web

Apache: mențineți active regulile de rescriere ale ownCloud

Pentru o instalare standard Apache, verificați mai întâi dacă fișierul furnizat de ownCloud .htaccesseste prezent și dacă Apache permite directivele sale de rescriere în directorul de instalare. Procesul de instalare și actualizare ownCloud menține aceste reguli. Dacă AllowOverride Noneîmpiedică Apache să le citească, fie permiteți suprascrierile necesare pentru directorul ownCloud, fie mutați regulile echivalente în configurația gazdă virtuală. Prima opțiune este mai ușor de întreținut pentru un singur site ownCloud tipic; regulile centrale pentru gazda virtuală pot fi preferabile atunci când politica necesită configurarea în afara directoarelor aplicațiilor.

Nu lipiți un bloc generic de rescriere peste o configurație funcțională. Confirmați că mod_rewriteeste activat, că site-ul indică spre rădăcina corectă a documentului ownCloud și că solicită /remote.php/davaccesul la handler-ul PHP. După modificarea configurației Apache, rulați testul de configurare înainte de a o reîncărca. Pe ownCloud Classic 11 bazat pe Docker, imaginea își gestionează configurația Apache încorporată; utilizați configurația și mecanismele de mediu acceptate de imagine în loc să editați fișierele generate într-un container care rulează. Consultați documentația de depanare ownCloud Server 11 .

Nginx: folosește configurația serverului ownCloud

Nginx nu citește .htaccessfișierele Apache. Dacă Nginx deservește direct ownCloud, folosește configurația Nginx care se potrivește cu versiunea ta de ownCloud și calea de instalare, inclusiv gestionarea locației PHP și rutarea legată de DAV. O locație PHP minimă personalizată poate deservi interfața web, ieșind ca o eroare 404 sau transmițând-o către handler-ul greșit. Compară blocul serverului activ cu documentația de instalare ownCloud 10.16/remote.php/dav a furnizorului , apoi testează configurația și reîncarcă Nginx. Directivele exacte depind de distribuție, socket-ul PHP-FPM și dacă ownCloud se află la rădăcina domeniului sau într-un subdirector.

Proxy invers: păstrează calea, metoda și adresa URL publică

Dacă un proxy termină HTTPS sau direcționează o subcale, cum ar fi /cloud, verificați dacă redirecționează întreaga cale DAV către backend și permite metode WebDAV precum PROPFIND, PUT, MOVEși DELETE. Un proxy sau un firewall de aplicație web poate bloca o metodă chiar și atunci când endpoint-ul PHP este corect. Comparați o cerere trimisă prin URL-ul public cu una trimisă direct către backend dintr-o rețea de încredere; dacă accesul direct returnează 207, dar cererea publică eșuează, concentrați-vă pe ruta proxy, filtrarea metodelor, redirecționări și anteturile de autorizare.

Setați adresele ownCloud doar trusted_proxiesla adrese proxy reale. Dacă detectarea automată a URL-ului eșuează, setările overwritehost, overwriteprotocol, și overwritewebrootpot descrie URL-ul public, dar nu repară o metodă DAV blocată sau o rută PHP lipsă. O încredere incorectă în proxy poate permite antete de adresă client falsificate. Utilizați ghidul oficial de configurare a proxy-ului invers pentru topologia dvs.

Păstrați descoperirea DAV separată de accesul la fișiere

Adresele URL /.well-known/caldavși /.well-known/carddavajută clienții din calendar și contacte să descopere punctele finale ale serviciilor. Acestea ar trebui să direcționeze către punctul final DAV al ownCloud, dar o eroare apare într-un avertisment separat de la o verificare WebDAV de sincronizare a fișierelor întreruptă. Remedierea doar a acelor redirecționări de descoperire poate să nu șteargă avertismentul de sincronizare. Pentru Apache, regulile livrate de ownCloud pot gestiona descoperirea atunci când sunt activate; implementările Nginx și subdirectoare necesită o configurație de server corespondentă. Verificați fiecare adresă URL și ținta sa de redirecționare independent, urmând îndrumările oficiale de avertizare ownCloud .

Verificați reparația

Repetați PROPFINDtestul de autentificare pentru adresa URL publică DAV și confirmați că returnează 207 Multi-Status. Apoi, reîmprospătați pagina de administrare ownCloud și rulați un mic test de sincronizare cu clientul desktop. Dacă solicitarea eșuează în continuare, comparați starea HTTP și marcajul temporal cu jurnalele serverului web, proxy, PHP și ownCloud. În Docker, documentația ownCloud menționează că jurnalele aplicației pot fi în directorul de jurnal montat, în timp ce jurnalele Apache și PHP sunt trimise către ieșirea containerului; acest lucru docker compose logs owncloudpoate ajuta la localizarea acestor erori.

Manualele actuale ale ownCloud acoperă atât Classic 11.0, cât și 10.16, iar comportamentul la instalare diferă în funcție de versiune; documentația Classic 11 specifică Docker ca metodă de instalare acceptată. Folosiți manualul pentru versiunea implementată și evitați aplicarea orbește a fragmentelor vechi de Apache sau Nginx la un container sau o configurație proxy mai nouă.