Hohe Auslastung smbd-notifyd

    Liebes QNAP-Forum,


    wir haben seit ca. 2 Wochen das Problem, dass der Dienst "smbd-notifyd" eine sehr hohe CPU Auslastung hat. Wir waren bereits per Fernwartung mit dem QNAP-Support dran, jedoch wurde angeblich nichts gefunden.


    Daten:

    TVS-863 mit 16GB RAM

    Firmware 4.3.6.0993 Build 20190704

    8x3TB im RAID 6


    Vorfall:
    smbd-notifyd-Dienst nimmt sehr viel CPU-Last auf und der RAM wird mit der Zeit voller (evtl. logfiles)


    SSH mit "top"-command zeigt, dass

    Code
    PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
13107 13104 admin    S    2276m 15.1   1  9.8 {smbd-notifyd} /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.conf

    der Übeltäter ist, jedoch ist diese PID unter /usr/local/samba/bin/smbstatus nicht auffindbar.


    Ich bin mir nicht sicher, glaube aber, dass dieses Problem kurz nach einem Firmwareupdate aufgetreten sein könnte.


    Was ich versucht habe:

    LACP bzw. 802.3ad dynamic neu aufgesetzt/entfernt und nur über ein LAN-Kabel laufen lassen. (Hatte es im Forum gelesen)

    Alle Backup-Aufträge deaktiviert und Hybrid-Sync Dienst beendet (Empfehlung IT-Fachkraft)

    Rechte der User neu aufgesetzt


    Was sofort Abhilfe schafft, ist, den Samba-Dienst neu zu starten.


    Any ideas? Ist das vielleicht sogar bei anderen Usern replizierbar?


    Best wishes

    KK


    Edit:

    Ich habe auch ein Dateisystemcheck durchgeführt

    RAID-Scrubbing läuft jede Woche ab

    Speicher ist zu ca. 70% voll

    So was ähnliches hatte ich auch.

    1. Prüf mal die DNS Einträge.

    2. Ist AntiVirus aktiv? Wenn 1. nichts bringt dies mal deaktivieren und NAS neustarten und beobachten.

    3. Malware Remover ist hoffentlich installiert. Ansonsten installieren oder aktualisieren und durchlaufen lassen.

    Hey Mavalok,


    danke erstmal für die rasche Message.


    1. Die DNS-Einträge habe ich tatsächlich geprüft und auch resettet (war auf Cloudflare, habe ich dann auf den Router gestellt)


    Oder meintest du, ich soll auf dem Router (ist ein UniFi USG) schauen?


    2. Antivirus wurde ebenfalls deaktiviert, vorher ein Testdurchlauf gemacht


    3. Malware Remover wurde auch ein Durchlauf gemacht.



    Meine nächsten Schritte:

    strace über entware-ng installieren und die PID suchen, nach dieser Anleitung:


    SMB Dienst läuft Amok - hohe CPU


    VG


    UPDATE: Ein tcpdump | grep "SMB" zeigte, dass ein iMac im Netzwerk den Server mit SMB-over-TCP Packets regelrecht überschwämmt, ich werde mir das anschauen und hier dann ein Update posten.

    Einmal editiert, zuletzt von kk_it ()

    Ich meine schon die DNS Einträge beim NAS. Bei einem Update hat es mir diese verstellt. Internet und alles weitere hat auch weiterhin funktioniert, weshalb mir dies nicht aufgefallen ist. Aber in der Nacht als der AntiVirus seine Definitions laden wollte hat dies zu Problemen geführt und den Samba-Dienst amok laufen lassen. Nach einem Neustart hat immer alles wieder funktioniert bis zum Definitions-Update des Virenscanners. Ursache war letzten Endes falsche DNS Einträge.

    Bei mir dient der Samba auch als DC- und DNS-Dienst und vermutlich wurde der Samba durch die falschen Einträge vom Virenscanner mit Anfragen bombardiert, möglicherweise wie bei Deinem iMac.

    Ein TCP-Dump sowie testweise Abschaltung von Macs in unserem Netzwerk hat leider keine Abhilfe geschafft. Mir fällt leider nichts mehr ein, kann hier jemand bitte weiterhelfen?


    Edit: Samba's Logstufe wurde auf 3 gestellt, leider kann ich die CPU-Last jedoch keinem Zugriff zuordnen.

    Einmal editiert, zuletzt von kk_it ()

    Zitat von kk_it

    ... testweise Abschaltung von Macs in unserem Netzwerk hat leider keine Abhilfe geschafft.

    Macs abschalten und danach NAS neustarten. Bei mir hat sich der Dienst erst nach einem Neustart beruhigen lassen, bis zum nächsten Auslöser.

    Beim Scan mit OpenVas ist mit mit der Firmware 4.3.6.0993 der Dienst auch das erst mal aufgefallen, dass er auf einem Kern volle Last erzeugt.

    Nach dem Neustart war das weg.


    War aber auch das erst mal das ich mit dem very deep ultimate auf das QTS los gegangen bin.


    Ist dein NAS aus dem Netz erreichbar?

    Nicht das hier jemand versucht den Dienst zu knacken.

    Hallo und erstmal danke für eure Messages, und sorry für die späte Rückmeldung.


    Ich habe jetzt die neueste Firmware aufgespielt, leider ist das Problem nicht behoben worden. Ich habe den QNAP Support diesbezüglich kontaktiert und man sagte mir, dass ich eine non-QVL RAM eingebaut hätte, Ausbaue erfolgt die Tage. Finde ich jedoch strange, da der Riegel schon über 1 Jahr verbaut ist.


    Crazyhorse : DDNS habe ich probeweise abgeschaltet, die QNAP war im Netz, leider nicht geholfen.


    Mavalok2 : Den SMB-Dienst einmal kurz neu zu starten hilft auch, ab diesem Zeitpunkt bin ich fast sicher, dass einer der MACs der Trigger für die Auslastung ist, da je nach Tag mal es nichts gibt, es dann aber plötzlich auftaucht und der Server abschmiert. Leider haben wir knapp 40 Geräte und ein ausfiltern ist fast unmöglich, da alle permanent am Arbeiten sind.


    Es sind alle Geräte Macs, die vorletzte MacOS soll angeblich SMB Probleme adressieren, werde das firmenweit mal aufspielen und schaue dann weiter.


    Best--

    Ich setze unter MacOS anstelle SMB NFS ein. Ich habe das Gefühl, dass ich unter NFS ein wenig mehr Durchsatz hinbekomme. Allerdings habe ich keine 40 Geräte, bei mir privat. :)

    Ich habe soeben Rückmeldungen von QNAP zu diesem Problem erhalten:


    1. Eine von zwei 8GB-RAM Modulen ausbauen, die ich vor 1 1/2 Jahren mal eingebaut hatte, da dieser nicht in der QVL sei. Obwohl es noch nie Probleme gab, werde ich das mal tun.

    2. Die Firmware 4.3.6.1040 ist zurückgezogen worden, da sie diverse Fehler enthielt. Ich hatte sie damals per QNAP aufgespielt (ein Grund mehr, etwas zu warten).

    Ich sollte ein Downgrade durchführen, was ich garnicht mag, jedoch ist Build 1050 raus und ich werde das erst einmal testen.


    So long~

    Kurzes Update:

    Nach Upgrade auf 4.4.1.1064 scheint das Problem nicht mehr aufzutauchen, ich halte euch auf dem Laufenden.


    MacOS Versionen zu dieser Zeit: 10.14.6 inkl. ergänzendes Update 1 (nicht 2)


    VG
    Eren