Pillendreher

So, BIOS zurückgesetzt und die powertop Befehle aus der Go-Datei entfernt: Upload iperf3 PC => Unraid (120 parallele Verbindungen; 30 Sekunden; TCP): [SUM] 0.00-30.00 sec 3.22 GBytes 922 Mbits/sec sender [SUM] 0.00-30.00 sec 3.22 GBytes 922 Mbits/sec receiver Download iperf3 Unraid => PC (120 parallele Verbindungen; 30 Sekunden; TCP): [SUM] 0.00-30.00 sec 3.31 GBytes 948 Mbits/sec 2924 sender [SUM] 0.00-30.00 sec 3.23 GBytes 925 Mbits/sec receiver Komischerweise erreiche ich diese Werte über SMB/FTP immer noch nicht - da ist bei knapp unter 800 MBit/s Schluss 🤨

Ja. 3 verschiedene Kabel waren glaube ich schon dran. Du meinst direkt das Kabel vom Server zum PC? Nein, bisher noch nicht. Upload von Unraid auf den iperf2 Server der Fritzbox mit 100 parallelen Verbindungen über UDP: [SUM] 0.0-30.1 sec 2.75 GBytes 787 Mbits/sec Download von Unraid auf den iperf2 Server der Fritzbox mit 100 parallelen Verbindungen über UDP: [SUM] 0.0-30.1 sec 2.79 GBytes 796 Mbits/sec Also hier geht in beide Richtungen weniger, aber zumindest gleich viel. Nur sobald es weitergeleitet wird, bricht mir der Upload vom Server weg... Mach ich gleich mal.

So, hier noch kurz der iperf Test im LAN vom Desktop PC aus: iperf3 Server auf Unraid, Upload vom PC aus (100 parallele Verbindungen über TCP): [SUM] 0.00-30.00 sec 3.16 GBytes 903 Mbits/sec sender [SUM] 0.00-30.00 sec 3.16 GBytes 903 Mbits/sec receiver iperf3 Server auf Unraid, Download vom PC aus (100 parallele Verbindungen über TCP): [SUM] 0.00-30.00 sec 2.13 GBytes 611 Mbits/sec 2008 sender [SUM] 0.00-30.00 sec 2.08 GBytes 595 Mbits/sec receiver iperf3 Server auf PC, Upload von Unraid aus (100 parallele Verbindungen über TCP): [SUM] 0.00-30.00 sec 2.14 GBytes 614 Mbits/sec 51 sender [SUM] 0.00-30.00 sec 2.09 GBytes 597 Mbits/sec receiver iperf3 Server auf PC, Download von Unraid aus (100 parallele Verbindungen über TCP): [SUM] 0.00-30.00 sec 3.22 GBytes 923 Mbits/sec sender [SUM] 0.00-30.00 sec 3.20 GBytes 916 Mbits/sec receiver Und auch hier sieht man wieder schön: PC => Unraid: In Ordnung Unraid => PC: Nicht in Ordnung

Ja, ansonsten alle Tests im LAN

So, hab Ubuntu über einen USB Stick gestartet - die SMB Übertragung vom Server weg bleibt bei 41 MB/s stehen und wird nicht schneller. Hier jetzt noch zum Vergleich iperf3 vom Laptop im WLAN mit dem Unraid Server als iperf3 Server: Upload zum Server hin: D:\Programme\iperf3>iperf3 -c 192.168.188.24 -p 5201 -P 100 -t 30 Connecting to host 192.168.188.24, port 5201 [...] - - - - - - - - - - - - - - - - - - - - - - - - - [SUM] 0.00-30.00 sec 1.84 GBytes 528 Mbits/sec sender [SUM] 0.00-30.00 sec 1.84 GBytes 528 Mbits/sec receiver iperf Done. Download vom Server weg: D:\Programme\iperf3>iperf3 -c 192.168.188.24 -p 5201 -P 100 -t 30 -R Connecting to host 192.168.188.24, port 5201 Reverse mode, remote host 192.168.188.24 is sending [...] [SUM] 0.00-30.00 sec 1.96 GBytes 561 Mbits/sec 79 sender [SUM] 0.00-30.00 sec 1.88 GBytes 538 Mbits/sec receiver iperf Done. Bei SMB und FTP wird aber weiterhin "gedrosselt". Wie kann das sein? Kann das damit zu tun haben, dass ich extra Benutzer für FTP und SMB angelegt habe?

Ja, jeweils GData Antivirus. Wieso sollte der Virenscanner aber die Datenübertragung in eine Richtung blockieren bzw. hämmen? Kann es morgen mal, wenn ich Zeit dafür finde, mal mit ner Live Installation von Ubuntu probieren.

So, ich muss das Ding hier nochmal hochholen, denn ich hab erneut das Problem und ich krieg es einfach nicht weg. In den letzten vier Tagen hab ich den Server bestimmt 10x neu aufgesetzt, aber irgendwann bricht mir jedes Mal die Uploadgeschwindigkeit vom Server hin zu einem Netzwerkgerät weg. Hier mal ein iperf2 Test zwischen der Fritzbox 6591 und dem Unraid Server: "Outbound", sprich Unraid Server schiebt Daten hin zur Fritzbox: root@Tower:/tmp# iperf -c 192.168.188.1 -p 4712 -u -b 1300m -P 20 -t 30 ------------------------------------------------------------ Client connecting to 192.168.188.1, UDP port 4712 Sending 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 22] local 192.168.188.24 port 45941 connected with 192.168.188.1 port 4712 [ 20] local 192.168.188.24 port 39375 connected with 192.168.188.1 port 4712 [ 3] local 192.168.188.24 port 36519 connected with 192.168.188.1 port 4712 [ 21] local 192.168.188.24 port 46627 connected with 192.168.188.1 port 4712 [ 4] local 192.168.188.24 port 40166 connected with 192.168.188.1 port 4712 [ 6] local 192.168.188.24 port 49969 connected with 192.168.188.1 port 4712 [ 10] local 192.168.188.24 port 45301 connected with 192.168.188.1 port 4712 [ 8] local 192.168.188.24 port 56648 connected with 192.168.188.1 port 4712 [ 7] local 192.168.188.24 port 54997 connected with 192.168.188.1 port 4712 [ 12] local 192.168.188.24 port 35222 connected with 192.168.188.1 port 4712 [ 9] local 192.168.188.24 port 43843 connected with 192.168.188.1 port 4712 [ 11] local 192.168.188.24 port 51679 connected with 192.168.188.1 port 4712 [ 5] local 192.168.188.24 port 45013 connected with 192.168.188.1 port 4712 [ 14] local 192.168.188.24 port 53385 connected with 192.168.188.1 port 4712 [ 15] local 192.168.188.24 port 53472 connected with 192.168.188.1 port 4712 [ 16] local 192.168.188.24 port 49955 connected with 192.168.188.1 port 4712 [ 17] local 192.168.188.24 port 44547 connected with 192.168.188.1 port 4712 [ 19] local 192.168.188.24 port 60247 connected with 192.168.188.1 port 4712 [ 13] local 192.168.188.24 port 41975 connected with 192.168.188.1 port 4712 [ 18] local 192.168.188.24 port 37531 connected with 192.168.188.1 port 4712 [ ID] Interval Transfer Bandwidth [ 20] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 20] Sent 106067 datagrams [ 3] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 3] Sent 106078 datagrams [ 10] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 10] Sent 106065 datagrams [ 9] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 9] Sent 106086 datagrams [ 5] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 5] Sent 106078 datagrams [ 15] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 15] Sent 106080 datagrams [ 18] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 18] Sent 106071 datagrams [ 22] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 22] Sent 106100 datagrams [ 21] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 21] Sent 106092 datagrams [ 4] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 4] Sent 106100 datagrams [ 6] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 6] Sent 106096 datagrams [ 8] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 8] Sent 106084 datagrams [ 7] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 7] Sent 106098 datagrams [ 12] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 12] Sent 106092 datagrams [ 11] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 11] Sent 106108 datagrams [ 14] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 14] Sent 106110 datagrams [ 16] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 16] Sent 106106 datagrams [ 17] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 17] Sent 106086 datagrams [ 19] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 19] Sent 106104 datagrams [ 13] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 13] Sent 106084 datagrams [SUM] 0.0-30.0 sec 2.90 GBytes 831 Mbits/sec Und jetzt in die andere Richtung: root@Tower:/tmp# iperf -c 192.168.188.1 -p 4712 -u -b 1300m -P 20 -t 30 -R ------------------------------------------------------------ Client connecting to 192.168.188.1, UDP port 4712 Sending 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 22] local 192.168.188.24 port 38202 connected with 192.168.188.1 port 4712 [ 4] local 192.168.188.24 port 45825 connected with 192.168.188.1 port 4712 [ 20] local 192.168.188.24 port 40051 connected with 192.168.188.1 port 4712 [ 3] local 192.168.188.24 port 35039 connected with 192.168.188.1 port 4712 [ 8] local 192.168.188.24 port 35668 connected with 192.168.188.1 port 4712 [ 7] local 192.168.188.24 port 54145 connected with 192.168.188.1 port 4712 [ 9] local 192.168.188.24 port 46344 connected with 192.168.188.1 port 4712 [ 11] local 192.168.188.24 port 37915 connected with 192.168.188.1 port 4712 [ 5] local 192.168.188.24 port 49954 connected with 192.168.188.1 port 4712 [ 10] local 192.168.188.24 port 55294 connected with 192.168.188.1 port 4712 [ 6] local 192.168.188.24 port 45886 connected with 192.168.188.1 port 4712 [ 13] local 192.168.188.24 port 39049 connected with 192.168.188.1 port 4712 [ 14] local 192.168.188.24 port 33757 connected with 192.168.188.1 port 4712 [ 15] local 192.168.188.24 port 53814 connected with 192.168.188.1 port 4712 [ 16] local 192.168.188.24 port 34882 connected with 192.168.188.1 port 4712 [ 17] local 192.168.188.24 port 33974 connected with 192.168.188.1 port 4712 [ 18] local 192.168.188.24 port 34665 connected with 192.168.188.1 port 4712 [ 21] local 192.168.188.24 port 43966 connected with 192.168.188.1 port 4712 [ 19] local 192.168.188.24 port 34355 connected with 192.168.188.1 port 4712 [ 12] local 192.168.188.24 port 55867 connected with 192.168.188.1 port 4712 [ ID] Interval Transfer Bandwidth [ 10] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 10] Sent 106212 datagrams [ 16] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 16] Sent 106210 datagrams [ 22] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 22] Sent 106220 datagrams [ 4] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 4] Sent 106248 datagrams [ 20] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 20] Sent 106222 datagrams [ 3] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 3] Sent 106250 datagrams [ 8] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 8] Sent 106234 datagrams [ 7] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 7] Sent 106224 datagrams [ 11] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 11] Sent 106236 datagrams [ 5] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 5] Sent 106220 datagrams [ 6] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 6] Sent 106216 datagrams [ 13] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 13] Sent 106222 datagrams [ 14] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 14] Sent 106250 datagrams [ 15] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 15] Sent 106228 datagrams [ 17] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 17] Sent 106253 datagrams [ 18] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 18] Sent 106236 datagrams [ 21] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 21] Sent 106218 datagrams [ 19] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 19] Sent 106230 datagrams [ 12] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 12] Sent 106244 datagrams [ 9] 0.0-30.0 sec 149 MBytes 41.6 Mbits/sec [ 9] Sent 106254 datagrams [SUM] 0.0-30.0 sec 2.91 GBytes 833 Mbits/sec Sobald ich aber über FTP oder SMB eine Datei vom Server runterziehe, komme ich nicht einmal ansatzweise in diese Regionen - da ist bei ~400 MBit/s Schluss (genaue Werte liefere ich nachher nach; bin gerade nur im WLAN). Woran kann das liegen? Ich kann es mir beim Besten willen nicht erklären. Und ich kann auch nicht klar feststellen, ab welchem Punkt beim Neuaufsetzen des Systems das Ganze auftritt. Es ist irgendwann da und geht dann auch nicht mehr weg...

Um das hier noch einmal aufzugreifen: Muss man denn mit einem i3-10100 anders vorgehen? Weder diese "modprobe" Methode noch das GPU Top Plugin führen bei mir dazu, dass ich bei Powertop die GPU sehe.

Ja, alles bis auf die paar Befehle, die eine meiner Festplatten betreffen - die wacht immer aus dem Schlaf auf, wenn ich die Powertop Befehle ausführe. Ich sehe aber gerade, dass mir powertop irgendwie Befehle als fehlend anzeigt: Muss mir das noch einmal genauer anschauen... PS: Die anderen C-States werden mir hier gar nicht angezeigt: root@Tower:/tmp# grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1_ACPI /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2_ACPI /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3_ACPI EDIT: Ich sehe gerade dass die fehlenden Befehle daher kommen, dass powertop 2.8 und 2.13 unterschiedliche Befehle empfehlen: 2.8: echo 'min_power' > '/sys/class/scsi_host/host6/link_power_management_policy'; 2.13: echo 'med_power_with_dipm' > '/sys/class/scsi_host/host6/link_power_management_policy'; Was ist denn nun zu empfehlen?

Gerade mal auf die alte Version runter. Mir wird jetzt das hier angezeigt: Installiert ist Unraid 6.9.2. Als Scaling Governor ist in Tips And Tweaks powersave eingestellt, aber wirklich runtertakten tun die Kerne damit auch nicht:

Mit obigen Einstellungen im UEFI komme ich zu folgendem Leerlaufverbrauch mit schlafenden Platten, 2x Kingston A2000, 2x Samsung Evo 850 und einer Dell H310 Karte: Kein Powertop, kein Undervolt: 36,41 W Powertop, kein Undervolt: 33,92 W Powertop, Undervolt, Platform Power Management, C-States bis C8, Audio Controller deaktiviert: 28,99 W Geht da noch was mit einem i3-10100, einem 16GB RAM Riegel, einem B460M D3H und einem be quiet! PURE POWER 11 400W CM? Was mir bei Powertop auffällt: Mein Prozessor nutzt keine wirklich tiefen C-States: Ist das normal? PS: Und obwohl laut dem Unraid WebIF nur 1 % Last auf dem Prozessor liegt, taktet er nicht runter: root@Tower:~# cat /proc/cpuinfo | grep MHz cpu MHz : 3491.784 cpu MHz : 2914.226 cpu MHz : 4002.536 cpu MHz : 4149.013 cpu MHz : 4193.121 cpu MHz : 4282.717 cpu MHz : 3683.213 cpu MHz : 4138.038

Das hat leider nichts gebracht. Habe jetzt mal durch ausprobieren rausgefunden, dass folgende Kombination das Schlafen nicht verhindert: C-States Control: Enabled CPU Enhanced Halt: Auto C3 State Support: Enabled C6/C7 State Support: Enabled C8 State Support: Enabled C 10 State Support: Disabled Package C State Limit: C8

Ich habe jetzt endlich auch mal die C-States in meinem UEFI (GIGABYTE B460M D3H) aktiviert und wollte schauen, wie weit ich mit Hilfe von powertop beim Leerlaufverbrauch komme...leider zerhagelt es mir dann den S3 Schlafzustand - das System ist nicht mehr erreichbar, schläft aber nicht. Hatte das hier jemand schon einmal bei seinen Stromsparversuchen? Hab jeden C-State aktiviert und das Limit auf C10 gesetzt - ist das so in Ordnung?

Das Problem mit den aufwachenden Festplatten gibt es ja schon seit nem halben Jahr. Die letzten Beta Versionen 6.9 hatten das schon. Man hat aber nicht wirklich auf entsprechende Meldungen reagiert. @mguttIch werde mal dein Skript bei mir testen.

Ja, das kenne ich. Solange aber kontinuierlich der Fortschritt angezeigt wird, konnte ich mich in der Vergangenheit auch darauf verlassen. In meinem Desktop läuft eine WD Black 750, in meinem Laptop eine Corsair MP510 SSD. Daran dürfte es nicht liegen Nein. Die *.img Datei war aber hier nur als Beispiel ausgewählt. Es trat genauso auch bei allen anderen testweise übertragenen Dateien auf.

Wenn sich aber in irgendwelche Konfigruationsdateien irgendetwas einschleicht, dann kriege ich das ja nicht mehr weg außer durch ein Zurücksetzen des Systems. Ich hatte z.B. eine Fehlermeldung vor ein paar Monaten ne Fehlermeldung im Sleep Plugin, die einfach nicht verschwinden wollte - irgendwas muss da beim Dynamix Plugin kaputt gegangen sein. Nach einem Neuaufsetzen des USB Sticks war der Fehler weg

Morgen! Nachdem ich gestern Abend mehrere Stunden lang den Datendurchsatz der Fritzboxen getestet und sogar mal die Netzwerkdosen geöffnet hatte, kann ich nun mit ziemlicher Sicherheit sagen, dass irgendwas mit meinem Unraid Server und Datenübertragungen nicht stimmt. Mir war das ganze schon vor gut 2 Wochen aufgefallen, als ich nach einer Neuinstallation von Windows Daten zurückholen wollte und nicht über 50 MB/s hinauskam. Ich hatte es erst auf die verwendete Festplatte geschoben, aber da das Ganze auch bei den SSDs im Server auftritt, kann es das nicht sein. Den verwendeten PC kann ich auch ausschließen, da es am Laptop genauso auftritt. Folgendes ist das Problem: Über SMB/FTP geht ein Upload mit mehr oder weniger vollen 1 GBit/s durch: Sobald ich aber Sachen vom Server holen möchte, komme ich nicht einmal mehr ansatzweise in diesen Bereich: Ich hattet nun erst die Router bzw. die Kabel im Verdacht, aber das kann ja eigentlich nicht das Problem sein, da über iperf die Leitung mehr oder weniger voll ausgelastet wird: Wenn hier also die Pakete nicht an dieser onimösen Grenze von gut 50 % der Gbit Verbindung hängen, kann es ja eigentlich kein direktes "Hardware-Problem" sein. Ich kann mir beim besten Willen aber nicht vorstellen, woran das Ganze liegen soll. Folgendes habe ich schon ausprobiert, jedoch ohne Besserung: -Neustart -Stoppen aller Docker-Container -Deaktivieren von Wireguard -Stoppen der W10 VM -Stoppen des Arrays, deaktivieren von Dokcer/VM/SMB/FTP, Einbinden einer der Fesplatten als unassigned device (FTP erneut aktiviert) -Undervolting rausgenommen Hatte jemand von euch schon einmal dieses Problem? Ich habe ehrlich gesagt wenig Lust, jetzt schon wieder alles neu aufzusetzen auf dem Server. Das wäre jetzt in 6 Monaten das 4. oder 5. Mal und jedes Mal, weil irgendwas plötzlich nicht mehr funktioniert... Grüße EDIT: Das gibt es nicht...da mir plötzlich die Platte, die ich über unassigned devices eingebunden hatte, als "unmountable" angezeigt wurde, hatte ich eine neue Konfiguration erstellt und das System neu gestartet. Und siehe da: Der Download läuft wieder mit nahezu voller Geschwindigkeit. Bin mal gespannt, ob das Problem jetzt dauerhaft verschwunden ist.

Ich hab doch aber nicht br0, sondern ein eigens erstelltes Netzwerk?!

Nö, ganz normal eingegeben. Hab es gerade testweise auch noch einmal mit Edge probiert: Die Erfolgsmeldung erscheint auch dort, ist also nicht nur ein Überbleibsel vergangener Tage im Firefox. Tatsache, jetzt geht es - wie kann das sein?! Wenn die Ports jeweils passen, kann doch nicht 444 fehlschlagen und 443 funktionieren...Oder hat das womöglich etwas mit "internal" als Parameter bei der Netzwerkerstellung zu tun?

NPM lauscht auf 1880 und 18443. Die Fritzbox leitet 443 auf 18443 und 80 auf 1880 des Unraid Servers weiter, der aber jetzt natürlich eine andere IP-Adresse als der NPM Container hat (192.168.178.24 vorher, jetzt laut ifconfig des Containers "inet addr:192.168.179.2". Sollte es aber ein Problem mit den Portweiterleitungen geben, dürfte doch eigentlich nicht diese NPM Seite beim Aufruf meiner externen IPv4-Adresse kommen, oder?

Also im Moment ist das Ganze so konfiguriert: MariaDB und Nextcloud sind in Unraid dem internen Netzwerk mit festen IPs zugeteilt (192.168.179.3 für MariaDB, 192.168.179.4 für Nextcloud). Nginx Proxy Manager ist in Unraid als "Bridge" konfiguriert und gleichzeitig mit dem internen Netzwerk verbunden: root@Tower:~# docker network inspect isoliertes_netzwerk [ { "Name": "isoliertes_netzwerk", "Id": "***", "Created": "2021-05-01T09:50:21.852711971+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.179.0/24" } ] }, "Internal": true, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "***": { "Name": "NginxProxyManager", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.2/24", "IPv6Address": "" }, "***": { "Name": "mariadb", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.3/24", "IPv6Address": "" }, "***": { "Name": "nextcloud", "EndpointID": "***", "MacAddress": "***", "IPv4Address": "192.168.179.4/24", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] Wenn ich meine externe IPv4-Adresse aufrufe, erscheint Folgendes: Nginx Proxy Manager scheint also zu laufen. Nextcloud scheint wie gesagt auch eine Verbindung zu MariaDB hergestellt zu haben, denn der occ Befehl "geht durch", bringt also keine Fehlermeldung. Im Nginx Proxy Manager sieht meine Weiterleitungs-Konfiguration so aus: Und Nextcloud ist in Unraid als Docker Container so konfiguriert: Tut mir Leid, aber verstehe nicht, was du mir hier empfiehlst. Ich habe in der Fritzbox ja bereits die Ports 443 und 80 für den Unraid Server geöffnet. Reicht das denn nicht? Ah, das würde darauf hindeuten, dass die Konfiguration nicht passt, also die Weiterleitung im Nirgendwo landet. Wie passt das aber damit zusammen, dass ich vom Nginx Proxy Manager Container erfolgreich einen Ping Richtung 192.168.179.4 (Nextcloud) schicken kann, und gleichzeitig der Nextcloud Container erfolgreich einen Ping Richtung 192.168.178.24 (Unraid Server) schicken kann? Andererseits frage ich mich aber: Müsste der Ping zum Unraid Server gerade nicht verhindert werden?!

Ich wollte das mal bei mir ausprobieren, aber leider geht so manches nicht. MariaDB, Nextcloud und NginxProxyManager hängen alle in einem internen Docker Netzwerk. Soweit so gut. Über die jeweilige Container-Console erreiche ich per curl bzw. ping die jeweils anderen Container, d.h. sie sehen sich und können miteinander kommunizieren. In der config.php von Nextcloud habe ich die IP Adresse von MariaDB geändert, was scheinbar auch funktioniert hat, denn der occ Befehl im Nextcloud-Container geht durch und wirft mir nicht wie vor der Änderung Datenbank-Fehler aus. Mein Problem ist nun aber: Obwohl ich in der Proxy Host Datei für Nextcloud die IP Adresse auf den neuen Adressraum des isolierten Containers geändert habe, klappt die Weiterleitung von der duckdns Adresse nicht. Darüber hinaus kann ich auch das Webinterface des ProxyManagers nicht öffnen - in Unraid möchte er sich noch über die alte IP-Adresse verbinden und selbst wenn ich die neue IP-Adresse eingebe und mit dem weitergeleiteten WebIF-Port versehe, kommt keine Verbindung zustande. Hast du hierfür noch irgendwelche besonderen Einstellungen vorgenommen? EDIT: Oh Mann, ich Depp. Das wird daran liegen, dass das Netzwerk keine Verbindungen von außen zulässt - "ping" von meinem Laptop aus landet auch im Nirgendwo... EDIT2: Mein Hauptfehler lag darin, den NginxProxyManager in Unraid dauerhaft dem internen Netzwerk zuzuweisen. Dein "network connect" Befehl von oben brachte Abhilfe. Jetzt komme ich auf das WebIF des NginxProxyManager wieder drauf, jedoch klappt die Weiterleitung von der duckdns Adresse weiterhin nicht: Es kommt eine Verbindung zustande, jedoch erscheint dann eine "502 Bad Gateway" Fehlermeldung. Mal schauen, woran das liegt...

Well, forgive my ignorance, but I always assumed that NPM was a sort of security measure. You know, instead of exposing the docker container "as is". So I could theorically open port 80 to get the certificate once and then close it again until the certificate expries?

I've got a quick question: I've made my Nextcloud container available for external use. Right now I'm forwarding port 443 and NPM forwards the incoming requests to the container. Since 443 is very common, I wanted to at least avoid port scans for common ports. Disabling the port forwarding of port 80 in my router makes NPM unaccessable as far as I can tell, so this does not seem to work. Is there any way to go away from forwarding port 80 and 443 and move to let's say 20080 and 20443?