mgutt

Mit Unraid 7.4 kann man nun die Sicherheit von Containern optimieren. Was sind die Vorraussetzungen: Settings -> Docker -> Preserve user defined networks aktivieren ein internal Netzwerk für Container erstellen, die ausschließlich untereinander kommunizieren sollen. In meinem Fall Nextcloud und Maria-DB. Also habe ich es wie folgt erstellt: docker network create nextcloud-internal --internaldas internal Netzwerk beiden Containern als additional network zuordnen: In der Nextcloud Config die DB-Credentials auf den Namen des MariaDB-Containers ändern: Prüfen, ob Nextcloud noch funktioniert nextcloud stoppen mariadb nur noch nextcloud-internal zuweisen die Port Config bei mariadb löschen nextcloud starten und erneut prüfen Der Vorteil daran ist, dass MariaDB nur noch vom Nextcloud-Container aus erreichbar ist. Der MariaDB Container kann auch nicht mehr ins Internet: $ timeout 3 bash -c 'exec 3<>/dev/tcp/1.1.1.1/80' && echo "Internet erreichbar" || echo "Keine Verbindung" bash: connect: Network is unreachable bash: line 1: /dev/tcp/1.1.1.1/80: Network is unreachable Keine Verbindung $ Der Nachteil ist, dass die erstellen Netzwerke wie nextcloud-internal nur im Docker Image existieren. Falls man also irgendwann mal Docker neu installiert, sind sie weg und müssen neu erstellt werden. Demnach sollte man sich in User Scripts ein Skript hinterlegen, was diese Netzwerke erstellt. Dann könnte man bei einer Neuinstallation einfach Docker neu installieren, Skript ausführen und Container wieder hinzufügen. Das Spiel kann man natürlich weitertreiben. z.B. kann man weitere interne Netzwerk erstellen, die man nur bei Proxy und Nextcloud ergänzt. Dann kann der Proxy Nextcloud auch über dessen Containernamen und lokalen Port erreichen: Und auch bei Nextcloud kann der Port weg: Das ergibt dann: Im nächsten Schritt muss ich jetzt noch das "bridge" Netzwerk von Nextcloud loswerden, damit andere Container, die auch "bridge" nutzen, nicht Nextcloud erreichen können. Dazu habe ich dann ein nextcloud Netzwerk erstellt, das diesmal nicht "internal" ist, also das Internet erreichen kann: docker network create nextcloudDas wurde dann das neue primäre Netzwerk: Der Test über die Console des Nextcloud-Containers: $ timeout 3 bash -c 'exec 3<>/dev/tcp/1.1.1.1/80' && echo "Internet erreichbar" || echo "Keine Verbindung" Internet erreichbarErgebnis: Allerdings verhindert man dadurch nur, dass sich die Container untereinander erreichen können. Es verhindert nicht, dass die Container Geräte aus dem Heimnetz erreichen können: Dafür bräuchte man jetzt iptables Regeln oder man vergibt allen Containern macvlan IP-Adressen aus jeweils eigenen VLANs, wo man dann einen entsprechenden Router/Firewall für benötigt.

Es ist kompliziert. Der Grund ist jedenfalls, das /mnt/cache/ssd/download ein Fuse-Mount sein kann, der Teil von /mnt/user/ssd/download ist. Und wenn das der Fall ist, kann man damit seine Daten löschen: root@atum:~# mkdir -p /mnt/cache/ssd/download root@atum:~# echo "test" >/mnt/cache/ssd/download/test.txt root@atum:~# cat /mnt/cache/ssd/download/test.txt test root@atum:~# cp /mnt/cache/ssd/download/test.txt /mnt/user/ssd/download/test.txt root@atum:~# cat /mnt/cache/ssd/download/test.txt root@atum:~# "Kann", weil es auch sein kann, dass er wegen Settings > Globale Share Settings > Permit exclusive shares doch keiner ist: Aber wie schon aus dem Hilfetext zu entnehmen, gelten dafür ganz bestimmte Voraussetzungen. Und dadurch entsteht eine Mischung an ungefährlichen und gefährlichen /mnt/user Zielen (überall wo -> steht, also ein Symlink aktiv ist = ungefährlich): root@atum:~# ls -lah /mnt/user total 16K drwxrwxrwx 1 nobody users 82 Oct 30 13:46 ./ drwxr-xr-x 7 root root 140 Oct 30 13:56 ../ lrwxrwxrwx 2 nobody users 41 Oct 28 08:14 appdata -> ../cache/appdata/ drwxrwxrwx 1 nobody users 56 Oct 28 22:46 arrayonly/ lrwxrwxrwx 2 nobody users 6 Jun 21 23:49 cacheonly -> ../cache/cacheonly/ drwxrwxrwx 1 nobody users 4.0K Oct 29 13:26 destination/ drwxrwxrwx 1 nobody users 6 Oct 29 17:04 fm_test/ drwxrwxrwx 1 nobody users 19 Oct 29 12:30 media/ lrwxrwxrwx 3 nobody users 22 Oct 30 13:46 ssd -> ../cache/ssd/ drwxrwxrwx 1 nobody users 8.0K Oct 28 22:13 test/ lrwxrwxrwx 4 nobody users 50 May 7 12:42 tmp-fdinfo-test -> ../cache/tmp-fdinfo-test/ root@atum:~# Ungefährlich ist es dann deswegen, weil die Linux Commands dann erkennen, dass die Datei sich selbst überschreiben würde und dann failen: root@atum:~# cp /mnt/cache/ssd/download/test.txt /mnt/user/ssd/download/test.txt cp: '/mnt/cache/ssd/download/test.txt' and '/mnt/user/ssd/download/test.txt' are the same file Es ist also gar nicht so ungefährlich das "einfach so" in den File Manager einzubauen. Man muss das genau im Blick haben. Aber ja, ich stimme dir zu, manche Kopiervorgänge könnte man erlauben. Muss ich aber wirklich sehr gut durchdenken.

Ich habe es mal so erfasst: Bedienung per Tastatur mit HotKeys für Aktionen Mehrere Aktionen (Copy, Move, etc.) parallel im Hintergrund Zweispaltige Ansicht Wobei eine Tastaturbedienung erst umsetzbar ist, wenn man das aktuelle Konzept mit den Checkboxen losgeworden ist. Bei der zweispaltigen Ansicht sehe ich mit den größten Aufwand.

Da man nur über die VPN-Verbindung (Tailscale) in das Netz kommt, ist das logischerweise sicher. Deine Überlegungen da noch mehr abzusichern, halte ich für unnötig, weil du den Server ja auch nicht gegen deine lokalen Clients abschirmst. Ich meine du überlegst gerade den Zugriff von Tailscale-Clients stärker abzuschirmen als du es mit all deinen anderen lokalen Clients machst. Wenn du Tailscale selbst nicht vertraust, dann bringen dir die dortigen Regeln auch nichts, denn wenn die gehackt werden würden, würde der Angreifer einfach deine Regeln löschen. Sinn machen solche Regeln nur, wenn du eine Tailscale-Machine mit Dritten teilst und die sollen nur ganz bestimmte Dienste bei dir erreichen können. Hast du das vor? Dann zu deinem P2P-Problem: du brauchst eine öffentlich erreichbare IPv4 oder IPv6 wenn nur IPv6 vorhanden ist, dann muss du im lokalen Netz IPv6 aktiviert haben, also der Unraid Server selbst braucht auch eine IPv6 der Unraid-Server baut eine Verbindung zu Tailscale auf der Client baut eine Verbinding zu Tailscale auf Tailscale teilt dem Unraid Server die öffentliche IP vom Client mit Unraid baut eine Verbindung zum Client auf, die zwar scheitert, aber deine Firewall erlaubt nun eingehende Verbindungen von der IP des Clients der Client baut erfolgreich eine direkte Verbindung zum Unraid Server auf Das gesamte Konzept nennt man UDP-Holepunching. Wenn das nicht klappt, scheint also noch was in Sachen IPv4 / IPv6 nicht zu stimmen. Nur am Rande, da du gerade im IT-Security-Modus bist: wenn du in einem fremden Netzwerk bist, könnte ein Angreifer versuchen deinen Client nachzunahmen und würde so den Tailscale-Port auf deinem Unraid Server erreichen (er kann sich nicht authentifizieren, aber eine Sicherheitslücke ausnutzen, sofern vorhanden) Tailscale läuft auf Unraid als root. Sollte also Tailscale eine Sicherheitslücke haben, wäre der Angreifer direkt root auf deinem Server. Also glaube nicht, dass das was du gerade baust "perfekt" ist. Du machst es Angreifern aber deutlich schwerer, keine Frage. Und ich warne dich vor: Wenn du jemals mit Dritten was teilen willst, wirst du dein Konzept eh aufgeben müssen 😅 Ich habe aktuell übrigens einen ähnlichen Aufbau wie du, weil bei mir gerade weder IPv4 noch IPv6 vorhanden ist. Ich habe daher eine Wireguard-Verbindung zwischen einem Container und einem VPS-Server aufgebaut, damit meine Dienste weiterhin über IPv4 public erreichbar sind. Sobald aber IPv6 verfügbar ist, werden alle meine Domains die IPv6 vom Nginx-Container erhalten und die Firewall diesen Traffic direkt durchlassen. Solange der eingehende Traffic erst durch Nginx geht und ausschließlich bei (non-root) Containern landet, mache ich mir da wenig Gedanken wegen der Sicherheit. Klar wäre es nervig, wenn jemand meine Nextcloud-Dateien zerlegt, aber dafür habe ich ja Backups und wir sind als Privatpersonen eh kein lohnendes Ziel. Tatsächlich habe ich auch einen Unraid-Server mit Tailscale verbunden. Da legt ein Freund manchmal Dateien ab. Wegen fehlendem P2P - so wie bei dir - etwas langsam, aber bevor ich deinen Aufwand treiben würde, würde ich auf dem Server Tailscale als Container installieren (wegen non-root) und den Port freigeben. Dazu dann Geoblocking in Unifi umsetzen und gut ist. Aber wie gesagt, wenn Public IPv4 oder IPv6 vorhanden sind, sollte UDP-Holepunching eigentlich dein Problem lösen und den VPS überflüssig machen.

Ich habe schon vor einiger Zeit angefangen den File Manager zu erweitern. Es ist nicht so als hätte ich nicht schon viele Ideen, aber die Liste wird sicher nicht vollständig sein, daher bitte gerne weitere Vorschläge machen: Dateien markieren inkl. Mehrfachauswahl per Maus (also nicht wie jetzt über Checkboxes, sondern wie bei einem Desktop) Dateisuche rekursive mit Filteroptionen Permissions Button soll auch Ausführungsrechte setzbar machen (muss von der Sicherheit noch hinterfragt werden) Datei-Eigenschaften Popup (evtl. auch mit EXIF-Daten etc.) Copy/Move optional auch checksum prüfen lassen Papierkorb Je nachdem wie die Gestaltung weitergeht (aktuell gibt es ja nur Mini-Icons): Vorschaubilder von Bildern, Videos, etc. Drag & Drop Upload Dateien teilen (über separaten Port und der Möglichkeit eine Custom-Domain anzugeben, damit man das z.B. über einen Reverse Proxy öffentlich nutzen kann, ohne gleich die WebUI selbst erreichbar machen zu müssen) File Manager für non-root User nutzbar machen (Zugriff nur auf berechtigte Shares) Bedienung per Tastatur mit HotKeys für Aktionen Mehrere Aktionen (Copy, Move, etc.) parallel im Hintergrund Zweispaltige Ansicht Copy/Move zwischen Pool/Disk- (mnt/cache/) und User-Pfaden (/mnt/user) erlauben ("Fuse User Share Copy Bug" bedenken!) Ein paar Sachen hatte ich auch schon umgesetzt: Upload viel schneller und Progress zeigt realistische Übertragungsrate und Restzeit Unraid merkt sich populäre Ziele bei Copy/Move: Und ein Klick öffnet automatisch den Baum: Rechte Maustaste auf den Ordner öffnet das Popup (das gab es schon) und markiert automatisch den Pfad (das ist neu): Der im Popup angezeigte Terminal-Button öffnet das Terminal in genau diesem Pfad: Was ich außerdem schon abgeschlossen habe, aber aktuell noch von Limetech geprüft wird, ist das Erstellen und Entpacken von Datei-Archiven: Da sieht man auch, das ich aktuell an dem File Editor dran bin. Der wird dann alle Text-Dateien bis zu einer bestimmten Größe öffnen können, egal welche Dateiendung sie haben (aktuell wird das ja über eine Liste geregelt, die man selber pflegen muss). Also immer her mit euren Ideen ✍

If the user sets "Permit exclusive shares" to "Yes" and sets docker path to "/mnt/user/appdata", rsync does not create the backup, instead it returns: as mentioned, the fix is to add --insecure-links option to the rsync command.

I've updated the power management code to exclude Intel 2.5G NICs: # Runtime PM for PCI devices for pcidev in /sys/bus/pci/devices/????:??:??.?; do driver=$(basename "$(readlink -f "$pcidev"/driver)") # skip Intel 2.5G NIC (igc driver) as it has known issues with runtime PM/ASPM causing link down if [[ $driver == igc ]]; then continue fi echo auto | tee "$pcidev"/power/control done

Das hast du denke ich falsch interpretiert. Im ersten Screenshot oben siehst du die Temperatur. Die lag bei 51 Grad bei niedriger Nutzung und 78 max laut SMART. Die Zahl 83,45 aus dem anderen Screenshot ist dagegen eine Prozentzahl und steht für den Auslastungsfaktor beim Lesen von der SSD. Also keine Temp. Im gleichen Slot habe ich nun die Samsung 860 Pro 4TB verbaut und die ist genauso warm wie alle anderen bzw. sogar kühler: Ich hatte das Verhalten übrigens bei zwei baugleichen SanDisk Ultra 3D. Foto von einer: Nach dem Ausbau habe ich dann mal einen Benchmark in Windows gemacht und die Schreibwerte waren gruselig: Dann habe ich TRIM ausgeführt (der fast 10 Minuten gedauert hat) und alles war plötzlich ok: Bekanntlich macht Unraid im Array kein TRIM, aber wie man sieht haben gute SSDs dank einer ordentlichen Garbage Collection kein Problem damit. Und deshalb kann ich gut schlussfolgern, dass die neuere Ultra 3D extrem wenig SLC-Cache haben muss oder gar keinen und die Garbage Collection ab einem gewissen Füllgrad nicht mehr funktioniert. Die Temperatur kommt dann denke ich zu Stande, weil die dann extrem oft Zellen neu beschreibt. Damit verhält sich die Ultra 3D ganz klar wie irgendeine eine Billig-SSD. Denn nur Billig-SSDs haben solche Probleme. Ich mein ich habe 24 SSDs im Server, 5 verschiedene Modelle und nur die neueren Ultra 3D haben sich so miserabel verhalten. Daher kann ich das denke ich schon gut erkennen. Für einen Windows PC ist die natürlich immer noch ok, aber meiner Ansicht nach nicht mehr das Geld wert, wie sie früher wert war. Eigentlich ist das ein gänzlich anderes Produkt als früher als diese SSD quasi von jeder PC-Seite in den Tests die obersten Platzierungen erhalten hat.

Da man kaum noch an den Swissbit dran kommt, möchte ich eine alternative Empfehlung aussprechen. Und zwar der Transcend JetFlash 270M ist auch ein Enterprise Stick und sollte lange halten. Technische Daten: MLC NAND Flash 0°C (32°F) bis 70°C (158°F) bis zu 31 TBW (ich nehme an für die 32GB Variante, entsprechend also 15 TBW für die 16GB und 7 TBW für die 8GB Variante) Artikelnummern: 8GB TS8GJF270M 16GB TS16GJF270M 32GB TS32GJF270M Benchmark des 16GB Sticks: Für den 16GB zahlt man ca. 45 €

Einfach umstellen und danach alle Container per "Add Container" wieder hinzufügen. Dadurch werden die Container Images neu geladen. Nein, wobei man immer für appdata ein Backup haben sollte. Wie sonst willst du du Daten wiederherstellen, wenn dir ein Defekt oder ein Update-Fehler alles zerlegt? Das macht keine Probleme, ist aber unsinnig. Die vDisk ist wie der Name schon sagt eine virtuelle Disk. Ob eine btrfs vDisk auf einer xfs liegt oder eine xfs vDisk auf btrfs, spielt überhaupt keine Rolle. Das einzige was überhaupt Sinn macht, wäre ein Wechsel auf Verzeichnis/Directory. Dann landen die Docker Dateien 1:1 auf der Disk, ohne die vDisk dazwischen. Außerdem hat man ab dann keine Größenbeschränkung mehr bzw. unnötigen Platzverbrauch, weil es eben keine vDisk mit vordefinierter Größe gibt.

Braucht noch jemand M920x? Also der wo direkt 2 M.2 NVMe reinpassen und man optional noch mit PCIe Adapter noch mehr einbauen kann. Habe noch ein paar übrig von denen ich mich trennen würde. Es fehlt bei allen die WLAN Antenne, aber bekommt man bei Bedarf für ein paar Euro online.

Ich weiß nicht, ob es von Limetech erzwungen wird, aber ohne Account-Bindung wäre es auf jeden Fall kompliziert, weil ja die Lizenz vom Stick deaktiviert wird und wenn du die Hardware wechselst, ist ja keine Lizenz da, die du auf den neuen TPM übertragen kannst. Der TPM ist ja kein Ordner wie auf dem USB Stick, wo dein Lizenzschlüssel in einer Datei steht. Ja. Ja, der hat danach keine Funktion mehr. Alles was du in /boot siehst, liegt dann auf einer extra /boot Partition deiner SSD. Ja Das funktioniert anders. Der lädt einen Schlüssel in den TPM. Also man kann theoretisch von Mainboard A zu B und zurück zu A. Wobei ich nicht herausfinden konnte, ob die 12 Monate Sperrzeit auch hier gelten. Ja, aber ein neuer, weil der alte gesperrt ist. Es bleibt erstmal lange bei beidem, weil Limetech auch Kunden erreichen will, deren Hardware gar keinen TPM hat. Wie das in 20 Jahren aussieht, kann man daraus natürlich nicht ableiten. Ja. Muss aber komplett formatiert werden. Also erstmal Richtung Array alles moven usw. Ja, gibt es immer noch.

Ich habe ja mehrere Unraid Server und in einem ausschließlich SSDs verbaut. Darin sind verschiedene Marken und Modelle verbaut und auch zwei ziemlich alte SanDisk Ultra 3D 4TB. Die haben nie Probleme gemacht und haben eine exzellente Performance. Wegen der guten Erfahrungen habe mir dann vor einziger Zeit noch zwei gekauft. Irgendwann fiel mir aber bei den Parity Checks auf, dass dieser nun deutlich länger braucht. Heute habe ich die Sache mal untersucht und es stellt sich heraus, dass das neuere Modell >15 Grad heißer wird als die alte Revision: Alle SSDs sind wohlgemerkt in exakt den gleichen 8-Bay Cages verbaut und wie man sieht ist nur diese eine SSD bei 51 Grad. Und laut SMART ist sie im Thermal_Throttle, d.h. ohne diese Drosselung wäre sie noch viel heißer: Sie hat wohl schon mal 78 Grad erreicht, was für eine SATA SSD einfach nur krass ist: Dass diese eine SSD das ganze Array runterzieht erkennt man z.B. mit iostat an dem extrem hohen r_await Wert: Falls sich jemand fragt, warum ich nur eine der neueren Ultra 3D in den Screenshots zeige: Die andere ist nach wenigen Monaten kaputt gegangen. Also langsam, überhitzt und stirbt schnell. Das ist mein Fazit für die neueren Revisionen dieses Modells. Aber von Western Digital erwarte ich mittlerweile auch nichts anderes mehr. Die sind ja bei HDDs schon negativ aufgefallen, dass sie einfach die Produkte durch Revision verschlechtern. Für mich ist der Hersteller nun endgültig gestorben.

Es gibt jetzt einen 10G Adapter für den WiFi Slot: https://auvidea.eu/product/m20e-m-2-10gbe/ Verbaut ist der neue Realtek RTL8127. Einfach krass, dass das nun schon ohne Kühlkörper geht. Es gibt natürlich auch normale PCIe Karten, aber das Modell wäre ideal für einen Lenovo Tiny PC (z.B. M920x), um parallel den PCIe Slot weiter für eine GPU nutzen zu können.

If you want to boost your uploads, you want to keep the cache pool. And if you (want to) use docker or vms, you don't want to avoid a cache (appdata) pool at all as those would be slow and power inefficient on an array disk. Installing unraid on the nvme for internal booting will only reserve 16GB. The rest of the NVMe is still usable as cache pool.