Beiträge von Nash123

SSH habe ich grundsätzlich aus und nur an wenn ich es vorher manuell freigebe

Meins hat sich in der Nacht sang- und klanglos aufgehängt. Ohne Fehlereintrag. Musste durch manuellen Shutdown wieder zum Leben erweckt werden da kein Zugriff über Browser o.ä. Dafür umso mehr Plattengerödel. Das passierte auch schon einmal zeitnah mit der Vorgängerfirmware. Wenn das sich häuft werde ich wohl downgraden.

Danke Becker2020. Hm, dann muss ich wohl doch nochmal an die OPNsense ran. Oder den Container mal neu einrichten.

Hallo tuxflo. Danke nochmal für deine Tipps. Hatte den mediathekview-container nun tatsächlich seit Jahren bis gestern problemlos in der Container Station im Einsatz, allerdings erhalte ich jetzt seit (vor)gestern beim Laden der Filmliste immer eine Javafehlermeldung mit - wie mir scheint - einem Zertifikatproblem, wenn ich die Meldungen im Terminal richtig deute.

Da ich vor nicht allzu langer Zeit eine OPNsense in Betrieb genommen habe und da auch am IDS/IPS Ruleset in den letzten Tagen rumgefummelt habe, dachte ich erst, dass es daran läge. Aber das scheint es nicht zu sein. Wenn ich das alles abschalte kommt der Fehler leider immer noch. Das Laden der Liste in einem Browser und manuelle Einpflegen in MV funktioniert auch noch einwandfrei.

Kannst du (oder jemand anders) mal bitte schauen ob das Laden der Filmliste funktioniert oder ob dann auch der Zertifikatsfehler kommt?

Vielen Dank vorab!

FW vor einigen Tagen aktualisiert. Jetzt gerade eben gab es einen Reboot aus dem Nichts.

"Power	NAS Power Status	[Power] The system was not shutdown properly last time."

Hm.

Heute gab es - nach mehreren Tagen problemloser Laufzeit - leider einen Reboot aus dem Nichts ...

Mavalok2

Manuell von der QNAP-Seite geladen und installiert.

Kein Neustart davor.

Ein (normaler) Neustart nach dem Einspielen.

Version davor war 5.0.1.2248

Lief bis vorhin schon mehrere Tage ohne erkennbare Probleme. Siehe auch Post 18 hier im Thread.

Powertaste lange gedrückt gehalten. Also auf die brachiale Art

Gestern dachte ich noch, wie gut das alles läuft mit der aktuellen Version. Heute habe ich plötzlich keinen Zugriff mehr auf das NAS und die Adminoberfläche, da diese gar nicht erst erscheint. Die Platten rödeln aber wie wild.

Nach einem langen Neustart geht es jetzt wieder, macht aber RAID-Sync ...

Läuft hier seit einigen Tagen ohne Auffälligkeiten.

Bin dann heute auch von der letzten 4.5er Version auf diese gewechselt. Kein Neustart nach über 50 Tagen Laufzeit. Dafür einen Neustart direkt nach dem (manuell geladenen) Update. Bisher funktioniert alles. Dauerte aber eine knappe Stunde mitsamt Neustarts, Warterei und Entsperrung des verschlüsselten Volumes.

Habe schon immer alles bei Autoupdate deaktiviert, da ich Firmwares und die meisten Apps mittlerweile händisch update. Bin auch immer noch auf der 4.5.4 1892. Insofern spricht einiges dafür, dass das "Zwangsupdate" nur erfolgt, wenn man einen der Haken an hat, wie andre-z schon über mir geschrieben hat.

Für das NAS (bzw. dessen interne IP) an sich sind auch outbound nur whitegelistete Domains erlaubt und der Aufruf direkter IPs verboten. qnap.com schmeiße ich jetzt aber auch mal eine Zeitlang von der Whitelist runter.

Ansonsten habe ich sogar eine Portfreigabe eingerichtet, aber die betrifft einen einzelnen rtorrent-Dockercontainer der Containerstation mit eigener interner IP. Bisher konnte noch kein Angreifer diese containerisierte Lösung überwinden. Zumal ja auch entsprechende spezielle Exploits in rtorrent bzw. der Station für einen Angriff nötig wären.

Nur für den Fall der Fälle. Habt ihr damit Erfahrungen? Gibt es Tools (für Windows)? Also außer in Linux mounten, etc. meine ich.

Diskinternals Linux Reader kann mit verschlüsselten ext4-Laufwerken wohl nichts anfangen.

Suche habe ich bemüht, aber leider nichts gefunden.

eyetap: Danke für das Angebot, aber da ich das NAS funktionsfähig brauche und auch gerade wenig Zeit für Experimente habe, bleibt das erstmal so auf dem Stand der 1741. Aber danke dass du das vorantreibst, damit QNAP das dann (hoffentlich) bald mal fixt.

eyetap: Doch, doch das war damals im späteren Verlauf ganz genauso mit der Lüfteranzeige. Habe die Hardwarewerte und das tatsächliche Verhalten auch immer im Blick.

Nein, ich habe damals kein Ticket aufgemacht. Bin zur Vorversion (1741) gewechselt und habe das Problem auf diese Weise gelöst. Hatte einige Zeit davor neuen Speicher und einen (nicht offiziell kompatiblen) SSD-Cache eingebaut und hatte die Vermutung, dass der Support das darauf schieben würde und wollte mir das ganze Gefrickel diesbezüglich sparen.

Hab damals in den Changelogs der 1787 auch noch gelesen, dass die da mit dem Auslesen der Hardware-/Lüfterwerte irgendwas bei QNAP geändert hatten.

Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Release Notes: QTS 4.5.4.1787 build 20210910

QTS could not correctly display the system fan speeds of the TS-882BR in Control Panel > System > System Status > Hardware Information.

Das (daraus?) resultierende Folgeproblem zieht sich jetzt offenbar durch alle neueren Firmwares.

Edit: Eine weitere Vermutung war, dass die manuelle Steuerung des Lüfters das Problem triggert und ggf. deswegen nur bei einzelnen Nutzern auftritt. Habe die "intelligente Lüftersteuerung" eigentlich nie an. Könnte man evtl. bei der Fehlersuche auch mal überprüfen.

Zitat von duke-f

Ich habe derzeit wieder was neues: Seit dieser oder der letzten Version ist nach einigen Tagen immer meine CPU sehr hoch belastet.

Die nach 3-4 Tagen auftretende hohe CPU-Last (hal-daemon) hatte ich auch schon zur Vorversion berichtet. Abstürze gab es bei mir auch.

Bin jetzt seit 12 Tagen wieder auf der 4.5.4.1741 und mit dieser Version ist endlich wieder Ruhe und Stabilität.

Nach einigen Tagen dreht der hal_daemon durch und erzeugt durchgängig 50% CPU-Last.

Vor dem Update war dies nie der Fall. Ich muss dann die Kiste neu booten, dann ist ein paar Tage Ruhe, bevor es wieder losgeht.

Edit: Was genau macht hal? Hat wohl was mit der Hardwaresteuerung zu tun, oder?

Danke!

Aktuellste Firmware.

Der Python-Prozess läuft übrigens auch mit aktiven Containern. Dann sogar mehrfach, wobei aber nur die eine ID die übermäßige Last erzeugt.

Muss mir wohl zukünftig vornehmen funktionierende Apps zu sichern, um im Fall der Fälle wieder zurück zu können.

Edit: Habe die Station soeben mal komplett platt gemacht (und nicht nur neu installiert) und alle Altlasten (sprich den entsprechenden Ordner) beseitigt. Frisch aufgesetzt ist der Prozess friedlich. Ich taste mich mal vor und schaue, ob evtl. ein Dockercontainer das Verhalten auslöst.

Edit2: Sobald irgendein Dockercontainer läuft geht es los mit der Last. Also wie vermutet, liegt es an der neuen Version der Containerstation-App.

Edit3: Eine alte Version (2.1.3.1360) funktioniert ohne das Auslastungsproblem. Jetzt muss ich nur noch die vorletzte Version als qpkg finden ...

Vergleichbares Problem in der aktuellen Version 2.4.0.2316.

Python2.7-Prozess nudelt immer 10-15% Last durch. Selbt wenn die Container nichts verbrauchen.

Wo findet man möglichwerweise die Vorversion (2.3.5.1708)? Da gab es das Problem nicht.