mgutt

Unraid neu:
Stell bei den Shares überall den Secondary auf "Array" und die Mover-Action auf "Cache to Array".
 
Unraid alt:
Stell bei den Shares alle prefer und only Caches auf Yes bzw No.
 
Egal ob neu oder alt:
Dann in den Settings Docker und VM auf "No" stellen und zum Schluss den Mover ausführen. Damit werden alle Dateien auf das Array verschoben.
 
Sobald die M.2 leer ist (über die Disk-Übersicht den Inhalt der SSD anschauen = muss komplett leer sein!), kannst du den Server herunterfahren und die M.2 ausbauen, die SATA SSD installieren und neu starten. Jetzt wird Unraid meckern weil die M.2 fehlt.
 
Nach Auswahl der neuen Cache SSD kannst du das Array starten. Nun wieder die Share Caches auf Only bzw Prefer stellen wie sie vorher waren. Den Mover ausführen und wenn der fertig ist (also die Dateien vom Array auf die SSD verschoben wurden), kannst du zum Schluss Docker und VM wieder aktivieren.
 
Docker und VM müssen übrigens deaktiviert werden, da sonst Dateien, die von den Diensten in Benutzung sind, nicht vom Mover bewegt werden können.

unRAID uses Slackware. Slackware's path to the services is /etc/rc.d
 
List all services:
ls /etc/rc.d
 
Restart a service:
/etc/rc.d/rc.ntpd restart

Du brauchst ein eigenes VLAN Netz mit eigenem IP-Adressbereich. Dann heißt es neue Interfaces zu erstellen. Siehe:
https://forums.unraid.net/topic/62107-network-isolation-in-unraid-64/

Hier mutmaßt man defekten RAM oder einen Bug im Linux Kernel:
https://unix.stackexchange.com/questions/682735/kernel-bug-unable-to-handle-page-fault-for-address
 

Die physische Verbindung von sdd ist gestört. Wodran hängt sdd? Nutzt du Stromsparmechanismen? Kabel in Ordnung? Stecker sitzt richtig? Meldet SMART des Datenträgers CRC Fehler?
 
Vom Prinzip gar nicht. Du kannst jetzt nur raten, dass die Daten auf der NVMe in Ordnung sind. Dh Einstellungen > Docker und auf Nein. Jetzt überlegen was man macht. Ich würde zb alles wegkopieren:

rsync --archive --stats /mnt/cache/ /mnt/disk1/backup/cache &> /mnt/disk1/rsync.log & disown
 
Die Log-Datei kannst du dir dann anschauen wegen evtl Fehlern.
 
Danach Pool löschen und neu erstellen, sobald du herausgefunden hast, was mit der SATA los ist. Wobei NVMe und SATA in Kombination eh Quark ist. Du bremst damit ja die NVMe aus.

Hat nichts damit zu tun. Ich habe redis auch gerade mal installiert. Läuft problemlos. Hast du evtl mal was am Template geändert? Wenn ja: Apps > Previous Apps und da redis löschen. Wenn du jetzt redis aus den Apps neu installierst, nimmt er das Original Template.
 
Bei der Installation erscheint "command". Da kommt keine Fehlermeldung? Würde mich wundern. Auch mal in Tools > Syslog schauen was so als letztes geloggt wurde.

Dann bekommt die Domain die IPv6 vom Router. Damit kann man nur den Router erreichen.
 
Leider nein. IPv6 unterstützt kein NAT (jedenfalls nicht standardmäßig). NAT ist das was bei IPv4 das Weiterleiten ermöglicht. Das passiert zB auch, wenn du einem Container dem Bridge-Netzwerk zuweist. Deswegen geht bei Bridge auch kein IPv6.
 
Die IPv6 Entwickler fanden das total supi, dass es kein NAT mehr gibt, weil das ja eine bessere Performance mit sich bringt. Dass es aber dadurch deutlich komplizierter für den Nutzer wird, hat man einfach ignoriert.
 
Gehe einfach nach der offiziellen Anleitung vor:
https://avm.de/service/vpn/wireguard-vpn-zur-fritzbox-am-computer-einrichten/
 
Sobald der Kumpel verbunden ist, siehst du das in der Fritz!Box an dem Status-Icon. Du könntest es zB mit deinem Handy und einem Laptop testen. Auf dem Handy den Hotspot an machen und den Laptop dann per Wireguard verbinden. Wobei auch das in die Hose gehen kann, wenn dein Handy-Netzbetreiber oder der Hotspot kein IPv6 kann ^^
 
Ach ja, selbes gilt natürlich auch für deinen Kumpel. Wenn der in seinem lokalen Netz IPv6 deaktiviert hat, kann Wireguard keine Verbindung zu deiner Fritz!Box aufbauen.
 
Es gibt auch IPv4, aber nur für Reiche ^^

Der rsync Befehl von mir löscht keine Ordner aus der Quelle. Wenn du aber den Share auf Prefer gestellt hast und den Mover startest, sollte der Mover eigentlich alle löschen. Wenn nicht, dann eben:
 
find /mnt/disk1/appdata -type d -delete
 
 "find" mit "-type d" kann keine Ordner löschen, wo Dateien drin sind, daher besteht da keine Gefahr bei dem Kommando:
 

 
 

Das sind vermutlich virtuelle Docker Laufwerke. 
 
Ich habe noch mal umgebaut:
 
#!/bin/bash while read -r type size usage free percent path; do if [[ $percent =~ (100|9[0-9])% ]]; then logger -t Devices "Error: $path ($type) uses $usage of $size and only $free ($percent) are left!" fi done < <(df -h -B GB | tr -s ' ' | cut -d ' ' -f 1-6)  
 
Wir hatten bisher "type" ausgegeben. Für dich relevanter ist aber "path".
 
Beispiel nun von mir:
Error: /mnt/disk1 uses 17160GB of 17999GB and only 839GB (96%) are left!
Error: /mnt/disk2 uses 17057GB of 17999GB and only 942GB (95%) are left!
Error: /mnt/disk3 uses 16824GB of 17999GB and only 1175GB (94%) are left!
Error: /mnt/disk4 uses 17232GB of 17999GB and only 767GB (96%) are left!
 

Genau das ändert rein gar nichts an dem Problem. appdata ist genau der Share, der NICHT von diesem Tool erfasst wird. Eben weil appdata Dateien mit unterschiedlichsten Rechten enthalten kann.
 
Das könnte es lösen, weil du dann root:root eingestellt hast. Ob Privileged dann überhaupt noch nötig ist, weiß ich gar nicht. Muss man einfach mal testen.

Die mit ASM1166 hat eine Buchse mehr und ist meist mit einem kleinen Blech stabilisiert. Die JMB585 Varianten habe ich bisher nur ohne Blech gesehen.
 
Einen Tod musst du sterben und SATA SSDs sind ja auch schnell genug.
 
Eventuell kannst du einen M.2 SATA Adapter optisch besser positionieren, wenn du mit einem Verlängerungskabel arbeitest:
http://www.adt.link/m2m.html
 
Doch. 12V und 5V sind notwendig. Nur 3.3V braucht man nicht.

Du musst den Container bearbeiten und weitere "path" hinzufügen. Da dann /mnt/disk1 zb

Mangels Support durch AMD laufen alte Ryzen 1xxx CPUs leider nicht sonderlich stabil in Linux:
https://bugzilla.kernel.org/show_bug.cgi?id=196683
 
Ein Workaround ist es die Typical Current Idle im BIOS zu aktivieren oder sogar die C-States vollständig zu deaktivieren. Siehe auch:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-819173
 
Im oben genannten Thread sprechen manche sogar noch von dem Kernel Flag "idle=nomwait". Und manche haben es in Kombination mit Deaktivierung von C6 geschafft (statt gleich alle C-States zu deaktivieren), in dem sie das Kernel Flag "processor.max_cstate=5" gesetzt haben.
 
 
Da musst du dich jetzt leider durchprobieren.
 

Appdata sollte kein SMB Share sein. Zum Bearbeiten von Dateien bietet sich das File Manager Plugin an.

Ja:
Shares beim Cache auf "Yes" stellen, Docker+VM deaktivieren und den Mover starten, damit er die Dateien auf die HDDs verschiebt.
 
Sobald die SSD leer ist, kannst du das Array stoppen / Server herunterfahren und die SSD ausbauen.

In den Voraussetzungen bei GitHub steht, das dass eine GPU voraussetzt?!

Spielt innerhalb von unRAID Einstellungen keine Rolle. 
 
Eher wenn man bestimmte Terminalbefehle verwendet. Zb würde ein "rsync /foo/ /bar/" den Ordner foo unterhalb von bar erstellen, während "rsync /foo/ /bar" nur den Inhalt der Ordner synchronisiert. Oder sagen wir man kopiert eine Datei mit "cp /foo/file /bar" und der Ordner "bar' existiert nicht. Dann würde er die Datei "bar" erstellen, welche die Kopie von "file" ist. Bei "cp /foo/file /bar/" gäbe es dagegen eine Fehlermeldung, dass der Zielordner nicht existiert. Also kommt tatsächlich auf das jeweilige Kommando an.

Was hast du für Board, RAM und CPU? Ich vermute nach wie vor den RAM.

Anmerkung: Die folgende Methode ist unsicher, weil du eine gewisse Zeit ohne Parität agierst, aber das Entfernen eines Laufwerks aus dem Array ist immer mit diesem Problem verbunden. Backups sind grundsätzlich zu empfehlen!
 
Wie ich es machen würde:
- File Manager Plugin installieren
- damit die SSD leeren, also evtl vorhandene Shares auf eine der HDDs verschieben. Falls appdata/system/domain da draufliegen sollte, vorher über Einstellungen Domain und VM auf "Nein" stellen!
- Screenshot von der Disk Übersicht machen
- Tools > New Config und "Pools behalten" auswählen
- dem Array weist du nun die HDDs wie zuvor dem Array zu (dafür der Screenshot)
- damit startest du jetzt erst mal und lässt die Parität neu aufbauen
 
 
Danach:
- Unassigned Devices Plugin installieren und den Destructive Mode aktivieren
- von SSD1 die Partition löschen
- Array stoppen
- Pool erweitern und die partitionslose SSD1 hinzufügen
- Array starten, so dass der Pool erweitert wird
- durch Klicken auf den Poolnamen kannst du das RAID1 Level noch mal verifzieren
 
Tipp: Oben rechts in der Disk Übersicht kannst du auf Transfergeschwindigkeit umschalten. Dann siehst du mit welcher Geschwindigkeit der gerade den SSD Pool in ein RAID1 umwandelt bzw die Parität neu erstellt.
 

Das geht über die Kommandozeile:
https://superuser.com/a/727949/129262
 
Auch könnte man sich über die hosts Datei mehr Hostnamen für den Server hinterlegen, denn pro Hostname darf ein anderer Login verwendet werden. Auch die IP darf einen anderen Login haben.

Das ist nicht möglich?!
 
Sichere Methode:
- Server aus
- eine Platte rausziehen
- eine neue Platte rein
- Server an
- Rebuild starten
 
Das bei jeder Platte wiederholen
 
Unsichere Methode:
- Screenshot von der Disk Übersicht machen
- Tools > New Config > Preserve Pools
- Server aus
- HDDs tauschen 
- alle Disks dem Array wie zuvor zuordnen, nur da wo die kleinen zugewiesen waren jetzt die großen zurodnen 
- starten und dabei die Parität neu erstellen lassen
 
Das ist unsicher, weil es dann solange keinen Ausfallschutz mehr gibt, aber der wäre bei einer Parität eh nicht mehr vorhanden, wenn einen Disk im Rebuild ist. Macht also unter dem Strich keinen Unterschied. Nur wenn man 2 Paritäten hat, wäre die sichere Methode von Vorteil, weil dann noch eine Disk ausfallen könnte.

Die Ports werden meine ich nur angezeigt, wenn der Entwickler des Containers in der Config die Ports auf "exposed" gestellt hat. Du kannst dir aber meine ich selbst die Ports hinzufügen (bearbeiten und unten bei erweitert hinzufügen). Ich meine dann listet er sie in der Übersicht auch auf. Natürlich könnten dann aber auch noch welche auf sein, von denen du nichts weißt. Also eine automatische Erkennung oder sowas gibt es leider nicht.

Schau dir Tools > syslog an
 
Hast du vorher den Parity Check regelmäßig laufen lassen?
 
Was heißt das? Tools > New Config und die Parity als valide markiert als du das Array gestartet hast? Dann sind die Fehler normal, weil sie nicht zur neuen Disk passt. Bedenke, dass die Parity die "Quersumme" aller Daten aller Disks enthält. Wenn du jetzt eine leere ins Array packst, muss er die Parity komplett anpassen, da die neue Disk nur Nullen enthält.

Das sind Container Variablen. Jeder Container hat andere Variablen und viele haben diese gar nicht.
 
Darauf kannst du in der Regel keinen Einfluss nehmen. Wenn ein Container als root läuft, dann hat das in der Regel auch seinen Grund. Allerdings ist dieser root nicht der root von Unraid. Er befindet sich in einer Art chroot-Umgebung, wo alle Ressourcen vom Host-System durch cgroups abgekapselt werden. Das ist eine Kernelfunktion, die die Basis für die Sicherheit in Linux darstellt. Gäbe es da ein Loch, wäre jedes Linux-System unsicher. Also ähnlich fatal als wenn das User-System nicht funktionieren würde und jeder User durch eine Lücke zum root werden könnte.
 
Wegen dem zuvor genannten cgroups Konzept ist das nicht möglich. Jeder Pfad muss explizit übergeben werden.
 
Dein eigentliches Problem ist aber eh, dass der Docker-Dienst selbst als Root läuft. Hat also Docker eine Sicherheitslücke und jemand schafft es auf die Art aus einem Container auszubrechen, so wäre er root auf dem Host-System. Das gilt bisher also nicht möglich, weil keine solche Lücke bekannt ist. Aber in der Theorie wäre das der beste Ansatz um einen Docker Host zu übernehmen.
 
Übrigens lässt Proxmox aus dem Grund die lxc Container als User und nicht als Root laufen. Da ist es noch mal etwas sicherer umgesetzt. Dadurch laufen aber manche Container nicht problemlos. Hat also nicht nur Vorteile. Aber das hat Sicherheit ja nie.
 
Fazit: Du kannst hier nichts optimieren. Du musst darauf vertrauen, dass Docker sicher ist. Natürlich ist nichts sicher, daher muss man abwägen wie viel Komfort man für die Sicherheit opfern möchte. Es gibt ja zB User, die Nextcloud nur per VPN erreichbar machen. Dadurch ist kein Container über das Internet erreichbar und entsprechend wenig Angriffsmöglichkeiten gibt es. Meine Meinung: Backups und mit dem Risiko leben. Kein System ist heute sicher. Außerdem ist man als Privatperson sowieso kein nennenswertes Ziel.

Erstelle mit dem Creator eine neuen Unraid Stick (dadurch wird er bootfähig) überschreib alles mit deinem Backup (wo die Lizenz mit drin ist) Boote mit dem neuen Stick und ein Assistent generiert dir einen neuen Lizenzschlüssel Das geht 1x pro Jahr und deaktiviert die Lizenz des alten USB Sticks.