mgutt

Nicht gerade einfach. Passt da denn dann noch ein mATX rein? EDIT: Ach das ist ja mATX ich Depp 🙈

Port 80 and 443 are HTTP ports. OpenVPN can use these ports, but it does not "speak" HTTP. The problem is that Nginx listens to the ports 80 and 443 and expects HTTP. So Nginx does not understand the incoming traffic. Optional it would be possible to add a "stream host" in Nginx. By that Nginx supports any "language" and it would be possible to forward the incoming traffic on port 443 to any target you like. But by that it ignores HTTP and domain names completely and any traffic on port 443 is forwarded to one single target. This means you can't distinguish through the domain name and forward the traffic to different targets. But if only OpenVPN should listen to port 443 this would be a solution. There is a very special method available which scans for the domain name by encrypting the SSL traffic in advance, but I don't know if it works with Nginx Proxy Manager as it needs a specific Nginx SNI extension which adds "SSL preread": https://stackoverflow.com/a/40135151/318765 And it isn't guaranteed that it will work. As an example someone mentions in the link's comments, that it does not work for SSH as it does not forward the domain name. Not sure about OpenVPN.

Wenn du nur einen User Share mit "cache-only" getestet hast, dann wird Fuse nicht umgangen. Habe ich gerade ausprobiert. Das solltest du auch über "htop" sehen. Da sollte ein SHFS Prozess mit hoher Last dabei sein. Nur wenn man Disk Share Pfade nutzt, taucht der SHFS Prozess gar nicht auf. 😒 Ok, dann muss ich wohl doch bald mal 6.10 testen 🙈 Hmm.. ich hab noch einen Atom hier und eine Intel SFP+ Karte... das ginge doch 😁

Yes, but still without a fixed release date. Most other OS have already fixed this issue.

What is the reason for this process? After starting the docker service without starting a container it's already present: This means it is something related to docker service itself. I found this documentation. It mentions the log-driver, which should be "json-file" as it is the default if no /etc/docker/daemon.js exists. So it would write logs to a json file, but is there really a log file for the docker service itself? EDIT: Yes there is a daemon log file under /var/log/docker.log, but this file is tiny and its last entries are several minutes old as well. And it looks like the process does not even access the log file: # ps -aef | grep containerd root 7815 7791 0 10:40 ? 00:00:03 containerd --config /var/run/docker/containerd/containerd.toml --log-level error root 29548 11758 0 10:55 pts/1 00:00:00 grep containerd Or is this something which can't be further influenced?

Cache Only? Dann dürfte es Fuse/SHFS umgehen. Wird es nicht. Nur bei Disk Shares.

Das ist krass. Weil die CPU ist ja mal echt schwach. Kannst du mal unRAID 6.9.2 testen? Da ist es noch Samba 4.12 und mit 6.10 dürfte denke ich ein neueres Samba enthalten sein, das ja seit 4.14 in Sachen Performance zugelegt haben soll. Mit SMB 4.13 sollte sogar RSS standardmäßig erkannt werden. Das könntest du testen, in dem du in Windows beim Netzwerk Treiber RSS (Receive Side Scaling) testweise deaktivierst.

Weil SMB davor liegt und das eben nur Single Threaded ist. Wenn du "htop" im Terminal beim Transfer öffnest, siehst du, dass zig SHFS Prozesse laufen, aber nur einer hat eine hohe Last (der den SMB Transfer "empfängt"). Wie gesagt. Multichannel + RSS und dein Problem hat sich erledigt. Ich nutze das schon seit Jahren. Damals noch auf einer Syno.

Poste mal bitte einen Screenshot von deiner NC config. Ich kann davon ausgehen, dass du bei der UD Disk keinen Share in den Einstellungen aktiviert hast? Hat denn einer der geloggten Kommandos die Disk geweckt? Also konntest du da einen Zusammenhang wahrnehmen?

It's not a bug, it's a feature, wie man so schön sagt. Bei User Shares überwacht unRAID ständig ob die Dateien auf den Cache oder die HDD übertragen werden soll. Dazu müssen verschiedene Regeln beachtet werden wie der Füllgrad und welches Split-Level der Nutzer eingestellt hat. Dieses Komfort-Merkmal kostet Rechenleistung und dein Ryzen 2700 scheint nicht genug davon zu haben, so dass du es bei 10G merkst. unRAID ist dabei eigentlich gar nicht mal so der Flaschenhals, sondern Samba, was nur auf einem CPU Kern ausgeführt wird. Die Kombination aus SHFS und Samba überlastet dann 1 bis 2 Kerne des Servers, selbst wenn man eigentlich genug davon hat. Das nächste Problem ist, dass Samba nach wie vor kein Multichannel, geschweige denn RSS aktiv hat. Gerade RSS würde dir viel bringen, da sich die Last dann auf mehrere Kerne verteilt. RSS muss aber auf beiden Seiten (Client und Server) unterstützt werden und ist immer noch nicht offiziell freigegebn. Mehr dazu steht im Guide. Diese Einschränkung gilt aber wie gesagt nur bei User Shares. Man kann sagen User Shares sind das Standard No-Brainer Setup und Disk Shares bzw Disk Pfade sind was für die Fortgeschrittenen, da man sie auch erst einsetzen sollte, wenn man das Konzept des Caches und des Movers verinnerlicht hat. Aber wie schon gesagt muss es das nicht zwangsläufig sein. Es gab auch schon andere Ursachen.

Dann leidest du vermutlich unter dem SHFS Overhead. Dieser entsteht, wenn man Dateien nach /mnt/user hochlädt und nicht nach /mnt/cache. Mehr dazu hier: https://forums.unraid.net/topic/97165-smb-performance-tuning/ Wenn du es auf die schnelle testen magst: Disk Shares aktivieren und direkt auf den Cache hochladen.

Not needed for any game, but helps if you like to block specific traffic / IP addresses. They force the user to enter domain:port, do not allow any different ports, but SRV records are supported to allow entering the domain only?! Why did they add SRV support instead of simply removing the obligation to enter the port. Strange. 😅

Yes, sometimes user requests are ignored and ignored 🙈 But Valheim supports it. 👍

Maybe someone is interested: I added a guide how to setup NPM to forward traffic for multiple minecraft servers: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/?tab=comments#comment-1011161

Ich sehe wieder nichts. Hast du mirror syslog nicht aktiviert? https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1008640 Aktiviere die Option. Was ich dann machen würde: ich würde mir eine neue Platten kaufen. Dann würde ich das Array runterfahren und Disk 4 mounten und ein Backup davon machen. Danach wieder Disk 4 rebuilden lassen und den Fehler provozieren. Diesmal aber dank mirror nachvollziehen was da los war. Schlussendlich klingt es für mich aber nach einem Totalausfall der Verbindung, da die HDD im Smart keine CRC Fehler geloggt hat. Also evtl: - defekte Stromversorgung (Wackelkontakt?!) - defekte Datenverbindung (Kabel, Buchse, etc) Ist die HDD an einer "besonderen" SATA Buchse, also andere Karte oder ist auf dem Board ein separater SATA Controller verbaut?

Vergleiche mal bitte die beiden XML mit einem Online Textvergleich Tool. Einfach um zu sehen was sich unterscheidet.

I wonder nobody checked their log path: du -sh /var/log/* Maybe the ngnx error is only a subsequent error.

Das spricht sonst denke ich nichts gegen. Single Thread Leistung sieht auch OK aus: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2680+v4+%40+2.40GHz&id=2779 Mehr ist natürlich nie verkehrt. Muss man sehen was es kostet.

Parity Check ist doch nur lesen (wenn keine Fehler vorhanden sind). Oder ist die Disk kleiner als die Party? Dann stimmt das natürlich.

Alternativ dazu könnte man auch einen Screenshot von der Disk Übersicht machen und eine New Config starten. Dann die Parity als bereits valide starten und einen Parity Check durchführen. Ist nur eine Frage ob man der Disk oder der Parity mehr vertraut.

Die CPU hat keine iGPU. Wenn du VMs betreiben möchtest, kann es gut sein, dass du direkt zwei GPUs brauchst, da die primäre gerne mal von Unraid in Beschlag genommen wird. Ansonsten wäre eben noch der hohe Stromverbrauch evtl relevant.

Dann ist die Auslastung so gering gewesen, weil einfach so wenig durch die LAN-Buchse ging. Ich denke mal jetzt mit Gbit wird die CPU mehr zu tun haben oder?

Ne gar nicht. Normalerweise wird absteigend nach Last sortiert und ohne diese Baumstruktur: Damit ich das so wie bei dir angezeigt bekomme, muss ich erst auf den Buchstaben "t" drücken. Mach das mal. Ich habe auch mal "t" gedrückt, also die Baumansicht aktiviert und htop beendet. Beim nächsten Start ist es wieder ohne Baumstruktur. Keine Ahnung warum das bei dir Standard ist.

Du hast die Sortierung in htop geändert. Bitte Standard lassen. Hast du wirklich nur eine 100 MBit LAN Buchse? Laut meiner Recherche hat dein System Gbit. Sicher, dass dein Switch Gbit-fähig ist?

Die CPU Last im Dashboard enthält auch I/O Wait, also wenn die CPU auf eine HDD warten muss. Die reale Auslastung, kannst du sehen, wenn du im WebTerminal "htop" ausführst. 70% ist erstaunlich wenig, dafür dass du schreibst und parallel ein Parity Check läuft. Oder geht dein Transfer nicht aufs Array? EDIT: Achso. Du hast nur eine 100 MBit LAN Buchse. Ernsthaft? Kein Gbit? Kann ich mir beim besten Willen nicht vorstellen. Sicher, dass dein Switch hier nicht die Bremse ist?