Se Google Drive scompare dall’interfaccia File di ZimaOS dopo aver funzionato per ore, verifica innanzitutto se il filesystem cloud è stato effettivamente smontato. Nel caso originale, le diagnostiche successive mostravano ancora mount fuse.rclone e un processo rclone rcd attivo, anche dopo che l’unità era scomparsa dall’interfaccia.
Questa evidenza distingue l’incidente originale da un arresto anomalo del processo rclone o da un errore di autorizzazione. Un membro della community lo ha interpretato come una probabile desincronizzazione dello stato tra File e il sistema, ma IceWhale non ha pubblicato una causa principale confermata nella discussione. Le segnalazioni successive di blocchi completi del sistema hanno introdotto un sintomo separato e più grave, che non dovrebbe essere accorpato alla prima diagnosi.
L’unità cloud funzionava, poi File ha indicato che non era montata
L’utente originale utilizzava ZimaOS 1.5.3 su uno ZimaBoard 832. Google Drive si collegava correttamente e appariva in File, ma la mattina seguente l’interfaccia indicava che lo spazio di archiviazione non era montato. Anche i tentativi di disconnetterlo o smontarlo dall’interfaccia non andavano a buon fine.
Controlla separatamente il livello di mount e l’interfaccia File
Il follow-up più utile nella discussione è stato raccolto subito dopo che l’unità era “scomparsa”. mount | grep -i google restituiva ancora diversi mount fuse.rclone e l’elenco dei processi mostrava ancora il processo principale di controllo remoto di rclone.
Se riesci a riprodurre il problema, raccogli le stesse informazioni prima di riavviare o riconnettere l’unità:
mount | grep -i google
ps aux | grep -i rcloneSe il mount FUSE e il processo rclone sono attivi, l’indagine deve concentrarsi sul tracciamento dello stato di ZimaOS, sull’integrazione con File o sulla visibilità del mount, invece di concludere semplicemente che “Google Drive si è disconnesso”. Se entrambi non sono più presenti, verifica invece l’autenticazione, la connettività di rete, i log di rclone e il ciclo di vita del mount.
Raccogli contemporaneamente gli errori del kernel e dei servizi
Il log del kernel dell’utente originale conteneva inoltre ripetuti trap per opcode non validi relativi a libjpeg.so.8.2.2. La discussione non ha dimostrato che questi errori abbiano causato la scomparsa dell’unità cloud, quindi devono essere registrati come elementi concomitanti e non indicati come causa principale.
Usa i timestamp per correlare eventuali messaggi relativi a rclone, FUSE, al servizio File, al kernel o a crash con l’ora esatta in cui l’unità scompare. Una voce di log semplicemente presente nella cronologia di avvio è una prova molto più debole rispetto a un errore che si ripete nel momento del problema.
Le versioni attuali di ZimaOS supportano ancora direttamente Google Drive in File
La documentazione attuale di ZimaOS continua a descrivere il mount diretto di Google Drive, Dropbox e OneDrive dall’app File. Supporta inoltre più account e la rimozione di un’unità cloud collegata dall’elenco degli spazi di archiviazione.
Guida attuale di ZimaOS alle unità cloud dovrebbe essere utilizzata per le procedure di connessione e autorizzazione, invece della vecchia interfaccia della versione 1.5.3.
ZimaOS 1.7.1 non dichiara di risolvere questo problema specifico
Il changelog di ZimaOS 1.7.1 del 24 agosto 2026 elenca miglioramenti relativi a sicurezza, memoria, backup, USB, RAID, dati delle app, Docker e YAML. Non indica Google Drive, rclone, FUSE, mount cloud o gestione dei file di swap come correzioni specifiche.
Questa assenza significa che la vecchia discussione non può essere chiusa semplicemente dicendo: “Aggiorna alla versione 1.7.1 e il problema è risolto”. Aggiornare all’ultima versione stabile rimane comunque un primo passo sensato prima di riprodurre un bug storico, ma è necessario verificare il comportamento e raccogliere nuove prove.
Changelog completo di ZimaOS 1.7.1 definisce il perimetro della versione attuale.
Una segnalazione successiva di blocco del sistema riguardava un guasto diverso
In seguito, un altro partecipante ha segnalato un blocco del sistema molto più esteso e ha condiviso log relativi al comportamento di smontaggio di rclone e a una dipendenza da /DATA/.swapfile. L’utente ha ipotizzato che la posizione dello swap su /DATA potesse contribuire a un deadlock durante lo smontaggio.
Si tratta di un’ipotesi informata della community, non di un difetto architetturale confermato da IceWhale. Non eliminare, spostare o disabilitare il file di swap di ZimaOS basandoti solo su questa teoria. Modificare lo swap durante la diagnosi di problemi di archiviazione può creare un ulteriore problema di stabilità.
Cosa salvare prima di riconnettere l’unità
Quando si verifica il problema, salva la versione di ZimaOS, uno screenshot di File, l’output dei mount, lo stato del processo rclone, i log recenti e indica se le altre unità locali e cloud continuano a funzionare. Specifica inoltre se il sistema rimane reattivo tramite SSH e se solo l’interfaccia File perde l’unità.
Questi dettagli permettono di distinguere un problema dello stato dell’interfaccia da un vero smontaggio dell’unità cloud o da un guasto dell’intero sistema. Riconnettere subito l’unità può ripristinare l’accesso, ma cancella anche le prove più utili per determinare quale livello abbia avuto il problema.
