Beiträge von Guido83

  • 2.5 GBit/s USB Ethernet Adapter

    Den installiert das NAS selbst. Neu gestartet habe ich bereits mehrfach. Wenn man den Netzwerkadapter am USB Port einsteckt, muss man das NAS, wie oben beschrieben, sowieso neu starten, damit der Adapter angezeigt wird.

  • 2.5 GBit/s USB Ethernet Adapter

    Ich habe mir für mein älteres NAS (TS-853A) einen USB Ethernet Adapter mit Realtek RS8156 Chip geholt, um ein schnelleren Netzwerkanschluss am NAS zu haben. NAch dem Einstecken wird er zunächst nicht vom QTS (v 5.1) erkannt. Nach einen Reboot wird er jedoch als 2.5G Netzwerkadapter im QTS erkannt (laut dmesg wird der r8152 Treiber verwendet, was auch korrekt ist). Es funktioniert so weit, jedoch sobald ich einen Filetransfer starten möchten, bricht die Verbindung extrem ein, Die Dateiübertragung geht auf 200 kbit/s und die gesamte Verbindung ist nicht mehr nutzbar. Woran könnte das liegen?

  • [4. Sammelthema] Probleme mit Festplatten-Standby

    Nein, wie ich einen Beitrag vorher schon geschriben habe, gehört die erste Zeile [~]# cat disconnect_internal_raid.sh NICHT in das Script. Dein Script muss so aussehen:

    und das speicherst du in einer Datei die meinetwegen disconnect_internal_raid.sh heisst. Diese Datei kopierst du dann zum Beispiel in den admin homes Ordner /share/CACHEDEV1_DATA/homes/admin/ und machst diese ausführbar chmod +x disconnect_internal_raid.sh


    Wenn es beim booten auch ausgeführt werden soll, muss folgendes in die autostart.sh angehängt werden:


    Bash
    #!/bin/sh
/share/CACHEDEV1_DATA/homes/admin/disconnect_internal_raid.sh

    Dazu Flash mounten:

    Code
    mount $(/sbin/hal_app --get_boot_pd port_id=0)6 /tmp/config

    autorun.sh bearbeiten, entweder mit WinSCP oder in der SSH console mit:

    Code
    vi /tmp/config/autorun.sh

    Datei speichern und ausführbar machen:

    Code
    chmod +x autorun.sh

    dann den Flash wieder unmounten:

    Code
    umount /tmp/config

    Anschliessend würde ich unbedingt noch den cronjob erstellen, damit das RAID täglich synchronisiert wird.

  • [4. Sammelthema] Probleme mit Festplatten-Standby

    Wo hakt es denn bei den Skripten?


    In dem verlinkten thread wird es ja eigentlich sehr ausführlich beschrieben. Für diejenigen die sich nicht so gut auskennen ist es etwas verwirrend, dass dort bei den skripten der befehl zum anzeigen des Skriptinhaltes mit im Code steht. Beispiel:

    mit dem Befehl cat rebuild_internal_raid.sh

    wir der Inhalt der Datei rebuild_internal_raid.sh in der Console ausgegeben. Um bei diesem Beipiel zu bleiben. In der Anleitung steht, das Skript zum Entfernen der Laufwerke sei:

    Aber eigentlich sollte das Skript nur folgendes beinhalten:

  • Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

    Der LE Client legt die Files bei mir an, das ist nicht das Problem. Erst wenn die ACMe challenge läuft und die generierten files abgeholt werden sollen, kommt es zum Fehler. Das NGINX Log file gibt dann auch für jeden host den fehler aus:

    Code
    2018/12/04 19:00:30 [error] 33#33: *34 open() "/usr/share/nginx/html/.well-known/acme-challenge/cMYMeDDKQemuGEcHn-ofn8b9ouB7in7zX2cFi9YgGxc" failed (13: Permission denied), client: 172.68.174.102, server: wiki.***.***, request: "GET /.well-known/acme-challenge/cMYMeDDKQemuGEcHn-ofn8b9ouB7in7zX2cFi9YgGxc HTTP/1.1", host: "wiki.***.***"

  • Poolerweiterung schlägt fehl, Platte defekt

    Ich habe, nachdem das Rebuild trotz ausgeworfener vierte Platte weiter lief, zunächst das rebuild durchlaufen lassen. Problem war dann dass das RAID5 aus 4 Festplatten bestand, von der aber eine nicht funktionierte. Diese vierte Platte habe ich dann aus dem RAID entfernt:

    Code
    mdadm -r /dev/md4 failed

    Anschliessend wurde das RAID mit 3 Platten wieder neu aufgebaut und funktioniert auch.

    Die Ausgbae von md_checker:

    also alles in Ordnung. man sieht, md4 besteht aus 3 Platten. Zugriff auf die Daten habe ich auch. Es wird aber bei jedem Start des NAS neu synchronisiert, weil das QTS noch immer 4 Platten erwartetn. in der raid.conf steht auch folgendes drin:

  • Poolerweiterung schlägt fehl, Platte defekt

    nachdem nun die dritte Festplatte endlich funktioniert stehe ich noch vor einem problem.

    Da das rebuild ja für 4 Platten gemacht wurde, obwhl eine davon ja sofrt nach beginn des rebuild ausgefallen war, lief der rebuild durch. resultat war natürlich dass das raid degradiert wurde, weil eine der 4 platten ja fehlte. ich habe dann per madm die fehlende platte entfernt, die grösse des raid wieder korrigiert und neu erstellen lassen. hat auch wunderbar funktioniert. das raid 5 funktioniert wieder. allerdings wird im qts noch immer die 4te platte mit angezeigt, jedoch mit dem zusatz "existiert nicht".

    cat proc/mdstat zeigt jedoch nur 3 Platten an und auch dass das raid aus 3 laufwerken besteht.

    Problem ist, jedes mal wenn ich das nas neu boote, wird im qts das raid synchronisiert (dauert dann etwa 16h)


    kann ich dieses problem irgendwie lösen?

  • Poolerweiterung schlägt fehl, Platte defekt

    Jetzt habe ich die neue Platte ausprobiert, in einem anderen Schacht.

    Genau das gleiche Problem. Festplatte zuerst erkannt, konnte aber kein Volume erstellen. Nun rattert sie auch pasuenlos, scheint also nun wieder kaputt gegangen zu sein


    Die Platte wird auch jetzt nicht mehr erkannt. Ich glaube irgendwie nicht dass beide Platten von Anfang an defekt waren


    EDIT:

    nachdem sie nun die ganze Nacht durchgerattert hat, hat sie sich dann irgendwann beruihgt und wurde nach einem Neustart dann wieder erkannt. Mals sehen wie es nun weitergeht



    Ich muss mich jetzt nochmal melden. Die Festplatte scheint nun wieder zu funktionieren und ich habe mal die system settings resettet. Dann konnte ich die neue Festplatte zum bestehenden RAID hinzfügen. Di Migration hat anschliessend gestartet, doch nach einer Weile gabe es einen Fehler "Hard Disk Ejected". Angeblich wurde die neue Platte während der Migration entfernt (was natürlich nicht gemacht wurde).

    Nun ist die Platte wieder mal verschwunden, jedoch läuft die Migration munter weiter?!?

    Was hat das wieder zu bedeuten?