Att logga in på ZimaOS via SSH och upptäcka att systemmapparna är skrivskyddade betyder inte att ditt konto är trasigt. ZimaOS skyddar avsiktligt det mesta av operativsystemets filsystem från normala skrivningar, även när en användare utökar sina behörigheter. Källtråden från februari 2026 började som en fråga om SSH-behörigheter men visade snabbt ett mer användbart mål: att automatiskt hämta mobilfoton från OneDrive till NAS-lagring och sedan göra filerna tillgängliga för Immich.
Den viktiga designinsikten är att skilja det oföränderliga systemlagret från skrivbar data. Använd SSH eller webbterminalen för administration och lagra användarskapade skript, konfiguration och programdata under /DATA eller en annan hanterad lagringsplats, och undvik att försöka göra ZimaOS till en konventionell Ubuntu-server genom att installera paket i det skyddade rotfilsystemet.
Skrivskyddad SSH-åtkomst är normalt i ZimaOS
Den ursprungliga användaren kunde autentisera sig med sitt vanliga ZimaOS-användarnamn och lösenord, men kunde inte skriva där de förväntade sig eller installera rclone som om värden vore Debian eller Ubuntu. Ett första svar föreslog sudo eller sudo -i, men en annan deltagare i communityt gjorde korrekt åtskillnad mellan behörighet och filsystemets skrivbarhet: att bli root gör inte en skrivskyddad systemavbildning skrivbar.
Den aktuella CLI-vägledningen från IceWhale bekräftar nu detta direkt: de flesta systemmappar är skrivskyddade även när du är inloggad som root, medan användar- och programdata finns under /DATA.
Använd den aktuella CLI-modellen för ZimaOS-filsystemet innan du tolkar en misslyckad skrivning under /usr, /app eller en annan systemsökväg som ett behörighetsfel.
sudo ändrar behörigheter, inte rotfilsystemets utformning
sudo är fortfarande användbart när ett kommando kräver utökade behörigheter, men kan inte kringgå ett filsystem som ZimaOS avsiktligt monterar skrivskyddat. Det förklarar varför ”försök som root” kan vara fel svar när felet är Filsystemet är skrivskyddat i stället för Åtkomst nekad.
För varaktig anpassning placerar du skript och data på skrivbart lagringsutrymme. Bygg inte ett arbetsflöde som är beroende av att basavbildningen för operativsystemet ändras manuellt, eftersom uppdateringar kan ersätta eller ogiltigförklara ändringarna även om en tillfällig lösning fungerar.
Aktuella ZimaOS aktiverar SSH från utvecklarläget
SSH är fortfarande en stödd administrationsväg. Aktuella ZimaOS har en växel för SSH-åtkomst under Inställningar > Utvecklarläge och erbjuder även en webbläsarterminal.
Följ den aktuella konfigurationen av SSH och webbterminalen i stället för att anta att skrivskyddade systemmappar innebär att SSH bara är delvis aktiverat.
Källanvändaren ville ha OneDrive → NAS → Immich
Användarens avsedda arbetsflöde var:
- ladda upp en liten omgång telefonfoton och -videor till det kostnadsfria OneDrive-utrymmet;
- regelbundet överföra dessa filer från OneDrive till NAS-enheten;
- göra den lokala destinationen tillgänglig för Immich;
- Efter att ha bekräftat överföringen tar du bort molnkopiorna så att det begränsade OneDrive-utrymmet kan återanvändas.
Detta är mer än vanlig säkerhetskopiering. Det innehåller ett destruktivt slutsteg: att radera källan efter en lyckad överföring.
Backup-appen från februari 2026 beskrevs som kopiering/synkronisering, inte flytt
I källtråden lade användaren märke till att den inbyggda Backup-appen kopierade OneDrive-data men inte tömde molnmappen efteråt. Ett svar från communityn sade att detta var avsiktligt och beskrev Backup-appen som icke-destruktiv, utan något alternativ för borttagning efter kopiering i det gränssnittet.
Det påståendet hör till källmiljön från februari 2026. Det var en förklaring från communityn snarare än ett svar från IceWhale-personal i tråden, så det bör inte låsas fast som ett permanent påstående att ”ZimaOS aldrig kan flytta molnfiler”.
Aktuella ZimaOS Files kan flytta molndata till lokal lagring
Den aktuella dokumentationen från IceWhale visar nu hur OneDrive, Google Drive och Dropbox monteras direkt i Files. Den beskriver också hur man väljer molninnehåll, väljer ett lokalt lagringsutrymme, startar en flytt och verifierar den slutförda överföringen.
För tillfällig eller manuellt övervakad migrering kan du använda det aktuella arbetsflödet för överföring från moln till lokal lagring i Files. Det är enklare än att bygga en rclone-container när överföringen inte behöver schemaläggas utan tillsyn.
Säkerhetskopiering och flytt har olika felhantering
En säkerhetskopia ska bevara källan. En flytt kan ta bort källan efter överföringen. Den skillnaden är viktig när källan är den enda molnkopian av telefonfoton.
Om målet är att automatiskt frigöra utrymme i OneDrive bör automatiseringen inte radera en molnfil enbart för att ett kopieringskommando avslutades utan ett uppenbart fel. Ett säkrare arbetsflöde verifierar att den lokala filen finns och är läsbar, och raderar sedan källan först när lyckandekriteriet är uttryckligt.
För schemalagd automatisering med borttagning efter överföring: isolera rclone från värdoperativsystemet
Källcommunityn rekommenderade att köra rclone i Docker i stället för att försöka installera det i ZimaOS rotfilsystem. Den arkitekturen överensstämmer med den övergripande ZimaOS-designen: containern innehåller verktyget, medan konfigurationen och målmapparna mappas till skrivbar ZimaOS-lagring.
Om du bygger det arbetsflödet ska du lagra rclone-konfigurationen och skripten på beständig lagring, till exempel /DATA/AppData eller någon annan hanterad datamapp. Mappa endast de lokala kataloger som jobbet behöver i stället för att ge containern bred åtkomst till hela NAS:en.
Det exakta rclone move kommandot var vägledning från communityn, inte ett IceWhale-författat kommando i den här tråden, så testa det på filer som kan undvaras innan du låter någon automatisering radera originalen i molnet.
Håll överföringsmappen åtskild från Immichs hanterade bibliotek när det är lämpligt
Källanvändaren beskrev att den nedladdade katalogen skulle användas som importplats i Immich. Immich kan hantera data från externa bibliotek eller uppladdningsliknande data på olika sätt beroende på version och distribution. Rikta inte bara ett destruktivt flyttjobb mot Immichs interna databas- eller applikationsdatamappar.
Använd en vanlig medie-/importmapp på hanterad NAS-lagring och konfigurera sedan det aktuella Immich-paketet att läsa den mappen med den lagringsmetod som stöds av den version du kör.
Aktuell säkerhetskopiering har fortfarande ett annat syfte än molnmigrering
Aktuella ZimaOS Backup är utformat kring schemalagda, återupptagbara kopieringar och versionshanterade återställningspunkter mellan moln, LAN, USB och Zima-lagring. IceWhale skiljer uttryckligen mellan molnsynkronisering och säkerhetskopiering, eftersom destruktiv spegling kan sprida misstag.
Om målet är skydd och inte att frigöra lagringsutrymme är det aktuella säkerhetskopieringsarbetsflödet i ZimaOS bättre lämpat än automatisering som raderar efter överföring.
Ett säkrare arbetsflöde för OneDrive-foton
- Anslut OneDrive via aktuella ZimaOS Files eller en dedikerad container.
- Välj en skrivbar lokal destination på hanterad lagring, inte en systemmapp.
- Överför först en liten testmängd.
- Verifiera antal filer, storlekar och några faktiska foton/videor lokalt.
- Bekräfta att Immich kan se det lokala innehållet med den avsedda importmetoden.
- Ta först därefter bort originalen i molnet om målet är att frigöra lagringsutrymme.
- Ha en oberoende säkerhetskopia av oersättliga foton; att flytta den enda molnkopian till en enda NAS är inte en 3-2-1-säkerhetskopia.
Vanliga frågor om skrivskyddad SSH i ZimaOS
Varför kan jag SSH-ansluta till ZimaOS men inte skapa filer i systemmappar?
De flesta systemmappar i ZimaOS är skrivskyddade avsiktligt. Skrivbar användar- och appdata ska ligga under hanterad datalagring, till exempel /DATA.
Gör sudo ZimaOS-rotfilsystemet skrivbart?
Nej. Utökade behörigheter ändrar inte ett filsystem som avsiktligt är monterat som skrivskyddat.
Kan aktuella ZimaOS komma åt OneDrive utan att rclone installeras manuellt?
Ja. Aktuella ZimaOS Files kan ansluta direkt till OneDrive och flytta valt molninnehåll till lokal lagring.
Fanns automatisk borttagning efter kopiering i det ursprungliga Backup-gränssnittet?
I communitytråden från februari 2026 sades det att detta inte var exponerat där. Se det som en historisk begränsning i Backup-appen, inte som ett permanent uttalande om alla aktuella arbetsflöden för molnöverföring.
