Den ursprungliga begäran var bredare än ”anslut Google Drive”. Användaren ville ha flera konton för Google Drive, Dropbox, OneDrive, Box och MEGA, med tvåvägsliknande synkroniserings-/överföringsbeteende, men utan att behöva avsätta en Ubuntu-VM åt en kommersiell GoodSync-klient.
ZimaOS har utvecklats avsevärt för detta användningsområde. Aktuella Files kan ansluta direkt till Google Drive, Dropbox och OneDrive, stöder flera konton från samma leverantör och låter användare kopiera/flytta data mellan molnlagring och lokal lagring. Aktuella Backup kan också använda moln-, LAN-, USB- eller Zima-källor/mål med scheman och versioner. Det är fortfarande inte identiskt med alla GoodSync-funktioner – särskilt inte godtycklig leverantörstäckning, konfliktregler och verklig tvåvägssynkronisering.
Aktuella Files stöder flera konton från samma molnleverantör
IceWhales aktuella dokumentation för Cloud Drives säger uttryckligen att användare kan ansluta två Google Drive- eller två OneDrive-konton sida vid sida. Anslutna molnmappar visas bredvid lokal lagring i Files.
Se det aktuella arbetsflödet för Cloud Drives med flera konton.
Backup och synkronisering är inte samma åtgärd
Den aktuella dokumentationen för IceWhale Backup varnar uttryckligen för att molnsynkronisering speglar ändringar – inklusive borttagningar – medan Backup skriver framåt och behåller versioner/återställningspunkter. Använd Backup när skydd är målet; använd kopiera/flytta/synkronisera endast när du förstår innebörden av borttagningar.
Använd den aktuella versionshanterade Backup-modellen.
rclone förblir ett kraftfullt alternativ för flera molntjänster
Communityn föreslog rclone eftersom det stöder många molntjänster och flera fjärranslutningar eller konton, med betydligt mindre omkostnader än en fullständig Ubuntu-VM.
Samma svar varnade upprepade gånger för att rclone sync kan radera filer på målet för att få de två sidorna att matcha. Nya användare rekommenderades att börja med enkelriktad copy mot testdata som kan tas bort.
En användare stötte på Docker-socketbehörighet innan rclone ens startade
SirWill's CLI-försök misslyckades eftersom den aktuella skalanvändaren inte kunde ansluta till /var/run/docker.sock. Det var ett Docker-behörighetsproblem, inte ett tecken på att rclone i sig var trasigt.
Custom App-gränssnittet skickade också rclone-kommandot felaktigt
rcd ... kommandot som ett argument i stället för separata argument.Communityn kom fram till att en korrekt Docker Compose-definition är tydligare eftersom varje argument anges explicit och kan återskapas.
IceWhale tog sig an funktionsförfrågan
777-Spider frågade om en utökning av den inbyggda Backup-appen med fler molntjänster och synkronisering skulle uppfylla behovet. I januari 2026 sade han att en synkroniseringsfunktion var planerad inom ungefär tre månader och att ytterligare molnintegrationer fanns med på färdplanen.
Det påståendet är historiska belägg från färdplanen, inte en garanti för att alla föreslagna GoodSync-funktioner har lanserats. Utvärdera den aktuella funktionsuppsättningen i Files/Backup direkt.
Ett säkert aktuellt val beror på uppgiften
- Bläddra bland, kopiera och flytta filer mellan Google Drive, Dropbox, OneDrive och lokal lagring: använd den aktuella Files-appen.
- Versionshanterat schemalagt skydd: använd Backup.
- Ejdrar eller komplexa överföringar som inte stöds: överväg rclone med testade fjärranslutningar och försiktiga kommandon.
- Tvåvägssynkronisering och konfliktpolicyer i kommersiell klass: kontrollera om den funktion du behöver finns innan du ersätter GoodSync.
Det inbyggda molnstödet täcker inte alla leverantörer i begäran
Den ursprungliga önskelistan omfattade Google Drive, Dropbox, OneDrive, Box och MEGA. Den aktuella dokumentationen från IceWhale om molnlagring täcker uttryckligen Google Drive, Dropbox och OneDrive. Antyd inte att Box och MEGA har samma inbyggda integration om inte det aktuella gränssnittet eller dokumentationen lägger till dem.
Den kvarstående luckan i leverantörsstödet är en av anledningarna till att rclone eller en annan extern synkroniseringsmotor fortfarande kan vara relevant.
Exponera inte ett rclone-webbgränssnitt som startats med --rc-no-auth
Communityts Docker-exempel använde medvetet --rc-no-auth och märkte det som ”endast LAN”. Det tar bort autentiseringen från rclones fjärrstyrnings-/webbgränssnitt. Alla som kan nå porten kan få kraftfull kontroll över filöverföringar.
Använd det i ett betrott nätverk eller konfigurera autentisering och en skyddad åtkomstväg innan fjärranvändning.
OAuth för molntjänster är en del av den operativa komplexiteten
Tråden dokumenterar också problem med Google-autentisering och omdirigering samt skillnader mellan CLI- och containerbaserade webbläsarflöden. När en molnanslutning misslyckas bör du skilja på leverantörens OAuth-/omdirigeringsproblem, Docker-behörigheter, rclone-kommandosyntax och ZimaOS-lagringsmappningar.
Testa raderingssemantiken med tillfälliga data
Ett arbetsflöde i stil med GoodSync är värdefullt eftersom det tydliggör riktning och konflikthantering. Innan du schemalägger någon rclone synkronisering eller någon annan speglingsåtgärd: skapa två tillfälliga mappar, lägg till och radera filer på båda sidorna och kontrollera exakt vilken sida som vinner.
Vanliga frågor om synkronisering med flera molntjänster
Kan aktuella ZimaOS ansluta flera konton från samma leverantör?
Ja. Den aktuella dokumentationen om molnlagring stöder uttryckligen flera konton från samma tjänst.
Är säkerhetskopiering samma sak som tvåvägssynkronisering?
Nej. Den aktuella dokumentationen från IceWhale skiljer uttryckligen mellan säkerhetskopiering/versionshantering och synkronisering/spegling.
Är rclone säkert för nybörjare som standard?
Nej. Källgemenskapen varnar upprepade gånger för att riktning och raderingssemantik måste testas noggrant.
