mgutt

Sieht nach dem Bug aus, dass VMs oder Docker im br0 Netzwerk laufen und Docker bei den Einstellungen auf macvlan steht. Mit ipvlan wird das vermutlich nicht mehr auftreten.

Ok, ich denke das liegt am Browser. Welchen verwendest du? Adblocker oder Popupblocker aktiv? Inkognito-Tab ausprobiert? Mir ist nämlich aufgefallen, dass das Popup ca 1 Sekunde braucht zum Laden. Also schon ungewöhnlich lange. EDIT: Gerade noch mal gedrückt und es dauerte diesmal 10 Sekunden bis das Popup erschien... erneut gedrückt 15 Sekunden, dies mal konnte man kurz die Warnung vom Browser sehen, dass die Seite nicht antwortet. Also da ist in jedem Fall was in Nextcloud 25 verbuggt. EDIT: Diesmal noch länger und ich konnte einen Screen von der Meldung machen:

 
Laut Google Chrome Taskmanager über 60% CPU Last. Da hat jemand wohl irgendwas in Javascript verhauen:

 
Hatte ich eigentlich schon angemerkt, dass meine private NC auf 24 festgesetzt ist? ^^

Fehler. Viele Consumer Boards erlauben keinen Boot ohne GPU. Außerdem schlicht unnötig, weil die CPU dadurch nicht sparsamer ist und du hast niemals die Möglichkeit die iGPU in Containern zu nutzen, um zb Videos schneller verarbeiten zu können.
 

- Screenshot von Disk Übersicht machen
- Tools > New Config und falls Pool vorhanden, diesen anhaken
- Jetzt kann das Array wieder neu mit den Disks zugeordnet werden
 

Nein, nur eine M.2 SATA SSD. Die wird ja wohl hoffentlich keiner kaufen 
 
Ich hatte doch geschrieben, dass der Chipsatz mit X4 angebunden ist und dass die NVMe wiederrum am Chipsatz hängen. Intel nennt das DMI:
https://en.wikipedia.org/wiki/Direct_Media_Interface
 
Ab den 6xx Chipsätzen ist es dann PCIe 4.0 und dadurch 8 GB/s total.
 
Das ist das einzige Problem, was du hast.
 
Ich vermute, dass dd nicht genug parallele Zugriffe generiert, um das Maximum aus der NVMe rauszuholen.
 
Auf die Art erreiche ich 2.2 GB/s:

 
# SSD trimmen fstrim /mnt/cache # ram cache auf 100MB reduzieren sysctl vm.dirty_bytes=100000000 # Zufallsdatei im RAM erstellen (sehr langsam) dd if=/dev/random of=/tmp/10GB.bin bs=128k iflag=count_bytes count=10G # Datei von RAM auf SSD kopieren dd if=/tmp/10GB.bin of=/mnt/cache/10GB.bin bs=1M # Dateien löschen rm /mnt/cache/10GB.bin /tmp/10GB.bin # RAM Cache wieder auf 20% stellen sysctl vm.dirty_ratio=20  

Dann Docker auf Nein stellen und den Mover starten. Erklärt aber immer noch nicht, dass alle Disks hochfahren. Denn so sollte eigentlich nur Disk 3 und Parity betroffen sein. Aber mach das erstmal und dann schauen wir weiter.

Mach doch mit dem User Scripts Plugin ein Script, was alle 15 Minuten oder so, das rclone Kommando ausführt.

Das Laufwerk UNRAID wurde beim letzten Abschalten des Servers nicht ordentlich getrennt. UNRAID ist der USB-Stick.
 
Musste der Server bei dem Neustart hart abgeschaltet werden? Wenn nein, dann stimmt was nicht mit dem Stick.
 
Der Inhalt des Sticks ist auf jeden Fall schon beschädigt. Daher bitte den Stick neu machen und /config aus einem Backup wiederherstellen.

Ist das bei allen absolut gleich?
 
Starte im Safe Mode neu (auf den Flash Stick klicken). Dann startet unRAID ohne Plugins. Oder halt das Plugin löschen und neu starten. Dann weißt du es verbindlich ob es daran liegt.

Bestimmt nicht.
 
Bringt nichts
 
Häh? Die Parität enthält die "Quersumme" aller Datendisks. Wenn du die nullst, sind alle diese Berechnungen natürlich weg, also die Parität leer. Du würdest sie dann komplett neu aufbauen lassen. Das ändert unter dem Strich aber nichts daran, dass sich Daten einfach so ändern.
 
Wenn sich die Daten während dem Betrieb, also ohne Neustart, einfach so ändern, dann kann es eigentlich nur folgendes sein:
- defekter RAM
- defekte CPU
- defekte Sektoren auf einer der HDDs
 
Ich tippe mittlerweile auf Letzteres.
 
Mach mal bei allen HDDs einen erweiterten SMART Test.

Ersetze rsync gegen:
 
cp -a --reflink=always /mnt/user/appdata/$i /mnt/user/appdata/backup/$i
 
Dadurch wird von jedem Container ein lokaler Snapshot erstellt. Das belegt keinen extra Speicherplatz und dauert nur wenige Sekunden pro Container (Ausfallzeit des Containers reduziert sich entsprechend).
 
Nach der Schleife also quasi in die letzte Zeile packst du dann dein Borg create, nutzt da den Quellpfad /mnt/user/appdata/backup und löschst danach die Quelle (wichtig, damit der nächste cp 1:1 ist und keine bereits gelöschten Dateien enthält):
 
rm -r /mnt/user/appdata/backup
 
Achtung: rm kann den gesamten Server löschen, wenn der Pfad entsprechend falsch gesetzt wird. Also immer genau prüfen bevor man rm ausführt.
 
Auch Achtung: der Pfad /appdata/backup sollte natürlich von keinem Container in Verwendung sein. Falls doch musst du logischerweise einen anderen Namen wählen.
 
 

Deine appdata Share Einstellung lautet?
 
Was zeigt Shares > appdata > LOCATION Spalte?
 
Wie sehen deine Docker Einatellungen aus bzw wo liegt Domains (auch LOCATION checken)?

Nein, das unterstützt der Container nicht und ich sehe auch keinen Sinn darin. Warum sollte man das ändern?

Jo, -1 deaktiviert das wohl. Wäre ein Versuch wert die Kernel Option zu ändern.
 
https://wiki.unraid.net/Boot_Codes

Korrekt. Sofern der entsprechende Share auf Prefer steht.
 

777 bzw drwxrwx--- ist in jedem Fall richtig. Ist bei mir auch so. Aber jetzt sehe ich was. Warum gehört dein /data Ordner dem User 99 und der Gruppe 100?!
 

 
Bitte wie folgt korrigieren:
 
chown 33:33 /mnt/user/nextcloud  
 

Laut hier ist quick standardmäßig an:
https://serverfault.com/a/547439/44086
 
Genau.
 
Kannst du machen wie du lustig bist. Die IP kannst du ja in der config.php ändern.
 
Für die Zukunft solltest du dir das Backup appdata Plugin anschauen 

find ist tatsächlich live. So etwas wie einen Index gibt es in Linux nur mit "locate" und das gibt es wie gesagt nicht in unRAID. Aber find ist halt Bombe schnell, wenn die Dateistruktur schon mal eingelesen wurde. Dann liegt sie ja im RAM.

Guckst du:
https://forums.unraid.net/topic/123730-vm-mit-eigener-img-datei/?do=findComment&comment=1128398

Ich vermute du hast Hot Swap aktiv. Dann könntest du das Array stoppen, die Platten ziehen und das Array starten. Danach steckst du Disk5 und Disk6 wieder rein. Nun sollten sie in UD zu sehen sein und von da könntest du dann auch bei Bedarf die Daten wegkopieren.
 
Wie gesagt könntest du auch über Tools>New Condig gehen und alle Disks neu zuordnen. Dadurch wird nichts rebuildet und es gehen auch keine Daten verloren. Das würde ich aber wie gesagt erst machen, wenn SMART und XFS repair durch ist. Einfach damit du sicher weißt, dass die Disks alle in Ordnung sind.

Das wird wegen SMB1 irgendwann eh nicht mehr gehen. Also dann muss man vermutlich eh einen Docker als Brücke nehmen oder seine SMB Config manuell unsicher machen.
 
a) warum nicht?
b) ich hab erst gar keine Laufwerke verbunden. Meine Frau darf auf die Verknüpfung zur Netzwerkumgebung des Servers klicken. Dann sieht sie ja alle Ordner wo sie drauf will. Was ein Netzlaufwek ist, weiß sie eh nicht. Am liebsten hätte ich das auf der Arbeit auch so. Support Anfragen wegen "Laufwerk X mit dem Namen Archiv geht nicht" und man weiß nie auf welchen SMB Server und welchen Unterordner die eigentlich zugreifen wollen ^^
 

Das ist der einzige Prozess, der zu dem Zeitpunkt auf dem Kern läuft. kworker ist ein Kernel-Prozess. Wir wissen allerdings nicht was der tut. Siehe auch:
https://www.linux-magazin.de/ausgaben/2016/01/kern-technik/
 
Spontan würde ich sagen:
- Reparatur auf allen Disks und Pools durchführen
- memtest durchführen 
 
 

https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/?do=findComment&comment=1011152

Das ist kein Fehler, nur ein Hinweis:
 
https://forums.unraid.net/topic/126828-suppress-mcelog-does-not-support-this-processor-error-message/#comment-1155640
 

Image platzsparend machen (Pfad vervollständigen):
 
fallocate -d /mnt/disk1/domains/../vdisk1.img
 
Platzsparendes Backup machen (Pfade vervollständigen):
 
cp --sparse=always /mnt/disk1/domains/../vdisk1.img /mnt/disk1/domains/../vdisk1.backup.img
 
Image verkleinern (Pfad vervollständigen):
 
qemu-img resize --shrink /mnt/disk1/domains/../vdisk1.img 80G
 
VM starten und Partition vergrößern.
 
Wenn alles läuft Backup löschen (Pfad vervollständigen):
 
rm /mnt/disk1/domains/../vdisk1.backup.img
 
Für die Zukunft solltest du VM Backup installieren oder anderweitig Backups erstellen.