Risolvi l'errore "L'interfaccia WebDAV è danneggiata" in ownCloud
Se ownCloud si carica in un browser ma la sua pagina di amministrazione segnala che "l'interfaccia WebDAV non funziona", anche il caricamento dei file, la sincronizzazione desktop e l'app File potrebbero non funzionare. L'avviso è un sintomo, non una diagnosi: l'endpoint DAV potrebbe essere irraggiungibile, riscritto in modo errato, bloccato da un proxy o da una regola di sicurezza, oppure inaccessibile quando ownCloud richiama il proprio URL pubblico.
Questa guida si applica alle installazioni di ownCloud Classic Server. ownCloud Infinite Scale ha un'architettura e un modello di implementazione diversi, quindi non applicare le impostazioni di Apache di Classic Server a un'implementazione di Infinite Scale. Le pagine ufficiali collegate di seguito riguardano ownCloud Server 10.15 e 10.16, oltre a Classic Server 11.0; i controlli utilizzano percorsi WebDAV e requisiti Apache documentati, mentre l'avviso di amministrazione esatto può variare a seconda della versione.
Nota illustrativa: le immagini dell'interfaccia e del terminale riportate di seguito sono esempi schematici. I nomi host, le righe di stato e i valori visualizzati sono segnaposto e non rappresentano un'installazione reale né una dichiarazione di esecuzione di un test.
Cosa significa l'avviso WebDAV?
WebDAV è l'interfaccia basata su HTTP che ownCloud utilizza per elencare e gestire i file per i client di sincronizzazione e per le relative operazioni sui file. L'accesso tramite browser conferma solo che l'interfaccia web risponde. Non conferma che una richiesta WebDAV raggiunga ownCloud con il percorso, il metodo, le intestazioni di autenticazione e la connessione HTTPS corretti.
Iniziate identificando se l'errore è esterno o si verifica solo durante l'autodiagnosi di ownCloud. Un errore del client di sincronizzazione e una richiesta WebDAV autenticata non riuscita indicano un problema con il percorso DAV o con l'autenticazione. Se i client funzionano ma l'avviso dell'amministratore persiste, verificate se il server stesso è in grado di risolvere e raggiungere il nome host pubblico, incluso il relativo certificato TLS.
Passaggio 1: annota l'URL esatto e testa WebDAV direttamente
Utilizzare lo stesso nome host e lo stesso percorso di installazione che gli utenti inseriscono in un browser. Per un'installazione nel dominio radice, il percorso DAV di Classic Server attualmente in uso segue generalmente questa forma:
Se ownCloud è installato in un percorso diverso, includi tale percorso prima di /remote.php, ad esempio https://example.com/owncloud/remote.php/dav/files/USERNAME/. Utilizza il tuo nome utente e URL. Non testare un nome host inventato né presumere che ogni installazione utilizzi la stessa sottocartella.
Da una macchina client, inviare una richiesta PROPFIND autenticata. Con cURL, passando solo il nome utente, viene richiesto di inserire la password anziché inserirla nel comando:
Una risposta WebDAV valida e autenticata utilizza comunemente HTTP 207 Multi-Status. Un errore 401potrebbe semplicemente significare che le credenziali non sono state accettate; un 404errore spesso indica un percorso errato o una riscrittura del percorso proxy; un errore 403suggerisce una regola di accesso, un WAF o una policy del server; e un errore o un 301errore 302possono indicare un reindirizzamento che il client o l'autoverifica non seguono come previsto. Leggere le intestazioni della risposta e i log del server prima di modificare la configurazione. Oscurare nomi utente, cookie, token e indirizzi IP pubblici prima di condividere l'output del comando.
Schema riassuntivo dell'interfaccia di amministrazione che mostra un avviso WebDAV; i valori di stato visualizzati sono a titolo di esempio.Un esempio del tipo di risposta 207 Multi-Status che può essere restituita da un controllo PROPFIND autenticato.
Passaggio 2: Verificare se il server può raggiungere il proprio URL pubblico
Alcuni controlli di configurazione effettuano una richiesta dal server ownCloud al suo indirizzo pubblico configurato. Esegui controlli DNS e HTTPS di base da quel server, non solo dal tuo laptop:
Il nome host deve risolversi in un indirizzo raggiungibile dal server e la richiesta HTTPS deve essere completata senza errori relativi al nome del certificato, alla catena di fiducia o alla connessione. Se il DNS indirizza il server attraverso un firewall che non supporta il NAT reflection (anche detto hairpin NAT), un client esterno potrebbe funzionare mentre l'autoverifica interna fallisce. Potrebbero essere opportune soluzioni come lo split DNS, una rotta interna verso il reverse proxy o una modifica della rete lato provider; apportare la modifica più circoscritta che si adatti alla propria architettura di rete.
Una voce trusted-domain è un elenco di host consentiti per le richieste ownCloud in entrata. Aggiungere solo i nomi host effettivamente utilizzati dagli utenti, seguendo la procedura di configurazione documentata. Non aggiungere indirizzi interni arbitrari a caso. L' overwrite.cli.urlimpostazione controlla l'URL utilizzato dai contesti della riga di comando/in background in alcune configurazioni; non sostituisce la correzione di DNS, routing o TLS. Verificare il significato dell'avviso prima di modificare una delle due impostazioni.
Esempio di configurazione di Apache che evidenzia l'impostazione di override della directory; verificare il percorso e le direttive effettivi per la propria installazione.
Passaggio 3: Verificare le impostazioni di riscrittura e di directory di Apache
Per le installazioni di Apache, la guida di configurazione manuale di ownCloud richiede mod_rewrite, AllowOverride Allper la directory ownCloud quando si utilizza .htaccess, e un'impostazione di Apache relativa a DAV che impedisce al modulo DAV di Apache di prendere il controllo del percorso dell'applicazione. Confronta il tuo host virtuale e il blocco di directory con la guida ufficiale invece di incollare un intero esempio su un sito personalizzato.
Su Debian o Ubuntu, esaminate il modulo di riscrittura caricato e la sintassi di configurazione di Apache:
Se la riscrittura non è presente, abilitala con sudo a2enmod rewrite, quindi convalida nuovamente la configurazione e ricarica Apache solo dopo che il controllo della sintassi è andato a buon fine. Verifica che il <Directory>percorso corrisponda alla directory principale web di ownCloud e che le sovrascritture non siano disabilitate più in alto nella configurazione. Evita di sostituire manualmente la regola di riscrittura generata da ownCloud .htaccesscon una regola di riscrittura generica; le regole personalizzate possono interrompere le route dell'applicazione o andare perse durante gli aggiornamenti.
Passaggio 4: Verifica dei proxy inversi, delle regole WAF e delle intestazioni di autenticazione
Se l'endpoint funziona quando viene chiamato direttamente sul server web ma non funziona tramite l'URL pubblico, controlla il proxy inverso o il bilanciatore di carico. Assicurati che mantenga il /remote.php/dav/percorso completo, inoltri le informazioni Host e HTTPS previste e consenta i metodi WebDAV come PROPFIND, OPTIONS, PUT, e MOVEove richiesto. Un proxy che rimuove un prefisso di installazione o invia le richieste DAV a un backend diverso può far apparire l'interfaccia utente web funzionante mentre le operazioni sui file falliscono.
Esamina i log del proxy, di Apache/Nginx e di ownCloud al momento di una richiesta non riuscita. Un firewall per applicazioni web o una regola di ModSecurity possono rifiutare un metodo o il corpo della richiesta. Identifica l'ID esatto della regola e crea un'eccezione specifica per la rotta o la richiesta di ownCloud interessata, quindi esegui nuovamente il test. Non disattivare il WAF a livello globale solo per eliminare un avviso. Se l'autenticazione DAV non riesce solo dietro un gestore FastCGI/PHP, verifica che l'intestazione di autorizzazione venga passata a PHP; le note di configurazione di ownCloud documentano questa tipologia di problema.
Passaggio 5: Convalida TLS e reindirizzamenti
I client WebDAV, proprio come i browser, dipendono da un protocollo HTTPS valido. Verifica che il certificato sia valido per il nome host, che includa i certificati intermedi necessari e che sia considerato attendibile dall'ambiente server che esegue l'autoverifica di ownCloud. Un browser potrebbe nascondere o considerare attendibile separatamente un problema del certificato segnalato da cURL o PHP. Non disabilitare la verifica del certificato come soluzione.
Verificare la presenza di loop di reindirizzamento, reindirizzamenti HTTP-to-HTTPS imprevisti o reindirizzamenti dal percorso DAV a una pagina di accesso o a una homepage generica. Un reindirizzamento può essere normale per l'URL di base di un browser, ma la richiesta DAV dovrebbe in definitiva raggiungere l'endpoint dell'applicazione mantenendo inalterati il metodo e l'intestazione di autorizzazione. Se un proxy termina TLS, verificare che ownCloud riceva il protocollo e l'host inoltrati corretti in base alla configurazione documentata del proxy.
Un esempio di verifica DNS e del certificato dal server che deve connettersi al nome host pubblico.
Verificare la riparazione da entrambi i lati
Dopo ogni modifica mirata, ripetete gli stessi controlli anziché modificare più livelli contemporaneamente:
Dal lato client, autenticarsi all'URL DAV documentato e verificare che la risposta sia una risposta WebDAV prevista, in genere 207 Multi-Statusper PROPFIND.
Dall'host di ownCloud, verificare che il nome host pubblico venga risolto correttamente e che la connessione HTTPS raggiunga l'istanza senza errori di convalida TLS.
Ricontrolla la panoramica amministrativa di ownCloud e analizza i log per individuare eventuali nuovi errori relativi a DAV, proxy o autenticazione.
Esegui una prova di caricamento, rinominazione e download di un piccolo file nell'interfaccia web o tramite un client di sincronizzazione supportato.
Se le richieste del client funzionano ma l'avviso persiste, concentrarsi sul DNS del server, sul routing, sull'attendibilità dei certificati e sull'URL pubblico configurato. Se sia l'autoverifica che i client falliscono, concentrarsi innanzitutto sul percorso dell'endpoint, sulle regole di riscrittura, sul routing del proxy, sui metodi di richiesta e sull'inoltro dell'autenticazione. Se il server è gestito da un provider di hosting, inviare all'assistenza il timestamp, lo stato HTTP sanificato, il percorso richiesto e la voce di log corrispondente; non inviare password o configurazioni contenenti dati sensibili.