Wenn Google Drive nach stundenlangem Betrieb aus der ZimaOS-Dateischnittstelle verschwindet, sollte zunächst festgestellt werden, ob das Cloud-Dateisystem tatsächlich ausgehängt wurde. Im ursprünglichen Fall zeigten spätere Diagnosen weiterhin fuse.rclone-Mounts und einen aktiven rclone rcd-Prozess, obwohl das Laufwerk aus der Benutzeroberfläche verschwunden war.
Diese Hinweise unterscheiden den ursprünglichen Vorfall von einem vollständigen Absturz des rclone-Prozesses oder einem Autorisierungsfehler. Ein Community-Mitglied deutete den Vorfall als wahrscheinliche Desynchronisierung des Zustands zwischen Files und der Benutzeroberfläche; IceWhale veröffentlichte im Thread jedoch keine bestätigte Ursache. Spätere Berichte über ein vollständiges Einfrieren des Systems beschrieben ein separates, schwerwiegenderes Symptom, das nicht mit der ersten Diagnose zusammengeführt werden sollte.
Das Cloud-Laufwerk funktionierte, dann meldete Files, es sei nicht eingebunden
Der ursprüngliche Nutzer verwendete ZimaOS 1.5.3 auf einem ZimaBoard 832. Google Drive wurde erfolgreich verbunden und in Files angezeigt, doch am nächsten Morgen meldete die Benutzeroberfläche, dass der Speicher nicht eingebunden sei. Auch Versuche, die Verbindung über die Benutzeroberfläche zu trennen oder das Laufwerk auszuhängen, schlugen fehl.
Die Mount-Ebene unabhängig von der Files-Benutzeroberfläche prüfen
Die nützlichste anschließende Untersuchung im Thread wurde unmittelbar nach dem „Verschwinden“ des Laufwerks durchgeführt. mount | grep -i google gab weiterhin mehrere fuse.rclone-Mounts aus, und die Prozessliste zeigte weiterhin den zentralen rclone-Remote-Control-Prozess.
Wenn sich das Problem reproduzieren lässt, sollten vor einem Neustart oder einer erneuten Verbindung dieselben Informationen erfasst werden:
mount | grep -i google
ps aux | grep -i rcloneWenn der FUSE-Mount und der rclone-Prozess noch aktiv sind, richtet sich die Untersuchung eher auf die Zustandsverfolgung durch ZimaOS, die Files-Integration oder die Sichtbarkeit des Mounts und nicht einfach auf eine „getrennte Google-Drive-Verbindung“. Sind beide nicht mehr vorhanden, sollten Authentifizierung, Netzwerkverbindung, rclone-Protokolle und der Lebenszyklus des Mounts untersucht werden.
Kernel- und Dienstfehler gleichzeitig erfassen
Das Kernel-Protokoll des ursprünglichen Nutzers enthielt außerdem wiederholte Invalid-Opcode-Traps im Zusammenhang mit libjpeg.so.8.2.2. Der Thread belegte nicht, dass diese Fehler das Verschwinden des Cloud-Laufwerks verursachten. Daher sollten sie als gleichzeitig aufgetretene Hinweise dokumentiert und nicht als Ursache dargestellt werden.
Anhand von Zeitstempeln sollte geprüft werden, ob rclone-, FUSE-, Files-Dienst-, Kernel- oder Absturzmeldungen zeitlich genau mit dem Verschwinden des Laufwerks zusammenfallen. Ein Protokolleintrag, der irgendwo in der bisherigen Startvorgeschichte vorhanden ist, liefert deutlich schwächere Belege als ein Eintrag, der zum Zeitpunkt des Fehlers wiederholt auftritt.
Aktuelle ZimaOS-Versionen unterstützen Google Drive weiterhin direkt in Files
Die aktuelle ZimaOS-Dokumentation beschreibt weiterhin das direkte Einbinden von Google Drive, Dropbox und OneDrive über die Files-App. Außerdem werden mehrere Konten sowie das Entfernen eines verbundenen Cloud-Laufwerks aus der Speicherliste unterstützt.
Aktuelle ZimaOS-Anleitung für Cloud-Laufwerke sollte für die Schritte zur Verbindung und Autorisierung verwendet werden, nicht die ältere Oberfläche von Version 1.5.3.
ZimaOS 1.7.1 beansprucht keine Behebung dieses konkreten Problems
Das Änderungsprotokoll von ZimaOS 1.7.1 vom 24. August 2026 nennt Verbesserungen bei Sicherheit, Speicherverwaltung, Backups, USB, RAID, App-Daten, Docker und YAML. Google Drive, rclone, FUSE, Cloud-Mounts oder die Verwaltung von Auslagerungsdateien werden darin nicht als konkrete behobene Probleme aufgeführt.
Das bedeutet, dass der alte Thread nicht einfach mit der Aussage „Auf 1.7.1 aktualisieren, dann ist es behoben“ abgeschlossen werden kann. Die Aktualisierung auf die aktuelle stabile Version ist dennoch ein sinnvoller erster Schritt, bevor ein historischer Fehler reproduziert wird. Anschließend sollte das Verhalten überprüft und neue Daten sollten erfasst werden.
Vollständiges Änderungsprotokoll von ZimaOS 1.7.1 markiert den aktuellen Versionsstand.
Ein später gemeldetes Einfrieren des Systems war ein anderer Fehler
Ein anderer Teilnehmer berichtete später von einem deutlich umfassenderen Systemstillstand und teilte Protokolle zum Verhalten beim Aushängen von rclone sowie zu einer Abhängigkeit von /DATA/.swapfile. Dieser Nutzer vermutete, dass die Platzierung des Swap-Speichers unter /DATA während des Aushängens zu einem Deadlock beitragen könnte.
Dies ist eine begründete Hypothese aus der Community, aber kein von IceWhale bestätigter Architekturfehler. Die ZimaOS-Swap-Datei sollte nicht allein aufgrund dieser Theorie gelöscht, verschoben oder deaktiviert werden. Änderungen am Swap während der Fehlersuche im Speicherbereich können ein separates Stabilitätsproblem verursachen.
Was vor dem erneuten Verbinden des Laufwerks gespeichert werden sollte
Wenn das Problem auftritt, sollten die ZimaOS-Version, ein Screenshot von Files, die Mount-Ausgabe, der Status der rclone-Prozesse, aktuelle Protokolle sowie die Information gespeichert werden, ob andere lokale und Cloud-Speichereinträge weiterhin funktionieren. Außerdem sollte festgehalten werden, ob das System über SSH erreichbar bleibt und ob nur die Files-Benutzeroberfläche das Laufwerk verliert.
Diese Angaben helfen dabei, ein Problem mit dem Zustand der Benutzeroberfläche von einem tatsächlichen Aushängen der Cloud oder einem Ausfall des gesamten Systems zu unterscheiden. Eine sofortige erneute Verbindung kann den Zugriff wiederherstellen, löscht jedoch zugleich die wichtigsten Hinweise darauf, welche Ebene ausgefallen ist.
