Problem att ansluta till ReadyNas Duo

Kan det bero på att Windows 10 inte använder sig av smb v1 längre?
Jag vet inte, jag kanske har samma problem, har inte haft min ReadyNAS Duo igång på nåt år eller så.
Jag får se om jag har tid att kolla på min i eftermiddag.

Sparkade igång min, den hittades direkt via RAIDar 6.5.0 och funkar som vanligt, inga problem att ändra inställningar via webbgränssnittet.

Var in i GUI och kollade:
RAIDiator 4.1.16 [1.00a043]

Kommer du åt administratörssidan via RAIDar?

Hittar RAIDar nasen överhuvudtaget?

Om RAIDar hittar nasen och den får en IPadress borde det ju gå att komma in i inställningarna genom att klicka på knappen där det står typ "Administratörssida" eller nåt liknande.

Läsning måste du göra via Linux - inte windows (windows är bara att glömma) det är en ext3 eller ext4-filsystem på denna och det känner inte windows till och tom. riskera kan göra diskarna haverererade när den försöker formatera om dem och du klickade på någon felruta av misstag i bara farten, så var försiktig och se helst till att Ubuntu är startat och klar på USB-sticka i din dator _innan_ du kopplar in USB-sladd(arna) för diskdockorna med nasens diskar (man kan faktiskt göra så med SATA-kabel också i en stationär dator även efter start - det är plug'n'play på samma sätt som USB.)

Är det 2 diskar så bör det köras på 2 diskdockor eller mindre önskat dubbel diskdocka (dock brukar dubbeldiskdockor inte fungera så bra med dålig prestanda när man har 2 diskar samtidigt - som tex Deltaco Artikelnr: 182550 hos Webbhallen och alla som ser liknande ut - det har med använda chipset att göra, och just deltacos dubbeldisk-docka så skall man använda B-platsen när man använder den med ensam disk - mer sällan att USB-chipet i läsaren hänger sig då timeouten i linux är rätt lång innan det görs USB-busreset och det kommer igång igen, A-platsen är rätt hopplös och med båda samtidigt kan det hänga sig flera gånger i minuten vid läsning/skrivning... )

Kör du på en ubuntu bootat från USB-sticka så brukar den kunna montera diskarna helt automagiskt och du får upp mappar med filträden under i desktopen eller dess filhhanterare (explorern)

Kör du under terminal och med 'mc' så är sökvägen liknande /media/användare/nasens_partition.

koppla du in extern USB-disk som tänker kopiera datat till så dyker den också upp i /media/användare/USB-disknamn.

Det är trolige 2 partitioner finns som mapp där - en för nasens systemdisk och en för själva lagringen och sedan mapp för ev inkopplad USB-disk.

Jag kunde inte heller ansluta till min via webbläsaren (Chrome), men det gick bra via RAIDar (klicka på knappen "Administratörssida). RAIDar talar också om statusen på diskarna, temp, mm.

ext2 låter som OS-partitionen

det brukar var den 3' partitionen som innehåller datat medans parition 1 har OS, partition 2 har swap-utrymme

Vet du om du hade RAID1 på diskparet eller körde du i Jbod/RAID0 för maximal utrymme. - är det sistnämnda så blir det nog att titta på kommersiella diskräddningsprogram som kan ext3/ext4 och mdadm-RAID om du har en skadad disk och rädda det som går.

normala kutymen är att man först gör diskimage av diskarna och lägger dessa på egen USB-disk modell stor och USB-disken läggs sedan undan som en backup och i linux görs helst med ddrescue (glöm inte loggfilen) då man med ddrescue kan upprepa körningarna många gånger för att mjölka ut de svårlästa sektorerna på en dålig disk - dock måste den dåliga disken ändå vara accessbart och inte helt död (dvs. syns i bios)

---

[efter att diskimage är gjort av båda diskarna om möjligt]

Är det RAID1 så kanske du får klappa mdadm-RAID snällt (dvs du får läsa manualen och/eller surfa på hur man aktiverar med bara en disk av en diskpar i RAID1) så att det går att monterar mdadm-partitionen till en /dev/mdxx-enhet (och det blir ofta en /dev/md127) som du sedan får mounta till en mapp (normalt under /mnt) som "mount -o ro /dev/md127 /mnt" om man kör via terminalläge. Är allt bra, så är dina filer under /mnt och kan kopieras ut. '-o ro' för mount är att disken monteras Readonly då det oftast vägrar att montera när 'dirty-byten' är satt pga av en oren stopp (strömavbrott) eller hängning mitt i operationerna.

Går det inte på ena disken med någon lycka så får du prova den andra disken.

är det problem med missade superblock så har ext3/ext4 ett antal sådana gömda på disken i en exponentiell ökande avstånd mellan varandra ju större disken är - så det går att leta fram ytterligare superblock som kan vara valida och du får ingång till filsystemet - du får googla på ext3 och ext4 och hur det monteras med annan superblock.

ext3 och ext4 är byggd som en stor disk som innehåller i sin tur en massa små minidiskar logiskt (typ 32 MB stora, större med större sektorblock - 32MB-storlek var typ 1/4-del av en disk i slutet av 1980-talet ) det var innan man börja kalla sådant för chunk) komplett med inoder och del i metadata för sin del - det gör att det finns rätt stor chans att rädda ur data med rätt så sammanhållna filer med olika filräddningsprogram som har kunskap om ext3/ext4.

Ext4 är erkänt bra på att inte fragmentera filer då vid skrivning med flera filer parallellt då OS helt enkelt gav varje fil en varsin minidisk i filsystemet som det kunder skriva både fram och tillbaka på utan att det blir trångt mot grannblock med data, så senlagd skrivning som möjligt så att så mycket som möjligt ligger i rätt ordning och helt fyllda 'minidiskar' om möjligt innan det trycks ned på disken och med ext4 börja man också lite med allokering av utrymme först just vid skrivning för att passa in datablocken i de lediga gluggarna så bra kant i kant med redan skriven data.

Dessa strategierna gör att fragmenteringsnivån sällan gick över 1% i ext3/4 och inte flätade filer i varandra som NTFS gjorde vid tex torrentnedtagingar med många parallella filer samtidigt. - och ja, man tittade under designen och arkitekturen för ext3/ext4 på vad som NTFS inte gjorde alls bra för att inte upprepa samma misstag.