mgutt

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.

Nein ich meine data. Steht auf RAID1. Also alles gut.
 
Ja. unRAID unterstützt aktuell nur BTRFS bei RAID Pools. Bald soll ZFS folgen.
 
Das ist nicht so. Pools und Array haben vom Prinzip rein gar nichts miteinander zu tun. unRAID steuert das nur so, dass zb beim Hochladen von Dateien, diese auf dem Pool erstellt werden. Der Mover verschiebt die Dateien dann später auf das Array. Und je nach Cache Einstellung des Shares, werden die Dateien in die eine oder andere oder gar nicht verschoben.
 
Aber selbst im Array ist das Dateisystem egal. Man kann dort zb auch XFS und BTRFS mischen, weil die Parität einfach nur die "Quersumme" aus den Bits aller Platten enthält. Das Dateisystem spielt dabei keine Rolle.

Nichts. Sind nur Warnungen und irrelevant. 

This the default behavior of IPv6 assignment:
https://ben.akrin.com/mac-address-to-ipv6-link-local-address-online-converter/

 
 
If you start a container, it gets a "random" MAC address (MACVLAN) from docker. This mac address can be obtained through "docker inspect":
root@Tower:~# docker inspect rsync-server | grep -A100 NetworkSettings "NetworkSettings": { ... "Gateway": "192.168.178.1", "IPAddress": "192.168.178.128", "IPPrefixLen": 24, "IPv6Gateway": "2003:xxxx:xxxx:xxxx::1", "GlobalIPv6Address": "2003:xxxx:xxxx:xxxx::2", "GlobalIPv6PrefixLen": 64, "MacAddress": "02:42:c0:a8:b2:80",  
So my container has the MAC address "02:42:c0:a8:b2:80". As there is an algorithm, which builds an IPv6 suffix based on this MAC address, the container now has the following additional IPv6 addresses:
946e7e921b50:~# ifconfig eth0      Link encap:Ethernet  HWaddr 02:42:C0:A8:B2:80             inet addr:192.168.178.128  Bcast:192.168.178.255  Mask:255.255.255.0           inet6 addr: 2003:xxxx:xxxx:xxxx:42:c0ff:fea8:b280/64 Scope:Global           inet6 addr: 2003:xxxx:xxxx:xxxx::2/64 Scope:Global           inet6 addr: fe80::42:c0ff:fea8:b280/64 Scope:Link ...  
As you can see my container now has three IPv6 addresses. Two of them are based on the MAC address, which resulted in "42:c0ff:fea8:b280". This allows us to forward the ports 80/443 to this suffix. But this won't be stable if you need to remove the docker.img, which can cause a different MAC address for each container.
 
But I found a solution for this!
 
We enable the advanced view and pass the "--mac-address 00:00:00:00:01:28" as extra parameter:

 
While in the fixed IP address field we only set the IPv4:

 
Again, additional IPv6 are added based on the mac-address and our container is permanently reachable through the suffix "200:ff:fe00:128", even if we need to delete the docker.img!
 

 
 
I played a little bit around and the shortest suffix I was able to produce, was by using a MAC-address like the following:
--mac-address 02:00:00:0F:00:09 --mac-address 02:00:00:0F:00:10 ...  
It returns this suffix:
::0:ff:fe0f:9 ::0:ff:fe0f:10 ...  
I tested it with an rsync-server container and made it public through port 22 (never forward this port, this is only for testing!) in my router and it works flawlessly:

 

 
 
Thanks @Omri for the inspiration!
 
 
 

Nun da wird irgendwas abgeschmiert sein. Also Logs checken.

Blöd ist, dass wir jetzt nicht wissen was passiert ist. Aber da der RAM in Ordnung ist, würde ich sagen eine Platte nach der anderen tauschen. 
 
Ich vermute aber, dass die Platten, die du entfernst auch in Ordnung sind und eher was mit der Kabelverbindung oder so war. Aber dann hast du zumindest ein Backup.
 

Ja das geht. Die bekommen jeweils eine feste IP aus komplett anderen Adressereichen. Zb hat dein Router 192.168.178.x. Dann würdest du den 10G Netzwerkkarten zb 192.168.168.1 und 192.168.168.2 geben. Oder 10.0.0.1 und 10.0.0.2. eben eine aus einem privaten Adressraum:
https://de.m.wikipedia.org/wiki/Private_IP-Adresse
 
 

Häh? Die Platte wird doch emuliert. Also file Manager Plugin und auf eine andere kopieren. Fertig.

Ich tippe darauf, dass deconz einen Port aufmacht, der dann später nicht mehr offen ist und den Plex auch verwendet. Oder für deconz ist dieser Port nicht so wichtig.
 
Da deconz im Host Netzwerk läuft, kannst du nicht sehen welche Ports wirklich davon geöffnet wurden. Ich hatte dazu mal einen Codeschnipsel gepostet, aber ob ich den wieder finde...
 
Vom Prinzip wäre denke ich die schnellste Methode:
 
- alle Container stoppen
- ausführen: ss -tulpn
- deconz starten und ausführen: ss -tulpn
- deconz stoppen
- Plex starten und ausführen: ss -tulpn
 
Alle Ergebnisse der offenen Ports vergleichen.
 
Die USB Fehlermeldung kann ignoriert werden. Damit hat das nichts zu tun. Plex hat auch gar keinen Zugriff auf USB (außer du hast explizit devices übergeben):
https://forums.plex.tv/t/critical-libusb-init-failed/722159/3
 
 

Diese Einstellungen werden auf dem USB Stick gespeichert. Wenn es also häufiger passiert, dann wegen dem Stick.

Naja SMB? Also ganz normale Unraid Shares?

Was kannst du sichern? Also fehlen nur einzelne Dateien aus /config und wenn ja welche? Vom Prinzip brauchst du nur die key file, aber dann musst du natürlich deine Einstellungen alle neu machen und die Containeränderungen, sofern du welche gemacht hast (zb Pfade geändert oder ähnpich), wären auch zu wiederholen. Wobei man selbst die Key File nicht unbedingt braucht. Limetech kann dir auch deinen Key wiederherstellen, wenn du ihn verloren hast.

Kauf den richtigen RAM und es gehen 32GB:
https://www.hardwareluxx.de/community/threads/asrock-j5005-itx-mit-32gb-ram-machbar.1285458/