Una subida a ownCloud que alcanza el 99 % y luego parece congelarse no suele solucionarse reiniciándola varias veces. En ese momento, es posible que el navegador ya haya transferido la mayor parte o la totalidad del archivo, mientras que el servidor aún está completando tareas como recibir el último fragmento, ensamblar fragmentos, mover el archivo completo a su destino, actualizar los metadatos o liberar bloqueos. El porcentaje por sí solo no identifica la causa, por lo que la forma más rápida de proceder es revisar la información del servidor en un orden determinado.
Esta guía utiliza la documentación de administración actual de ownCloud Server 11.0, disponible en octubre de 2026. Si bien los mismos principios se aplican a muchas implementaciones de ownCloud Classic, las rutas de configuración y el comportamiento de Docker pueden variar en versiones anteriores. Antes de modificar los límites, confirme la versión instalada y el método de implementación.
| Qué comprobar | Por qué es importante | Pista fuerte |
|---|---|---|
| ownCloud, PHP y registros del servidor web | El fallo puede producirse después de que el navegador termine de enviar los datos. | Tiempo de espera agotado, almacenamiento, WebDAV, bloqueo, error 5xx o error de permisos en el momento de la carga. |
| Espacio libre temporal y para directorios de carga | Las cargas divididas en fragmentos necesitan almacenamiento temporal antes de su finalización. | Los archivos grandes fallan mientras que los pequeños funcionan, o bien el sistema de archivos está casi lleno. |
| Cuota de usuario y almacenamiento de destino | El archivo final aún necesita espacio en su destino. | El fallo se produce únicamente para un usuario, carpeta o destino de almacenamiento externo. |
| Límites de tiempo y de carga de PHP | Las solicitudes no fragmentadas y las solicitudes de soporte pueden ser rechazadas o caducar. | Los errores mencionan el tamaño de la solicitud, el tiempo de ejecución, el tiempo de entrada o los archivos temporales de carga. |
| Duración de la sesión | Una sesión que caduca antes de que finalice una carga larga puede interrumpir su finalización. | Los fallos se correlacionan con la duración de la carga, más que con el tipo de archivo. |
| Proxy inverso, CDN o balanceador de carga | Un componente anterior puede imponer su propio límite de tamaño de cuerpo o de tiempo de espera. | El acceso directo funciona, pero el nombre de host público a través del proxy falla. |
| Bloqueo de archivos transaccionales | ownCloud bloquea los archivos mientras se realizan las operaciones de archivo. | Los registros contienen errores de bloqueo, especialmente bajo carga o en almacenamiento en clúster. |
Realice una carga controlada con un archivo que reproduzca el problema de forma fiable y anote la hora exacta. A continuación, revise el registro de ownCloud, el registro de PHP y el registro de errores del servidor web en torno a esa hora. No realice varios cambios de configuración antes; hacerlo dificulta determinar qué capa falló realmente.
La documentación oficial de solución de problemas de ownCloud recomienda explícitamente revisar primero los registros de PHP, Apache y ownCloud. En la implementación estándar de Docker, ownCloud documenta que la salida de Apache y PHP se enruta a través de stdout/stderr del contenedor, y sugiere seguir los registros del contenedor con docker compose logs owncloud -f.
También puedes obtener el registro de ownCloud desde la interfaz de administración. La guía de configuración y registro de ownCloud documenta el proceso a través de Configuración > Administración > General y ofrece una occ configreport:generateopción para cuando se necesita un informe de configuración más completo.
Céntrese en el primer error asociado a la solicitud fallida, no en todas las advertencias posteriores. Algunas categorías útiles son: tiempos de espera de solicitud, almacenamiento insuficiente, imposibilidad de crear o renombrar un archivo temporal, errores de permisos, excepciones de WebDAV, respuestas HTTP 413/502/504 y fallos de bloqueo de archivos. Si aumenta temporalmente el nivel de registro de ownCloud a DEBUG, vuelva a configurarlo al nivel normal posteriormente; ownCloud indica que el registro detallado puede afectar al rendimiento del servidor. Consulte la referencia oficial de configuración de registro .
Esta es una de las comprobaciones más importantes para evitar un bloqueo del 99 %. ownCloud Server 11.0 explica que las cargas pueden usar más de un área temporal. El directorio temporal de carga de PHP debe tener espacio para los fragmentos activos, mientras que el directorio de carga del usuario recopila los fragmentos de un archivo hasta que la carga se completa.
Según la documentación de ownCloud sobre la carga de archivos grandes , el espacio temporal de PHP debe calcularse aproximadamente multiplicando el número de cargas simultáneas por el tamaño de los fragmentos. Más importante aún, para un archivo único de gran tamaño, el directorio de carga del usuario necesita temporalmente un espacio equivalente al tamaño final del archivo, ya que almacena los fragmentos hasta que se completa el ensamblaje. Una vez finalizada la carga, ownCloud escribe los fragmentos en el destino final y los elimina.
Compruebe el sistema de archivos que contiene el directorio de datos, el directorio temporal de PHP y cualquier ubicación configurada a través de OWNCLOUD_DAV_CHUNK_BASE_DIR. Verifique también el destino real, especialmente cuando el destino es un almacenamiento externo. Un servidor puede tener mucho espacio libre en /mientras que un volumen de datos separado está lleno.
No mueva manualmente los archivos dentro ni fuera del directorio de datos de ownCloud para "finalizar" la carga. ownCloud advierte que su directorio de datos es exclusivo de la aplicación; las modificaciones directas pueden generar inconsistencias de sincronización y en la base de datos.
Una cuota de usuario puede bloquear un archivo final grande incluso cuando el área de almacenamiento temporal tiene suficiente espacio. Verifique la cuota del usuario afectado y, si corresponde, la capacidad y los permisos de un punto de montaje de almacenamiento externo. Una prueba útil consiste en subir el mismo archivo a otra cuenta o destino con espacio claramente suficiente. Si el fallo se produce con el usuario o la carpeta, en lugar de con el archivo, la cuota o la política de almacenamiento se convierten en una prioridad.
Si los registros apuntan al tamaño de la solicitud o a los límites de ejecución, revise la configuración efectiva de PHP en lugar de asumir que los valores en un php.iniarchivo aleatorio están activos. Las directivas comunes incluyen post_max_size, upload_max_filesize, upload_tmp_dir, max_input_time, max_execution_time, y memory_limit.
Para la configuración de ownCloud Server 11.0 con Docker compatible, la documentación asigna estos a las variables de entorno: OWNCLOUD_MAX_UPLOAD, OWNCLOUD_TEMP_DIRECTORY, OWNCLOUD_MAX_INPUT_TIME, OWNCLOUD_MAX_EXECUTION_TIME, y OWNCLOUD_MEMORY_LIMIT. Esto es importante porque ownCloud indica que las implementaciones que utilizan su configuración de Docker deben usar las variables de entorno proporcionadas en lugar de depender de .htaccesspatrones de personalización o PHP más antiguos.
No establezca límites excesivamente altos para todos los archivos. Un valor más adecuado sería aquel que permita alcanzar el tamaño máximo de archivo previsto y la conexión legítima más lenta, sin comprometer la seguridad operativa.
ownCloud advierte específicamente que session_lifetimeno debe ser más corto que la carga más larga prevista. Si lo ha personalizado, configúrelo al menos con el número de segundos que requiere la carga más lenta prevista, o elimine cualquier valor personalizado innecesario y vuelva al comportamiento predeterminado compatible.
Esto es especialmente importante de comprobar cuando un archivo de 500 MB se descarga correctamente, pero un archivo de varios gigabytes falla repetidamente después de aproximadamente el mismo tiempo transcurrido.
La documentación de ownCloud sobre archivos grandes indica que los proxies del lado del cliente y servicios como Cloudflare pueden restringir las cargas. Esto significa que una pila ownCloud/PHP perfectamente configurada aún puede fallar porque otro nodo limita el cuerpo de la solicitud, almacena en búfer una solicitud larga, cierra una conexión inactiva o se agota el tiempo de espera mientras ownCloud prepara la carga.
Si su arquitectura permite una prueba administrativa segura, compare la misma carga a través de la ruta pública habitual y a través de una ruta que omita el proxy inverso o la CDN. Si la ruta directa funciona, revise la documentación oficial del intermediario para verificar el tamaño de la solicitud, el tiempo de espera de carga, el almacenamiento en búfer y el comportamiento de WebDAV. No debilite TLS ni exponga el backend públicamente solo para realizar esta prueba.
El bloqueo transaccional de archivos está habilitado de forma predeterminada y protege los archivos de modificaciones simultáneas. ownCloud indica que esto también es importante al ensamblar cargas fragmentadas. En servidores con mucha carga, un problema de bloqueo puede manifestarse como una transferencia completada, pero que no se pudo confirmar correctamente.
Consulte la documentación sobre el bloqueo de archivos transaccionales antes de modificar este subsistema. ownCloud recomienda utilizar un backend de caché en memoria para el bloqueo en cargas de trabajo pesadas, en lugar de depender del bloqueo de la base de datos. En implementaciones en clúster, el bloqueo compartido de Redis es especialmente importante, ya que todos los nodos de la aplicación deben ver el mismo estado de bloqueo.
También existe un caso especial documentado para cargas muy largas a carpetas públicas cuando la fragmentación no está activada. ownCloud indica que las cargas que duran más de una hora pueden requerir un tamaño suficientemente grande OWNCLOUD_FILELOCKING_TTL; de lo contrario, la recolección de basura de Redis puede eliminar el bloqueo adquirido al inicio de la operación. No modifique esta configuración a menos que su ruta de carga coincida con este escenario.
Tras corregir un problema detectado, vuelva a intentarlo con el mismo archivo, cuenta, destino, navegador y ruta de red. A continuación, verifique tres cosas: que el proceso se complete, que el archivo aparezca en el destino con el tamaño esperado y que los registros no contengan ningún error nuevo para esa solicitud.
Una progresión útil consiste en un archivo pequeño, uno mediano y, finalmente, el tamaño del archivo que inicialmente falló. Si los archivos pequeños siempre se abren correctamente, pero los fallos comienzan a partir de un tamaño repetible, concéntrese en la capacidad de almacenamiento y los límites de tamaño. Si los fallos comienzan después de un período de tiempo repetible, concéntrese en las sesiones y los tiempos de espera. Si ocurren solo a través de un nombre de host o ruta de red, concéntrese en los proxies y los balanceadores de carga.
Si necesita un manual de procedimientos breve, siga este orden: reproduzca el problema una vez; lea los registros de ownCloud/PHP/servidor web; revise el almacenamiento de datos, temporal y de fragmentos; verifique la cuota; confirme la configuración efectiva de carga y tiempo; inspeccione la duración de la sesión; omita o inspeccione el proxy inverso/CDN; luego investigue el bloqueo transaccional. Este orden prioriza la evidencia y las limitaciones de infraestructura de mayor probabilidad antes de realizar cambios de configuración arriesgados.
Lo importante es que el "99 por ciento" no es un código de error en sí mismo. Indica dónde el usuario detectó el problema, no qué componente lo causó. La solución definitiva consiste en comparar la marca de tiempo de la carga fallida con la información de almacenamiento, tiempo de espera, proxy, sesión o bloqueo en el servidor.
Diagnosticar y reducir de forma segura el almacenamiento multimedia de Matrix Synapse, purgar la caché remota, gestionar las cargas locales y configurar la retención para evitar incidentes de disco lleno.
Solucione el problema de la advertencia HSTS faltante en Nextcloud configurando el servidor web HTTPS o el proxy inverso, y luego verifique de forma segura el encabezado Strict-Transport-Security.
Solucione el error "CSync Unknown Error" del cliente de escritorio de ownCloud reconstruyendo la base de datos de sincronización oculta y, a continuación, verifique la conectividad, los permisos, los nombres de archivo, el espacio en disco y los registros.
El proxy Matrix Sliding Sync está archivado y reemplazado. Habilite la sincronización deslizante simplificada nativa en Synapse, verifique la compatibilidad del cliente, actualice el enrutamiento del proxy y pruebe la sincronización móvil de forma segura.
Diagnostique la lentitud en la federación de Matrix Synapse y en las uniones a salas comprobando la conectividad, el estado de reintento del servidor remoto, las métricas, la carga de la base de datos y los límites de velocidad de unión.
Configure la retención de la papelera de Nextcloud y las tareas en segundo plano para eliminar automáticamente los archivos borrados, verificar la limpieza y evitar comandos de purga inseguros para todos los usuarios.
Diagnostica el eco de BigBlueButton y el retardo de audio de WebRTC separando la retroalimentación del micrófono del retardo de la red, comprobando la prueba de eco, los dispositivos del navegador, la conectividad UDP y la carga del servidor.
Configura un repositorio Restic cifrado y una tarea programada (cron job) para Nextcloud, incluyendo el modo de mantenimiento, una copia de seguridad de MariaDB, retención, registros y comprobaciones de restauración.
Solucione los problemas de cargas de ownCloud que se quedan atascadas en el 99 % revisando los registros, el almacenamiento temporal, el espacio de fragmentos, los límites de PHP, las sesiones, los proxies y el bloqueo de archivos en el orden correcto.
Habilite y aplique correctamente la autenticación de dos factores (2FA) de Zimbra, registre una cuenta de administrador, elija la verificación por TOTP o correo electrónico y pruebe el inicio de sesión en la consola de administración.
