När en RAID-array plötsligt blir skrivskyddad är det inte första prioritet att tvinga tillbaka den till läs- och skrivläge. Den viktigare frågan är varför arrayen tappade förtroendet för en eller flera diskar.
I den här tråden från maj 2026 gick en RAID 5 med fyra diskar in i ett skyddande skrivskyddat läge efter att en medlemsdisk tillfälligt försvunnit. Arrayen återgick senare till ett friskt [UUUU]-läge och påbörjade en lång skydds- och omsynkroniseringsprocess, men diskbortfallen återkom. Diskussionen skiftade då från ”hur aktiverar jag skrivåtkomst igen?” till maskinvarans kommunikationsväg.
Arrayen gick in i skyddande skrivskyddat läge
Tråden visade inte att användaren råkade klicka på en skrivskyddad växel. Gemenskapens analys tolkade tillståndet som en reaktion på ett degraderat eller instabilt lagringstillstånd.
RAID-arrayen kunde återhämta sig och ändå ha ett underliggande problem
Efter omstart och återställning syntes alla fyra RAID-medlemmar igen, och arrayen gick in i läget ”Protection in progress”.
Upprepade omstarter under en paritetsomsynkronisering kan starta om eller förlänga återställningsarbetet. Gemenskapens råd var att låta arrayen slutföra sin skyddsprocess samtidigt som man undersökte varför diskarna försvann.
SMART godkändes, men felhistoriken för gränssnittet var viktig
De två Toshiba-diskarna rapporterade övergripande SMART-status som godkänd, utan omallokerade eller väntande sektorer i det delade resultatet. Därför saknades stöd för den enkla slutsatsen att ”diskarna definitivt är döda”.
SMART-loggarna visade dock också Ultra DMA CRC-räknare samt flera ICRC/ABRT-kommandofel. Dessa fält förknippas ofta med misslyckad kommunikation mellan en disk och värdsystemet, snarare än enbart med mediefel. Gemenskapen fokuserade därför på SATA-datakablar, strömförsörjning, styrenhetens stabilitet, fast programvara och upprepade länkåterställningar.
Tvinga inte tillbaka en degraderad array till läs- och skrivläge
Tråden innehåller inget kommando från IceWhale som på ett säkert sätt åsidosätter skyddsläget. För långsiktiga råd är detta den korrekta gränsen: säkerhetskopiera åtkomliga data, verifiera arrayens hälsa, kontrollera fysiska anslutningar och diagnostisera bortfallet innan du försöker kringgå skyddet.
Använd den aktuella lagringspanelen för att bekräfta arrayens hälsa
Aktuella ZimaOS visar lagringshälsa och status för medlemsdiskar under Settings > Storage. När du felsöker en modern version bör du kontrollera hur det aktuella lagringsgränssnittet rapporterar arrayen och dess medlemsdiskar innan du drar slutsatser utifrån den här incidenten från 2026.
Vanliga frågor om skrivskyddad RAID i ZimaOS
Ändrade ZimaOS slumpmässigt en frisk RAID till skrivskyddad?
Den tillgängliga bevisningen pekar på bortfall av medlemsdiskar. Skyddsläget uppstod samtidigt som en disk saknades, snarare än som en isolerad ändring av en inställning i gränssnittet.
Bevisade SMART att Toshiba-diskarna hade gått sönder?
Nej. Den övergripande SMART-hälsan var godkänd och vanliga räknare för sektorfel stod på noll, även om loggarna innehöll betydande kommunikationsfel i gränssnittet.
Vad bör jag undersöka när CRC- eller ICRC-fel visas?
Gemenskapen fokuserade på SATA-kablar, strömanslutningar, nätaggregatets stabilitet, styrenhetens beteende, fast programvara och om samma disk eller port upprepade gånger försvinner.
Fanns det någon officiell diagnos av grundorsaken från IceWhale?
Nej. Den publicerade tråden avslutades med gemenskapens maskinvaruanalys, inte med någon teknisk slutsats från IceWhale.
