Solucione la advertencia "La interfaz WebDAV parece estar dañada" confirmando que el punto final DAV de ownCloud sea accesible y que su servidor web reenvíe las solicitudes WebDAV, incluido el PROPFINDmétodo, a la aplicación PHP de ownCloud. El cambio correcto depende de si Apache, Nginx o un proxy inverso gestionan la URL pública; pruebe el punto final antes de editar la configuración para corregir la capa que falla.
El verificador de administración de ownCloud Classic informa esta advertencia cuando su comprobación de sincronización de archivos no puede usar la interfaz WebDAV. En muchos casos, se trata de un problema del servidor web o de la ruta de la solicitud, no de una prueba de que los archivos o la base de datos estén dañados. La referencia oficial de advertencias de ownCloud Server 11 la describe por separado de la /.well-known/caldavcomprobación /.well-known/carddavde detección de servicios.
Utilice el punto final DAV que coincida con su ruta de instalación pública. En la raíz del dominio, el punto final suele ser https://cloud.example.com/remote.php/dav; cuando se instala en un subdirectorio, inclúyalo, por ejemplo https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16 también documenta la URL de compatibilidad /remote.php/webdavpara algunas conexiones de escritorio y administrador de archivos. No considere que la URL de cliente antigua y el nuevo punto final DAV sean intercambiables en todas las configuraciones.
Envía una PROPFINDsolicitud autenticada con profundidad cero. En este comando, reemplaza el host/ruta y el nombre de usuario de ejemplo. Curl solicita la contraseña porque solo se proporciona el nombre de usuario a -u:
curl -i -u 'USERNAME' -X PROPFIND \
-H 'Depth: 0' \
'https://cloud.example.com/owncloud/remote.php/dav'Una respuesta WebDAV exitosa suele ser 207 Multi-Status. Interprete otras respuestas como pistas: 301o 302apunta a un problema de redirección o URL canónica; 401significa que la autenticación no fue aceptada; 404a menudo significa que la ruta o la reescritura de PHP no llegó a ownCloud; y 405o 501sugiere que un servidor, proxy o capa de seguridad rechazó el método DAV. Que un navegador abra la URL con una página de inicio de sesión no prueba que PROPFINDfuncione.
Para una instalación estándar de Apache, primero verifique que el archivo proporcionado por ownCloud .htaccessesté presente y que Apache permita sus directivas de reescritura en el directorio de instalación. El instalador y el proceso de actualización de ownCloud mantienen estas reglas. Si AllowOverride Noneesto impide que Apache las lea, permita las anulaciones necesarias para el directorio ownCloud o mueva las reglas equivalentes a la configuración del host virtual. La primera opción es más fácil de mantener para un sitio ownCloud típico; las reglas centrales del host virtual pueden ser preferibles cuando la política requiere configuración fuera de los directorios de la aplicación.
No pegue un bloque de reescritura genérico sobre una configuración que funcione. Confirme que mod_rewriteesté habilitado, que el sitio apunte a la raíz de documentos de ownCloud correcta y que las solicitudes /remote.php/davlleguen al controlador PHP. Después de cambiar la configuración de Apache, ejecute su prueba de configuración antes de recargarla. En ownCloud Classic 11 basado en Docker, la imagen gestiona su configuración de Apache integrada; utilice los mecanismos de configuración y entorno compatibles de la imagen en lugar de editar archivos generados dentro de un contenedor en ejecución. Consulte la documentación de solución de problemas de ownCloud Server 11 .
Nginx no lee .htaccessarchivos de Apache. Si Nginx sirve ownCloud directamente, utilice la configuración de Nginx que coincida con su versión de ownCloud y ruta de instalación, incluyendo el manejo de la ubicación PHP y el enrutamiento relacionado con DAV. Una ubicación PHP mínima personalizada puede servir la interfaz web pero generar /remote.php/davun error 404 o enviarla al manejador incorrecto. Compare su bloque de servidor activo con la documentación de instalación de ownCloud 10.16 del proveedor , luego pruebe la configuración y reinicie Nginx. Las directivas exactas dependen de la distribución, el socket PHP-FPM y si ownCloud se encuentra en la raíz del dominio o en un subdirectorio.
Si un proxy finaliza HTTPS o enruta una subruta como /cloud, verifique que reenvíe la ruta DAV completa al backend y permita métodos WebDAV como PROPFIND, PUT, MOVE, y DELETE. Un proxy o firewall de aplicaciones web puede bloquear un método incluso cuando el punto final PHP es correcto. Compare una solicitud enviada a través de la URL pública con una enviada directamente al backend desde una red de confianza; si el acceso directo devuelve 207 pero la solicitud pública falla, concéntrese en la ruta del proxy, el filtrado de métodos, las redirecciones y los encabezados de autorización.
Configure ownCloud únicamente trusted_proxiescon direcciones proxy reales. Si la detección automática de URL falla, las configuraciones overwritehost, overwriteprotocoly overwritewebrootpueden describir la URL pública, pero no solucionan un método DAV bloqueado ni una ruta PHP faltante. Una confianza de proxy incorrecta puede permitir encabezados de dirección de cliente falsificados. Consulte la guía oficial de configuración de proxy inverso para su topología.
Las /.well-known/caldavURL /.well-known/carddavayudan a los clientes de calendario y contactos a descubrir los puntos finales del servicio. Deben redirigir al punto final DAV de ownCloud, pero un fallo allí genera una advertencia independiente de una comprobación WebDAV de sincronización de archivos defectuosa. Corregir solo esas redirecciones de descubrimiento puede no eliminar la advertencia de sincronización. Para Apache, las reglas incluidas en ownCloud pueden gestionar el descubrimiento cuando están habilitadas; las implementaciones de Nginx y subdirectorios necesitan una configuración de servidor coincidente. Compruebe cada URL y su destino de redirección de forma independiente, siguiendo la guía de advertencia oficial de ownCloud .
Repita la PROPFINDprueba autenticada con la URL pública de DAV y confirme que devuelve 207 Multi-Status. A continuación, actualice la página de administración de ownCloud y ejecute una pequeña prueba de sincronización con el cliente de escritorio. Si la solicitud sigue fallando, compare el estado HTTP y la marca de tiempo con los registros del servidor web, el proxy, PHP y ownCloud. En Docker, la documentación de ownCloud indica que los registros de la aplicación pueden estar en el directorio de registro montado, mientras que los registros de Apache y PHP se envían a la salida del contenedor; docker compose logs owncloudesto puede ayudar a localizar esos errores.
Los manuales actuales de ownCloud cubren tanto Classic 11.0 como 10.16, y el comportamiento de instalación difiere según la versión; la documentación de Classic 11 especifica Docker como método de instalación compatible. Utilice el manual de la versión implementada y evite aplicar fragmentos de código antiguos de Apache o Nginx sin más a una configuración de contenedor o proxy más reciente.
Elimine todas las versiones de archivos almacenadas de ownCloud Server Classic para una cuenta o para todos los usuarios, y distinga entre una eliminación completa y la caducidad basada en la retención.
Para rastrear un rechazo de conexión móvil de ownCloud, verifique la URL del servidor, la red telefónica, el punto final HTTPS y los registros del servidor en el orden correcto.
Sustituya la ejecución de trabajos bajo demanda por un temporizador systemd que ejecute el comando occ system:cron compatible con ownCloud cada 15 minutos.
Rastrea la solicitud WebDAV a través de Apache, Nginx o un proxy inverso, y luego confirma que la sincronización de ownCloud funciona con una prueba PROPFIND autenticada.
Solucione el problema de Nextcloud que indica que falta la dirección de correo electrónico saliente configurando su URL canónica y comprobando el DNS, HTTPS y el enrutamiento del proxy inverso desde el propio servidor.
Configure APCu y Redis a través de un socket Unix local para el almacenamiento en caché y el bloqueo de archivos de Nextcloud, con pasos para las versiones actuales y anteriores de Nextcloud.
Comprueba el modo cron de Nextcloud, repara su servicio systemd y su temporizador, y verifica que las tareas en segundo plano se ejecuten después del inicio y cada cinco minutos.
Habilite el bloqueo de archivos confiable de Nextcloud, elija el backend Redis o Valkey adecuado y verifique que la advertencia desaparezca sin riesgo de que se produzcan cambios simultáneos en los archivos.
Solucione los problemas comunes detectados en los análisis de Nextcloud con las últimas actualizaciones, HTTPS y HSTS, una configuración precisa de la confianza en el proxy inverso y comprobaciones con el servidor público.
Configure Nextcloud SSE para el almacenamiento que lo necesite, proteja las claves de cifrado y mida el impacto en la transferencia y la CPU antes de cifrar los archivos existentes.
