Leaderboard

open unriad terminal wondow, type the following mkdir /mnt/ram mount -t tmpfs -o size=115G tmpfs /mnt/ram/ add path into your machinaris setup inside machinaris plotting config

I am attempting to set up remote access for my unRAID server through the My Servers plugin. I have an existing reverse proxy network enabled for nextcloud, so I set my Management Access page to look like this: Ports are forwarded, but I cannot use port 443 as the HTTPS port due to my reverse proxy network and my router refusing to forward the port (even though port 443 is not currently open inside the network). The server shows as "local access" but no combination of ports or forwarding will allow me to achieve remote access. What am I doing wrong? EDIT: I discovered the problem. I was visiting https://forums.unraid.net/my-servers/ while on the same network as my server, so it only showed "local access". When I visited the site from a separate network, I was able to use remote access.

@yogy thank you soo much for the help here. I actually found this gem of a video and yeah I did see geeked video as well, but it was def IBRACORP that did it for me with an Edge cert method, amazing. again thank you so much for the support, it all started making sense after weeks of hammering away, but of course still so much to watch out for and to learn.

That's a thing I can't answer because you have to tell if you can monitor all things that are important for you with Prometheus. My approach is a little different since I try to only use Prometheus and running the necessary plugins directly on unRAID with minimal configuration as possible and keep the load under control, most people forget that monitoring all or much things on a host can actually use also much or more power.

Auf jeden Fall. Ein Gaming Server und sparsamer Smart Home Server schließen sich aus. Das läuft dann eher auf zwei Server hinaus.

If you don't bind it, unRAID will use it for it's terminal output. Did you connect a monitor to the GPU to test this? As long as unRAID ist using the GPU, you can't use it in the VM. So your main target should be to boot unRAID gpu-less.

Wo klickst du hin? Kann dir nicht folgen.

I will look into this, please give me some time...

Disks are allocated using their serial numbers and where they are connected is not relevant (unless it somehow results in presenting a different serial number to UnRaid)

Grundsätzlich gilt: Es gibt überall Sicherheitslücken und alles lässt sich hacken. Die Frage ist ob sich der Aufwand für den Angreifer lohnt die Hürden zu überwinden. Und genau diese Hürden kann man erhöhen. Mal von oben nach unten wie der Zugriff auf Plex am sichersten wäre: man holt sich einen smarten Switch und erstellt VLANs, also virtuelle getrennte Netze mit eigenen IP-Adressräumen. In ein VLAN käme Plex und die Clients und in ein anderes Unraid. So wäre gewährleistet, dass nur der Admin auf Unraid selbst käme. Plex selbst und die Clients könnten zwar immer noch gehackt werden, wenn sich einer der Clients zB beim Surfen einen Virus einfährt, aber der Angreifer wäre auf die Clients dieses VLANs beschränkt. dann der Klassiker wie es die meisten haben. Alle Clients und auch Plex sind im selben Heimnetzwerk. Wird irgendein Client gehackt zB durch einen Trojaner, könnte dieser versuchen alle Clients und natürlich auch Unraid selbst zu attackieren. Jetzt wie in 1., nur mit Zugriff über das Internet. Hier würde man sich von unterwegs per VPN Tunnel mit dem Plex VLAN verbinden. Der Angreifer kann in dem Szenario erst mal nur den VPN Server attackieren, Plex und Clients erreicht man erst, wenn man diese Hürde überwunden hat. Der potentielle Schwachpunkt wäre also der VPN Server. Stärkster VPN Server wäre eine gehärtete Hardware wie ein VPN-fähiger Router. Solche Komponenten werden jeden Tag angegriffen und gelten als besonders gut abgesichert gegen Angriffe. Schwächster VPN Server wäre Unraid selbst, da es sich um einen klassischen "Linux PC" handelt mit einem relativ umfangreichen Linux Kernel. Auch hier gibt es natürlich die Möglichkeit, dass ein Client durch einen Angreifer kontrolliert wird. Der stärkste Tunnel nützt dann natürlich wenig. Das kann zB schon ein Smartphone sein, dass unbeaufsichtigt herumliegt und wo jemand mal kurz den WLAN Hotspot aktiviert und dann über einen Laptop das heimische Netz angreifen könnte. Jetzt wie in 2., also klassisches Heimnetzwerk mit dem man sich per VPN-Tunnel verbindet. Auch hier wäre der VPN-Server bzw die Clients der Schwachpunkt, aber nach einem erfolgreichen Angriff könnte man auch Unraid selbst attackieren. Jetzt wie in 2. nur diesmal mit einer simplen Port-Freigabe im Router auf einen Reverse Proxy Container mit IP-Whitelist, der wiederum die Zugriffe auf den Plex Container weiterleitet. Jetzt kann jeder aus Land X und ohne Login direkt den Reverse Proxy Container und/oder den Plex Container versuchen zu attackieren und erst im nächsten Schritt die Clients oder Unraid. Der Reverse Proxy gilt dabei aber als kleine zusätzliche Hürde, da hier Nginx im Einsatz ist, was sich nicht so schnell von Angriffen beeindrucken lässt, wie der Webserver, der beim Plex Container selbst zum Einsatz kommt. In wie weit aber Nginx die Angriffe einfach durchleitet, kann natürlich keiner abschätzen. Wie in 7. aber ohne eine IP-Whitelist ein, die ausschließlich Zugriffe aus Land X erlaubt. Jetzt wie in 7. mit einer simplen Port-Freigabe im Router, die aber nun direkt auf den Plex Container verweist. Jetzt wie in 9., aber Plex ist nicht als Container installiert, sondern direkt auf dem Server selbst (geht nicht in Unraid, nur zur Vollständigkeit). Hier hätte der Angreifer also nach einer erfolgreichen Attacke den kompletten Server übernommen. Wie du siehst ist der dritte und sechste Punkt leer. Das habe ich bewusst gemacht um aufzuzeigen, dass alles was nur lokal oder mit VPN Tunneln stattfindet, deutlich sicherer ist als die dann folgenden Varianten. Natürlich gibt es dann noch so Kleinigkeiten um weitere Hürden zu realisieren wie zB ob der Plex Container schreibend auf deine Film-Sammlung zugreifen kann. Bei mir ist zB ausschließlich ein lesender Zugriff möglich. Auch die Frage ob der Plex Container Zugriff auf das Internet erhält. Ohne Internet könnte Plex zB keine Cover, Filmnamen usw runterladen. Macht natürlich keinen Sinn. Aber vielleicht sperrt man alles bis auf die Domains von Plex.... Ein Container ohne Internetzugriff ist jedenfalls sicherer, weil der Angreifer keine Software nachladen könnte. Und nach dieser Fülle an Varianten muss man sich nun fragen: Lohnt der Aufwand? Was könnte ein Angreifer stehlen und lohnt sich das dann für diesen? Was wäre, wenn ich an einem externen Standort ein sicheres Backup aufbewahren würde, würde mich dann ein Angriff noch sonderlich stören? Ich möchte zB Nextcloud öffentlich verfügbar machen und kann hier gar keinen VPN Tunnel einsetzen, da sonst Gäste nicht auf die Cloud zugreifen könnten, wenn ich mit ihnen Dateien teile. Nextcloud muss außerdem schreibenden Zugriff besitzen. Ich kann mich also gar nicht wirklich gegen Angriffe schützen, außer vielleicht über eine IP-Whitelist. Die einzige Sicherheit ist hier mein Backup am externen Standort und besonders sensible Daten nicht über Nextcloud verfügbar zu machen und/oder sie dort nur verschlüsselt hochzuladen (zB ein AES verschlüsseltes 7z Archiv). Die einzige Sicherheit ist in so einem Fall also mein Backup. Ich handhabe es daher aktuell wie in 7. und verlasse mich im Härtefall auf mein Backup. Außerdem arbeite ich mich immer weiter in die Thematik ein wie man zusätzliche Hürden umsetzen könnte wie zB das Beispiel mit der Internetsperre für Plex. Wenn aber außer den Familienmitgliedern sonst keiner darauf zugreifen können soll, würde ich in jedem Fall einen VPN Tunnel empfehlen. Wer dann noch Geld und Zeit dafür hat, sollte mit VLANs arbeiten. Dann könnte man zB zu Hause auch getrennte Netze für potentiell unsichere Clients bereitstellen wie zB den Staubsauger-Roboter oder den Mähroboter, da so ein Equipment ja in der Regel nach x Jahren keine Updates mehr erhält. Wie du siehst ein durchaus komplexes Thema, dass man nicht mal eben mit Ja oder Nein beantworten kann.

I don't understand that completely but have you tried to click "Direct Connection" on the bottom and enter the IP from your unRAID server and the Port? First I would start to make it work internally like I've said above. Sorry I can't help you here since I have done everything that I could to troubleshoot it but I really can't see why it doesn't work on your unRAID box. Evenutally someone else can help here.

the probleme is the CoreFreq plugin !

You're correct the "peers.allowed_ips" are wrong on my remote side. As I'm using home assistant wireguard, so I have to manually add another field in its yaml configuration - allowed_ips: - 172.27.66.0/24 - 192.168.1.0/24 The reason I'm using the VPN tunneled access is because I'm trying to access from 192.168.1.0/24 to 192.168.0.0/24 and not the other way round. LAN to LAN also work for me. Thanks

Yes you need to reinstall them. if you go into Apps -> Previous Apps then you can tick of the ones you want reinstalled and they will then be put back with the same settings that you had earlier.

I wont be able to answer your question completely because I use Nginx Proxy Manager as a reverse proxy, so I have no clue how to do it with Swag. To answer your second question (2.), no, you don't open any ports on your router, that's what reverse proxy is all about. The only port forwarding on the router is for reverse proxy (in your case Swag or any other if you choose so). The purchase of your own domain is a great choise, I would recomend it for everyone, since it doesn't really cost much. So the idea of a Reverse Proxy is that you will be able to access (on the Internet) your apps via subdomains. If your domain is xywz.com, you will be able to access bitwarden / vaultwarden via vaultwarden.xywz.com without entering port number at the end. Let's encrypt will provide you with necesary certificate for this subdomain and if you go with Cloudflare DNS you are protecting the access to your apps even more. You can also use their DDNS. If you decide to switch Swag with Nginx Proxy Manager (NPM) as a reverse proxy with Cloudflare take a look of this great video Check out also a long discusion of NPM on this forum.

Die extreme Auslastung kommt meiner Ansicht nach dadurch, dass Chrome usw keine Hardwarebeschleunigung verwenden kann. Dh die CPU simuliert gerade in der VM eine GPU und das überlastet deine CPU. Das wäre eins der Probleme, die sich von alleine erledigen würden, wenn du eine Intel CPU mit iGPU hättest. Alternativ natürlich auch, wenn die GPU in der VM funktionieren würde. Dazu dann aber in dem anderen Thread. Das ist korrekt. Das sparsamste Setup wäre ein 8xxx oder 9xxxx Intel. Wir empfehlen am häufigsten das C246M-WU4, da es optional ECC RAM unterstützt, sowie 2x M.2 und 8x SATA besitzt. Noch sparsamer wäre das C246N-WU2, was aber ITX ist und daher nur einen PCIE Slot besitzt und auch nur 1x M.2. Einen i3-8xxx findet man außerdem mittlerweile häufiger gebraucht. Wenn es mehr Kerne sein müssen, ginge dann ein i5 oder wenn es ECC RAM sein soll, ein Xeon E-2xxxG. Ja, überlasse alles der CPU. Isolation usw macht meiner Ansicht nach nur Sinn, wenn man wirklich viele Kerne hat und wirklich das letzte Prozent Leistung für die VM exklusiv haben will. Dann wäre wirklich zu überlegen ob nicht lieber ein Board mit Thunderbolt-Anschluss suchst, wo man dann eine eGPU anschließt, die man dann physisch an die VM durchschleift. EDIT: Ok, Unraid ist noch nicht soweit, was ich aus dem Thread so rauslese: https://forums.unraid.net/topic/92522-thunderbolt-3-egpu-with-windows-10/ Vielleicht schafft man es mit so einem Adapter: https://riser.maxcloudon.com/en/non-bifurcated-risers/32-riser-x8-set.html Dieser verlängert einfach nur x8 auf x8, nutzt aber für die Extender Card eine eigene Stromversorgung. Daraus schließe ich, dass die GPU komplett aus ist, wenn man die Stromversorgung der Extender Card trennt. Dann wäre der Plan, VM runterfahren, Strom trennen. Und wenn man die VM wieder braucht, Strom wieder an. Sollte das gehen, könnte man auch sicher was mit einem smarten Schalter und ioBroker umsetzen, so dass man das nicht von Hand machen muss. Aber man müsste es erstmal testen. Ich habe bei Maxcloud übrigens diesen und einen weiteren Adapter bestellt. Ich wollte damit eh noch was testen und dann kann ich das gleich auch noch mit testen.

Busy work week last week. Glad to hear those worked for you @Masterwishx. I need to update the steps as the speedtest script was updated by the original developer (thanks for the pull request shiftlilbastrd) to present the version the way it had been. Yes, have noticed the same, seems to be 10% lower than what was previously reported. My latest speed test was 210Mb, and I know to add 10%, which means an older script version would have registered as 231Mb. Did notice that this version of the speedtest script has many more lines of code than previous ones. Have not compared it to a prior version to see if something was added that is causing the lower speed test results.

Hi, New contribution. Best Regards 😎

My swag broke on update. None of my sites work. I had 2 domains and several subdomains on my 1st domain running. This is only error I get: nginx: [emerg] "proxy_redirect" directive is duplicate in /config/nginx/site-confs/mydomain2.conf:28 What does this mean? I created the mydomain2.conf file in the past and I need it as it redirects to my wordpress docker. Heres the contents of mydomain2.conf server { listen 80; listen [::]:80; server_name mydomain2.com; return 301 https://$host$request_uri; } # main server block server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name mydomain2.com; # all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app 192.168.1.102; set $upstream_port 8086; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_redirect off; } } In the meantime I rolled back to an older version using linuxserver/swag:version-1.16.0 as the repository (Which works fine). What is changed in Swag 1.17 that is causing this error? Swag is just so overly complicated. I would switch to nginx proxy manager in a heartbeat but I need fail2ban.

New contribution of a new banner inspired by the colors of UnRAID and the Gray theme. I recommend that the header custom text color be the same tone as the icons: Header custom text color: # ff4800 Best regards

https://1drv.ms/u/s!AlHg8pmWgJJ_gr9mLid6muLTIMOddA?e=KbfHe2

Here are other options for Dell machines 😎

difficult to say as i dont use LSIO's code-server container (obviously 🙂 ) but the main difference is going to be i support http and https, self signed and cloud hosted which i think LSIO doesn't, i also have modified code-server to use the official VSCode rep for extensions, dunno if LSIO has done that?, and lastly a very minor change, i have modified the icon as the code-server one is just plain nasty. the other obvious change is i use arch linux, so adding in packages is probably easier (and a more extensive library) than the base OS LSIO uses, at the end of the day it IS the same app so the experience is going to be similar.

Any Rick and Morty fans out there... here is a 1920x90 option. It works great with white text. I'll be adding an animated Rick and Morty themed banner within the next week or so.

Thought I would post a few banners I threw together on here. All of these have some kind of animation.

recently had to do a fresh install of unraid, and incidentally lost all my user scripts (as they're stored on flash). So, i wrote a simple script to backup user scripts to the array in my backups destination. flash path should be the same for everyone (unless you manually changed it), you'll just need to adjust destination path accordingly. Maybe somebody can find it useful. #!/bin/bash dir=/boot/config/plugins/user.scripts/scripts/ echo 'Copying Scripts' rsync -avh $dir /your/backup/destination/path chmod -R 777 /your/backup/destination/path echo 'all good' Cheers!

Click on "Parity" and check the setting for "Spin down delay".