Cuando Archivos de ZimaOS muestra Error al cargar, pero el acceso SMB desde Windows sigue funcionando, no asumas de inmediato que el RAID o los datos han desaparecido. Ese fue el patrón en este hilo de febrero de 2026: la interfaz de Archivos falló después de la actualización 1.5.4, mientras que otras aplicaciones y el acceso a archivos mediante Samba seguían funcionando.
Posteriormente, el personal de IceWhale estableció el límite más importante de la causa raíz. raller1028 indicó que, en ZimaOS 1.5.4, cuando el disco del sistema está lleno, el servicio de Archivos puede dejar de funcionar correctamente. La recuperación oficial consistía en liberar espacio en el disco del sistema y reiniciar icewhale-files. Una solución alternativa de la comunidad que consistía en cambiar el nombre de la base de datos ayudó a varios usuarios, pero IceWhale no la presentó como la solución inicial.
Que SMB siga funcionando es una prueba sólida de que los datos y los montajes aún existen
El autor original todavía podía acceder a los archivos mediante un recurso compartido de Samba en Windows. Esto significa que el almacenamiento del equipo y la ruta de datos seguían activos, aunque la aplicación web Archivos no pudiera mostrarlos.
Esta es una distinción importante entre:
- pérdida de almacenamiento o datos;
- fallo del servicio de Archivos;
- fallo del navegador o de la interfaz.
Archivos no es un contenedor Docker normal de la tienda de aplicaciones
Por lo tanto, es normal que docker ps no muestre un contenedor de Archivos. Reiniciar contenedores Docker al azar no reparará el servicio nativo de Archivos.
IceWhale identificó el almacenamiento del sistema lleno como el desencadenante en 1.5.4
El 26 de febrero, raller1028, de IceWhale, escribió que el problema “debería” deberse a que el disco del sistema estaba lleno en la versión 1.5.4.
La secuencia de recuperación oficial era:
- liberar espacio en el disco del sistema mediante la línea de comandos;
- reiniciar el servicio de Archivos:
systemctl restart icewhale-filesA los usuarios que no conocían la limpieza mediante la línea de comandos se les indicó que contactaran con el soporte técnico en lugar de eliminar archivos a ciegas.
Por qué un disco del sistema lleno puede interrumpir Archivos mientras SMB sigue funcionando
Los servicios nativos necesitan espacio de trabajo para bases de datos, estados, archivos temporales, registros u operaciones del servicio. Los datos grandes del usuario pueden permanecer intactos en otra matriz de almacenamiento mientras una pequeña partición del sistema alcanza el 100 % de uso y provoca un fallo específico del servicio.
Por eso, comprobar únicamente que “mi RAID tiene espacio libre” no es suficiente.
Mantén los datos crecientes de las aplicaciones fuera de la unidad del sistema
La documentación actual de ZimaOS recomienda mover los datos de las aplicaciones a un espacio de almacenamiento real, en lugar de permitir que las bases de datos de Docker, las miniaturas y las cachés llenen el disco del sistema.
Consulta las recomendaciones actuales de almacenamiento de aplicaciones de ZimaOS para evitar otra fuente de presión sobre la unidad del sistema.
Cambiar el nombre de files.db funcionó para varios usuarios
Posteriormente, un usuario de la comunidad publicó:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesVarios participantes respondieron que esto restauró Archivos.
Aun así, debe considerarse una vía de recuperación secundaria de la comunidad. El personal de IceWhale preguntó inmediatamente cuál era la importancia de eliminar la base de datos de Archivos y no sustituyó la recomendación oficial de “liberar espacio del sistema y reiniciar el servicio” por este comando.
Cambiar el nombre de una base de datos es más seguro que eliminarla, pero aun así modifica el estado de la aplicación
El comando de la comunidad conserva una copia .bak en lugar de borrar la base de datos. Esto facilita la reversión, pero la reconstrucción de la base de datos de Archivos puede modificar los metadatos indexados u otro estado del servicio.
No lo uses como primera medida cuando el disco del sistema simplemente está lleno.
No des por hecho que el error de 1.5.4 persiste en el ZimaOS actual
El ZimaOS actual es la versión 1.7.x y ha seguido recibiendo correcciones para Archivos, almacenamiento, memoria, seguridad y almacenamiento de aplicaciones. Este problema histórico es útil porque enseña a distinguir un fallo del servicio de una pérdida de datos, no porque todos los errores modernos de Archivos tengan la misma causa.
Si el problema vuelve a aparecer hoy, registra primero el espacio libre actual del sistema, la versión actual, el estado del servicio y si SMB u otro método de acceso a archivos sigue funcionando.
Libera espacio deliberadamente
No ejecutes scripts de limpieza generales en directorios del sistema desconocidos. Identifica las cachés grandes de aplicaciones, los datos de Docker, las copias de seguridad o los registros, y utiliza los controles actuales de limpieza o migración de ZimaOS siempre que sea posible.
Preguntas frecuentes sobre el error al cargar de Archivos
¿SMB seguía funcionando en el caso original?
Sí, lo que sugería firmemente que los datos y los montajes seguían presentes.
¿Qué identificó el personal de IceWhale como el problema de 1.5.4?
Un disco del sistema lleno que hacía que el servicio de Archivos dejara de funcionar correctamente.
¿Cuál era el comando oficial para reiniciar el servicio?
systemctl restart icewhale-files.
¿Cambiar el nombre de files.db era la recomendación oficial inicial?
No. Era una solución alternativa de la comunidad que varios usuarios confirmaron, mientras que la recomendación inicial de IceWhale era liberar espacio y reiniciar el servicio de Archivos.
