mgutt

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

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.