När en extern DAS-enhet ansluts till ZimaOS finns det minst två olika detekteringslager att kontrollera: om Linux kan se varje blockenhet och om ZimaOS gränssnitt för Lagring registrerar dessa enheter för hantering. Den här tråden från december 2025 visade varför skillnaden är viktig.
Den ursprungliga inläggsskaparen körde ZimaOS 1.5.3 med en TerraMaster D4-320 och kunde bara se tre av fyra enheter i gränssnittet. Andra användare rapporterade sedan ett relaterat men annorlunda symtom: alla fyra diskar visades i lsblk och fdisk -lmen ingen av dem visades korrekt i ZimaOS-appen Lagring.
Skilj först mellan kärnans detektering och ZimaOS registrering i Lagring
Ett tidigt förslag skyllde på DAS-bryggan för att inte exponera varje disk separat. Den förklaringen drogs senare tillbaka efter att en annan användare publicerat lsblk utdata som visar alla fyra diskar på 5,5 TB som separata enheter.
Det ändrade felsökningsinriktningen. Om varje disk visas individuellt i lsblk eller fdisk -lUSB-bryggan exponerar åtminstone dessa blockenheter för operativsystemet. Det återstående problemet kan ligga högre upp i lagringshanteringsstacken.
Anta inte att omformatering eller radering är en bevisad lösning
Svar i communityn föreslog att manuellt skapade GPT-/filsystemslayouter kunde vara orsaken till att ZimaOS gränssnitt för Lagring ignorerade diskarna. Användare försökte sedan radera filsystemssignaturer och partitionstabeller.
Dessa försök löste inte problemet på ett tillförlitligt sätt. Två deltagare rapporterade att enheterna fortfarande inte visades i Lagring efter destruktiva raderingsåtgärder och omstart. En ägare av en D5-300C rapporterade liknande beteende.
Eftersom dessa raderingskommandon kom från communitydeltagare och inte löste de ursprungliga fallen bör de inte framställas som en officiell reparationsmetod. Kommandon för radering av diskar kan förstöra data permanent om de används på fel enhet.
ZimaOS-teamet försökte återskapa D4-320-fallet
IceWhale-teammedlemmen 777-Spider sade att teamet köpte in relevant DAS-maskinvara för att återskapa problemet. Några dagar senare rapporterade Dina att teamet hade testat en TerraMaster D4-320 med fyra NTFS-/exFAT-enheter som formaterats i Windows och att alla fyra visades i ZimaOS under testet.
Det resultatet är viktigt eftersom det innebär att tråden inte fastställde någon generell inkompatibilitet mellan ZimaOS och TerraMaster D4-320. I stället bad teamet berörda användare om mer information om filsystemformaten och hur enheterna hade formaterats.
Insamling av officiella diagnostikloggar från tråden
Dina tillhandahöll också ett officiellt diagnostikkommando för att samla in information om blockenheter, API:t för lokal lagring och devmon.service informationen i en loggfil. Det här kommandot hämtades från tråden från december 2025 och kan behöva justeras i framtida ZimaOS-versioner.
sudo -i
LOG=/DATA/disk-info.log; : > $LOG; { echo "=== lsblk ==="; lsblk; echo; echo "=== lsblk -f ==="; lsblk -f; echo; echo "=== curl http://127.0.0.1/v2/local_storage/disk ==="; curl http://127.0.0.1/v2/local_storage/disk; echo; echo "=== curl http://127.0.0.1/v2/local_storage/storages ==="; curl http://127.0.0.1/v2/local_storage/storages; echo; echo "=== journalctl -xe -u devmon.service ==="; journalctl -xe -u devmon.service; echo; } >> $LOG 2>&1 && echo "The output has been saved to $LOG"Inlägget sade att den resulterande filen kunde hittas som /ZimaOS-HD/disk-info.log i Files och delades med supportteamet. Detta är insamling av diagnostik, inte ett kommando som reparerar eller formaterar en disk.
Saknade diskar och RAID 5 var separata frågor
Den ursprungliga skribenten ville också skapa ett RAID 5-kluster. Under trådens gång hindrade problemet med den saknade disken en tydlig utvärdering av det arbetsflödet. Senare, efter communityts försök att radera diskarna, kunde användaren fortfarande inte skapa RAID och hade dessutom förlorat åtkomsten till diskarna i Files och Storage.
IceWhales svar den 15 december 2025 sade att hantering av USB-enheter, inklusive formatering och skapande av RAID, planerades som framtida stöd. Betrakta detta som en historisk färdplansnotis, inte som bevis för vad varje aktuell ZimaOS-version stöder i dag.
En säkrare felsökningsordning
- Bekräfta antalet diskar som fysiskt är installerade i DAS-enheten.
- Kontrollera om varje disk visas separat på Linux-lagret för blockenheter.
- Jämför detta med vad ZimaOS Storage-gränssnittet visar.
- Anteckna filsystemstyp och hur varje disk tidigare formaterades.
- Radera inte partitionstabeller bara för att ett community-inlägg föreslog det.
- Om kärnan ser diskarna men ZimaOS Storage inte gör det, samla in diagnostik och ange exakt kapslingsmodell, filsystemsinformation och ZimaOS-version till supporten.
Vanliga frågor om externa DAS-enheter i ZimaOS
Visar TerraMaster D4-320 bara tre enheter i ZimaOS?
Tråden stödde inte den slutsatsen. Andra användare visade fyra fristående diskar i lsblk, och IceWhale-teamet rapporterade senare att de såg alla fyra enheterna i sitt eget D4-320-test.
Om lsblk ser alla enheter, varför kan ZimaOS Storage ändå missa dem?
Detektering på kärnnivå och registrering i ZimaOS Storage är olika lager. Källtråden visade fall där kärnan identifierade enheter som inte visades i gränssnittet.
Bör jag köra sgdisk eller wipefs för att få enheterna att visas?
Inte utifrån den här tråden. De destruktiva förslagen kom från svar i communityt och löste inte problemet på ett tillförlitligt sätt. Säkerhetskopiera data och följ aktuell supportvägledning innan du raderar metadata från någon disk.
Löstes problemet helt i tråden?
Nej. Teamet återskapade en fungerande D4-320-konfiguration med NTFS-/exFAT-diskar och begärde diagnostikinformation från berörda användare, men tråden publicerade ingen universell grundorsak eller lösning.
