Si Google Drive desaparece de la interfaz Archivos de ZimaOS después de funcionar durante horas, determina primero si el sistema de archivos en la nube realmente se desmontó. En el caso original, los diagnósticos posteriores seguían mostrando montajes fuse.rclone y un proceso rclone rcd activo incluso después de que la unidad hubiera desaparecido de la interfaz.
Esto diferencia el incidente original de un cierre inesperado del proceso de rclone o de un fallo de autorización. Un miembro de la comunidad lo interpretó como una probable desincronización del estado entre Archivos y el sistema, pero IceWhale no publicó una causa raíz confirmada en el hilo. Los informes posteriores sobre bloqueos completos del sistema introdujeron un síntoma distinto y más grave que no debe mezclarse con el primer diagnóstico.
La unidad en la nube funcionaba, pero Archivos indicaba que no estaba montada
El usuario original ejecutaba ZimaOS 1.5.3 en una ZimaBoard 832. Google Drive se conectó correctamente y apareció en Archivos, pero a la mañana siguiente la interfaz indicaba que el almacenamiento no estaba montado. Los intentos de desconectarlo o desmontarlo desde la interfaz también fallaron.
Comprueba la capa de montaje por separado de la interfaz Archivos
El seguimiento más útil del hilo se recopiló inmediatamente después de que la unidad «desapareciera». mount | grep -i google seguía mostrando varios montajes fuse.rclone, y la lista de procesos todavía mostraba el proceso principal de control remoto de rclone.
Si puedes reproducir el problema, recopila las mismas pruebas antes de reiniciar o volver a conectar:
mount | grep -i google
ps aux | grep -i rcloneSi el montaje FUSE y el proceso de rclone siguen activos, la investigación debe centrarse en el seguimiento del estado de ZimaOS, la integración con Archivos o la visibilidad del montaje, en lugar de asumir simplemente que «Google Drive se desconectó». Si ambos han desaparecido, investiga la autenticación, la conectividad de red, los registros de rclone y el ciclo de vida del montaje.
Recopila al mismo tiempo los errores del kernel y de los servicios
El registro del kernel del usuario original también contenía errores de tipo «invalid opcode» repetidos relacionados con libjpeg.so.8.2.2. El hilo no demostró que esos errores causaran la desaparición de la unidad en la nube, por lo que deben registrarse como pruebas simultáneas y no elevarse a la categoría de causa raíz.
Usa marcas de tiempo para correlacionar cualquier mensaje de rclone, FUSE, el servicio Archivos, el kernel o fallos con la hora exacta en que desaparece la unidad. Una entrada de registro que simplemente exista en algún punto del historial de arranque constituye una prueba mucho más débil que una que se repita en el momento del fallo.
Las versiones actuales de ZimaOS siguen admitiendo Google Drive directamente en Archivos
La documentación actual de ZimaOS continúa describiendo el montaje directo de Google Drive, Dropbox y OneDrive desde la aplicación Archivos. También admite varias cuentas y permite eliminar una unidad en la nube conectada de la lista de almacenamiento.
Para los pasos de conexión y autorización, debe utilizarse la guía actual de unidades en la nube de ZimaOS en lugar de la interfaz anterior de la versión 1.5.3.
ZimaOS 1.7.1 no afirma solucionar este problema específico
El registro de cambios de ZimaOS 1.7.1, publicado el 24 de agosto de 2026, enumera mejoras de seguridad, memoria, copias de seguridad, USB, RAID, datos de aplicaciones, Docker y YAML. No menciona Google Drive, rclone, FUSE, montajes en la nube ni la gestión de archivos de intercambio como correcciones específicas.
La ausencia de esa mención significa que el hilo antiguo no puede darse por cerrado diciendo simplemente «actualiza a la versión 1.7.1 y estará solucionado». Aun así, actualizar a la versión estable actual es un primer paso sensato antes de intentar reproducir un error histórico, pero debes verificar el comportamiento y recopilar nuevas pruebas.
El registro de cambios completo de ZimaOS 1.7.1 establece el límite de la versión actual.
Un informe posterior de bloqueo del sistema correspondía a un fallo diferente
Más adelante, otro participante informó de un bloqueo mucho más amplio del sistema y compartió registros relacionados con el comportamiento de desmontaje de rclone y una dependencia de /DATA/.swapfile. Ese usuario planteó que la ubicación del archivo de intercambio en /DATA podría contribuir a un interbloqueo durante el desmontaje.
Se trata de una hipótesis informada de la comunidad, no de un defecto de arquitectura confirmado por IceWhale. No elimines, cambies de ubicación ni desactives el archivo de intercambio de ZimaOS basándote únicamente en esa teoría. Modificar el intercambio mientras se solucionan problemas de almacenamiento puede crear un problema de estabilidad independiente.
Qué guardar antes de volver a conectar la unidad
Cuando ocurra el problema, guarda la versión de ZimaOS, una captura de Archivos, la salida de los comandos de montaje, el estado del proceso de rclone, los registros recientes y una indicación de si las demás entradas de almacenamiento local y en la nube siguen funcionando. Anota también si el sistema continúa respondiendo mediante SSH y si solo la interfaz Archivos pierde la unidad.
Estos datos permiten distinguir un problema del estado de la interfaz de un desmontaje real de la nube o de un fallo de todo el sistema. Volver a conectar la unidad inmediatamente puede restablecer el acceso, pero también elimina las pruebas más útiles para determinar qué capa falló.
