数時間動作した後に Google Drive が ZimaOS の「ファイル」インターフェースから消えた場合は、まずクラウドファイルシステムが実際にアンマウントされたかどうかを確認してください。元の事例では、ドライブが UI から消えた後も、後続の診断で fuse.rclone マウントと、動作中の rclone rcd プロセスが確認されました。
この証拠から、元のインシデントは rclone プロセスの完全なクラッシュや認証失敗とは異なります。コミュニティの回答者は、Files/UI の状態が同期しなくなった可能性が高いと解釈しましたが、IceWhale はスレッド内で確認済みの根本原因を公表していません。その後に報告されたシステム全体のフリーズは、より深刻な別の症状であり、最初の診断と混同すべきではありません。
クラウドドライブは動作していたのに、Files では未マウントと表示された
元のユーザーは、ZimaBoard 832 で ZimaOS 1.5.3 を使用していました。Google Drive への接続は正常に完了し、Files に表示されていましたが、翌朝までにインターフェース上でストレージがマウントされていないと表示されました。UI から切断またはアンマウントしようとしても失敗しました。
Files UI とは別にマウント層を確認する
スレッドで最も有用だった追加調査は、ドライブが「消えた」直後に実施されました。mount | grep -i google は複数の fuse.rclone マウントを引き続き返し、プロセス一覧にもメインの rclone リモート制御プロセスが表示されました。
問題を再現できる場合は、再起動または再接続を行う前に、同じ情報を取得してください。
mount | grep -i google
ps aux | grep -i rcloneFUSE マウントと rclone プロセスが稼働している場合、調査の焦点は単純な「Google Drive の切断」ではなく、ZimaOS の状態追跡、Files との統合、またはマウントの可視性に移ります。両方とも消えている場合は、認証、ネットワーク接続、rclone ログ、マウントのライフサイクルを調査してください。
カーネルとサービスのエラーを同時に収集する
元のユーザーのカーネルログには、libjpeg.so.8.2.2 に関連する無効なオペコードトラップも繰り返し記録されていました。スレッドでは、これらのエラーがクラウドドライブの消失を引き起こしたとは証明されていないため、根本原因と断定せず、同時に発生した証拠として記録してください。
タイムスタンプを使って、ドライブが消えた正確な時刻と、rclone、FUSE、Files サービス、カーネル、クラッシュに関するメッセージを照合してください。起動履歴のどこかに存在するだけのログエントリは、障害発生時刻に繰り返し記録されたものよりも、はるかに弱い証拠です。
現在の ZimaOS でも Files から Google Drive を直接利用できる
現在の ZimaOS のドキュメントでは、Files アプリから Google Drive、Dropbox、OneDrive を直接マウントできると引き続き説明されています。また、複数のアカウントに対応しており、接続済みのクラウドドライブをストレージ一覧から削除することもできます。
現在の ZimaOS クラウドドライブガイドを使用して、古い 1.5.3 のインターフェースではなく、接続と認証の手順を確認してください。
ZimaOS 1.7.1 はこの特定の問題を修正したとは記載していない
2026 年 8 月 24 日公開の ZimaOS 1.7.1 の変更履歴には、セキュリティ、メモリ、バックアップ、USB、RAID、アプリデータ、Docker、YAML に関する改善が記載されています。Google Drive、rclone、FUSE、クラウドマウント、スワップファイルの処理は、修正項目として明記されていません。
つまり、「1.7.1 にアップグレードすれば直る」とだけ言って古いスレッドを終わらせることはできません。過去の不具合を再現する前に最新の安定版へ更新するのは合理的な最初の手順ですが、動作を検証し、新しい証拠を収集してください。
ZimaOS 1.7.1 の完全な変更履歴で、現在のリリース範囲を確認できます。
後から報告されたシステムフリーズは別の障害だった
その後、別の参加者が、より広範なシステムフリーズを報告し、rclone のアンマウント処理と /DATA/.swapfile への依存に関するログを共有しました。そのユーザーは、/DATA 上にスワップを配置していることが、アンマウント時のデッドロックに関係する可能性があると提案しました。
これは十分に根拠のあるコミュニティの仮説ですが、IceWhale が確認したアーキテクチャ上の欠陥ではありません。その説だけを根拠に、ZimaOS のスワップファイルを削除、移動、無効化しないでください。ストレージのトラブルシューティング中にスワップを変更すると、別の安定性問題が発生する可能性があります。
ドライブを再接続する前に保存しておく情報
問題が発生したら、ZimaOS のバージョン、Files のスクリーンショット、マウント出力、rclone のプロセス状態、直近のログ、その他のローカルおよびクラウドストレージ項目が引き続き動作しているかどうかを保存してください。また、SSH 経由ではシステムが応答するか、Files UI だけでドライブが失われているのかも記録してください。
これらの情報により、UI の状態に関する問題なのか、実際のクラウドアンマウントなのか、システム全体の障害なのかを区別できます。すぐに再接続すればアクセスは復旧するかもしれませんが、どの層で障害が発生したのかを判断するために最も有用な証拠も失われてしまいます。
