mgutt

That happens, because NPM talks to an online API to get the recent list of this IP addresses. As you can see here, it tries to access three different URLs: https://github.com/jc21/nginx-proxy-manager/blob/b39a59ce72eb032d5b725dce90dd6f3cf08b7d29/backend/internal/ip_ranges.js And this is done every 6 hours, so it will happen again even if you don't restart the container😒 Maybe you should try to open all three URLs through your PC and solve the captcha (if it hopefully will be shown) to "unlock" your public ip address for accessing them: https://ip-ranges.amazonaws.com/ip-ranges.json https://www.cloudflare.com/ips-v4 https://www.cloudflare.com/ips-v6 Or try to lock the file with the following command: su chattr +i /etc/nginx/conf.d/include/ip_ranges.conf A file with the "i" flag can't be modified or deleted. Optional: If you need to make it editable again: chattr -i /etc/nginx/conf.d/include/ip_ranges.conf

Àuf deinem Screenshot sieht man aber was ganz anderes.

Interessantes Projekt. Bekommt man da so viel Speicherplatz, wie man selbst zur Verfügung stellt oder muss man eher was draufzahlen?

This usually means that NPM's ports are used by different container. Check if other containers use the same IP-address and on which ports they listen. NPM needs 80, 81, 443 and 3000.

Ok, you found a Bug in the NPM. This HTML code should not be part of this file. As long this bug is present, please execute this, to remove the HTML code: sed -i '/DOCTYPE/Q' /etc/nginx/conf.d/include/ip_ranges.conf Please verify with "cat" if it worked.

Found a mistake in your checks. You used Unraid's webterminal to find the include folder. But you need to use the console of the container: Then check the content of the file with the following command: cat /etc/nginx/conf.d/include/ip_ranges.conf For me it's: set_real_ip_from 120.52.22.96/27; set_real_ip_from 205.251.249.0/24; set_real_ip_from 180.163.57.128/26; set_real_ip_from 204.246.168.0/22; set_real_ip_from 205.251.252.0/23; set_real_ip_from 54.192.0.0/16; set_real_ip_from 204.246.173.0/24; set_real_ip_from 54.230.200.0/21; set_real_ip_from 120.253.240.192/26; set_real_ip_from 116.129.226.128/26; set_real_ip_from 130.176.0.0/17; set_real_ip_from 108.156.0.0/14; set_real_ip_from 99.86.0.0/16; set_real_ip_from 205.251.200.0/21; set_real_ip_from 223.71.71.128/25; set_real_ip_from 13.32.0.0/15; set_real_ip_from 120.253.245.128/26; set_real_ip_from 13.224.0.0/14; set_real_ip_from 70.132.0.0/18; set_real_ip_from 15.158.0.0/16; set_real_ip_from 13.249.0.0/16; set_real_ip_from 205.251.208.0/20; set_real_ip_from 65.9.128.0/18; set_real_ip_from 130.176.128.0/18; set_real_ip_from 58.254.138.0/25; set_real_ip_from 54.230.208.0/20; set_real_ip_from 116.129.226.0/25; set_real_ip_from 52.222.128.0/17; set_real_ip_from 64.252.128.0/18; set_real_ip_from 205.251.254.0/24; set_real_ip_from 54.230.224.0/19; set_real_ip_from 71.152.0.0/17; set_real_ip_from 216.137.32.0/19; set_real_ip_from 204.246.172.0/24; set_real_ip_from 120.52.39.128/27; set_real_ip_from 118.193.97.64/26; set_real_ip_from 223.71.71.96/27; set_real_ip_from 54.240.128.0/18; set_real_ip_from 205.251.250.0/23; set_real_ip_from 180.163.57.0/25; set_real_ip_from 52.46.0.0/18; set_real_ip_from 223.71.11.0/27; set_real_ip_from 52.82.128.0/19; set_real_ip_from 54.230.0.0/17; set_real_ip_from 54.230.128.0/18; set_real_ip_from 54.239.128.0/18; set_real_ip_from 130.176.224.0/20; set_real_ip_from 36.103.232.128/26; set_real_ip_from 52.84.0.0/15; set_real_ip_from 143.204.0.0/16; set_real_ip_from 144.220.0.0/16; set_real_ip_from 120.52.153.192/26; set_real_ip_from 119.147.182.0/25; set_real_ip_from 120.232.236.0/25; set_real_ip_from 54.182.0.0/16; set_real_ip_from 58.254.138.128/26; set_real_ip_from 120.253.245.192/27; set_real_ip_from 54.239.192.0/19; set_real_ip_from 18.64.0.0/14; set_real_ip_from 120.52.12.64/26; set_real_ip_from 99.84.0.0/16; set_real_ip_from 130.176.192.0/19; set_real_ip_from 52.124.128.0/17; set_real_ip_from 204.246.164.0/22; set_real_ip_from 13.35.0.0/16; set_real_ip_from 204.246.174.0/23; set_real_ip_from 36.103.232.0/25; set_real_ip_from 119.147.182.128/26; set_real_ip_from 118.193.97.128/25; set_real_ip_from 120.232.236.128/26; set_real_ip_from 204.246.176.0/20; set_real_ip_from 65.8.0.0/16; set_real_ip_from 65.9.0.0/17; set_real_ip_from 108.138.0.0/15; set_real_ip_from 120.253.241.160/27; set_real_ip_from 64.252.64.0/18; set_real_ip_from 13.113.196.64/26; set_real_ip_from 13.113.203.0/24; set_real_ip_from 52.199.127.192/26; set_real_ip_from 13.124.199.0/24; set_real_ip_from 3.35.130.128/25; set_real_ip_from 52.78.247.128/26; set_real_ip_from 13.233.177.192/26; set_real_ip_from 15.207.13.128/25; set_real_ip_from 15.207.213.128/25; set_real_ip_from 52.66.194.128/26; set_real_ip_from 13.228.69.0/24; set_real_ip_from 52.220.191.0/26; set_real_ip_from 13.210.67.128/26; set_real_ip_from 13.54.63.128/26; set_real_ip_from 99.79.169.0/24; set_real_ip_from 18.192.142.0/23; set_real_ip_from 35.158.136.0/24; set_real_ip_from 52.57.254.0/24; set_real_ip_from 13.48.32.0/24; set_real_ip_from 18.200.212.0/23; set_real_ip_from 52.212.248.0/26; set_real_ip_from 3.10.17.128/25; set_real_ip_from 3.11.53.0/24; set_real_ip_from 52.56.127.0/25; set_real_ip_from 15.188.184.0/24; set_real_ip_from 52.47.139.0/24; set_real_ip_from 18.229.220.192/26; set_real_ip_from 54.233.255.128/26; set_real_ip_from 3.231.2.0/25; set_real_ip_from 3.234.232.224/27; set_real_ip_from 3.236.169.192/26; set_real_ip_from 3.236.48.0/23; set_real_ip_from 34.195.252.0/24; set_real_ip_from 34.226.14.0/24; set_real_ip_from 13.59.250.0/26; set_real_ip_from 18.216.170.128/25; set_real_ip_from 3.128.93.0/24; set_real_ip_from 3.134.215.0/24; set_real_ip_from 52.15.127.128/26; set_real_ip_from 3.101.158.0/23; set_real_ip_from 52.52.191.128/26; set_real_ip_from 34.216.51.0/25; set_real_ip_from 34.223.12.224/27; set_real_ip_from 34.223.80.192/26; set_real_ip_from 35.162.63.192/26; set_real_ip_from 35.167.191.128/26; set_real_ip_from 44.227.178.0/24; set_real_ip_from 44.234.108.128/25; set_real_ip_from 44.234.90.252/30; set_real_ip_from 2600:9000:3000::/36; set_real_ip_from 2600:9000:ddd::/48; set_real_ip_from 2600:9000:5300::/40; set_real_ip_from 2600:9000:1000::/36; set_real_ip_from 2600:9000:2000::/36; set_real_ip_from 2400:7fc0:500::/40; set_real_ip_from 2600:9000:4000::/36; set_real_ip_from 2600:9000:fff::/48; set_real_ip_from 2404:c2c0:500::/40; set_real_ip_from 2600:9000:f000::/36; set_real_ip_from 2600:9000:eee::/48; set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/13; set_real_ip_from 104.24.0.0/14; set_real_ip_from 172.64.0.0/13; set_real_ip_from 131.0.72.0/22; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2a06:98c0::/29; set_real_ip_from 2c0f:f248::/32

Hmm. Strange. I did the same and it was installed successfully. 🤔

Nichts wichtiges drin. Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=1010632

Hier bietet sich evtl der Krusader Docker an. Dann musst du nicht mit Windows hantieren bzw musst darauf warten, dass es fertig wird. Das mv Kommando geht auch, aber pass auf, dass du nicht das Terminal schließt, denn sonst bricht der ab und du kannst mv nicht fortsetzen.

Maybe. Do a simple test. Change the name of your installed container. Then go to the apps and install it a second time, but this time you change all three paths, so the second installation uses different folders. Example:

Hast du die /dev/disk/by-id/ Methode probiert bzw sprechen wir von SATA oder M.2?

Das Forum hier dreht sich nicht um Windows, sondern um unRAID. Daher wäre deine Frage woanders besser aufgehoben. Ich kann dir nur den Tipp geben, dass du dir Search Everything installierst und damit mal nach großen Dateien suchst. Ansonsten wie gesagt mal in einem anderen Forum fragen.

Wurde der Server zwischenzeitlich neu gestartet? Bitte Syslog Mirror aktivieren und deine Logs Posten mit Angabe wann die Disk rausgeflogen ist.

Ist schon ziemlich lahm: https://www.cpubenchmark.net/cpu.php?cpu=AMD+C-60+APU&id=244 Probieren geht aber über studieren

Da geht nichts verloren außer die Warngrenzen zu Speicherplatz und Temperatur, sofern du die überhaupt bei den einzelnen Disks eingestellt hast. Die Shares, deren Einstellungen, die User, usw bleiben alle erhalten. EDIT: ich meine Disk Share Einstellungen gehen verloren. Also falls du die nutzt, vielleicht einen Screenshot davon machen. Du gehst auf New Config und klickst Pools an, dass die erhalten bleiben sollen. Also nur Parity und Array soll "neu" sein. Dann weist du Parity und Array Disk wie zuvor zu (nicht vertauschen!). Dann anklicken, dass die Partity bereits richtig ist und Array starten. Das war's. Mach vorher vielleicht noch ein Backup von Stick und einen Screenshot von der Disk Übersicht. Aber vom Prinzip ist New Config nichts besonderes. Habe ich bestimmt schon 20x gemacht.

Er spricht von Windows und UUP Dump. Der Ordner heißt auch nicht MountUUI, sondern MountUUP. Offensichtlich hat er das Script abgebrochen, so dass die Mounts am Ende nicht gelöst wurden. Damit sollte der Mount gelöst werden: DISM.exe /Unmount-WIM /mountdir=C:\MountUUP / Oder hier ist auch noch eine Methode beschrieben: https://amp.reddit.com/r/WindowsHelp/comments/odfqic/mountuup_folder_cant_be_deleted/ Ist jetzt nicht so schwer zu ergoogeln.

Ist dein server_name mit der Wildcard so korrekt? Hast du mal stattdessen die Domain angegeben? Hast du den Zielport nach Wechsel auf knex666 angepasst? Keine Ahnung wie das bei Swag geht, aber nach einer Änderung muss Nginx neu gestartet werden.

As long you don't have the errors in the logs, you don't need to change anything.

Ja doch. Wird nur wieder geweckt 😁 Hast du manuell die Platte gestoppt und gestartet? Vielleicht auch mal new config probieren und Parity als bereits valide markieren. Gefühl ist da einfach nur irgendein Timing Banane zu sein, so dass der Smart Check zu spät kommt.

Nein, das ist egal. Es darf nur kein Slot im Array mittendrin leer sein. Ich hätte zb Disk5 nicht zugewiesen.

Meine Container nutzen ja bereits Disk Pfade. Dafür brauche ich ja keine Disk Shares aktivieren. Mein persönlicher Share passt aber nicht komplett auf die SSD. Ich kann also nicht /mnt/cache/Marc als Custom Share freigeben, weil da nicht alle Dateien drin wären. Ich hätte dann quasi zwei Shares nebeneinander. Tatsächlich mache ich das für mich selbst so, aber das brauche ich hier sonst keinem im Haus erklären. Daher sehe ich als einzige Lösung: A) SSD Cache Pool mit entsprechend vielen SSDs / Speicherplatz wo /mnt/cache/Marc drauf passt oder B) auf mehrere Arrays warten und einem zweiten Array nur SSDs zuweisen und /mnt/a2disk1/Marc als Custom Share freigeben Vielleicht setze ich doch mal A) um. Ginge dann aber nur mit mehreren SATA SSDs 🤔

Du brauchst pro Gaming VM eine GPU und Unraid selbst hätte auch gerne eine. Manche haben es geschafft Unraid diese abzugewöhnen (mit Kernel Parametern), aber das gelingt wohl nicht jedem. Es kann also sein, dass du im Härtefall eine dritte kleine GPU für Unraid benötigst wie zB eine GT 710 oder GT 1030. Besonders von Vorteil ist es, wenn Unraid die Primäre GPU erhält, die man im BIOS eingestellt hat. Auch das Unraid abzugewöhnen gelingt nicht jedem. Also Schritt 1 wäre eine zweite GPU zu kaufen und ein wenig zum Thema "unraid single gpu passthrough" zu recherchieren. Das erste Ziel wäre dann zwei VMs zu starten, die jeweils eine GPU nutzen und wo du dann auch was auf dem Monitor sehen kannst. Natürlich darf man bei so einem Unterfangen auch nicht das Netzteil außer Acht lassen und ob die 8 Kerne des 2700x für Unraid und zwei VMs ausreichen, muss sich dann zeigen. Besser wäre wohl ein 10 Kerner, wo man 2 Kerne für Unraid und jeweils 4 Kerne für die Gaming VMs nutzen könnte. Denk auch dran, dass deine Freundin nicht zwangsläufig vor deinem Rechner sitzen muss. Sie könnte auch Remote über Parsec auf ihrem Laptop spielen. Der 27 Zöller käme dann entsprechend an ihren Laptop. Bitte beachte, dass manche Spiele wegen Anti-Cheat empfindlich auf VMs reagieren: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1007233 Diese Frage verstehe ich nicht. Was meinst du mit "unabhängig"?!

Ich habe die Ausgabe mit einem Backup verglichen. Das Passwort was ich nicht geändert habe und was aktuell nicht funktioniert, besitzt nach wie vor den selben Hash. Allerdings haben sich die Hashs aller anderen User geändert. Fehlermeldung in Total Commander (Android): EDIT: Ok. Habe etwas gefunden. In der Datei /boot/config/smbpasswd fehlen offensichtlich Einträge: Der User "root" und der Nutzer, wo ich das Passwort noch nicht geändert habe, hat keinen Eintrag. Die Datei wurde heute morgen überschrieben als ich eines der Passwörter geändert habe: Ich habe auch gerade mal den Server neu gestartet, aber die Datei wurde nicht aktualisiert. Schon komisch, dass die warum auch immer geleert worden zu sein scheint, als ich den Server heruntergefahren habe (oder wann auch immer). Wo die Datei generiert wird, konnte ich leider nicht herausfinden. Nur dass sie scheinbar von /etc/rc.d/rc.M vom Stick ins System kopiert wird: if [ -r /boot/config/smbpasswd ]; then cp /boot/config/smbpasswd /var/lib/samba/private fi Scheinbar wird die von /usr/local/sbin/emhttp von /var/lib/samba/private/smbpasswd auf den Stick kopiert, aber ich kann nicht herauslesen wann das passiert: Ich erinnere mich, dass ich vor einigen Tagen einen User gelöscht habe. Vielleicht kam es zu dem Zeitpunkt bereits zu dem Fehler?! Eventuell habe ich das auch selbst verursacht. Denn ich habe ja wegen meinem SSD Abnutzungs-Guide ständig mit Mounts herumgespielt, wobei ich meiner Ansicht nach nie /var/lib woanders hingemountet habe, sondern nur andere Ordner auf /var/lib habe verweisen lassen. Hätte ich das gemacht, hätte ja auch nichts mehr funktioniert. Naja, zumindest weiß ich zumindest grob wo das Problem liegt. Falls du mal über den Quelltext stolperst wo die smbpasswd generiert / auf den Stick kopiert wird, immer her damit 😉

Was geht denn nicht? Startet der VM Service nicht oder ist die Liste mit den VMs leer oder was?

Sagen wir du schaltest den Server ein, machst ein Backup vom PC, dann machst du den Server aus und beim nächsten Einschalten ist die SSD kaputt. Bei einem Backup wäre das egal. Die Daten sind ja noch auf dem PC, aber wenn du vom PC Daten auf den Server verschoben hast, hast du ein Problem.