Om Google Drive försvinner från ZimaOS Files-gränssnittet efter att ha fungerat i flera timmar bör du först ta reda på om molnfilsystemet faktiskt avmonterades. I det ursprungliga fallet visade senare diagnostik fortfarande fuse.rclone-monteringar och en aktiv rclone rcd-process, även efter att enheten hade försvunnit från gränssnittet.
Detta tyder på att den ursprungliga incidenten skilde sig från en ren krasch av rclone-processen eller ett auktoriseringsfel. En person i communityn tolkade det som en sannolik desynkronisering av tillståndet mellan Files och systemet, men IceWhale publicerade ingen bekräftad grundorsak i tråden. Senare rapporter om att hela systemet frös innebar ett separat och allvarligare symtom som inte bör slås ihop med den första diagnosen.
Molnenheten fungerade, men Files sade att den inte var monterad
Den ursprungliga användaren körde ZimaOS 1.5.3 på en ZimaBoard 832. Google Drive anslöts utan problem och visades i Files, men nästa morgon rapporterade gränssnittet att lagringen inte var monterad. Försök att koppla från eller avmontera den via gränssnittet misslyckades också.
Kontrollera monteringslagret separat från Files-gränssnittet
Den mest användbara uppföljningen i tråden samlades in direkt efter att enheten hade ”försvunnit”. mount | grep -i google returnerade fortfarande flera fuse.rclone-monteringar, och processlistan visade fortfarande den huvudsakliga rclone-fjärrstyrningsprocessen.
Om du kan återskapa problemet bör du samla in samma information innan du startar om eller ansluter igen:
mount | grep -i google
ps aux | grep -i rcloneOm FUSE-monteringen och rclone-processen fortfarande körs bör utredningen inriktas på ZimaOS tillståndsspårning, Files-integrationen eller monteringssynligheten, snarare än att helt enkelt anta att ”Google Drive kopplades från”. Om båda har försvunnit bör du i stället undersöka autentisering, nätverksanslutning, rclone-loggar och monteringsförloppet.
Samla in kärn- och tjänstefel samtidigt
Den ursprungliga användarens kärnlogg innehöll också upprepade fällor för ogiltiga opkoder som berörde libjpeg.so.8.2.2. Tråden bevisade inte att dessa fel orsakade att molnenheten försvann, så de bör dokumenteras som samtidiga observationer och inte framställas som en grundorsak.
Använd tidsstämplar för att koppla eventuella meddelanden från rclone, FUSE, Files-tjänsten, kärnan eller krascher till den exakta tidpunkten då enheten försvinner. En loggpost som bara förekommer någonstans i starthistoriken är betydligt svagare bevis än en som upprepas när felet inträffar.
Aktuella ZimaOS har fortfarande direkt stöd för Google Drive i Files
Den aktuella ZimaOS-dokumentationen beskriver fortfarande direkt montering av Google Drive, Dropbox och OneDrive från Files-appen. Den stöder även flera konton och borttagning av en ansluten molnenhet från lagringslistan.
Aktuell guide för molnenheter i ZimaOS bör användas för anslutnings- och auktoriseringssteg i stället för det äldre gränssnittet i version 1.5.3.
ZimaOS 1.7.1 hävdar inte att just detta problem är åtgärdat
Ändringsloggen för ZimaOS 1.7.1 från den 24 augusti 2026 listar förbättringar av säkerhet, minne, säkerhetskopiering, USB, RAID, appdata, Docker och YAML. Den nämner inte Google Drive, rclone, FUSE, molnmonteringar eller hantering av växlingsfiler som en specifik åtgärd.
Det innebär att den gamla tråden inte kan avslutas genom att helt enkelt säga ”uppgradera till 1.7.1 så är problemet löst”. Att uppdatera till den aktuella stabila versionen är fortfarande ett klokt första steg innan du försöker återskapa ett historiskt fel, men verifiera beteendet och samla in nya bevis.
Fullständig ändringslogg för ZimaOS 1.7.1 visar den aktuella versionsgränsen.
En senare rapport om att systemet frös gällde ett annat fel
En annan deltagare rapporterade senare att hela systemet hade frusit och delade loggar som berörde rclones avmonteringsbeteende samt ett beroende av /DATA/.swapfile. Användaren föreslog att en växlingsfil på /DATA kunde bidra till ett dödläge under avmontering.
Detta är en välgrundad hypotes från communityn, inte en arkitekturdefekt som har bekräftats av IceWhale. Ta inte bort, flytta eller inaktivera ZimaOS växlingsfil enbart utifrån den teorin. Att ändra växlingsfilen under felsökning av lagring kan skapa ett separat stabilitetsproblem.
Detta bör du spara innan du ansluter enheten igen
När problemet uppstår bör du spara ZimaOS-versionen, en skärmbild från Files, monteringsutdata, rclone-processens tillstånd, aktuella loggar samt information om huruvida andra lokala lagringsenheter och molnenheter fortfarande fungerar. Notera även om systemet fortfarande svarar via SSH och om det bara är Files-gränssnittet som tappar enheten.
Den informationen skiljer ett problem med gränssnittets tillstånd från en verklig avmontering av molnenheten eller ett fel i hela systemet. Att ansluta igen direkt kan återställa åtkomsten, men det raderar också de mest användbara bevisen för att avgöra vilket lager som slutade fungera.
