Ich würde ihn erst migrieren lassen. Aber das ist meine persönliche Meinung.
Auf keinen Fall beides parallel.
Die Meldung sagt erst einmal nur, dass ein Volume nicht unmounted wurde, und daher eventuell Fehler haben könnte.
Sowas ist zu erwarten, wenn man ein NAS "hart ausschaltet".
Was mich nur wundert, wenn es mit der Firmware zusammenhängt... Es haben doch sicher schon viel mehr Leute auf 5.0.0.1892 upgedated.
Das müssten die doch auch haben?! Ich kann mir nicht vorstellen, dass niemand den Outgoing DNS-Traffic monitored in seinem Netzwerk.
tiermutter Danke für den Link auf den Post, den kannte ich noch nicht.
Ich bin nicht mehr der Einzige. <jubel> 
</jubel> Sorry, garderobier
Jetzt müssen wir nur noch die Ursache finden.. Okay, Du hast am 27.12.2021 Deine Firmware geupdated... Ist es Dir vorher vielleicht nicht aufgefallen und jetzt reichen die Logs nicht mehr weit genug zurück?
Bei mir hat es am 28.12.2021 angefangen; genau an dem Tag habe ich die neue Firmware QuTS 5.x eingespielt.
Der Malware-Remover läuft bei mir täglich. Das App-Center steht auf Auto-Update. Der Malware-Remover hat seit dem 28.12.2021, seit dem tritt das auf, noch nichts gefunden.
Die Liste der laufenden Prozesse (ps) bin ich zweimal komplett durchgegangen, auch da für meinen Geschmack nichts auffälliges; außer das QuTS, aber das hat es vorher auch schon getan, eine Unmenge aktiver Prozesse hat im Vergleich zu QTS. Bei beiden Stichproben liefen so ca. 3.500 Prozesse.
Ich bin ja selbst total am Rätseln, was und wieso.
An einen Miner hatte ich auch schon gedacht, aber dann wieder frage ich mich, wie der draufkommen sollte. Ich gebe keine listening ports des NAS ins Internet raus.
War auch meine Vermutung... aber sollte man das nicht auch gerade an der CPU merken?
Das macht mich ein wenig stutzig, dass ich keine erhöhte CPU Last finden kann.
Hallo zusammen,
ich habe ein kurioses Phänomen auf meinem QuTS TS-h886.
Seit ein paar Tagen (konkret seit dem 28.12.2021) beobachte ich massenhafte DNS-Anfragen nach dem A-Record von ipfs.adatools.io ProTag kommen so um die 150.000 Anfragen (!) zusammen, es ist mir nur aufgefallen, weil ich meinen eigenen DNS-Resolver betreibe. Aber alle Anfragen kommen von der IPv6-Adresse des NAS. Bisher konnte ich den Grund nicht ausfindig machen. In Verdacht hatte ich virtuelle Maschinen bzw. Docker-Container. Aber selbst ein Stop aller virtuellen Instanzen ändert das Verhalten mit den Unmengen an DNS-Anfragen nicht. Ich finde das Verhalten aber überaus suspekt.
Es gibt auch kein auffälliges I/O-, CPU- oder RAM-Verhalten auf dem TS-h886. Die CPU geht selten über 18%. Ich konnte bei verschiedenen Stichproben auch keine verdächtigen TCP-Verbindungen finden, alle Verbindungen zu den Zeitpunkten der Stichproben waren legitim. Es gibt auch allgemeinen keinen Auffälligen Netzwerk-Traffic von oder zum NAS. Sieht man von den komischen DNS-Anfragen nach diesem einen Record ab.
Das einzige was entfernt mit dem Auftreten des Phänomens zusammenhängt... am 28.12.2021 habe ich ein Firmware-Update auf QuTS h5.0.0.1892 eingespielt.
Vielleicht hat ja noch einer von Euch eine Idee.
Danke.
Das liegt vermutlich an der Konfiguration. php greift über einen anderen Weg auf die Datenbank zu als das CLI-Tool.
Das CLI-Tool möchte einen Zugriff über Unix Socket machen, kann diesen aber nicht finden.
Das PHP und auch Kodi wird höchstwahrscheinlich einen Zugriff über TCP/IP machen.
Zwei mögliche Lösungen: Lass das CLI-Tool über TCP/IP zugreifen. Oder prüf mal, was am Unix Socket nicht passt.
Hi nils_heidorn
oh man, es stand im Betreff/Titel. Da hab ich es nicht wahrgenommen. Peinlich.
Das das Kabel am Switch funktioniert ist "Glück". Denn das von Dir genannte Kabel steht auf keiner Kompatibilitätliste. Weder auf der vom NAS noch der vom Switch.
Laut QNAP kompatible SFP+ Transceiver für den Switch: https://www.qnap.com/de-de/com…ty/?model=534&category=26
Laut QNAP kompatible SFP+ Transceiver für das NAS: https://www.qnap.com/de-de/com…ty/?model=325&category=26
Als gemeinsamen Nenner würde sich z.B. das Kabel: https://eustore.qnap.com/cab-dac15m-sfpp.html eignen.
Barungar
Grundsätzlich fehlen um Dir zu fehlen ein paar Angaben. Welcher Switch und welches NAS (mit welcher LAN-Karte).
Grundsätzlich gibt es so genannte Kompatibilitätslisten für SFP+ der einzelnen Geräte.
Ich würde daher, wenn man auf erhöhte Sicherheit wert legt gleich zu RAID-6 zu greifen.
Da "laufen" dann alle vier Festplatten, aber zwei davon können ausfallen und die Daten sind noch im Zugriff.
Hallo zusammen,
mir ist heute was aufgefallen... Ich betreibe im gleichen Subnetz ein QNAP TS-653b und ein QNAP TS-563, auf beiden ist LACP und IPv6 aktiv. Weiterhin betreibe ich einen DHCPv6-Server im Netzwerk, der Präfix und IPv6-Adressen verteilt. Dabei gibt der DHCPv6-Server jeweils das veränderliche Präfix des Providers weiter alsauch ein statisch definiertes ULA-Präfix (unique local address).
Das ältere TS-563 bindet daraufhin absolut korrekt drei IPv6-Adressen an sein Interface:
Das neue TS-653b hingegen bindet nur zwei IPv6-Adressen an sein Interface:
hier fehlt eindeutig die ULA!
Hat jemand sowas auch bzw. viel wichtiger hat jemand eine Idee, was ich dagegen tun kann?
Das TS-563 hat 4.3.4.0551.
Das TS-653b hat 4.3.6.0805.
