mgutt

Mach es so wie es das Menü anbietet. Wenn du auf Nummer sicher gehen willst:
deaktiviere den Docker Dienst
deaktiviere den VM Dienst
kopiere alle Dateien vom USB Stick
Falls was nicht wie gewünscht geklappt hat, einfach das Backup auf den Stick schreiben und du bist nach einem Neustart wieder bei 6.12.0-RC3

Liegt da bei dir noch eine wg1 File herum?

root@horus:~# find /boot -name "*wg*" /boot/config/wireguard/wg0.conf /boot/config/wireguard/wg0.cfg /boot/config/wireguard/peers/peer-horus-wg0-1.conf /boot/config/wireguard/peers/peer-horus-wg0-1.png

Es gibt ein Plugin dafür:
https://forums.unraid.net/topic/114415-plugin-docker-compose-manager/

Wenn man eine Parität hat, darf nur eine Platte ausfallen. Der Rebuild braucht dann alle restlichen Platten. Wenn du also zwei defekte Platten hast, sind die Daten einer komplett defekten Platten verloren.

Wenn du ohne Rebuild auf die Daten von Disk 5 zugreifst, dann werden diese Daten über die restlichen Disks emuliert. Dh du bist auch dann voll von Disk 6 abhängig.

Bei defektem RAM kommt noch dazu, dass die Paritätsplatte selbst völlig falsche Daten enthalten könnte. Dann würde nicht mal mehr der Rebuild mit einer defekten Platte gehen.

Und das ganze kann noch schlimmer werden: Sagen wir, dass wegen defektem RAM die Parität hinüber ist. Disk5 hat kurz die Verbindung verloren und du startest mit verfälschten Daten der Paritätsplatte den Rebuild von Disk 5: Auch Disk 5 Daten gehen kaputt.

Das gleiche Spiel gilt übrigens auch, falls Disk 6 aktuell kompletten Unsinn zurückgeben sollte. Dann würde der Rebuild von Disk 5 mit Unsinn-Daten erfolgen = Disk 5 wird kaputt geschrieben.

Daher würde ich jetzt gar nichts mehr mit Rebuild oder Emulation versuchen. Deine einzige Rettung sind die echten Daten von Disk 5, in der Hoffnung, dass der Rebuild die Disk nicht noch zerlegt hat. Du darfst ja nicht vergessen: Disk 5 hatte zwar Lesefehler, aber die Daten auf Disk 5 sind ja nativ vorhanden. Ein Rebuild überschreibt nur einfach die Daten, die bereits drauf sind. Das macht Unraid aus Sicherheitsgründen, weil zwischen dem Lesefehler und dem aktuellen Zeitpunkt, könnten ja weitere Daten auf Disk 5 hinzugekommen sein. Wenn du das aber ausschließen kannst, dann interessieren dich eigentlich nur die Daten, die eh schon drauf sind.

Was ich also machen würde:
erst mal RAM testen und dann nur garantiert fehlerfreien RAM verwenden
Array stoppen und nicht mehr starten (Autostart in Disk Settings deaktivieren)
Docker deaktivieren
VM deaktivieren
Screenshot von der Disk-Übersicht machen, damit du weißt, welche Disk wo zugewiesen war
unter Tools > New Config die Pools behalten auswählen und dann bestätigen
jede Disk kann nun einzeln mit dem Unassigned Devices Plugin READ-ONLY (!) gemountet werden
Nun kopierst du alle Daten von Disk 5 auf eine neue HDD (neue HDD, denn Disk 6 kannst du wegen der Lesefehler nicht nehmen und die Paritätsdisk würde ich mir erst mal aufheben)
sollte das fehlerfrei funktionieren: vermutlich ist die Disk 5 noch in Ordnung, das ganze mit allen anderen Disks wiederholen, bis du alle mit Fehlern ermittelt hast
falls zB Disk 1 in Ordnung sein sollte: Ausbauen und an dem Anschluss eine defekte Disk anschließen (vielleicht ist nicht die Disk kaputt, sondern das Kabel?!)
vielleicht ist die Disk auch nicht kaputt, sondern die Kühlung mangelhaft?! Ich hatte schon mal CRC Fehler als eine meiner HDDs über 50 Grad erreicht haben.
falls eine fehlerhafte Disk gefunden wurde zB weil nicht alle Dateien kopiert werden können oder sie gar nicht mehr zu mounten ist. In dem Fall nicht weiter herumspielen, sondern gleich eine Datenrettung versuchen: https://www.ufsexplorer.com/ufs-explorer-standard-recovery/ (nicht über USB, sondern nativ SATA!)
Falls Disk 5 und Disk 6 komplett hinüber sein sollten:
Wenn auf Disk 6 noch nie Daten waren (also nicht eine einzige Datei!!!) und der RAM die Parität nicht beeinflusst hat und wenn alle anderen Disks nicht mehr verändert werden (nur noch mit READ-ONLY auf alle Disks zugreifen!!!), könntest du auch versuchen zwei neue HDDs zu kaufen. Irgendeine Beliebige als Ersatz für Disk 5 und exakt die gleiche (!) als Ersatz für Disk 6. Disk 6 bereitest du dann mit dem Unassigned Devices Preclear Plugin vor. Das Plugin schreibt auf diese neue Disk 6 alles voller Nullen. Wichtig: Wieder mit XFS formatieren. Nun das Array exakt so zuzuweisen, wie es vorher war, nur das die Ersatz HDDs dann in Disk 5 und Disk 6 zugewiesen werden. Beim Start wählt man dann, dass die Parität NICHT neu gebaut werden soll, sondern dass man der bestehenden Parität vertraut. Der Rebuild bzw die Emulation von Disk 5 erfolgt dann mit der "alten" Partität, allen anderen alten Disks und der nagelneuen Disk 6 (auf der nur Nullen enhalten sind). Falls doch mal Daten auf Disk 6 lagen, wird der Rebuild nicht komplett erfoglreich passieren. Dann werden ein Teil der Dateien korrupt sein oder das ganze Dateisystem nicht lesbar sein. Das hängt ganz davon ab wie viele Daten auf Disk 6 mal lagen. Ich würde in dem Fall dann diese neu erzeugte Disk 5 auch noch mal mit der oben gennnten Datenrettungssoftware behandeln. Jedenfalls ist das wirklich der letzte Strohhalm und jeder Fehler führt zum Totalverlust.

Wenn du durch bist und neu mit einem Array starten willst:
wieder über New Config und Pools behalten das Array leeren
Paritätsdisk wieder dem Paritätsslot zuweisen, der Rest kann beliebig oder gleich zugeordnet werden
diesmal die Parität neu bauen lassen
Für die Zukunft:
niemals defekten RAM verwenden
eine Parität ist kein Backup
evtl über zusätzlichen Backup-Server für die wichtigsten Daten nachdenken
oder zumindest auf eine separate Disk des Arrays die wichtigsten Daten kopieren Dh wenn sehr wichtige Daten auf Disk 1 liegen, diese regelmäßig zB auf Disk 7 kopieren. Solange nicht diese beiden parallel ausfallen, ist alles fein.

Ja das wird wie bereits gesagt daran liegen, dass über SMB die Dateien erst auf den Client herunter- und dann wieder hochgeladen werden. Dadurch wechseln die dann auch auf die korrekte Disk.

Das ist egal. Es wäre nur wichtig, wenn du die Karte an eine Windows VM durchschleifen würdest und diese mit einem UEFI BIOS bootest. Dann setzt Windows voraus, dass auch alle Komponenten im EFI Modus laufen. Unraid scheint das egal zu sein und akzeptiert beides.

Ich vermute du hast das selbe Problem:
https://forums.unraid.net/topic/108659-supermicro-ipmi-bildschirm-lässt-sich-nicht-aufwecken/

Um Unassigned Devices zu mounten, installiert man sich da Unassigned Devices Plugin aus den Apps.
 

 
Um Dateien im Browser verschieben zu können, nutzen denke ich die meisten Krusader. Der von ich777 ist meine ich auf Deutsch nutzbar:

 
Unraid möchte schlank sein und überlasst daher viele Funktionen den Apps und Plugins. So kann sich jeder sein System individualisieren.
 

Nein. Das Skript sollte immer auf dem Remote ausgeführt werden, also abholen. Allerdings sollte man dabei root-Rechte auf dem Quellserver besitzen. Da man aber auf keinen Fall den Unraid root User remote nutzen sollte, empfehle ich den rsync Container zu verwenden um die entsprechenden Pfade nur read-only verfügbar und nur dessen SSH Port erreichbar zu machen.
 
Grundregeln:
- auf der Remote Maschine ausführen
- keine /mnt/user Pfade nutzen (um Unraids Overhead zu umgehen)
- rsync über SSH verbinden und nicht zb nicht per SMB oder sshfs gemountete Pfade verwenden
 
Ich kann dir in dem Punkt nicht folgen was du nun wirklich machst, wenn es langsam ist. Das Skript von chatgpt ist ja nicht inkrementell?!
 
 

Kann denke ich nur am Stick oder UEFI/BIOS Boot liegen. Wenn zb nur UEFI unterstützt wird, darf der EFI Ordner keinen Unterstrich enthalten. Wird aber auch bei der Installation des Sticks abgefragt. Was hat das BIOS hier alles für Einstellungen? Geht nur UEFI oder auch CSM?

Dann sag doch nicht, dass das Caching geht. Die CSS Dateien werden nicht gecached und machen ja mal locker 12 Sekunden aus.
 
Das ist nicht der offizielle Container. Der offizielle Container ist dieser:
https://hub.docker.com/_/nextcloud/
 
Dieser wird aber (noch) nicht über die Unraid Apps angeboten und muss von Hand eingestellt werden.
 
Ich habe mal den LSIO Nextcloud Container installiert. Dabei ist mir aufgefallen, obwohl die HTTP Header alle korrekt sind und ich nicht F5 drücke, sondern durch die Seiten klicke, dass er die Stylesheet Dateien manchmal cached und manchmal nicht. Daraufhin habe ich mal recherchiert und bin auf diesen interessanten Kommentar gestoßen:
Da der LSIO Container ausschließlich den Zugriff über Port 443, also https erlaubt, können wir es nicht verizieren, ob es bei Port 80, also http, funktionieren würde, aber wenn die Aussage stimmt, dann klappt das Browser-Caching nur dann zuverlässig, wenn man ein korrektes SSL Zertifikat verwendet. Das können wir schon mal im Hinterkopf behalten.
 
Trotzdem ist dein Webserver sehr langsam. 2 Sekunden für eine statische Textdatei, was ja eine Stylesheet Datei ist, ist viel zu lang. Soweit ich das richtig sehe, verwendet der LSIO Container nginx und nginx braucht eigentlich kaum Ressourcen und sollte von deiner CPU spielend gestemmt werden. Allerdings habe ich eine Vermutung, die trotzdem mit deiner CPU zusammenhängt:
 
Beim Installieren von Containern, landen die Container-Dateien im /mnt/user/system/docker/docker.img. Dieses Image ist ein BTRFS Dateisytem und wird unter /var/lib/docker/ gemountet. Allerdings läuft der Pfad /mnt/user durch Unraids SHFS Prozess, der sicherstellt, dass das docker.img sowohl auf dem Cache als auch auf einer Disk des Arrays liegen kann. Dieses Konstrukt ist relativ "kompliziert" und kann eine eine hohe Last auf der CPU verursachen. Mein Vorschlag wäre, sofern deine Shares appdata und system immer auf dem Cache liegen, dass du folgendes probierst:
 
1.) Docker stoppen
2.) Im Terminal das ausführen:
sync; echo 1 > /proc/sys/vm/drop_caches
3.) In den Docker-Einstellungen /mnt/user/system/docker/docker.img in /mnt/cache/system/docker/docker.img ändern
4.) Den Nextcloud-Container bearbeiten und den "AppData Config Path" von /mnt/user/appdata/nextcloud in /mnt/cache/appdata/nextcloud ändern (nicht den "Host Path 2", wo die hochgeladenen Dateien landen)
5.) Den MariaDB-Container bearbeiten und den "AppData Config Path" von /mnt/user/appdata/mariadb in /mnt/cache/appdata/mariadb ändern
6.) Docker starten
 
Jetzt wird das docker.img nicht mehr durch den SHFS Prozess gejagt, sondern es wird beim Mounten direkt auf die Cache-Disk zugegriffen. Auch laufen die ganzen Nextcloud-Dateien und die Datenbank-Abfragen nicht mehr durch SHFS. Das sollte einiges an Last von der CPU nehmen.
 
Das selbe kannst du natürlich mit jedem Docker-Container machen, aber beachte, dass wenn du die SSD irgendwann ersetzt, dass du den Docker-Dienst erst wieder startest, wenn alle Dateien wieder auf der neuen SSD liegen. Ansonsten installieren sich die Container alle neu, weil sie nichts von evtl Dateien auf dem Disk-Array wissen, da der Pfad /mnt/cache wirklich nur auf die SSD abzielt. Auch darfst du niemals den Cache von system und appdata deaktivieren und den Mover starten während der Docker-Dienst noch läuft. Ansonsten verschiebt der Mover die Dateien auf das Disk-Array und die Container finden sie nicht mehr, weil sie nur den Pfad der SSD kennen.
 
Und natürlich gilt: Erst mal Backup machen und Nutzung auf eigene Gefahr ^^

Einfach Ordner löschen würde ich nie machen. Das docker.img kann gelöscht werden, wenn du jetzt mit der Verzeichnis-Methode arbeitest.
 
Bei dem Rest würde ich prüfen, ob Dateien nicht versehentlich doppelt vorhanden sind. Also auf Cache und Disk. Also die Ordner öffnen und soweit durchklicken bis du zu Dateien kommst. Wenn zB das libvirt.img auf cache und diskX wäre, müsste man herausfinden welche die aktuell genutzte ist. Ansonsten wird keine VM mehr hochfahren.

Kann es sein, dass er gar nicht ssh, sondern den rsync daemon ansprechen möchte? Also ist rsync;// wirklich richtig? Dein rsync server spricht aktuell nur ssh.

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