Beiträge von Nordstern

    Kurze Rückmeldung von mir. Gelöst wurde das Problem, indem sich ein Techniker von QNAP aufgeschaltet hat. Hiernach war eine Migration auf die 4 x 5TB WD50EFRX möglich (jeweil HDD rund 10h) . Nach einem Neustart des Systems war das RAID5 jedoch erneut wieder nicht ansprechbar. ;(
    Nach einem Update von Firmware 4.1.1 auf 4.1.2 funktionierte das Wiederhestellen der Volumes jedoch wieder (vorher kam an dieser Stelle die Fehlermeldung "ERR_GENERIC") und auch nach einem Neustart wurde das RAID5 wieder eingebunden.


    Danke an Dr. Mike für die geleistete Hilfestellung!

    Ein md0 existiert offenbar nicht.
    ergänzende Informationen:

    Hallo,
    ich bitte um eure Hilfe bei folgendem Problem: Mein derzeitiges Raid besteht aus 4 x 4 TB WD Wd40EFRX. Da der Speicherplatz nun zur Neige geht wollte ich eine Kapazitätserweiterung durchführen. Die habe ich bei anderen QNAP NAS' bereits öfter durchgeführt und es gab keine Probleme.
    Nur diese Mal wurde beim einstecken der ersten neuen HDD ( 5TB WD50EFRX) die dritte HD in der NAS als fehlend gekennzeichnet und die Erweiterung brach ab.
    Nun habe ich die NAS neu gestartet und dabei die vorher verwendete 4TB HDD wieder in den ersten Slot gesteckt. Nun steht der Status des Raid auf Fehler (ERR_GENERIC")! Mit SSH komme ich auf die NAS. Was kann ich nun machen?
    Angaben zum System: Neuseste FW (4.1.1 2014-11-01)


    Code
    [~] # cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md256 : active raid1 sdd2[3](S) sdc2[2](S) sdb2[1] sda2[0]      530112 blocks super 1.0 [2/2] [UU]      bitmap: 0/1 pages [0KB], 65536KB chunkmd13 : active raid1 sda4[0] sdd4[25] sdc4[24] sdb4[1]      458880 blocks super 1.0 [24/4] [UUUU____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkmd9 : active raid1 sda1[0] sdd1[25] sdc1[24] sdb1[1]      530048 blocks super 1.0 [24/4] [UUUU____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkunused devices: <none>


    Code
    [~] # fdisk -lDisk /dev/sda: 4000.7 GB, 4000787030016 bytes255 heads, 63 sectors/track, 486401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sdc: 4000.7 GB, 4000787030016 bytes255 heads, 63 sectors/track, 486401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdc1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sdb: 4000.7 GB, 4000787030016 bytes255 heads, 63 sectors/track, 486401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sdd: 4000.7 GB, 4000787030016 bytes255 heads, 63 sectors/track, 486401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdd1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sde: 515 MB, 515899392 bytes8 heads, 32 sectors/track, 3936 cylindersUnits = cylinders of 256 * 512 = 131072 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sde1               1          41        5244   83  Linux/dev/sde2   *          42        1922      240768   83  Linux/dev/sde3            1923        3803      240768   83  Linux/dev/sde4            3804        3936       17024    5  Extended/dev/sde5            3804        3868        8304   83  Linux/dev/sde6            3869        3936        8688   83  LinuxDisk /dev/md9: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytes


    Code
    [~] # mdadm --examine --scan
    ARRAY /dev/md/9  metadata=1.0 UUID=95fff832:9807b3ce:714752e2:12ae5660 name=9
    ARRAY /dev/md/256  metadata=1.0 UUID=d1e889b5:39e9691e:d78af25d:f4c22bf7 name=256
       spares=2
    ARRAY /dev/md/1  metadata=1.0 UUID=1af2444c:4777463d:f524576d:30230f35 name=1
    ARRAY /dev/md/13  metadata=1.0 UUID=6d9b5242:6ae4473d:3eb0785c:098327da name=13
    ARRAY /dev/md/321  metadata=1.0 UUID=4a84df11:ad2ceab8:992e5874:f4cc4494 name=321
    [~] #


    Von Linux habe ich leider keine Ahnung. Ich habe jedoch schon begriffen, dass mdadm hier mein Freund sein könnte. Dennoch habe ich die Befürchtung, etwas falsch zu machen und bitte daher um Hilfestellung. Soweit ich denke, sind die Daten noch vorhanden und die Disks "clean". Wahrscheinlich müssen die Disks assembled werden. ich bin mir auch deshalb nicht sicher, weil ich früher MD0_DATA als Pfad hatte und nun CACHEDEV1_DATA was wohl auf die verwendung vom neuen (?) LVM-Manager hinweist. (?)

    Hallo,
    ich habe kürzlich eine QNAP SS-453 Pro NAS erworden.
    Bei der Einrichtung habe ich die vorhandenen Festplatten meiner alten SS-439 Pro verwendet. Die neue NAS wurde erfolgreich mit den alten Platten migriert.
    Leider wurden auch die unglücklich benannten Standardordner der SS-439 Pro mit migriert (Qdownload, QMulimedia etc.).
    Ich hätte jedoch gerne andere Standard-Ordnerbezeichnungen wie bei meiner TS-451 (Download, Multimedia etc).
    Kann mir ein Besitzer einer SS-453 Pro mitteilen wie die Standard-Ordnerbezeichnungen ohne eine Migration lauten? Dann wurde ich die neue SS-453 Pro lieber nochmal neu aufsetzen.


    Vielen Dank im Voraus!

    News:
    Ich habe gestern ein Firmwareupdate gemacht : v4.1.0 vom 30.05.2014
    Danach eine der 4 TB eingesteckt (welche ich bereits vorher schon einmal drin hatte) und siehe da das Rebuild lief an! :)
    Soweit so gut. Gestartet habe ich gestern Abend etwa gegen 19:00 Uhr. Heute morgen gegen 6:00 war er bei über 90 % des Rebuilds.
    Als ich 9 h später von der Arbeit kam, war das Webinterface vom Speichermanager nicht mehr erreichbar. :(
    Ich gehe daher davon aus, dass etwas schief gelaufen sein muss, da die restlichen 10 % in etwa 1,5 h hätten durchlaufen müssen.
    Daher habe ich die NAS manuell neu gestartet (ein Reboot ging nicht weil die NAS hing).
    Nach einem Neustart war die HDD 1 auch Bestandteil des Raid 5, jedoch lief das Raid nicht an. Es lief sich auch nicht durch "Wiederherstellen" der Raid-Verwaltung aktivieren... (Log: RAID Recovery failed)
    Der aktuelle Stand:



    Nun die Antworten auf eure Fragen:


    Zitat

    Damit sind die Daten nun in höchster Gefahr, folglich ist im Augenblick nichts wichtiger, als die Daten des RAID unverzüglich zu sichern bzw. das vorhandene Backup zu aktualisieren, so lange dies noch möglich ist.


    -> Wohin mit 8,5 TB Daten?


    Zitat

    Wie lange ist die HDD1 bereits aus dem System raus,


    -> Seitdem ich gepostet habe, jedoch habe ich die NAS eigentlich nicht meh an gehabt, um Datenverlust zu vermeiden.


    Zitat

    war der RAID Status vor dem Austausch der HDD1 noch in Ordnung (also nicht "degraded") und wurde nach dem Austausch der HDD1 bereits wieder auf das RAID geschrieben ?


    -> Ja und nein (außer FW-Update)


    ...und nun die Code-Blöcke:


    Code
    [~] # cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md4 : active raid1 sdd2[2](S) sdc2[3](S) sdb2[1] sda2[0]                 530048 blocks [2/2] [UU]md13 : active raid1 sdc4[0] sda4[3] sdb4[2] sdd4[1]                 458880 blocks [4/4] [UUUU]                 bitmap: 0/57 pages [0KB], 4KB chunkmd9 : active raid1 sdc1[0] sdb1[3] sda1[2] sdd1[1]                 530048 blocks [4/4] [UUUU]                 bitmap: 1/65 pages [4KB], 4KB chunkunused devices: <none>


    Code
    [~] # fdisk -lDisk /dev/sdb: 3000.5 GB, 3000592982016 bytes255 heads, 63 sectors/track, 364801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sdc: 3000.5 GB, 3000592982016 bytes255 heads, 63 sectors/track, 364801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdc1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sdd: 3000.5 GB, 3000592982016 bytes255 heads, 63 sectors/track, 364801 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdd1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sda: 4000.7 GB, 4000787030016 bytes255 heads, 63 sectors/track, 486401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1               1      267350  2147483647+  ee  EFI GPTDisk /dev/sda4: 469 MB, 469893120 bytes2 heads, 4 sectors/track, 114720 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/sda4 doesn't contain a valid partition tableDisk /dev/sdx: 515 MB, 515899392 bytes8 heads, 32 sectors/track, 3936 cylindersUnits = cylinders of 256 * 512 = 131072 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdx1               1          17        2160   83  Linux/dev/sdx2              18        1910      242304   83  Linux/dev/sdx3            1911        3803      242304   83  Linux/dev/sdx4            3804        3936       17024    5  Extended/dev/sdx5            3804        3868        8304   83  Linux/dev/sdx6            3869        3936        8688   83  LinuxDisk /dev/md9: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md9 doesn't contain a valid partition tableDisk /dev/md4: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md4 doesn't contain a valid partition table


    Code
    [~] # mdadm -D /dev/md0mdadm: md device /dev/md0 does not appear to be active.


    Code
    [~] # cat /etc/config/raidtabraiddev /dev/md0        raid-level      5        nr-raid-disks   4        nr-spare-disks  0        chunk-size      4        persistent-superblock   1        device  /dev/sda3        raid-disk       0        device  /dev/sdb3        raid-disk       1        device  /dev/sdc3        raid-disk       2        device  /dev/sdd3        raid-disk       3


    Code
    [~] # cat /etc/config/mdadm.confARRAY /dev/md0 devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3


    Code
    [~] # cat /etc/storage.conf[VOLUME 1]device name = /dev/md0raid level = 5raid disks = 1,2,3,4spare raid disks =status = -2record_time = Wed Jun  4 18:35:23 2014filesystem = 104[Global]Available Disk = 4



    Ihr seht, ihr bekommt alle Infos, die ihr benötigt...
    Tausend Dank für Eure Hilfe!!!

    Die Logs geben leider nur oberflächliche Meldungen wie:
    [RAID5 Disk Volume: Drive 1 2 3 4] RAID device in degraded mode.


    [RAID5 Disk Volume: Drive 1 2 3 4] Drive 1 removed.


    Drive 1 plugged out.


    [RAID5 Disk Volume: Drive 1 2 3 4] Add drive 1 to the volume failed.


    Leider nichts, worn man festmachen könnte, was zu tun ist.


    Heute habe ich die Firmware auf die aktuelle 4.1.0 vom 30.05.2014 upgedatet, jedoch alles genauso unbefriedigend wie zuvor. :(


    Unglücklicherweise, wird seit heute beim 2 Drive eine SMART-Warnung (smart current pending sector) ausgegeben. Viel Zeit habe ich wohl nicht mehr, bis alle Daten hinüber sind... hat jemand viell. noch Ideen?




    Ist schon merkwürdig, jahrelang überhaupt keine Probleme und nun alles auf einmal...

    Danke. Genau dies habe ich bereits gemacht:
    Alle 4 TB Platten an einen PC gesteckt, alle Partitionen gelöscht und wieder in die NAS gesteckt. leider ohne Erfolg! ;-/
    Gibt es viell. sonst Möglichkeiten. Evtl über SSH/Putty?

    Guten Abend,
    ich habe seit einiger Zeit das Problem, dass nach einem fehlgeschlagenen Versuch zur Kapazitätserweiterung mein Raid degraded ist und nicht wieder recovered.


    Mein System: QNAP TS-459 Pro II mit FW 4.1.0 beta von 12/2013
    alte Platten: 4 x Western Digital Red 3000GB, SATA 6Gb-s (WD30EFRX)
    neue Platten: 4 x Western Digital Red 4000GB, SATA 6Gb-s (WD40EFRX)
    RAID-Modus: RAID-5 mit Bitmap
    Problem: Kein Rebuild


    Da ich nicht ganz firm mit Linux bin, habe ich nicht so Recht eine Idee, wo ich weiter ansetzen kann.
    Mit Putty und SSH auf die Box ist kein Problem.
    Für Hilfe wäre ich sehr dankbar!


    Der derzeitige Stand:

    Danke für den Link. Ich werde ihn mir gleich mal zu Gemüte führen.
    Mein Problem konnte ich lösen. Grund für den hohen Traffic war mein Roboform Password-Manager. Ich hatte dessen Passwort-Dateien auf der Nas ausgelagert. Bei jeder Verbindung mit der Nas versuchte Roboform sämtliche vorhandene Passwort-Dateien (weit über 1.000) einzulesen. Dies geschah aus mir unerklärlichen Gründen gleich mehrfach. Trotzdem Danke! Die Konfiguration funktioniert wie oben beschrieben.

    Hallo, ich bin frisch gebackener Besitzer einer SS-439, daher habe ich noch eine Frage bei der ich mir schon reichlich Gedanken gemacht habe. Ich habe mir auch bereits alle relavanten Themen hier und im Netz durchgelesen aber so recht scheint bei mir nichts zu funktionieren. Daher gleich zu meiner Konstellation:


    Meine NAS hängt mit Ethernet-1 (192.168.1.2) am integrierten 100 MBit-Switch der Fritzbox (192.168.1.1). Um Internet für meinen PC's zu gewärleisten hängt auch dieser an der Fritzbox mit 192.168.1.4. Verbindung auch hier wegen dem Switch der Fritzbox 100 Mbit.
    Da die Nas und auch der PC jeweils einen 1.000 Mbit Port haben, habe ich beide mit einem Cat5e S-FTP Kabel verbunden Um die GB Verbindung auch zu nutzen. Daher habe ich sie in einen andere IP-Bereich gelegt, um die beiden Netze zu trennen (Nas 192.168.2.2 & PC 192.168.2.4)
    Alle haben die Subnetzmaske 255.255.255.0. DHCP ist auf der Fritzbox aktiviert (192.168.1.1). Stand-Alone Konfiguration.


    Nochmal in kurz:


    FRITZ!Box (192.168.1.1) -> 100 MBit -> PC (192.168.1.4)
    FRITZ!Box (192.168.1.1) -> 100 MBit -> NAS (192.168.1.2)
    DHCP für obige: FRITZ!Box (192.168.1.1)


    PC (192.168.2.4) -> 1.000 MBit -> NAS (192.168.2.2)
    Subnetzmaske für alle: 255.255.255.0


    Eigentlich sollte die Konfiguration stimmen und der Daten-Transfer für die gemappten Freigaben ist auch möglich. Jedoch hängt der PC bei allem was das Netzwerk betrifft sehr oft und beide Browser (FF & IE) hängen sich beim Starten immer wieder auf. Ich habe nun herausgefunden, das der System-Prozess (Win 7 Ultimate x64) eine konstante Verbindung zu Nas mit ca 500 KB/s herstellt, sobald eine Verbindung nach dem Starten von Windows hergestellt ist. Der Traffic steigt dabei langsam bis zur besagten Geschwindigkeit. Erst dachte ich an eine Indexierung der Medien auf der Nas, jedoch konnte ich dafür keine konkreten Anhaltspunkte finden. Auch sind keine dafür typischen Prozesse aktiv. Nun denke ich, dass die Konfiguration der Netzwerk-Adapter doch nicht korrekt ist. Daher bitte ich Euch um Hilfe, und um Überprüfung der Konfiguration. Viell. kennt jemand das Phänomen und kann zur Klärung beitragen Vielen Dank!

    Hallo, ich habe folgendes problem: ich benutze die SS-439 und windows 7. Wenn ich mich unter win 7 mit benutzernamen/passwort einloggen will, bekomme ich eine fehlermeldung im log. der benutzername und das passwort auf win 7 sowie das konto auf der nas sind identisch.


    Im log der Nas steht dazu: 2009-12-16 00:43:24 Nordstern 192.168.0.12 pc SAMBA --- Login Fail


    ein einloggen anderer user, als das gerade in win 7 verwendete Konto dagegen ist möglich.
    woran kann das liegen? Ich bin schon seit stunden am suchen nach einer Lösung...
    Hiintergrund ist, dass ich ein netzlaufwerk mit userrechten mappen möchte. Danke im Voraus!