Se o Google Drive desaparecer da interface Ficheiros do ZimaOS depois de funcionar durante horas, determine primeiro se o sistema de ficheiros na nuvem foi realmente desmontado. No caso de origem, diagnósticos posteriores continuavam a mostrar montagens fuse.rclone e um processo rclone rcd ativo, mesmo depois de a unidade ter desaparecido da interface.
Essa evidência distingue o incidente original de uma falha completa do processo rclone ou de um problema de autorização. Um membro da comunidade interpretou-o como uma provável dessincronização do estado entre os Ficheiros e a interface, mas a IceWhale não publicou uma causa-raiz confirmada no tópico. Relatos posteriores de bloqueio total do sistema introduziram um sintoma diferente e mais grave, que não deve ser combinado com o primeiro diagnóstico.
A Unidade na Nuvem Funcionava, mas os Ficheiros Indicavam que Não Estava Montada
O utilizador original executava o ZimaOS 1.5.3 num ZimaBoard 832. O Google Drive foi ligado com êxito e apareceu nos Ficheiros, mas na manhã seguinte a interface indicava que o armazenamento não estava montado. As tentativas de o desligar ou desmontar através da interface também falharam.
Verifique a Camada de Montagem Separadamente da Interface Ficheiros
O acompanhamento mais útil no tópico foi recolhido imediatamente depois de a unidade ter “desaparecido”. O comando mount | grep -i google continuava a devolver várias montagens fuse.rclone, e a lista de processos continuava a mostrar o principal processo de controlo remoto do rclone.
Se conseguir reproduzir o problema, recolha as mesmas informações antes de reiniciar ou voltar a ligar:
mount | grep -i google
ps aux | grep -i rcloneSe a montagem FUSE e o processo rclone estiverem ativos, a investigação deve concentrar-se no acompanhamento do estado pelo ZimaOS, na integração com os Ficheiros ou na visibilidade da montagem, em vez de assumir simplesmente que o “Google Drive foi desligado”. Se ambos tiverem desaparecido, investigue a autenticação, a conectividade de rede, os registos do rclone e o ciclo de vida da montagem.
Recolha Simultaneamente os Erros do Kernel e dos Serviços
O registo do kernel do utilizador original também continha falhas repetidas de opcode inválido relacionadas com libjpeg.so.8.2.2. O tópico não provou que esses erros tivessem causado o desaparecimento da unidade na nuvem, pelo que devem ser registados como evidência concorrente, e não apresentados como causa-raiz.
Utilize marcas temporais para correlacionar quaisquer mensagens do rclone, FUSE, serviço Ficheiros, kernel ou falhas com a hora exata em que a unidade desaparece. Uma entrada de registo que exista simplesmente algures no histórico do arranque é uma evidência muito mais fraca do que uma entrada que se repita no momento da falha.
O ZimaOS Atual Continua a Suportar Diretamente o Google Drive nos Ficheiros
A documentação atual do ZimaOS continua a descrever a montagem direta do Google Drive, Dropbox e OneDrive a partir da aplicação Ficheiros. Também suporta várias contas e a remoção de uma unidade na nuvem ligada da lista de armazenamento.
Deve utilizar o guia atual de unidades na nuvem do ZimaOS para os passos de ligação e autorização, em vez da interface mais antiga da versão 1.5.3.
O ZimaOS 1.7.1 Não Afirma Corrigir Este Problema Específico
O registo de alterações do ZimaOS 1.7.1, de 24 de agosto de 2026, enumera melhorias de segurança, memória, cópias de segurança, USB, RAID, dados de aplicações, Docker e YAML. Não enumera o Google Drive, rclone, FUSE, montagens na nuvem ou a gestão do ficheiro de swap como correções identificadas.
Essa ausência significa que o tópico antigo não pode ser encerrado simplesmente dizendo “atualize para a versão 1.7.1 e ficará corrigido”. Atualizar para a versão estável atual continua a ser um primeiro passo sensato antes de reproduzir um erro histórico, mas verifique o comportamento e recolha novas evidências.
O registo de alterações completo do ZimaOS 1.7.1 define o limite da versão atual.
Um Relato Posterior de Bloqueio do Sistema Correspondia a uma Falha Diferente
Mais tarde, outro participante relatou um bloqueio do sistema muito mais abrangente e partilhou registos relacionados com o comportamento de desmontagem do rclone e uma dependência de /DATA/.swapfile. Esse utilizador sugeriu que a localização do swap em /DATA poderia contribuir para um deadlock durante a desmontagem.
Esta é uma hipótese fundamentada da comunidade, não um defeito de arquitetura confirmado pela IceWhale. Não elimine, desloque nem desative o ficheiro de swap do ZimaOS baseando-se apenas nessa teoria. Alterar o swap durante a resolução de problemas de armazenamento pode criar um problema de estabilidade separado.
O Que Guardar Antes de Voltar a Ligar a Unidade
Quando o problema ocorrer, guarde a versão do ZimaOS, uma captura de ecrã dos Ficheiros, o resultado da montagem, o estado do processo rclone, os registos recentes e a indicação sobre se as outras entradas de armazenamento local e na nuvem continuam a funcionar. Registe também se o sistema permanece responsivo através de SSH e se apenas a interface Ficheiros perde a unidade.
Esses detalhes permitem distinguir um problema do estado da interface de uma desmontagem real da nuvem ou de uma falha de todo o sistema. Voltar a ligar imediatamente pode restaurar o acesso, mas também elimina as evidências mais úteis para determinar qual camada falhou.
