Si Google Drive disparaît de l’interface Fichiers de ZimaOS après avoir fonctionné pendant plusieurs heures, déterminez d’abord si le système de fichiers cloud a réellement été démonté. Dans le cas étudié, les diagnostics effectués ultérieurement affichaient toujours des montages fuse.rclone et un processus rclone rcd actif, même après la disparition du lecteur de l’interface.
Ces éléments distinguent l’incident initial d’un arrêt net du processus rclone ou d’un échec d’autorisation. Un membre de la communauté l’a interprété comme une probable désynchronisation de l’état entre Fichiers et le système, mais IceWhale n’a pas publié de cause racine confirmée dans le fil. Des signalements ultérieurs de gel complet du système ont fait apparaître un symptôme distinct et plus grave, qui ne doit pas être confondu avec le premier diagnostic.
Le lecteur cloud fonctionnait, puis Fichiers indiquait qu’il n’était pas monté
L’utilisateur initial exécutait ZimaOS 1.5.3 sur un ZimaBoard 832. Google Drive s’était connecté correctement et apparaissait dans Fichiers, mais le lendemain matin, l’interface indiquait que le stockage n’était pas monté. Les tentatives de déconnexion ou de démontage depuis l’interface échouaient également.
Vérifiez séparément la couche de montage et l’interface Fichiers
Le suivi le plus utile du fil a été recueilli immédiatement après la « disparition » du lecteur. mount | grep -i google renvoyait toujours plusieurs montages fuse.rclone, et la liste des processus affichait encore le processus principal de contrôle à distance rclone.
Si vous pouvez reproduire le problème, recueillez les mêmes éléments avant de redémarrer ou de reconnecter le lecteur :
mount | grep -i google
ps aux | grep -i rcloneSi le montage FUSE et le processus rclone sont actifs, l’enquête doit s’orienter vers le suivi de l’état de ZimaOS, l’intégration de Fichiers ou la visibilité du montage, plutôt que de conclure simplement que « Google Drive s’est déconnecté ». Si les deux ont disparu, examinez plutôt l’authentification, la connectivité réseau, les journaux rclone et le cycle de vie du montage.
Capturez simultanément les erreurs du noyau et des services
Le journal du noyau de l’utilisateur initial contenait également des pièges répétés d’opcodes invalides impliquant libjpeg.so.8.2.2. Le fil n’a pas démontré que ces erreurs étaient à l’origine de la disparition du lecteur cloud ; elles doivent donc être consignées comme des éléments concomitants, et non présentées comme la cause racine.
Utilisez les horodatages pour mettre en corrélation les messages rclone, FUSE, du service Fichiers, du noyau ou liés à un plantage avec l’heure exacte à laquelle le lecteur disparaît. Une entrée de journal simplement présente quelque part dans l’historique du démarrage constitue un indice bien plus faible qu’un message qui se répète au moment de la défaillance.
Les versions actuelles de ZimaOS prennent toujours en charge Google Drive directement dans Fichiers
La documentation actuelle de ZimaOS décrit toujours le montage direct de Google Drive, Dropbox et OneDrive depuis l’application Fichiers. Elle prend également en charge plusieurs comptes et la suppression d’un lecteur cloud connecté de la liste des stockages.
Guide actuel des lecteurs cloud de ZimaOS doit être utilisé pour les étapes de connexion et d’autorisation, plutôt que l’ancienne interface 1.5.3.
ZimaOS 1.7.1 ne revendique pas la correction spécifique de ce problème
Le journal des modifications de ZimaOS 1.7.1 du 24 août 2026 répertorie des améliorations de sécurité, de mémoire, de sauvegarde, d’USB, de RAID, de données d’application, de Docker et de YAML. Il ne mentionne pas Google Drive, rclone, FUSE, les montages cloud ou la gestion des fichiers d’échange comme corrections spécifiques.
Cette absence signifie qu’il n’est pas possible de clore l’ancien fil en affirmant simplement : « mettez à niveau vers la version 1.7.1 et le problème est résolu ». La mise à jour vers la version stable actuelle reste une première étape judicieuse avant de reproduire un ancien problème, mais vérifiez le comportement et recueillez de nouveaux éléments.
Journal complet des modifications de ZimaOS 1.7.1 définit la limite de la version actuelle.
Un signalement ultérieur de gel du système correspondait à une autre défaillance
Un autre participant a ensuite signalé un gel beaucoup plus étendu du système et partagé des journaux concernant le comportement de démontage de rclone ainsi qu’une dépendance envers /DATA/.swapfile. Selon son hypothèse, l’emplacement du fichier d’échange sur /DATA pourrait contribuer à un interblocage lors du démontage.
Il s’agit d’une hypothèse éclairée de la communauté, et non d’un défaut d’architecture confirmé par IceWhale. Ne supprimez pas, ne déplacez pas et ne désactivez pas le fichier d’échange de ZimaOS en vous fondant uniquement sur cette théorie. Modifier l’espace d’échange pendant le dépannage du stockage peut créer un problème de stabilité distinct.
Éléments à enregistrer avant de reconnecter le lecteur
Lorsque le problème survient, enregistrez la version de ZimaOS, une capture d’écran de Fichiers, la sortie des commandes de montage, l’état du processus rclone, les journaux récents et indiquez si les autres entrées de stockage local et cloud fonctionnent toujours. Notez également si le système reste réactif via SSH et si seule l’interface Fichiers perd le lecteur.
Ces informations permettent de distinguer un problème d’état de l’interface d’un véritable démontage cloud ou d’une défaillance générale du système. Reconnecter immédiatement le lecteur peut rétablir l’accès, mais cela efface également les éléments les plus utiles pour déterminer quelle couche a échoué.
