Soluciona el problema de la página en blanco/pantalla blanca de la muerte de ownCloud: elige la ruta de recuperación correcta.

Empieza por decidir qué tipo de página en blanco tienes realmente.

La pantalla blanca de ownCloud es un síntoma, no un diagnóstico. La mejor solución depende de si el navegador recibió un error del servidor, recibió HTML válido pero no pudo cargar JavaScript o CSS, o si se conectó a un proxy inverso que no pudo acceder a ownCloud.

Esa distinción es importante porque las ventajas y desventajas son muy diferentes. Deshabilitar una aplicación de terceros conlleva un riesgo relativamente bajo cuando una excepción de PHP la menciona. Cambiar la propiedad de los archivos en toda la instalación es mucho más invasivo y no debería ser la primera respuesta ante un error de JavaScript. Del mismo modo, reiniciar todos los servicios puede ocultar brevemente un problema sin indicar si proviene de PHP, un proxy, una actualización o una aplicación.

Esta guía cubre ownCloud Classic. Según la documentación actual de ownCloud Classic 11, la versión 11 es compatible con una implementación basada en Docker, donde el sistema operativo, el entorno de ejecución de PHP, la base de datos y Apache se encuentran dentro de los contenedores proporcionados por ownCloud. Las instalaciones anteriores de la versión 10.x aún pueden usar un servidor web tradicional y una configuración PHP-FPM. Utilice la rama de comandos que corresponda a su implementación. Consulte los requisitos del sistema de ownCloud Classic 11 .

1. ¿La página en blanco devuelve un código HTTP 500, o el navegador falla después de un código HTTP 200?

Abre las herramientas para desarrolladores del navegador e inspecciona las pestañas Red y Consola . Prueba también el punto final desde una terminal:

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

Leyenda: Una respuesta 500 del lado del servidor apunta a ownCloud, PHP, la base de datos o la pila web, en lugar de a un simple problema de renderizado del navegador.

Si el documento principal devuelve un error 500 o 502/503 , priorice los registros del servidor y del proxy. Si el documento principal devuelve un error 200 , pero los paquetes JavaScript fallan con errores 404, 403 o excepciones de script, priorice las rutas de los recursos, la reescritura del proxy inverso, los temas, la caché o la compatibilidad de la aplicación. Si solo un navegador se ve afectado, pruebe con una ventana privada y otro navegador compatible antes de cambiar el servidor.

2. ¿El problema comenzó después de una actualización de ownCloud o de PHP?

Esta es una de las preguntas más importantes, ya que permite delimitar de inmediato el origen del problema. Las notas de la versión actual de ownCloud indican que ownCloud Classic 11 elevó la versión mínima de PHP a PHP 8.3 y que ownCloud Classic 11 solo es compatible con Docker. Una instalación antigua de ownCloud 10.x sigue reglas de compatibilidad de PHP diferentes, por lo que no se deben copiar las recomendaciones de PHP de otra versión principal.

Para una instalación tradicional de ownCloud 10.x, ejecute el comando desde el directorio de ownCloud:

sudo -u www-data ./occ status
php -v

Para ownCloud Classic 11, ejecute OCC a través de la implementación de Compose:

docker compose exec owncloud occ status
docker compose exec owncloud php -v

Leyenda: Comprobar las versiones instaladas de ownCloud y PHP es especialmente importante cuando la pantalla en blanco aparece inmediatamente después de una actualización.

Compara el resultado con las notas de la versión que estés utilizando. Las notas de la versión oficial de ownCloud son la fuente correcta para conocer las versiones mínimas actuales y los cambios incompatibles. Revertir a una versión anterior no es una solución genérica segura: la documentación de ownCloud advierte que no se admite la reversión a una versión anterior, ya que puede dañar los datos.

3. ¿Qué registro te da el primer error concreto?

Los registros suelen ser más útiles que los cambios de configuración por ensayo y error. El manual de administración de ownCloud recomienda el registro de ownCloud para diagnosticar problemas; por defecto, el registro se almacena en el directorio de datos configurado, a menos que logfilese especifique uno diferente.

En una instalación tradicional, algunos ejemplos son:

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

En ownCloud Classic 11, inspeccione los servicios de Compose en su lugar:

docker compose logs --tail=200 owncloud
docker compose ps

Leyenda: Un error fatal de PHP o un rastreo de pila que mencione una aplicación o clase proporciona un objetivo de solución de problemas mucho más seguro que cambiar configuraciones del servidor no relacionadas.

Busque la primera excepción fatal relacionada con la solicitud fallida, no solo la cascada final de errores. Las categorías comunes incluyen una clase PHP faltante, una aplicación incompatible, un fallo en la conexión a la base de datos, una configuración ilegible, archivos de código faltantes o una excepción durante una actualización incompleta.

La documentación de registro de ownCloud indica que el registro DEBUG puede ser útil durante el diagnóstico, pero genera mucha información y puede afectar el rendimiento. Si aumenta temporalmente el nivel de registro, vuelva a un valor menos detallado después de recopilar la información. Consulte la configuración de registro de ownCloud .

4. ¿Deberías deshabilitar una aplicación de terceros?

Seleccione esta opción cuando el error indique una aplicación que no sea principal, cuando la página en blanco aparezca después de instalar o actualizar una aplicación, o cuando el fallo se produzca durante una actualización de ownCloud. La guía de solución de problemas de ownCloud recomienda explícitamente deshabilitar las aplicaciones de terceros para solucionar problemas y antes de las actualizaciones.

Primero enumera las aplicaciones. En ownCloud 10.x:

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

En ownCloud 11:

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

Leyenda: Deshabilitar únicamente la aplicación implicada en los registros resulta menos perjudicial que deshabilitar muchos componentes o cambiar toda la pila web.

La desventaja radica en la funcionalidad: los usuarios pierden la aplicación hasta que se actualice o se vuelva a habilitar. Esto suele ser preferible a deshabilitar los servicios principales de ownCloud. La documentación de OCC también indica que varias aplicaciones principales no se pueden deshabilitar, como DAV, FederatedFileSharing, Files y Files_External. Consulte la guía oficial de solución de problemas generales y la referencia de comandos de OCC .

5. ¿Cuándo merece la pena corregir los permisos?

Los permisos son una fuerte sospecha cuando el registro contiene errores Permission denied, una implementación reciente copió archivos de app/config como el usuario incorrecto, o una actualización reemplazó archivos con propiedad incorrecta. Son una sospecha débil cuando la única evidencia es un error de JavaScript del lado del navegador.

Ponga el sistema en modo de mantenimiento antes de realizar trabajos de reparación que puedan interrumpir el servicio. Para ownCloud 11:

docker compose exec owncloud occ maintenance:mode --on

Para una implementación tradicional de 10.x:

sudo -u www-data ./occ maintenance:mode --on

Leyenda: El modo de mantenimiento reduce la actividad del usuario mientras se investigan errores de propiedad o permisos de archivo que ya están respaldados por evidencia de registro.

No ejecute chmod 777recetas de permisos recursivas generales ni copie recetas de permisos de una versión no relacionada. El manual actual de ownCloud 11 documenta la propiedad y los modos específicos para los archivos agregados manualmente en los directorios montados appsen Docker config: propiedad www-data:root, archivos de la aplicación 0644, directorios de la aplicación 0751y archivos de configuración agregados 0644. También documenta los 0640cambios manuales . Utilice la documentación de actualización manual de ownCloud 11 como referencia específica de la versión..htaccess.user.ini

6. ¿Deberías cambiar los módulos de PHP, OPcache o la configuración de memoria?

Solo cuando los registros o las comprobaciones de compatibilidad apuntan a ello. Este método tiene un alcance mayor que deshabilitar una sola aplicación defectuosa. Una extensión PHP necesaria que falte puede impedir la ejecución del código, mientras que una configuración PHP incorrecta puede afectar a todas las aplicaciones PHP del servidor.

Para una pila PHP heredada administrada por el host, inspeccione lo que realmente carga el entorno de ejecución web:

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

Leyenda: Las comprobaciones de módulos PHP y OPcache son útiles cuando los registros del servidor indican extensiones faltantes o incompatibilidad en tiempo de ejecución, pero no deberían ser el primer cambio sin evidencia.

Para ownCloud 11, la imagen oficial gestiona el entorno de ejecución de PHP, por lo que cambiar los paquetes PHP del host generalmente no es la solución. ownCloud documenta que OPcache está habilitado por defecto en su imagen Docker. Consulte la documentación de almacenamiento en caché de memoria de ownCloud .

Si sospecha que la caché de código de operación (OPcache) está obsoleta tras reemplazar manualmente archivos PHP en una instalación antigua, reiniciar PHP-FPM o el servicio web/PHP correspondiente puede borrar la caché de código de operación local del proceso. La desventaja es una breve interrupción y un rendimiento inferior al de la caché en frío posteriormente. Realice este procedimiento después de corregir los archivos subyacentes, no como sustituto de la identificación del error.

7. ¿Se interrumpió una actualización o los archivos principales son inconsistentes?

Si la página en blanco apareció durante o inmediatamente después de una actualización, primero verifique el estado de la misma. La documentación de actualización de ownCloud recomienda usar OCC para la actualización y reparación en lugar de manipular la base de datos manualmente.

Para ownCloud 11:

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

Para ownCloud 10.x, utilice los comandos OCC equivalentes bajo el usuario del servidor web:

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

Leyenda: La reparación de OCC es apropiada para una actualización interrumpida o inconsistente, mientras que las comprobaciones de integridad pueden identificar archivos principales firmados modificados o faltantes.

Los resultados de integridad del código necesitan interpretación. ownCloud documenta INVALID_HASH, FILE_MISSINGy EXTRA_FILEcomo condiciones distintas. No edite signature.jsonpara hacer desaparecer las advertencias. La documentación actual de ownCloud 11 también hace que la firma de aplicaciones de terceros sea obligatoria para la instalación, las actualizaciones y la habilitación. Consulte la documentación de firma de código de ownCloud .

8. ¿Cómo se debe verificar la solución?

Una buena recuperación no se limita a que “la página ya no esté en blanco”. Verifique toda la ruta de la solicitud:

• La página principal de ownCloud devuelve el estado HTTP esperado en lugar de 500/502/503.
• Las herramientas para desarrolladores del navegador no muestran ningún error fatal recurrente de JavaScript ni la falta de paquetes principales.
• El registro de ownCloud no registra inmediatamente una nueva excepción fatal para la misma solicitud.
• occ statusInforma de una instancia instalada y de que no hay necesidad de actualización inesperada.
• El modo de mantenimiento se desactiva una vez finalizado el mantenimiento.
• Un usuario de prueba puede iniciar sesión y abrir la página de Archivos.

Para ownCloud 11:

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

Leyenda: La recuperación debe confirmarse en ambas capas: la interfaz de ownCloud se carga correctamente y el estado del servidor y las comprobaciones HTTP siguen funcionando correctamente.

¿Qué solución ofrece la mejor relación riesgo-beneficio?

Qué no hacer cuando ownCloud muestra una pantalla en blanco

• No habilite PHP display_errorsen un sitio de producción público solo para exponer los rastreos de pila al navegador; utilice los registros del servidor en su lugar.
• No establezca de forma recursiva permisos de escritura para todos los usuarios en todo el árbol de ownCloud.
• No degrade ownCloud mediante una reversión rápida a menos que esté restaurando una copia de seguridad compatible en un entorno compatible.
• No elimine aleatoriamente el directorio de datos, los datos de la aplicación, las tablas de la base de datos ni los directorios de caché.
• No desactive todas las aplicaciones a la vez cuando se puede aislar una aplicación específica.
• No edite los archivos de volcado firmados ni los utilice signature.jsonsimplemente para suprimir errores de integridad.

¿Cuándo conviene intensificar los esfuerzos en lugar de seguir experimentando?

Deje de realizar cambios cuando los registros indiquen corrupción de la base de datos, problemas con la clave de cifrado, fallos repetidos de integridad del núcleo tras una restauración limpia o un estado de actualización que no pueda completarse con el flujo de trabajo OCC documentado. Asimismo, escale el problema cuando la página en blanco afecte a un clúster de producción y no pueda aislar un único nodo sin poner en riesgo la coherencia de los datos.

Antes de abrir un caso de soporte, ownCloud recomienda recopilar un informe de configuración y los registros relevantes. Para ownCloud 10.x, el comando documentado es:

sudo -u www-data ./occ configreport:generate > config_report.txt

Utilice el método de ejecución OCC correspondiente a su implementación y revise la salida en busca de información confidencial antes de compartirla fuera de su organización. La guía de recopilación de registros y configuración de ownCloud explica qué información suelen necesitar los ingenieros de soporte.

Referencias oficiales

• Solución de problemas generales de ownCloud Classic 11
• Requisitos del sistema de ownCloud Classic 11
• Notas de la versión del servidor ownCloud
• Actualización manual de ownCloud Classic 11
• Configuración de registro de ownCloud