Beiträge von kk_it

  • Hohe Auslastung smbd-notifyd

    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

  • Volume verkleinern steckt fest bei 52,7%, bitte um Hilfe!

    @fel-ts251plus


    Nach dem Update auf die neueste Firmware (zum Zeitpunkt der Durchführung 4.3.6.0993 build 20190704) funktionierte der Resize ohne Probleme.


    Einziger Haken: Irgendwo in der 50% Region bleibt er stecken, jedoch nur, weil anscheinend nicht geupdatet wird. Nach 4 Stunden sprang der Prozess dann plötzlich auf 91%

    Mein Tipp: Alle unnötigen Dienste (SMB/AFP/DHCP bzw NTP Server und alle Apps im Appstore) ausschalten, rebooten, dann den Vorgang durchführen.


    Backup sollte selbstverständlich sein.

  • Hohe Auslastung smbd-notifyd

    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~

  • Hohe Auslastung smbd-notifyd

    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--

  • Hohe Auslastung smbd-notifyd

    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.

  • Hohe Auslastung smbd-notifyd

    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.

  • 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

  • Volume verkleinern steckt fest bei 52,7%, bitte um Hilfe!

    Hallo Jagi,


    das mit stehen bis Montag war selbstverständlich nicht an euch gerichtet! Das wäre absolut respektlos, ich weiß, dass sich die User hier im FOrum die Zeit nehmen und ihr Wissen teilen, dafür bin ich sehr dankbar. Der Satz war einfach dafür da, meinen Zweifel kund zu tun. Ich werde ihn rausnehmen, da er wohl fehl am Platz ist.


    Backups sind vorhanden und werden täglich auf einem baugleichen Modell durchgeführt.


    Danke nochmal



    Hallo nochmal,


    ich habe soeben herausgefunden, dass die obige SSH-Antwort aus dem Server auf keinen Resync-Prozess zurückführt, sprich, es wird nicht mehr verkleinert. Das kann von mehreren Faktoren abhängen, wie blockierende Apps und Technischem, was über meine Expertise hinausgeht. Ich habe den Server neugestartet:


    1. Reboot dauerte 4-5 Min., hier war der Server nicht da, weil die IP-Adresse nicht korrekt vom Router genommen wurde (war mit LACP konfiguriert).


    2. Reboot, dieses Mal mit nur einem LAN-Port und ohne LACP brachte die Lösung.

    Problem: Das zu verkleinernde Volume war nun unsauber.

    Lösung: File System Check durchgeführt, alle Ordner sind normal per SMB zugänglich.


    Ich werde nun die Migration starten, ohne eine Vol-Verkleinerung.


    Danke dennoch für die Möglichkeit, hier posten zu dürfen.


    Freundliche Grüße und angenehmes WE.

  • Volume verkleinern steckt fest bei 52,7%, bitte um Hilfe!

    Liebe Forum-Kolleg/Innen,


    leider habe ich ein etwas erschreckendes Problem:


    Wir haben bei uns eine TVS-863 mit der neuesten stabilen Firmware und mit 8 Festplatten je 2,73TB in RAID 6 laufen. In einem einzigen riesingen Pool befindet sich 1 Volume mit 3 Freigaben, alle Volumes sind Thin-Volumes nebenbei:


    • Freigabordner1: 180GB groß - Archiv
    • Freigabeordner2: 200GB groß - kleiner Office-Kram
    • Freigabeordner3: knapp 6,5TB groß - Projekte, wichtiges Zeug


    Ich habe vor ca. 2 Wochen zum ersten Mal Snapshots darauf eingerichtet und bin dann auf einen Artikel über die Migration von Freigabeordnern in Snapshot-Freigabeordnern mit eigenen Volumes entdeckt.


    Ich habe mit der Migration angefangen, Vol1 und Vol2 gingen in 30 Min. auf die neuen Volumes ohne Probleme über.


    Hier nun der Twist:


    Die alte Volume (also der riesige alte Hauptvolume) war so groß, dass ich den Vol3 nicht migrieren konnte, ich habe daraufhin eine Verkleinerung des alten Hauptvolumes gestartet. Die Verkleinerung ging innerhalb von einer Stunde auf 52,7% hoch und verweilt da nun seit ca. 14 Stunden!


    Ein Befehl, den ich im QNAP Forum gefunden habe zeigt den aktuellen Stand:




    Ich bin wirklich ratlos, habe ich einen Fehler gemacht? Kann es sein, dass ich die Volume "zu sehr" verkleiner habe? Im alten Volume sehe nämlich ein Überabbonement...



    Vielen Dank im Voraus für eure Zeit und Mühen!