Google Drive가 몇 시간 동안 정상 작동한 후 ZimaOS Files 인터페이스에서 사라진다면, 먼저 클라우드 파일 시스템이 실제로 마운트 해제되었는지 확인하세요. 원래 사례에서는 드라이브가 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와 관련된 잘못된 opcode 트랩도 반복적으로 기록되어 있었습니다. 해당 스레드에서는 이 오류가 클라우드 드라이브의 사라짐을 초래했다는 점을 입증하지 못했으므로, 이를 근본 원인으로 단정하지 말고 동시에 발생한 증거로 기록해야 합니다.
드라이브가 사라진 정확한 시점과 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 상태 문제인지, 실제 클라우드 마운트 해제인지, 아니면 전체 시스템 장애인지를 구분하는 데 도움이 됩니다. 즉시 다시 연결하면 접근성이 복구될 수 있지만, 어떤 계층에서 문제가 발생했는지 판단하는 데 가장 유용한 증거도 함께 사라집니다.
