Wanneer een externe DAS op ZimaOS wordt aangesloten, moeten ten minste twee verschillende detectielagen worden gecontroleerd: of Linux elk blokapparaat kan zien en of de ZimaOS-interface Opslag die schijven voor beheer registreert. Deze thread uit december 2025 liet zien waarom dat onderscheid belangrijk is.
De oorspronkelijke melder gebruikte ZimaOS 1.5.3 met een TerraMaster D4-320 en zag slechts drie van de vier schijven in de interface. Andere gebruikers meldden vervolgens een gerelateerd maar ander symptoom: alle vier de schijven verschenen in lsblk en fdisk -l, maar geen enkele verscheen correct in de ZimaOS-app Opslag.
Maak eerst onderscheid tussen detectie door de kernel en registratie in ZimaOS Opslag
Een vroege suggestie gaf de DAS-brug de schuld omdat die niet elke schijf afzonderlijk beschikbaar zou maken. Die verklaring werd later ingetrokken nadat een andere gebruiker een bericht plaatste met lsblk uitvoer waarin alle vier de schijven van 5,5 TB als afzonderlijke apparaten worden weergegeven.
Dat veranderde de richting van het oplossen van problemen. Als elke schijf afzonderlijk verschijnt in lsblk of fdisk -l, maar de USB-brug stelt die blokapparaten in elk geval beschikbaar aan het besturingssysteem. Het resterende probleem kan zich hoger in de opslagbeheerstapel bevinden.
Ga er niet van uit dat opnieuw formatteren of wissen een bewezen oplossing is
In reacties uit de community werd voorgesteld dat handmatig aangemaakte GPT-/bestandssysteemindelingen de reden konden zijn dat de ZimaOS-interface Opslag de schijven negeerde. Gebruikers probeerden vervolgens bestandssysteemhandtekeningen en partitietabellen te wissen.
Die pogingen losten het probleem niet betrouwbaar op. Twee deelnemers meldden dat de schijven na destructieve wisprocedures en een herstart nog steeds niet in Opslag verschenen. Een eigenaar van een D5-300C meldde vergelijkbaar gedrag.
Omdat die wisopdrachten afkomstig waren van communitydeelnemers en de oorspronkelijke gevallen niet oplosten, mogen ze niet worden gepresenteerd als een officiële herstelprocedure. Opdrachten om schijven te wissen kunnen gegevens permanent vernietigen als ze op het verkeerde apparaat worden toegepast.
Het ZimaOS-team probeerde de D4-320-situatie te reproduceren
IceWhale-teamlid 777-Spider zei dat het team relevante DAS-hardware aanschafte om het probleem te reproduceren. Een paar dagen later meldde Dina dat het team een TerraMaster D4-320 had getest met vier NTFS/exFAT-schijven die in Windows waren geformatteerd, en dat alle vier in hun test in ZimaOS verschenen.
Dat resultaat is belangrijk, omdat het betekent dat de thread geen algemene incompatibiliteit tussen ZimaOS en de TerraMaster D4-320 heeft vastgesteld. In plaats daarvan vroeg het team getroffen gebruikers om meer informatie over de bestandssysteemindelingen en de manier waarop de schijven waren geformatteerd.
Officiële verzameling van diagnostische logboeken uit de thread
Dina gaf ook een officiële diagnostische opdracht voor het verzamelen van informatie over blokapparaten, de lokale-opslag-API en devmon.service informatie in een logbestand. Deze opdracht kwam uit de thread van december 2025 en moet mogelijk worden aangepast voor toekomstige ZimaOS-versies.
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"In het bericht stond dat het resulterende bestand te vinden was op /ZimaOS-HD/disk-info.log in Files en deelde die met het ondersteuningsteam. Dit is het verzamelen van diagnostische gegevens, geen opdracht om een schijf te repareren of te formatteren.
Ontbrekende schijven en RAID 5 waren afzonderlijke kwesties
De oorspronkelijke poster wilde ook een RAID 5-cluster maken. Tijdens de thread kon die workflow door het probleem met de ontbrekende schijf niet goed worden geëvalueerd. Later, na pogingen van de community om schijven te wissen, kon de gebruiker nog steeds geen RAID maken en waren de schijven ook niet meer zichtbaar in Files en Storage.
In het antwoord van IceWhale van 15 december 2025 stond dat USB-apparaatbeheer, waaronder formatteren en het maken van RAID, gepland was voor toekomstige ondersteuning. Beschouw die uitspraak als een historische routekaartnotitie, niet als bewijs van wat elke huidige ZimaOS-release vandaag ondersteunt.
Een veiligere volgorde voor probleemoplossing
- Bevestig hoeveel schijven er fysiek in de DAS zijn geïnstalleerd.
- Controleer of elke schijf afzonderlijk op de Linux-laag voor blokapparaten verschijnt.
- Vergelijk dat met wat de ZimaOS Storage-interface weergeeft.
- Noteer het bestandssysteemtype en hoe elke schijf eerder was geformatteerd.
- Wis partitietabellen niet alleen omdat een communitybericht dat suggereerde.
- Als de kernel de schijven ziet maar ZimaOS Storage niet, verzamel dan diagnostische gegevens en geef het exacte model van de behuizing, de bestandssysteeminformatie en de ZimaOS-versie door aan de ondersteuning.
Veelgestelde vragen over externe DAS van ZimaOS
Geeft de TerraMaster D4-320 slechts drie schijven door aan ZimaOS?
De thread ondersteunde die conclusie niet. Andere gebruikers toonden vier afzonderlijke schijven in lsblk, en het IceWhale-team meldde later dat het tijdens een eigen D4-320-test alle vier de schijven zag.
Als lsblk elke schijf ziet, waarom kan ZimaOS Storage ze dan toch missen?
Detectie op kernelniveau en registratie in ZimaOS Storage zijn verschillende lagen. In de oorspronkelijke thread werden gevallen beschreven waarin de kernel schijven opsomde die niet door de interface werden weergegeven.
Moet ik sgdisk of wipefs uitvoeren om de schijven zichtbaar te maken?
Niet op basis van deze thread. Die destructieve suggesties kwamen uit reacties van de community en losten het probleem niet betrouwbaar op. Maak een back-up van je gegevens en volg de actuele ondersteuningsrichtlijnen voordat je metagegevens van een schijf wist.
Werd het probleem in de thread volledig opgelost?
Nee. Het team reproduceerde een werkende D4-320-configuratie met NTFS-/exFAT-schijven en vroeg getroffen gebruikers om diagnostische informatie, maar in de thread werd geen universele oorzaak of oplossing gepubliceerd.
