Cuando las cargas de ownCloud se detienen al 99%, compruebe estos límites.

Cuando la página de ownCloud Files se queda en el 99 %, primero compruebe si el archivo completo ya aparece en la carpeta de destino antes de volver a intentarlo. Si falta o está incompleto, pida al administrador que revise la cuota de usuario, el espacio libre en los directorios temporales de PHP y de fragmentos de ownCloud, y los límites de solicitudes de PHP y del servidor web. Un indicador del 99 % no es suficiente para identificar qué parte falló.

Esta guía práctica abarca las cargas a través de la interfaz web de ownCloud Server (Classic) 10.16. Las cargas con escalado infinito y sincronización de escritorio utilizan rutas de servidor y registros diferentes. Los ejemplos siguen la documentación oficial de la versión 10.16; utilice la configuración y las rutas de archivo que correspondan a su propia implementación.

Clasificación rápida

1. Confirma el estado de la carga antes de volver a intentarlo.

Abra la carpeta de destino en una segunda pestaña o actualícela una vez que la carga haya finalizado. Si el archivo está presente, compare su tamaño en bytes con el del archivo original local y ábralo. Un archivo completo con una barra de progreso obsoleta indica que no se pudo completar la carga o que hay un problema de visualización en el navegador; esto no justifica la carga de una segunda copia.

Si el archivo no existe o es demasiado pequeño, intente con un archivo de prueba pequeño en la misma carpeta y, si es posible, intente con el original desde otro navegador o red. Registre el tamaño del archivo, el usuario, el destino, la hora aproximada y si la prueba falló. Estas comparaciones ayudan a diferenciar un problema de un solo archivo o del cliente de un problema general del servidor. Evite cancelar y reiniciar repetidamente una carga grande mientras el servidor aún la está procesando.

2. Verificar cuota, espacio temporal y permisos.

Solicita al administrador de ownCloud que verifique la cuota del usuario afectado y los permisos de escritura de la carpeta de destino. Un límite de cuota puede impedir que se almacene un archivo nuevo, incluso cuando el navegador ya haya enviado la mayor parte de sus datos. Si el destino es un montaje externo, verifica también el espacio disponible y los permisos de escritura de ese servidor.

En el servidor, compruebe los bloques libres y los inodos en el directorio de datos y en todos los directorios temporales relevantes. Un inodo es el registro del sistema de archivos que se utiliza para crear un archivo; un volumen puede tener gigabytes libres pero ningún inodo disponible. Utilice las rutas reales de su configuración de PHP y ownCloud.

df -h /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp
df -i /path/to/owncloud-data /path/to/php-temp /path/to/chunk-temp

Los archivos PHP upload_tmp_dirdeben tener permisos de escritura para la cuenta del servidor web/PHP. ownCloud también cuenta con una configuración de directorio temporal, y las cargas de fragmentos se almacenan de forma predeterminada en el directorio de cargas del usuario. Durante el ensamblaje, ownCloud puede necesitar espacio temporal equivalente aproximadamente al tamaño final del archivo. El usuario dav.chunk_base_dirpuede modificar esta ubicación. Verifique todos estos volúmenes, no solo el disco de datos principal.

3. Ajustar los límites de carga y los tiempos de espera al archivo.

Si los archivos pequeños funcionan pero un archivo más grande no, compare su tamaño con la configuración efectiva de web-PHP: upload_max_filesizey post_max_size. PHP requiere post_max_sizeque sea mayor que upload_max_filesize. Verifique la configuración de PHP utilizada por el servidor web o PHP-FPM; la configuración de PHP de la línea de comandos puede ser diferente. En las configuraciones de PHP-FPM, ownCloud señala que la configuración de PHP debe estar en .user.inio en la configuración de FPM, no solo en .htaccess.

También revise max_input_timesi las cargas tardan mucho y si se produce un tiempo de espera de ejecución de PHP en los registros. Establezca límites para la carga de trabajo prevista en lugar de copiar un valor de ejemplo; reinicie o recargue PHP y el servidor web después de modificar la configuración. Consulte la configuración de carga de archivos grandes de ownCloud y la referencia de la directiva de carga de PHP .

Luego, revise cada capa HTTP delante de PHP. Nginx client_max_body_sizerechaza los cuerpos de solicitud de gran tamaño con HTTP 413; configúrelo lo suficientemente alto para el tamaño de solicitud utilizado por su ruta de carga. Apache LimitRequestBodytambién mod_reqtimeoutpuede restringir las cargas. ownCloud advierte específicamente que los proxies inversos, Cloudflare, los límites de E/S del alojamiento y la configuración de tiempo de espera de solicitud de Apache pueden afectar las cargas grandes. Cambie solo la capa implicada en los registros y evite deshabilitar los módulos de seguridad globalmente como primera solución. Consulte la documentación oficial de Nginx sobre el cuerpo de la solicitud .

4. Utilice los registros para localizar la capa que está fallando.

Reproduzca el problema una vez, anotando la hora, y luego revise el registro de ownCloud y el registro de errores del servidor web o proxy para ese mismo minuto. El registro de ownCloud suele estar en el directorio de datos configurado; la ruta real se puede modificar en config.php. Busque mensajes sobre cuota, permisos, archivos temporales, bloqueos, tamaño de la solicitud o tiempo de espera. Si la solicitud no aparece en el registro de ownCloud, investigue primero el proxy o el servidor web.

tail -n 100 /path/to/owncloud.log

Sustituya el marcador de posición por la ruta configurada en su instalación. El comando solo muestra las líneas de registro recientes; no modifica los datos del servidor. Evite publicar registros sin procesar sin eliminar nombres de usuario, rutas de archivo, direcciones IP y tokens. ownCloud explica la ubicación de los registros en su documentación de depuración .

Verificar la solución

• Sube un archivo pequeño y luego vuelve a intentar subir el archivo afectado una vez.
• Confirme que la copia de destino tenga el tamaño esperado y se abra correctamente.
• Compruebe que no aparezca ningún error de cuota, almacenamiento, HTTP 413, permisos o tiempo de espera durante la carga.
• Si el problema persiste, proporcione al administrador el tamaño del archivo, la ubicación, la marca de tiempo y la entrada de registro correspondiente para que pueda identificar la capa que detuvo la solicitud.

No aumente todos los límites ni desactive las protecciones de solicitud a la vez. Un cambio selectivo seguido de un reintento controlado facilita la confirmación de la causa y mantiene intacta la configuración del resto del servidor.