Gorosch

Was spuckt docker stats (in der Serverkonsole eingeben) denn so aus, was die CPU Last angeht? Du hast eine Menge Fehler in den Docker Logs: level=error msg="forward event" error="context deadline exceeded" Irgendein Container schlägt da quer. Am besten mal alle Stoppen und die Configs der Container prüfen (Mappings, Pfade, IPs, Ports, etc.).

Eine Portweiterleitung geht entweder oder sie geht nicht. Dazwischen gibt es nichts. Ich kenne leider nur die UDM-Pros in sämtlichen Variationen, weiß also nicht, wie beschnitten die UD7 im Funktionsumfang und Leistung ist. Daher kann ich nur indirekt vergleichen. Hat die UD7 solche Dinge wie DPI und Malware Schutz und sind diese aktiv? Wenn ja, ggf. mal zum testen abschalten. Ich kenne es noch von den alten USGs, dass diese Funktionen den Durchsatz ordentlich eingedämpft haben. Hast du Firewall Regeln erstellt, die sich eventuell in die Quere kommen? Auch mal die Logs des UD7 prüfen, ob da Dinge blockiert werden.

Multichannel war nur ein Hinweis, trägt hier jedoch nicht zur Lösung bei. Unraid benötigt bei aktuellen Clients normal keine besondere Anpassung und ist out of the Box sowohl per IP als auch per Hostname erreichbar. Da du ein einfaches Heimnetz hast, welches von einer Fritzbox verwaltet wird, dürfte es hier auch keine Probleme geben. Was sagt dein Windows PC beim nslookup? Nutz der die FritzBox als DNS Server? Wenn dein PC seine IP Adresse per DHCP bekommen sollte und an den Netzwerkeinstellungen der FritzBox keine Anpassungen vorgenommen worden sind, müsste dies so der Fall sein. Wenn eine statische IP gentutz wird, diese prüfen. Zumindest die FritzBox kann den Namen schon mal intern auflösen. Ansonsten mal pauschal folgende Dinge testen/prüfen: Erkennt Windows dein Netz als privates Netzwerk an? Wenn nein, Netzwerkkonfig in Windows prüfen und ggf. anpassen. Ansonsten eben manuell auf privat umstellen. Wenn Windows ein FritzBox Netz nicht automatisch als privat erkennt, liegt hier irgendwas im argen. Wie alt sind deine Android Tablets? Wenn zu alt, benötigen diese evtl. SMB V1, um Unraid überhaupt finden zu können. Um in Unraid SMB V1 zu aktivieren, muss unter SMB Settings NetBios aktiviert werden.

Die Logik der Portweiterleitungen bei Unifi ist der FritzLogik eigentlich ziemlich identisch. Nur als vergleich bei einer UDM-Pro: Um Irritationen zu vermeiden: Unraid hat bei mir angepasste Ports für http und https, weswegen ich direkt auf 80 und 443 weiterleiten kann. Du hast also eigentlich alles richtig gemacht. Die Frage bei dir ist nun: Wie baut dein UD7 die Verbindung zum Internet auf? Hängt da vielleicht ein Modem/Router davor? Falls ja: wurden die Ports in Richtung UD7 auch aufgemacht?

Namensauflösung ist DNS Sache. Solltest du bei deinem PC einen öffentlichen DNS Server eingetragen haben wie Google (8.8.8.8), Quad9 (9.9.9.9), Cloudflare (1.1.1.1) usw., wird dein PC interne Gerät nie über den Namen finden können. Daher die Frage, welchen DNS du nutzt. Wenn du dass nicht weist, kannst du das über die Kommandozeile in Windows herasufinden. Dafür nslookup eingeben, dannach den Hostnamen deines Unraidservers. Dann siehst du, welchen DNS dein PC nutzt und ob dieser DNS mit dem Namen was anfangen kann. Das sollte dann so aussehen (Datenschleuder ist mein Unraid Server): Ergänzung: In deinen SMB Einstellungen hast du Multichannel aktiviert. Solltest du eine odere mehrere Netzwerkkarten mit 10 GbE haben, ist diese Einstllung Sinvoll, sofern Netzwerk- und Clientseitig sauber konfiguriert. Hast du jedoch nur eine oder mehrer 1 GbE Karten, wird Multichannel keine großen Vorteile bringen und eher für Probleme sorgen. Daher am besten abschalten, wenn 10 GbE bei dir kein Thema ist.

Das habe ich fast schon befürchtet. Aber Danke.

Hallo Zusammen, diesen Text habe ich auch im Emby Forum gepostet. Aber vielleicht kennt hier jemand auch eine Idee, wie ich das "Problem" auf Unraid Basis lösen kann. Ich habe hier auch schon das Skript gefunden, welches die ersten Minuten von Medien in den RAM packt, um diese Thematik zu umgehen. Dies ist leider in meinem Szenario leider keine Lösung, da jeden ab ab 23 Uhr der Server prüft, ob noch irgendwelche Aktivtäten laufen und wenn nicht, fährt dieser herunter, bis er um 06:00 Uhr morgens per WoL wieder gestartet wird. Somit müsste die Kiste jeden Tag die Medien wieder auslesen, was bei h.265 eher kontraproduktiv ist. Ist also kein Unraid spezifisches Problem. Aber vielleicht hat hier jemand das gleiche Problem und schon eine Lösung dafür gefunden.

USB ist immer schlecht bei Unraid. Dennoch: sollte da irgendwo eine USB-C Verbindung sein, dreh den Anschluss auf USB-C Seite einmal. USB-C - sofern genutzt, kann ja egal wie rum angeschlossen werden. Wenn du aber ein Kabel hast, bei dem der Hersteller gespart hast, ist es nicht voll belegt. Dann läuft es auf der einen Seite zwar mit USB 3 Speed, auf der anderen Seite aber nur mit USB 2 Speed. Und da kommen deine 21,5 MB/s ziemlich genau hin. Habe übrigens genau das gleiche bei Problem bei einem externen USB Gehäuse, was einen Typ C Anschluss hat und in dem eine SSD verbaut ist. Steckt das Kabel "falsch herum", gibt es eben nur diese 20 MB/s. Getestet an mehreren Geräten. Hat mich auch schon zum verwundern gebracht.

Dafür! Hatte vor ein paar Tagen einen Stromausfall. Unraid ist so konfiguriert, dass es nach zwei Minuten unter USV Strom herunterfährt, da es dann in der Regel eine längere Angelegenheit wird (was es mit einer Stunde auch war). Nur hat dann auch irgendeine Rsync Geschichte das unmounten der Disks blockiert. Da ich zuhause war, habe ich das mitbekommen und konnte dann noch eingreifen. Als ob am am Freitag Abend mit Stromausfall nicht schon genug gestraft wäre. Im Härtefall hätte die Kiste jedoch die USV leergelutscht, was im dümmsten Fall zum Datenverlust, im ägerlichen Fall nur zum unötigen Parity Check geführt hätte. Dies ist in der Tat nicht sauber von Unraid gelöst.

Das ist noch ein Überbleibsel, was ich mal getestet habe. Bringt bei 2x 1GbE übrigens nichts bzw. keine relevanten Vorteile. Habe ich den Eintrag wohl nicht sauber gelöscht. Schande. Aber das ist jetzt zumindest mal ein Anhaltspunkt, denn ich angehen kann. Dafür schon Mal danke. Diese Woche werde ich das nicht gegen Testen können. Werde aber Ende nächster Woche wahrscheinlich schon Feedback geben können.

This is a remnant of what I once tested. By the way, with 2x 1GbE there are no or no relevant advantages with multichannel and 802.3ad LACP. I guess I didn't delete the entry cleanly. Shame. But this is at least a starting point that I can tackle. Thank you for that. I won't be able to test it this week. But I'll probably be able to give feedback at the end of next week.

The latest. On Unraid V7

Hello, I've been using the plugin for a few months now, so far everything has been great. Today, however, I had the interesting problem that the plugin filled up my rootfs until nothing worked anymore. In the logs I found the hint that the plugin moved data from "/mnt/user/media" to "/mnt/none". However, there is no share with the name "none". The logs showed that the secondary target is "none", which is correct. However, I don't know how the plugin comes up with the idea of creating a "none" folder under /mnt/. As I was still able to access the server via SSH and move the data back to the correct location, there was fortunately no data loss. I was also able to restart nginx and access the WebUI directly again. I then carried out a clean restart to be on the safe side and unfortunately forgot to save the logs. I would like to use the plugin again. Does anyone have any idea what the problem could be?

Thanks, but its allready done.

Hello everyone. This will be a short summary of the following thread from the German subforum. Maybe someone has an idea if this problem could be related to UD. Briefly about the system: Unraid 7 in a Unifi network with corresponding MACLAN customisation 64 GB RAM 2x NICs, one is called DMZ but does not lead to a DMZ (to avoid any panic) 1 array. XFS, with parity Various pools, both ZFS and XFS various Docker Nvidia GPU for Emby, Tdarr and Immich Backup: Daily automatic backup to external USB HDD via Mgutt script of the most important data Once a week automatically encrypted on NAS off-site and in the cloud via duplicacy of the most important data Always, if deemed necessary, manual backup of the entire array to internal NAS via duplicacy Mods of the Go File: Auto Unlock Array RAM disc for Docker json/log files v1.6 for 7.0.0 (also used for Emby, if transcode required) (no longer used, even if still available in Diagnostics) Adjustments since update to V7: fastusr Fix Overlay2 Docker Storage Driver including re-import of all Docker Permit exclusive shares and adjust the Docker and mappings from formerly Diskshare Appdata (mnt/cache/appdata) back to mnt/user/appdata Since the update to V7 no problems have occurred so far. Now I've been trying to run a manual backup to the internal NAS via Duplicacy again for a few days (the first time under Unraid 7, as it is only triggered manually every few months). This runs for a while without any problems, then Unraid starts to become very sluggish and sometimes stops responding. When you get back to the WebUI at some point, you can see that it is constantly reading from the USB stick. My understanding of Unraid tells me that something is cluttering up my RAM and Unraid has to keep reloading the OS from the stick into RAM. But so far I have not been able to find out what is causing this problem. Since it only occurs during the backup, I have checked the docker mappings in general and especially Duplicacy several times, but cannot find any errors - I don't want to rule out my own operational blindness or incompetence at this point. For more information, please refer to the pinned thread, where you can also find the diagnostics. Thank you.

Wie versprochen die Rückmeldung: Nach einigen Tests kann ich mit Sicherheit sagen, dass die Kombi Unraid V7 mit Duplicacy Backup und größeren Datenmengen (zweistelliger TB Bereich) auf ein SMB Share über UD für ein Memoryproblem sorgt, was dazu führt, das Unraid immer wieder vom Stick laden muss. Über NFS gibt es keine Probleme. Dies wurde Mehrmals die letzten Tage mit beiden Variationen getestet. Warum und weshalb konnte ich leider nach wie vor nicht in Erfahrung bringen. Sowohl jegliche Art von TOP als auch die Logs spucken zumindest für mich nichts verwertbares oder aufälliges aus. Ob das nun an Dupli, UD oder Unraid liegt, weiß ich leider nicht. Ich werde es jedenfalls Mal im UD Thread weiter geben, da hier SMB und NFS zumindet zusammen laufen. Irgendwo muss man ja anfangen. Ich kann das Problem damit umgehen, dass ich eben NFS statt SMB nutze, was für mich weder einen Vorteil noch Nachteil bringt. Deswegen kann ich damit leben. Bis auf die Tatsache, dass mein Ego nun angekratzt ist, da ich den Fehler nicht finde und lösen kann. 😅

Danke für den Tipp. Werde ich machen. Ich warte nur noch die restlichen Stunden des Backups ab, ob es nun wirklich bis zum Schluss per NFS durchlauft.

Ok, da habe ich wohl bei "direkt aus dupli heraus" was falsch verstanden. Es geht schon direkt aus Dupli raus: Aber "/backuproot-remote/" führt innerhalb des Dockermapping auf "/mnt/remotes" - wie gesagt, über UD eingebunden: Nur eben seit zwei Tagen über NFS zwecks Test statt wie bisher die letzten Jahre über SMB. Und seit NFS bisher eben ohne Probleme, wie eben auch SMB unter V6. Aber das Backup ist noch nicht durch. Nur kam ich mit SMB und V7 eben soweit gar nicht mehr.

Danke für den Tipp. Bei mir sind jedoch generell alle Docker bereits über die Extra Paramter limitiert, was CPU und RAM angehen. Auch Dupli - allerdings mit 8 GB statt mit 4 GB.

Ja, dass habe ich defintiv. Du machst deinem Namen Ehre. Dann kann es echt nur an der Kombi Dupli mit größere Datenmengen und SMB liegen und meinem System liegen. Nur das warum und weshalb fehlen noch.

Die ersten paar TB gab es bei mir auch keine Probleme. Erst wenn der Job eine Weile lief, gab es diese Probleme - also wenn schon mehre TB im zweistelligen Bereich verabreitet worden sind. Daher muss ich in diesem Kontext leider sagen, dass 2,x TB hier nicht die "größere Datenschieberei" ist, die das Problem bei mir verursacht sondern hier von min. 10-15 TB die Rede ist, ab wann es zu Problemen kommt. Hätte ich nur ein inkrementelles Backup gefahren und kein Vollbackup, hätte ich dieses Problem aber wahrscheinlich auch nicht gehabt. Zumindest kurz nach dem Update auf V7 habe ich auf dem System auch "kleinere" Datenmengen (auf den Kontext bezogen) von unter 5 TB vom Proudktivsystem (Unraid) weg zum Langzeitdatengrab (Synology NAS, SMB per UD) bewegt und hatte da auch keine Probleme. Und ja, 2 TB als auch 5 TB sind natürlich eine ganze Menge an Daten. Aber hier auf das Ganze betrachtet (36TB Array, ca. 4 TB in diversen Pools) keine Menge, die mir bisher Probleme machte.

Servus, vor zwei Tagen habe ich die interne NAS von SMB auf NFS umgestellt und ein Vollbackup angestoßen (36TB). Seit dem läuft auch immer noch alles normal, kein Einfrieren und kein ständies nachladen vom Stick. Das Backup läuft zwar Stand jetzt noch 1 Tag und 10 Stunden, aber solange lief es mit SMB und Unraid 7 nicht stabil durch, ohne dass der RAM voll lief. Leider sehe ich sowohl under TOP als auch CTOP keine großartigen unterschiede im vergleich zur SMB Konfig. Aber nach aktuellen Stand mag irgendetwas keine größere Datenschieberei mit SMB unter Unraid V7. Unter V6 hatte ich mit dieser Kombi keine Probleme. Ich konnte bisher leider noch nicht rausfinden, was genau in der Kombi das Problem auslöst. Wenn das Backup fertig ist (oder beim nächsten Freeze - hoffentlich nicht) gebe ich nochmals Rückmeldung.

Alle Backups, bis auf das USB HDD Backup, werden direkt über Dupli angesprochen und sind auch als Storage in Dupli konfiguriert. Davon gehen zwei kleine, wöchentliche Backups auf die B2B Cloud und eins auf einen externen unraid Server, welcher als NFS in UD eingebunden ist. Das große Backup geht auf eine interne NAS, welche als SMB in UD eingebunden ist. Beide UD Remote Shares sind entsprechend in Dupli eingebunden. Alle Dupli Backups laufen seit min. 2020 bisher ohne Probleme. Auch die beiden "kleinen", wöchentlichen Backups liefen schon mehrmals seit dem Updatre auf V7 ohne Probleme. Das "große" Backups des ganzen Arrays lief unter V6 ebenfalls schon Jahre ohne Probleme. Aber eben nur immer nach Bedarf, also nicht automatisiert. Das letzte Mal irgendwann im Oktober 2024 auf der V6. Nun das erste Mal auf V7.

Täglich automatisch auf externe USB HDD per Mgutt Script der wichtigsten Daten 1x Wöchentlich automatisch verschlüsselt auf NAS (NFS) außer Haus und in Cloud (B2B) per Duplicacy der wichtigsten Daten Immer, wenn für nötig gehalten, manuelle Sicherung des gesamten Arrays auf interne NAS (SMB) per Duplicacy (da komprimiert) Der Punkt drei läuft nun zum ersten Mal unter V7 und macht auch erst seit dem Probleme.

Die Nerdtools sind schon länger nicht mehr kompatibel, nicht erst mit V7. Wenn du keine extra Pakete aus den Nerdtools benötigst, schalte diese einfach ab. Alles, was nicht läuft und auch nicht benötigt wird, kann auch keine Probleme machen. Als Ersatz kann ich dir Unget empfehlen, wenn du selber keine benötigten Pakete auf den Stick packen und verwalten möchtest. https://github.com/ich777/un-get