Hi
Ich habe seit einiger Zeit dasselbe Problem auf einem TS-451DeU.
Zeitlich kann ich das leider ebenfalls nicht wirklich zuordnen, da es eher zufällig aufgefallen ist, dass GPT.INI fehlt. Es muss aber eines der jüngsten FW-Updates (Nov/Dez 23) gewesen sein. Die akutelle Firmware QTS 5.1.4.2596 behebt das Problem nicht. Nach dem Reboot fehlt das File.
Hallo Crazy,
danke für die Antwort. Irgendwo hatte ich den Beitrag mit dem SAT-Teil bereits gelesen. Per SMB hängen da ausschließlich (Domain-)Windowsen dran; ich werde trotzdem mal mit einem Nicht-Domain-Linux prüfen ob es noch auftritt, wenn die Windowsen aus sind. Ich bin aber trotz alledem der Auffassung, das da ein Grundproblem in der Samba-Installation/Konfiguration vorliegt.
Danke auch für den Tip mit dem Cache. Ich habe genau darüber länger gegrübelt und mich dann für den Cache entschieden, da ich in der von dir vorgeschlagenen Konfiguration auch nicht die Mega-Vorteile gesehen habe und der Cache so für meine Videokameraaufzeichnungen ebenfalls zur Verfügung steht (Läuft per NFS, hatte ich oben aber nicht erwähnt.)...Mir fällt nach nochmaligem Grübeln aber auf, dass mir das Cachen bei Video wohl ebenfalls ziemlich wenig bringt....ich denke, ich versuche es dann doch mal mit nem extra Pool.
Hallo
Ich bin seit über 5 Jahren Besitzer eines QNAP (erst TS-451U, jetzt TS-451DeU) und habe hier schon häufiger Lösungen für meine Probleme gefunden. Bei meinem aktuellen Problem sind mir mittlerweile die Ideen ausgegangen und ich suche mal aktiv Hilfe.
Erst einmal Daten zu meinem Gerät:
TS-451DeU, Firmware: 4.5.1.1495 Build 20201123
Storage 4x WD Red 3TB als Raid5 + 2x Crucial M.2 250GB Raid1 als Cache
Aktive genutzte Dienste:
- Virtualisation Station (1 VM)
- Domain Controller (private Mini-Domain)
- SMB-/NFS-Share
Ich habe seit einem Update irgendwann in diesem Jahr das Problem, dass in regelmäßigen Abständen die SMB-Zugriffe von Windows-Clients in Timeouts laufen. Die NFS-Verbindungen von Linux-Clients funktionieren einwandfrei. Das Webinterface läuft bei einer Anmeldung ebenfalls in einen Timeout und die SSH-Anmeldung dauert ca. ne Viertelstunde. Wenn ich SMB per SSH neustarte (/etc/init.d/smb.sh restart), läuft es eine Zeit lang wieder. Das Problem tritt dann aber nach ca. einem Tag wieder auf.
Ursache für die Hänger ist die hohe CPU-Auslastung/Load auf dem System die durch Samba erzeugt wird. Leider konnte ich das Problem nicht wirklich eingrenzen und habe mir daher sogar ein neues NAS gekauft, da ich angenommen hatte, dass evtl. die CPU mit den neueren Samba-Versionen überfordert war. Das war leider ein Trugschluss. Das Problem ist auf dem neuen System genauso heftig wie auf dem Alten...Sehr ärgerlich, da unnötig einiges an Kohle geopfert
(Btw. ich hätte nun ein TS-451U übrig...).
Da das Problem mit dem neuen NAS weiter existiert habe ich mich doch weiter damit beschäftigt und folgendes rausgefunden:
Es gibt drei Prozesse, die dauerhaft viel Last erzeugen (zwischen 30 und 70% CPU):
{samba-tool} /usr/local/Python3/bin/python3 -B /usr/local/samba/bin/samba-tool domain passwordsettings set --min-pwd-age=0 --max-pwd-age=0 --min-pwd-l
/usr/local/samba/sbin/samba -s /etc/config/smb.conf
/sbin/dnsmasq -S /DOMAIN.local/127.0.0.1Bei der Last sticht besonders das samba-tool Kommando hervor. Ich frage mich wozu das ständig ausgeführt wird. Die Settings werden doch eigentlich nur einmal gemacht und das wars. Warum wird das ständig aufgerufen?
Wenn ich htop richtig interpretiere, wird dieser samba-tool-Prozess immer wieder vom Daemon "qooba --service gpo" gestartet. Dieser Daemon wird scheinbar beim Aufruf des Samba-Startup-Scripts gestartet. Zu diesem qooba-Teil finde ich leider gar nichts (vielleicht bin ich auch nur zu blöd zum suchen)....
Im Moment verzichte ich schon darauf, die VM im Virtualization Center laufen zu lassen, um die CPU zu schonen...trotzdem hängt der Kram regelmäßig wieder. Kann mir jemand weiterhelfen?
Danke und guten Rutsch
Maik