Si el propio CasaOS se carga, pero la sección Aplicaciones solo muestra «No se han podido cargar las aplicaciones; vuelve a intentarlo más tarde» después de una actualización de Docker, comprueba los registros de CasaOS App Management antes de cambiar los permisos del sistema de archivos. En el caso de IceWhale Community de noviembre de 2025, el error decisivo no estaba en el panel en sí: CasaOS App Management intentaba utilizar la API de Docker 1.43, mientras que Docker Engine 29.0.1 requería como mínimo la API 1.44.
El mismo registro también contenía errores de permisos en /var/run/casaos, /var/log/casaos, y /var/lib/casaos, pero el rechazo de la API de Docker era un fallo de compatibilidad independiente que impedía que CasaOS mostrara información sobre contenedores y aplicaciones. Posteriormente, los responsables de CasaOS actualizaron el script de instalación para que funcionara con versiones más recientes de Docker y aplicara la compatibilidad de API correspondiente, por lo que los usuarios actuales deberían empezar con el instalador actualizado de CasaOS en lugar de degradar Docker de forma permanente.
El error que identificó el verdadero problema de compatibilidad
El autor original informó:
Respuesta de error del demonio:
la versión 1.43 del cliente es demasiado antigua.
La versión mínima de API compatible es la 1.44,
actualiza tu cliente a una versión más recienteEl entorno era:
- Ubuntu Server;
- Docker Engine 29.0.1;
- API de Docker 1.52;
- CasaOS App Management compilado en octubre de 2024.
Esto explica por qué el panel de CasaOS podía seguir abriéndose mientras fallaba la sección Aplicaciones: la interfaz web y el servicio de administración de aplicaciones respaldado por Docker son capas distintas.
Por qué una actualización de Docker podría interrumpir la lista de aplicaciones de CasaOS
Docker Engine expone una API versionada. Por lo general, los clientes de administración antiguos pueden negociar con demonios más recientes, pero Docker ha aumentado progresivamente la versión mínima de API que acepta.
La documentación actual de Docker explica la negociación de versiones de la API y señala que las versiones antiguas se están quedando obsoletas o se están eliminando gradualmente. Consulta la documentación de la API de Docker Engine.
En este caso de origen, CasaOS App Management se comunicaba mediante la API 1.43, mientras que el demonio Docker 29 rechazaba cualquier versión inferior a la 1.44. Por eso, la enumeración de aplicaciones fallaba antes de que la interfaz pudiera mostrar la lista.
Los errores de permisos eran reales, pero no constituían el mismo fallo
Los registros también contenían mensajes como:
open /var/run/casaos/app-management.url: permiso denegado
mkdir /var/lib/casaos/appstore/...tmp: permiso denegado
no se puede cambiar el nombre del archivo de registro... permiso denegadoEl autor ya había creado los directorios pertinentes de CasaOS y ajustado sus permisos, pero la Tienda de aplicaciones seguía sin funcionar. Ese resultado es importante: los cambios generales de permisos no podían solucionar una incompatibilidad con la API de Docker.
No de forma recursiva chmod 777 ni cambies la propiedad de los directorios del sistema de CasaOS solo porque la interfaz indique que las aplicaciones no se han podido cargar. Lee primero los registros exactos.
Lo que recomendaba la comunidad en aquel momento
MjTech respondió que se trataba de un problema conocido relacionado con Docker y remitió al autor a una solución de la comunidad BigBear para los errores de la API de Docker en CasaOS.
En aquel momento, entre las soluciones temporales habituales se incluían:
- reducir la versión mínima de la API de Docker aceptada por el daemon mediante una anulación de systemd;
- o usar temporalmente una versión anterior de Docker que aún aceptara la API del cliente de CasaOS.
Esas soluciones alternativas fueron valiosas en noviembre de 2025, pero no deberían convertirse automáticamente en el procedimiento permanente de 2026 porque posteriormente se actualizó el instalador de CasaOS.
CasaOS actualizó posteriormente el instalador
En diciembre de 2025, un mantenedor de CasaOS informó en GitHub de que el script de instalación se había corregido para:
- instalar la versión más reciente disponible de Docker Engine en lugar de la antigua versión objetivo 24.0.7 de Docker;
- aplicar la gestión de compatibilidad de la API de Docker para versiones más recientes de Docker;
- permitir que los servicios y las aplicaciones integradas de CasaOS funcionen con Docker moderno.
El mantenedor indicó específicamente que se podía usar una instalación limpia o el script de instalación actual para reparar el problema anterior por el que las aplicaciones de Docker no se cargaban.
Para consultar el código fuente actual, visita el script instalador de CasaOS.
Primera solución actual: usa el instalador actualizado de CasaOS
CasaOS documenta actualmente:
curl -fsSL https://get.casaos.io | sudo basho:
wget -qO- https://get.casaos.io | sudo bashAntes de ejecutar un instalador sobre un servidor existente, haz una copia de seguridad de las bases de datos y la configuración de las aplicaciones importantes. La reparación está diseñada para conservar el estado de CasaOS, pero un servidor doméstico nunca debería depender de un script de reparación como único plan de recuperación.
Las instrucciones de instalación actuales están disponibles en el repositorio de GitHub de CasaOS.
Verifica el error de la API antes de aplicar cualquier anulación de compatibilidad
Comprueba Docker:
docker versionEntonces inspecciona la gestión de aplicaciones de CasaOS:
sudo systemctl status casaos-app-management
sudo journalctl -u casaos-app-management --no-pager -n 100Si el registro contiene explícitamente:
la versión del cliente 1.43 es demasiado antigua
La versión mínima de API compatible es la 1.44entonces estás lidiando con la misma clase de fallo de la API de Docker que en el hilo original.
Si el registro muestra errores de disco lleno, fallos de DNS, un daemon de Docker detenido, un catálogo de la tienda de aplicaciones dañado o archivos faltantes, no apliques una solución alternativa de la API solo porque el mensaje de la interfaz sea idéntico.
Acerca de la anulación histórica de compatibilidad de la API de Docker
Las soluciones alternativas de la comunidad y GitHub durante el incidente de 2025 añadieron una configuración de entorno de systemd para Docker que volvió a permitir versiones antiguas de la API del cliente. Eso podía restaurar la lista de aplicaciones mientras CasaOS aún usaba la API 1.43.
Esto cambia el límite de compatibilidad del daemon de Docker. Trátalo como un mecanismo temporal de compatibilidad para una incompatibilidad verificada entre un cliente antiguo y un daemon nuevo, no como un ajuste genérico de CasaOS.
La documentación actual de Docker explica que la compatibilidad con APIs heredadas cambia con el tiempo y recomienda mantener los clientes actualizados en lugar de depender permanentemente de versiones antiguas de la API.
No establezcas DOCKER_API_VERSION a ciegas en CasaOS
De Docker DOCKER_API_VERSION variable obliga a un cliente a usar una versión específica de la API y desactiva la negociación normal de la API. Docker la documenta principalmente para los casos en los que se requiere una versión exacta de la API o para depuración.
Eso es distinto de hacer que un daemon de Docker más reciente acepte la API de un cliente antiguo de CasaOS. Establecer un valor arbitrario para la API del cliente puede empeorar la incompatibilidad.
Confirma también que Docker funciona correctamente
sudo systemctl status docker
docker psSi Docker está detenido, CasaOS no puede mostrar los contenedores en ejecución, independientemente de la versión de la API.
Comprueba el espacio en disco antes de reinstalar nada
El mismo mensaje de la interfaz «Failed to load apps» ha aparecido en casos no relacionados de CasaOS en los que el disco del sistema estaba casi lleno. Comprueba:
df -hUn sistema de archivos raíz lleno puede impedir los registros, los archivos temporales, las actualizaciones de la tienda de aplicaciones y el estado de Docker. No supongas que todos los banners idénticos de la interfaz tienen la misma causa.
Orden seguro de solución de problemas
- Confirma que el propio panel de CasaOS se abre.
- Comprueba
systemctl status dockerydocker ps. - Comprueba
df -h. - Lee
casaos-app-managementregistros. - Si los registros muestran la incompatibilidad de API 1.43/1.44, usa primero la ruta actual de instalación/reparación de CasaOS.
- Usa una anulación de compatibilidad de API únicamente cuando se haya verificado la incompatibilidad y la ruta de reparación actual no esté disponible.
- No relajes ampliamente los permisos de los directorios de CasaOS sin pruebas.
- Haz una copia de seguridad de los datos de las aplicaciones antes de reinstalar o realizar cambios en Docker a nivel del sistema.
Preguntas frecuentes sobre «Failed to Load Apps» en CasaOS
¿Por qué funciona el panel de CasaOS mientras que las aplicaciones no?
La interfaz, los servicios de CasaOS, el daemon de Docker y CasaOS App Management son componentes independientes. El caso de origen fallaba específicamente cuando App Management intentaba consultar Docker.
¿Docker 29 fue la causa en el hilo de origen?
Los registros de origen mostraban que Docker 29.0.1 requería la API 1.44, mientras que el cliente de CasaOS App Management instalado usaba la API 1.43. Esa incompatibilidad impedía directamente mostrar las aplicaciones.
¿Debería ejecutar chmod en las carpetas de CasaOS para solucionar la página?
No sin pruebas. El autor original ya modificó los permisos y aun así tuvo el fallo de la API de Docker. Lee primero los registros exactos del servicio.
¿Debería cambiar a una versión anterior de Docker?
Esa fue una solución alternativa histórica. Posteriormente, CasaOS actualizó su instalador para admitir la compatibilidad con versiones modernas de Docker, así que usa la ruta actual de reparación/instalación antes de forzar una versión anterior de Docker.
¿«Failed to load apps» siempre significa que hay una incompatibilidad de la API de Docker?
No. El mismo mensaje de la interfaz puede deberse a un daemon de Docker detenido, al disco lleno, a permisos, a fallos en la gestión de aplicaciones u otros problemas de servicios. Los registros determinan el diagnóstico.
