Risolvi l'avviso "L'interfaccia WebDAV sembra essere danneggiata" verificando che l'endpoint DAV di ownCloud sia raggiungibile e che il tuo server web inoltri le richieste WebDAV, incluso il PROPFINDmetodo, all'applicazione PHP di ownCloud. La modifica corretta dipende dal fatto che l'URL pubblico sia gestito da Apache, Nginx o da un proxy inverso; testa l'endpoint prima di modificare la configurazione per correggere il livello difettoso.
Scopri cosa sta effettivamente testando l'avviso
Il controllo amministrativo di ownCloud Classic segnala questo avviso quando il controllo di sincronizzazione dei file non riesce a utilizzare l'interfaccia WebDAV. Nella maggior parte dei casi si tratta di un problema del server web o del percorso di richiesta, non di una prova che i file o il database siano danneggiati. La documentazione ufficiale di ownCloud Server 11 descrive questo avviso separatamente dal controllo di individuazione /.well-known/caldavdei /.well-known/carddavservizi.
Utilizza l'endpoint DAV corrispondente al percorso di installazione pubblico. Nella directory principale del dominio, l'endpoint è solitamente https://cloud.example.com/remote.php/dav; se installato in una sottocartella, includilo, ad esempio https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 documenta anche l'URL di compatibilità /remote.php/webdavper alcune connessioni desktop e di gestione file. Non considerare il vecchio URL client e il nuovo endpoint DAV come intercambiabili in ogni configurazione.
Invia una PROPFINDrichiesta autenticata con profondità zero. In questo comando, sostituisci l'host/percorso di esempio e il nome utente. Curl richiede la password perché viene fornito solo il nome utente a -u:
curl -i -u 'USERNAME' -X PROPFIND \
-H 'Depth: 0' \
'https://cloud.example.com/owncloud/remote.php/dav'
Una risposta WebDAV di successo è in genere 207 Multi-Status. Interpreta altre risposte come indizi: 301o 302indica un problema di reindirizzamento o di URL canonico; 401significa che l'autenticazione non è stata accettata; 404spesso significa che il percorso o la riscrittura PHP non hanno raggiunto ownCloud; e 405o 501suggerisce che un server, un proxy o un livello di sicurezza ha rifiutato il metodo DAV. Il fatto che un browser apra l'URL con una pagina di login non dimostra che PROPFINDfunzioni.
Scegli la correzione in base al layout del server web
Apache: mantieni attive le regole di riscrittura di ownCloud
Per un'installazione standard di Apache, verificare innanzitutto che il .htaccessfile fornito da ownCloud sia presente e che Apache consenta le sue direttive di riscrittura nella directory di installazione. Il processo di installazione e aggiornamento di ownCloud gestisce queste regole. Se AllowOverride Noneciò impedisce ad Apache di leggerle, è necessario consentire le sovrascritture richieste per la directory di ownCloud oppure spostare le regole equivalenti nella configurazione dell'host virtuale. La prima opzione è più facile da gestire per un tipico sito ownCloud singolo; le regole centralizzate per gli host virtuali possono essere preferibili quando le policy richiedono una configurazione al di fuori delle directory dell'applicazione.
Non incollare un blocco di riscrittura generico sopra una configurazione funzionante. Verifica che mod_rewritesia abilitato, che il sito punti alla directory radice corretta di ownCloud e che le richieste raggiungano /remote.php/davil gestore PHP. Dopo aver modificato la configurazione di Apache, esegui il test di configurazione prima di ricaricarla. Su ownCloud Classic 11 basato su Docker, l'immagine gestisce la propria configurazione Apache integrata; utilizza i meccanismi di configurazione e ambiente supportati dall'immagine anziché modificare i file generati all'interno di un container in esecuzione. Consulta la documentazione per la risoluzione dei problemi di ownCloud Server 11 .
Nginx: utilizzare la configurazione del server ownCloud
Nginx non legge .htaccessi file di Apache. Se Nginx serve direttamente ownCloud, usa la configurazione di Nginx corrispondente alla tua versione di ownCloud e al percorso di installazione, inclusa la gestione della posizione PHP e il routing relativo a DAV. Una posizione PHP minimale personalizzata potrebbe servire l'interfaccia web restituendo /remote.php/davun errore 404 o passando la richiesta al gestore sbagliato. Confronta il blocco server attivo con la documentazione di installazione di ownCloud 10.16 del fornitore , quindi testa la configurazione e ricarica Nginx. Le direttive esatte dipendono dalla distribuzione, dal socket PHP-FPM e dal fatto che ownCloud si trovi nella directory principale del dominio o in una sottocartella.
Proxy inverso: preserva percorso, metodo e URL pubblico
Se un proxy termina HTTPS o instrada un sottopercorso come /cloud, verifica che inoltri l'intero percorso DAV al backend e consenta metodi WebDAV come PROPFIND, PUT, MOVE, e DELETE. Un proxy o un firewall per applicazioni web può bloccare un metodo anche quando l'endpoint PHP è corretto. Confronta una richiesta inviata tramite l'URL pubblico con una inviata direttamente al backend da una rete attendibile; se l'accesso diretto restituisce 207 ma la richiesta pubblica fallisce, concentrati sul percorso del proxy, sul filtro dei metodi, sui reindirizzamenti e sulle intestazioni di autorizzazione.
Imposta ownCloud solo trusted_proxiessugli indirizzi proxy effettivi. Se il rilevamento automatico dell'URL fallisce, le overwritehostimpostazioni overwriteprotocol, e overwritewebrootpossono descrivere l'URL pubblico, ma non risolvono un metodo DAV bloccato o una route PHP mancante. Un'errata attendibilità del proxy può consentire l'utilizzo di intestazioni di indirizzo client falsificate. Utilizza le linee guida ufficiali per la configurazione del proxy inverso in base alla tua topologia.
Mantenere la funzionalità di rilevamento DAV separata dall'accesso ai file.
Gli URL /.well-known/caldave /.well-known/carddavaiutano i client di calendario e contatti a individuare gli endpoint dei servizi. Dovrebbero instradare verso l'endpoint DAV di ownCloud, ma un errore in quel punto genera un avviso separato rispetto a un controllo WebDAV di sincronizzazione dei file non riuscito. Correggere solo questi reindirizzamenti di individuazione potrebbe non eliminare l'avviso di sincronizzazione. Per Apache, le regole predefinite di ownCloud potrebbero gestire l'individuazione quando abilitate; le implementazioni Nginx e le sottocartelle richiedono una configurazione del server corrispondente. Verificare ogni URL e il relativo target di reindirizzamento singolarmente, seguendo le linee guida ufficiali di ownCloud relative agli avvisi .
Verifica la riparazione
Ripeti il PROPFINDtest autenticato sull'URL DAV pubblico e verifica che restituisca un risultato positivo 207 Multi-Status. Quindi aggiorna la pagina di amministrazione di ownCloud ed esegui un piccolo test di sincronizzazione con il client desktop. Se la richiesta continua a fallire, confronta lo stato HTTP e il timestamp con i log del server web, del proxy, di PHP e di ownCloud. In Docker, la documentazione di ownCloud indica che i log dell'applicazione potrebbero trovarsi nella directory dei log montata, mentre i log di Apache e PHP vengono inviati all'output del container; docker compose logs owncloudquesto può aiutare a individuare tali errori.
I manuali di ownCloud attualmente disponibili coprono sia la versione Classic 11.0 che la 10.16, e la procedura di installazione varia a seconda della versione; la documentazione di Classic 11 specifica Docker come metodo di installazione supportato. Utilizza il manuale relativo alla versione in uso ed evita di applicare ciecamente vecchi snippet di Apache o Nginx a una configurazione di container o proxy più recente.