Gorosch

Ich habe keine Ahnung, wie sich das BMC ohne RAM verhält, da ich tatsächlich noch nie einen Server ohne RAM eingerichtet habe. Aber da du über iKVM drauf kommst, scheint es wohl zu laufen. Ich kenne diese Problemtaik persönlich auch nur von Intel Server Boards, wenn die Kollegen nicht aufgepasst haben, wie die Riegel gesteckt werden müssen. Falls nicht schon geschehen das BIOS reseten. Und dann strikt nach Handbuch vorgehen. Wenn es kompatible RAM sind, und es keinen Hardware Defekt gibt, sollte die Kiste dann booten. Also Board Layout bachten: Die LEDs beachten: Und die richtige Bestückung der DIMM Sockel nutzen:

Das ist richtig. Genau von dieser Reihe gibt es aber eine neuere Version, da in 6.9 doch ein paar Dinge dazu gekommen sind. Das macht die alte Reihe sicher nicht schlechter. Die Neue bezieht sich nur eben auf den aktuellen Stand und erklärt ein paar Dinge nochmals besser.

Im VM Tab eine Custom VM erstellen und die XML reinkopieren. Eventuell die Pfade zu den VDISKs anpasssen. Das sollte es dann schon gewesen sein.

Auch wenn es mit dem eigentlichen Problem nichts zu tun hat: Die 850W wirst du sicherlich nicht sprengen, aber der Idle Vebrauch wird dennoch ziemlich hoch sein. Eine von den CPUs hat schon 115 W TDP. Im Idle liegen die bei 18 Watt pro CPU. Du hast gleich zwei davon. Also schon 36 Watt, nur um die beiden CPUs im Idle nutzen zu können. Die Restliche Hardware ist da noch gar nicht mit eingerechnet. Hier gibt es Systeme, die liegen im Idle bei unter 30 Watt gesammt. Zum dran basteln sicher Cool, aber definitiv ein Geldfresser, für die wenige Leistung, die du raus bekommst. Zurück zum eigentlichen Problem, sofern wir dich jetzt nicht von der Hardware abgeschreckt haben: Waren die RAM Riegel bei dem System dabei und hast du die Möglichekit, die Riegel einzeln zu testen?

Hier werden alle Docker und Plugins angezeigt, welche du jemals auf dem System hattest. Am besten erst mal nur Docker anzeigen lassen und noch mal prüfen, dass dort auch nur Container ausgewählt werden, welche du auch haben willst. Sonst macht er dir auch Container drauf, welche du vielleicht schon wieder entfernt hast. Du kannst entweder alle auf einmal drauf packen oder du gehst jeden einzelnen noch mal druch. Ich würde dir letzteres empfehlen, da du dann noch mal den Appdata Pfad anpassen kannst, falls der Name des Cache Pools sich geändert hat, in dem nun der appdata Share liegt. Da die Docker nach dem installieren direkt starten, legen die sonst neue Verzeichnisse an, wenn die die alten appdata nicht finden. Solltest du die Standardpfade nutzen, also "/mnt/user/appdata" kannst du auch alle auf einmal installieren, da die Pfade ja dann passen sollten. Die Docker werden dann in dein Docker Image gepackt. Da dieses nun fehlt, werden dir auch die Docker nicht mehr angezeigt. Die Einstellungen der Docker selbst liegen jedoch im Appdata Share. Also wie oben erwähnt, die Pfade beim installieren prüfen. Dann laufen deine Docker direkt los, als wäre nie etwas gewssen. Solltest du ein eigenes Docker Netzwerk erstellt haben, musst du dies jedoch davor wieder erstellen, da dies beim Verlust des Docker Image ebenfalls verloren ging. Wenn du so etwas nicht hattest, brauchst du nichts weiter beachten.

Stimmt, du hast Recht. Von der Erklärung her sollte es aber dennoch stimmen, was ich gemeint habe. Wenn nicht, bitte korregieren. Das liegt aber daran, dass der Container Pfad "/unraid" auf den Server Pfad "/mnt" führt. Und in "/mnt" liegen eben, wie oben beschrieben diese Verzeichnisse. Abgesehen davon gibt es bezüglich Krusader ein neueres Video, was dies noch mal besser erklärt. Hier wird sogar empfohlen, den Host Pfad "/mnt/user" zu entfernen und eigene Pfade zu nutzen. Warum, wird im Video besser und schneller erklärt, als es hier zu tippen. Zu diesem Thema gibt es sogar eine ganze Videoreihe, welche alle Möglichkeiten aufzeigt, Daten in Unraid, um Unraid und um Unraid herum zu bewegen. Sollte dir sicherlich weiterhelfen.

Genau. Beispiel Dokumente Share, welcher ausschließlich auf der Disk 3 bei mir liegt: Dennoch solltest du auch da immer über das "/mnt/user" Verzichniss die Shares befüllen. Unraid packkt die Daten dann von ganz allein gemäß den Einstellungen auf die jeweilige Disk. Wenn du die Platten jedoch über "/mnt/diskX" befüllst, kann dies erhebliche Probleme mit sich bringen. Angefangen davon, dass der Mover nicht mehr macht, was er soll - bis hin zu Datenverlust bei falscher Handhabung.

Ich glaube, ich weiß, was du meinst. Dann passt aber irgendwas mit deiner Krusader Config nicht. Das /mnt Verzeichniss müsste, je nach Platten im Array und Pools, ungefähr so aussehen: Im /mnt/user Verzeichniss werden hingegen nur deine Shares angezeigt, unabhängig davon, auf welcher Disk die liegen. Bei mir sieht es z.B. so aus: Die Disks wurden noch nie im User Verzeichniss angezeigt, seit ich Unraid in der Version 6 seit 2016 nutze. Alles, was davor war, kann ich dir nicht sagen, kann mir aber nicht vorstellen, dass es da anders war.

Genau so. Wichtig: Backups erstellen. Beim umformatieren werden logischerweiße alle Daten von den Platten gelöscht. Eine Empfehlung: für den Anfang solltest du vielleicht erst Mal die Standardeinstellungen bei den Speicherorten belassen. Also "/mnt/user/appdata" und "/mnt/user/system". Wenn du dann nach einiger Zeit ein Verständniss dafür hast, wie Cache Pools und das Array miteinander aggieren, kann man das immer noch anpassen. Geändert ist es schnell. Ist kein Muss, aber gerade am Anfang deutlich einfacher, das System kennen zu lernen, bevor es an die größeren Tweaks geht.

Disk Shares nutze ich auch, hatte dennoch noch nie Probleme mit dem Tool. Aber gerade Dateien, welche von Dockern erstellt wurden, haben ab und zu Probleme mit den Rechten. Dublicacy beim Wiederherstelllen von Datein ist da so ein Kandidat. Bevor ich da nun in die Konsole gehe und die Befehle Tippe, habe ich schneller den Button gedrückt. In der Zeit gehe ich nen Kaffee trinken, und das Problem ist behoben. Appdata wird nicht angepasst, es können keine Fehler durch Tippfehler entstehen, usw. Leichter gehts nicht. Dieser Pfad ist etwas verwirrend. Unter /mnt/user liegen normalerweiße deine Shares und keine Laufwerke. Array Laufwerke findest du einen ebene höher, also unter /mnt/disk1, usw. Laufwerke ausserhalb des Arrays findest du unter /mnt/disks. Wie sehen denn die Konfigs deiner Shares aus?

Ok, das ist ja nun doch einiges. Ich gehe mal von Oben nach unten durch. Das Arrays selbst würde ich nur mit XFS betreiben. Ob verschlüsselt oder nicht, obliegt deiner eigenen, gesunden Paranoia. BTRFS im Array bringt dir keinen Vorteil und macht nur bei Pools mit mehr als einer Disk Sinn. Alles was eine Disk ist, immer mit XFS betreiben. Auch die Disks im Array kannst du so gesehen als einzelne Disks ansehen. Richtig ist, dass die Parity Disk immer die größte im Array sein muss. Das hat mit den Pools jedoch nichts zu tun. Hier kannst du Betreiben, was du willst. Solltest du in einem Pool jedoch verschiedene Größen mixen, hast du immer nur den Speicher der kleinsten Platte zur Verfügung. Hast du z.B. eine 4TB und eine 2TB Platte im Pool als RAID1, hast du auch nur einen Pool mit 2TB zur Verfügung. Die defekte 6 TB Parity Disk natürlich so schnell wie möglich ersetzen. Sollte jetzt noch eine Daten Disk in deinem Array das zeitliche segnen, sind die Daten ohne Backup verloren. Die 240GB SDD solltest du in einen Pool setzen. Da dein Array immer nur so schnell ist, wie die langsamste Disk, machst du den Vorteil der SSD spätestens bei Schreibvorgängen zunichte, da hier immer auf die Parity Disk gewartet werden muss. Und gerade bei Docker Container und Transcodieren ist ne Menge an Schreibvorgängen vorhanden. Du bremst dich also selbst enorm aus. Im Array kannst du generell nicht mit RAID5 arbeiten. Dies geht nur über Pools. Du musst also min. eine Disk im Array haben, wenn du nur über Pools arbeiten willst. Ohne Array kann Unraid die Dienste nicht starten. In den Pools wäre dann auch ZFS möglich, was jetzt aber deutlich den Rahmen sprengen würde. Den Stick an der Fritte am besten mit einer USB Platte ersetzen. Zum einem ist ein Stick beim Schreiben recht langsam, zum anderen halten Sticks nicht sehr lange, wenn diese immer wieder beschrieben werden. Die Platte am besten direkt am Server anschließen. Schont dein Netzwerk und du hast schneller Übertragungsgeschwindigkeiten. Einfach gesagt würde ich das System wie folgt aufbauen: Deine HDDs ins Array als XFS. Was auf welche Disk drauf kommt, kannst du entweder selbst steuern oder über die Shares mit included/excluded Disk regeln. Die SSDs als eigenständige Pools einrichten. Einzelne Disks als XFS, mehrere Disks im Pool als BTRFS. Deine zwei 970er EVOs am besten als RAID1 im Pool betreiben. Die jeweiligen Shares mit wichtigen Daten dann auf Cache "Yes" und diesen Pool auswählen. So sind diese Daten auch im Cache sicher, wenn mal eine von den beiden SSDs ausfällt, und die Daten noch nicht im Array liegen. Als Beispiel mein Share mit Dokumenten: Hier wird der Cache bestehend aus zwei SSDs im RAID1 genutzt. Über Nacht packt der Mover die Daten vom Cache ausschließlich auf Disk 3. So dinge wie der Appdata oder System Share kannst du entweder ebenfalls auf diesen Cache packen. Oder du nimmst die einzelne 240 GB SSD dafür. Somit hast du weniger Schreiblast auf den beiden SSDs und auch eine bessere Performance der Docker und VM, da die sich nicht die I/O mit anderen Dingen teilen müssen. Dank dem Appdata und VM Backup Plugin aus dem CA, sind die Daten schnell wieder hergestellt, wenn diese einzelne SSD den Geist aufgibt. Hängt natürlich davon ab, was für Docker und VMs du am Laufen hast und ob du den Ausfall selbiger verkraften kannst, bist ne neue SSD verbaut wäre. Appdate Backups gehen bei mir auf ne Disk im Array, sind aber von den unten stehenden Backupmethoden ausgeschlossen. Da die Backups inkrementell sind, würden diese Appdata Backups sonst ins unermessliche gehen, was denn Spicherplatz angeht. Mit dem oben genannten Script kannst du auf die USB Platte sichern, welche als Unassigned Device eingebunden ist. Optimal als XFS formatiert. NTFS geht aber auch, wenn du auf die Backup Daten am Windows PC ohne großen Aufwand zugreifen willst. Achtung: NTFS ist in Unraid deutlich langsamer als XFS. Der Script behält die Daten eine gewisse Zeit in den Backups, bevor diese gelöscht werden. Ganz einfach ausgedrückt sind dies drei Jahre. Löscht du also eine Datei von deinem Server, fällt diese erst nach drei Jahren aus dem Backup. Solltest du also erst nach Monaten merken, dass etwas wichtiges fehlt, ist des dennoch noch in den Backups vorhanden. Was du als Lösung für Externe Backups nimmst, ist eine andere Sache. Ob diese Magenta Cloud in Dublicacy funktoniert, weiß ich nicht. Vielleicht hat da jemand mehr Erfahrung. Duplicacy nutze ich selbst nur, weil es sich einfach Bedienen lässt als Docker in Unraid und die Backups verschlüsselt und komprimiert. Das würde auch alles mit rsync gehen, übersteigt aber aktuell noch meine Kenntnisse. Mit dieser Konfiguration sollten deine Übertragungsraten zum Server also recht flott gehen, da beim schreieben nur deine SSDs limitieren und beim Lesen die Geschwindigkeit der Platten im Array. Ein Normales 1Gbit Netzwerk zuhause sollte also ohne weiteres um die 112 Mbit darstellen können. Bei mir sieht das Ganze so aus. Sicher nicht perfekt, macht aber was es soll und das zuverlässig seit Jahren. Grüße

Genauso stecken, wie es im Handbuch steht. Alles andere ist Voodoo. Und nicht irgdnwelchen RAM stecken. Das Board braucht bestimmte RAM Typen. Siehe oben.

Gibt es irgendwelche BIOS Codes in Form von Piepen oder einer LED Anzeige auf dem Board? Bei Boards mit zwei CPUs sollte in der Regel daruf geachtet werden, wie die DIMM Slots gentutz werden müssen. Kennne es von Intel Server Boards, das da ein falsch gestecker RAM die Kiste am booten hindert. In der Regel kommt nicht mal der POST durch. Wird bei Asus sicher nicht anders sein. Wenn die Belegung passt, könnte es auch ein defekter RAM sein. Wenn möglich, die Riegel mal in einem Single CPU Board testen. Falls das Board bisher noch nie im Einsatz war: Sind die richtigen RAM verbaut?

JDownloader2 würde mir da Spontan einfallen. Das Teil hat nen Scheduler als auch nen Event Scripter. Damit sollte sich das wohl einrichten lassen. Gibt es als Docker bei den CA.

Das ganze Forum dursucht, aber diesen Thread nicht gesehen. Wald und Bäume und so. Aber tatsächlich das selbe Problem. Und auf dem gleichen Weg gelöst (relative Mouse). Besten Dank.

Da muss ich leider widersprechen, weil es genau das nicht macht: "This utility will restore standard unRaid permissions to all shares and files without touching any of the APPDATA shares for docker applications."

Ganz blöd gefragt: sollte das Porblem nicht mit der "Docker Safe New Perms" Funktion unter Tools behoben werden?

Servus, folgendes Problem bei folgender Hardware: Das Board ist ein Supermicro - X11SSM-F. Firmware: 01.63, BIOS: 2.5. Das Problem ist nun, dass beim starten des Server die Remotekonsole über BMC bzw. iKMV ganz normal funktioniert. Ich kann also ins BIOS, kann das booten von Unraid beobachten und habe auch den Linux Typischen Login Screen, sobald die Kiste oben ist. Nach ca. 10 Minuten wird das Bild schwarz und das war es dann auch. Der Server ist nach wie vor in Betrieb und funktioniert auch ganz normal. Nur eben kein Bild mehr über die Konsole. Was ich bisher schon versucht habe: Die Tipps in diesem Thread mit "nomodeset" versucht. Ohne Erfolg. Den Aspeed Treiber in Unraid laden sowohl mit nomodeset als auch ohne. Ebenfalls kein Erfolg. Das Downgrade der Firmware habe ich bisher noch nicht gemacht, da ich mich dagegen tatsächlich etwas sträube. Sollte es aber defintiiv keine andere Möglichkeit geben, wäre das der letzte Ausweg. Es handelt sich um eine Aspeed iGPU, welche auch nirgends durchgeschleift wurde. Also weder Docker noch VMs haben darauf zugriff. Daher die Frage an euch: Habt ihr ne Idee, was ich noch versuchen könnte? Grüße

Servus, für meine Backups nutze ich die 3-2-1 Regel. Also mindestens drei Kopien auf zwei Verschiedenen Medien, wobei eine außer Haus gelagert wird. Mein System hat 36 TB Speicher. Die wichtigsten Sachen, an die ich nicht mehr rankomme, wenn sie weg sind, sind in jedem Backup dabei. Also so Dinge wie Bilder, Dokumente, meine Musiksammlung. Filme und Serien kann ich bei Verlust des großen Backups wieder von den DVDs und BDs rippen. Von den drei Backups geht eines per Mgutts Script auf eine externe 5TB Platte. Das Script arbeitet inkrementell und die Daten liegen direkt auf der Platte. Man kommt also sehr schnell und einfach an verlorene Daten ran, ohne ein extra Tool zu benötigen. Die Platte selbst ist, wie das Array und die Pools, verschlüsselt. Hier liegen wie gesagt nur die wichtigen Daten. Dieses Backup läuft einmal am Tag. Die gleichen Daten gehen verschlüsselt und komprimiert per Dublicacy an einen B2 Backblaze Bucket. Dies wäre dann mein Backup außer Haus, welches einmal die Woche läuft. Ebenfalls per Duplicacy geht einmal der Komplette Datenbestand aller Shares an eine NAS, welche zumindest eine räumliche Trennung hat. Das wäre dann das große Backup, welches einmal im Monat läuft. Wichtig ist jedoch immer: Ein RAID in welcher Art und weiße auch immer (auch das Array in Unraid ist damit gemeint!) sollte nie als Backup der Daten angesehen werden! Zu deinen restlichen Fragen: 1. Du brauchst nicht zwingend eine USV, um ein Array in Betrieb nehmen zu können. Unraid läuft mit allen Funktionen mit als auch ohne USV. Eine USV schützt einfach nur durch Datenverlust im Falle eines Stromausfalls. Dies hat damit zu tun, dass Unraid standardmäßig 20% des RAMs als Schreibcache verwendet, bevor die Daten auf dem Cachepool oder dem Array landen. Wenn du also gerade wichtige Daten auf deinen Server packst und in dem Moment ein Stromausfall ist, sind alle Daten, welche noch im RAM lagen, unwiederbringlich verloren. Den Daten auf den Disks sollte unter normalen Umständen dabei jedoch nichts passieren. Bis auf den Neustart und den anschließenden Parity Check ist das ganze also nur lästig, aber nicht für den Betrieb wichtig. Eine USV hat jedoch ebenfalls noch den Vorteil, deinen Server bei Spannungsschwankungen (z.B. Blitzschlag) zu schützen. So etwas kann nämlich auch deine Platten killen, was dann ein paar Probleme mit sich bringt, wenn du keine sauberen Backups hast. 2. Wenn du einen Pool aus min. 3 Platten erstellst, sollte ein RAID5 möglich sein. Vielleicht kann dies aber noch jemand bestätigen. 3. Das Array in Unraid selbst kommt wohl dem RAID5 am nächsten. Da im Array jedoch kein Stripping der Daten stattfindet, ist jedoch kein RAID (UNraid). Ansonsten wie gesagt über die Pools ab Unraid 6.9 wohl machbar. 4. Bei einem RAID5 darf max. eine Platte ausfallen, damit die Daten noch verfügbar bleiben. HotSpare gibt es in Unraid nicht. Sollte also eine Platte in einem Pool ausfallen, muss diese einfach nur ersetzt werden. Array stoppen. defekte Platte im Pool tauschen, Array starten. Der Rebuild des RAID im Pool sollte dann direkt starten. Dennoch auch hier nochmal: Ein RAID stellt kein Backup dar. Ich habe es schon oft genug erlebt, dass ein Rebuild eines RAID auch mal schief gehen kann. Also immer Backups der wichtigen Daten haben! Grüße

Es wird die aktuelle SMB Version genutzt. SMB V1 ist deaktiviert.

Hi und danke für die Antwort. Dann habe ich es wohl zu gut gemeint, mit dem ausführlichen erklären. Im Grunde ist es aber genau das Problem, welches du beschrieben hast. Von "/mnt/user/share_A" verschieben nach "/mnt/user/share_B" mit WIndows klappt Wunderbar. Innerhalb von Unraid z.B. mit MC nicht jedoch nicht, da die Datein im share_A liegen bleiben. Somit wäre das dann wohl erklärt. Besten Dank.

Hallo Zusammen, Unraid nutze ich mittlerweile seit mehreren Jahren und es hat bisher auch immer das gemacht, was es sollte – mit vollster Zufriedenheit. Und wenn es mal doch nicht gemacht hat, was es sollte, lag es fast immer an Eigenverschulden meinerseits. Nun hat mein System jedoch seit einigen Wochen ein merkwürdiges Verhalten beim Verschieben von Daten aus dem Pool ins Array, welches ich mir nicht erklären kann. Hier hoffe ich auf eure Unterstützung. Kurz zum System (wer es ausführlich haben möchte, die Diagnostics liegt bei): Das Array besteht aus 4.1 Platten. Die Shares sind auf einzelne Disks gebunden. Serien auf Diks 1, Filme auf Disk 2, Musik, Dokumente etc. auf Disk 3, usw. Es gibt diverse Cache Pools: Ein Raid 1 aus zwei SSDs dient als Cache für wichtige Daten und beherbergt auch wichtige Shares wie appdate, System, und Cloud. Dann gibt es noch einen Pool aus jeweils einer SSD für die VMs (nichts Relevantes, daher kein Raid, jedoch mit Backups gesichert). Und der letzte Pool besteht aus einer älteren WD Velociraptor HDD. Um den letzten Pool mit dem Namen „Datacache“ geht es. Auf diesem Pool liegt ein Share mit dem Namen „Datencache“ (Cache only) und hier laufen nur Dinge mit hoher Schreiblast, welche aber keine hohen I/O Ops benötigen. Konkret werden hier Filme und Serien zwischengelagert, welche von einem anderen Rechner gerippt werden oder vom JDownloader geladen und entpackt werden, bevor die im Array landen. Selbstverständlich liegt alles im Original als DVD oder BD vor. Geladen wird nur, worauf ich selbst keine Lust zum Rippen habe – in der Regel Serien. Sowohl der Film- als auch der Serien Share sind ohne Cache eingestellt (Cache no). Wenn ich nun von diesem Share „Datencache“ die fertigen Daten manuell von einem anderen Rechner oder einer VM innerhalb des Unraid System in die jeweiligen Shares „Filme“ und „Serien“ verteile, läuft alles wie erwartet. Verschiebe ich die Daten jedoch über MC oder Krusader, erstellt Unraid im Datencache einen Ordner mit dem jeweiligen Share Namen und lässt die Daten auf dem Share im Pool liegen. Das Verschieben ist sofort abgeschlossen. Auch der Mover lässt die Daten dann dort liegen, da ja Filme und Serien ohne Cache konfiguriert sind. Schalte ich für die beiden Shares jedoch den Cache ein und wählen den Datacache als Pool aus, werden die Daten vom Mover verschoben. Hier versteh ich nun nicht, warum Unraid selbst (MC oder Krusader) die Daten nicht von einem Share ins andere Share verschiebt. Von einem Rechner oder einer VM funktioniert dies ohne Probleme. Dieses Verhalten ist erst seit ein paar Wochen, davor gab es keine Probleme. Ich wüsste auch nicht, was ich verstellt haben könnte, was dieses Verhalten erklären könnte. Auch die Einstellungen sehen für mich alle richtig aus. Hat jemand von euch ne Idee, woran dies liegen könnte? Grüße

Servus, hatte vor ein paar Tagen das gleiche Problem, nachdem ich im BIOS etwas mit den Energieeinstellungen und den C-States rumgetestet habe. Anlass war dieser Thread. Auslöser war bei mir die Änderung des C-State Limit von "Auto" auf "C8" (C10 wird bei mir nicht unterstützt). Der Server hat dann ganz normal gearbeitet, sobald es jedoch zu ruhig im Netzwerk wurde, konnte ich ihn nicht mehr erreichen. Sowohl WebUI als auch SSH waren tot. Auch per Remotezugriff per BMC war der Bildschirm schwarz und konnte nicht reaktiviert werden. Erst ein Reset erweckte den Server wieder zum Leben. Nach dem Anpassen des C-State Limit wieder auf "Auto" war das Problem behoben. Vielleicht hast du ja ähnliche Änderungen vorgenommen. Im Notfall einfach mal das BIOS auf Default Settings laden, Bootreihgenfolge und VT sowieo UEFI wieder aktivieren (sofern genutzt). Sofern du nicht mehr weißt, was du alles im BIOS verstellt hast, wäre das erst mal der einfachste Weg. Grüße

Hello everybody, Before I come with my next problem, I wanted to thank you first for your commitment. I read a lot here, so I could solve a lot of problems or avoid them right away and find this community great. Unfortunately, pure reading does not help me with the following problem. After reporting a problem with port forwarding in another thread a few days ago (downgrading the firmware and the controller solved the problem by the way), I now have a problem with Letsencrypt and Nextcloud. The two Docker container I have set up after the very good video instructions from Spaceinvader and ran until a few days ago without problems. Now that I've fixed the port forwarding issues yesterday, the cloud can be recovered from outside and doing what it should. However, it is no longer possible to access the cloud via the local network. Here I suspect the reverse proxy of Letsencrypt because the requests from the WAN as well as from the LAN arrive at the container, but this does not forward the requests from the LAN to Nextcloud. I have already re-installed the Letsencrypt Docker and the new certification of the subdomains ran without problems. Also, the configs have been checked and recreated several times, but can find no error. So now I need your help, hoping that you have an idea or even a solution to that. My router has a static IPv4 at my ISP. Hairpinning - NAT loopback is enabled. Via NSlookup I land on both the WAN and LAN at the right address. Below my settings and configs. greetings Gorosch No further files were modified

Hello everybody! Yesterday I did the latest update for the Unifi Controller according to the instructions described here. Through the updates, my USG3P was patched to the current firmware. Since then, the port forwardings no longer seem to work. Two ports (80 and 443) were forwarded to a letsencrypt docker responsible for a Nextcloud container. The whole thing went wonderfully until yesterday's update. According to CLI and WebGUI, all rules are in place, but the cloud is beyond reach. Also other port forwardings to a test network and a Minecraft server do not work. Thus, I exclude a mistake in the Docker containers. Does anyone have a similar or even the same problem and a solution for it? The whole thing runs on the current Relase version of Unraid (6.6.6). Grettings