QNAP TS-859U+ Freigaben sind nicht mehr erreichbar

    Hallo,


    Seit Montag ist die Funktion unserer QNAP TS-859U+ stark eingeschränkt.

    Die Freigaben der QNAP sind über Windows 10 nicht mehr erreichbar. Nach einem Neustart der QNAP sind diese ca. für 5 Minuten ohne Probleme zu erreichen. Danach sind die Freigaben nicht mehr erreichbar, egal ob über Hostname oder IP Adresse.


    Zusätzlich lässt sich die QNAP nicht mehr sauber Neustarten bzw. Herunterfahren. Auch nach 12h abwarten mit der Meldung „System Shutdown“ im Display fährt die QNAP nicht herunter. Die QNAP lässt sich nur über die Powertaste abschalten.


    Seit längeren haben wir auch Probleme mit sporadischen Neustarts, dann steht nur im Systemprotokoll "The System was not shut down properly last time." Dies passiert aber nur alle paar Monate.


    Die Firmware der QNAP ist die 4.2.6.

    Vielen Dank schon mal für Eure Hilfe!

    Zitat von Optimessprime

    QNAP TS-859U+

    Hallo,


    ich kann dieses Modell nicht finden. Handelt es sich möglicherweise um ein TS-859U-RP+ bzw. SP+?

    Zitat von Optimessprime

    Die Firmware der QNAP ist die 4.2.6.

    Leider gibt es mittlerweile 11 FW-Version mit dieser Nummer. Bitte nenne auch noch das Build-Datum.

    Wie wurde diese FW installiert. Es kann zu Problemen kommen, wenn die automatische Update-Funktion benutzt wird. In diesem Fall das FW-Archiv herunterladen und nach dem Entpacken die FW manuell mit dem QFinder oder das Web-Frontend drüber installieren. Andernfalls trotzdem noch mal installieren. Und vor der Installation das NAS bitte neu Starten.


    Werden in der Ereignisanzeige Fehlermeldungen angezeigt?

    Hat das NAS eine feste IP-Adresse, oder wird DHCP benutzt?

    Gibt es möglicherweise einen Adresskonflikt?

    Die Angaben waren bis jetzt was dürftig, hier ein paar mehr Infos:


    NAS-Modell: QNAP TS-859U+ (Ist die Bezeichnung die im Admininterface steht) Glaube aber das es eine TS-859U-RP+ ist. Kann man die irgendwo auslesen? Auf der QNAP finde ich leider nichts

    - NAS-Firmwareversion, Build-Date: 4.2.6 , Build 20171208
    - Festplattenanzahl x Festplattentyp: 8x ST4000NM0033-9ZMSN04 mit 3726,02 GB

    - Festplattenkonfiguration: RAID5

    - Volumeverschlüsselung aktiviert ja/nein: nein

    - Netzwerkschnittstellenkonfiguration: Schnittstelle Ethernet 1+ 2 (1GbE), kein DHCP, Feste IP, Bündelungsgruppe 1 "IEEE 802.3ad" Ethernet 1+2, kein VLAN

    - Netzwerkbasisanschluss der NAS: Switch/1000Mbit

    - WLAN/DLAN Verbindungen von/zur NAS ja/nein: Nein

    - angeschlossene externe Geräte: keine Geräte angeschlossen, Zeitweise zur Datensicherung eine externe Festplatte mit 5 TB


    Ich konnte das Problem eingrenzen. Es hängt wohl mit den sporadischen Shutdowns zu tun, der kurz bevor das Problem auftrat, wieder statt fand. Das hat wohl anscheinend zu Problemen mit dem RAID geführt. Das entsprechende Log im Anhang.

    Im Moment führe ich eine Überprüfung des RAID Dateisystems durch. Diese läuft aber schon seit 17 Stunden und ist noch bei 0.0%.


    Hi,


    kann es sein das beim Win10 die SMB Versionen durch ein Update seitens MS eingeschränkt wurden und die Freigaben deshalb nicht mehr sichtbar sind?



    Cheers,


    Gerry

    Hallo dehoschii,


    das Problem habe ich nicht nur bei den Windows Freigaben, auch wenn ich per FTP auf die Ordner zugreife. Die Verbindung bricht Zeitgleich zusammen, wenn auch die Windows Freigaben nicht mehr gehen.

    Mal drüber nachgedacht eine kleine USV an das 2. Netzteil zu hängen?


    Ich hatte schon 2x bei 859U-RP defekte Netzteile sowie nach längerem Betrieb + defektem Netzteil einen fehlerhaften RAM-Riegel.


    Das ist halt alte Hardware....

    Die vielen fs-ext4 errors ehen für mich aber eher nach einem defekten Filesystem aus!

    Schon mal das Volumes einem "Filesystem-Check" unterworfen?

    Ausserdem müsste es auch für diese Geräte eine neuere FW geben, 4.2.6-20180531 müsste die aktuelle sein.


    Gruss

    Ja, genau. Das war auch meine Vermutung mit dem defekten Filesystem. Der Filesystem-Check läuft im Moment, hängt aber bei 0,0 % bei fast 24 h Laufzeit.

    Firmware update kommt, wenn ich wieder an die Daten komme. Hatte leider schon des öfteren, das die QNAP einen totalen Datenverlust hatte nach einem Firmware Update hatte.

    Da ich auch des öfteren Probleme habe einen FS Check durchzuführen gehe ich gewöhnlich nach diesen Schritten vor, das funktioniert bei mir immer.

    Allerdings hängt der Check nicht, sondern bringt immer den Fehler "cannot unmount disk".

    Wenn ich dann nachsehe welche Prozesse auf /dev/md0 zugreifen sehe ich haufenweise Einträge mit QSync und Phyton. Ich vermute das beide den Check verhindern da sie nicht terminiert werden können.

    bei mir reicht es übrigens die Prozesse per CLI zu stoppen, mit dem lsof Befehl die Prozesse herauszufinden und per kill zu stoppen.

    Danach kann ich in der GUI den Filesystem check durchführen. Nach dem Ceck werden die Dienste auch alle wieder gestartetm ein Reboot ist nicht notwendig.


    Gruss

    Danke FSC830, zumindest konnte ich so mal einen FS Check durch führen.

    Leider bricht er Erfolglos ab:


    Auch das ausführen von # e2fsck_64 -fp -C0 /dev/md0 brachte keinen Erfolg.


    Code
    [69052.490321] Out of memory: Kill process 23093 (e2fsck_64) score 575 or sacrifice child
[69052.492561] Killed process 23093 (e2fsck_64) total-vm:940404kB, anon-rss:450824kB, file-rss:60kB

    Schlussendlich habe ich die beiden Netzteile und den Speicher ausgetauscht, die NAS neu initialisiert und die Firmware aktualisiert.

    Jetzt heißt es nur noch abwarten, und hoffen das die sporadischen Shutdowns Geschichte sind.

    Trotzdem danke für eure Hilfe!

    Der QNAP Support konnte mir auch noch mal weiterhelfen. In den LOGs tauchten immer wieder segfaults auf, die auf einen defekten Speicher hinweisen können.

    (Segfaults sind General Protection Faults, die normalerweise durch Speicherfehler auftreten können oder durch beschädigte Dateien.)


    Seitdem der Speicher getauscht wurde, traten auch keine weiteren segfaults auf.

    Danke dir für die Rückmeldung zu den Segfaults, das war mir noch nicht bewusst, das man das direkt ableiten kann.


    Grüße,


    Gerry