mgutt

Das ist kein Disk Share, sondern ein User Share. Nur weil ein User Share auf einer einzigen Disk abgelegt wird, wird daraus kein Disk Share. Disk Shares sind der direkte Zugriff auf die Disk mit allen darin enthaltenen User Shares. zB habe ich den User Share "Marc", der auf Disk 6 liegt: Der Disk Share /mnt/disk6 hätte aber nicht nur Zugriff auf den User Share "Marc", sondern auf alle User Shares, die auf dieser Disk liegen: Also noch mal: /mnt/diskX = Disk Share /mnt/user/sharename = User Share

Wie gesagt. Deine Krusader Config ist "falsch". Du musst /mnt mit /mnt verlinken. Dann sieht es auch in Krusader richtig aus. Nein. Disk Share Pfade sind das: /mnt/disk1/ /mnt/disk2/ /mnt/poolname/ Und sie werden in den Global Share Settings separat aktiviert: User Shares sind das: /mnt/user/sharename (dessen Dateien sich wiederrum auf /mnt/disk1/sharename, /mnt/disk2/sharename und /mnt/poolname/sharename verteilen können) /mnt/user/sharename2 (dessen Dateien sich wiederrum auf /mnt/disk1/sharename2, /mnt/disk2/sharename2 und /mnt/poolname/sharename2 verteilen können) Manche arbeiten ausschließlich mit Disk Shares, da dann die Performance noch etwas besser ist. Man muss aber wissen was das bewirkt. zB mache ich das nicht, weil ich nicht einem User eine komplette 18TB Festplatte zuweisen will (/mnt/disk1/), sondern eben nur einen Unterordner auf der 18TB Festplatte (/mnt/disk1/sharename). Mehreren Usern eine Disk zuweisen, würde ja sonst heißen, dass jeder User bei jedem User in den Dateien rumfummeln kann. Also Disk Shares gehören zur Kategorie "Unraid Experte" 😉

Ja korrekt. Die fehlen komischerweise. x steht für Execution Recht. Erste Block ist der User, zweiter die Gruppe und die letzte alle Gäste. Standardrecht ist 777, also alle dürfen alles: https://chmod-calculator.com/ Mich wundert das Unraid nun 666 gesetzt hat: Denn die erste Ebene unter /mnt wird ja beim Booten erst erstellt. Du kannst mal versuchen die Rechte wie folgt zu korrigieren, aber ich befürchte fast, dass das keinen Reboot überlebt: chmod 777 /mnt/* Damit werden nur paar Ordner in /mnt aktualisiert. Also nicht rekursiv alle Unterordner darunter. Der Befehl ist also in einer Sekunde durch. Klappt der Befehl? Werden die Shares nun wieder angezeigt? Wenn ja, bitte neu starten und schauen ob das dann auch noch so ist.

Das bezweifle ich. Normal ist es so: /mnt/user/sharename oder: /mnt/disk1/sharename /mnt/disk2/sharename usw Wenn Du in Krusader auch die Pfade "remotes" usw siehst, dann hast du vermutlich das: In das geändert: Dadurch sehen die Pfade bei dir im Krusader nun "falsch" aus, sind aber nach wie vor richtig. "Korrekter" wäre es so gewesen: Dann hättest du die Pfade 1:1 so gesehen, wie sie normalerweise in Unraid heißen. Das hat aber alles nichts mit deinem aktuellen Problem zu tun. Ist nur ein Darstellungs"fehler".

Das sind die Original Einstellungen und die können auch so bleiben. Also egal ob die Dateien schlussendlich auf dem Array oder Pool liegen. /mnt/user verweist immer auf den Inhalt aller Disks, die diesen Share-Ordner enthalten. Genauso hatte ich es hier gemeint (2. Absatz): https://forums.unraid.net/topic/111205-backupmethoden/?tab=comments#comment-1013822 Aber wie gesagt. Jetzt erst mal Schritt 1 und die SSD aus dem Array bekommen. Das habe ich ehrlich gesagt noch nie gemacht, also von BTRFS zu XFS. Ich vermute, du musst dafür die Festplatte aus dem Array rausnehmen (also wie gehabt mit New Config) und dann mit Unassigned Devices die Platten formatieren. Natürlich vorher alles extern sichern, weil dadurch natürlich alles der Platte gelöscht wird. Hast du sie dann wieder dem Array hinzugefügt, wird Unraid die Platte entsprechen der Disk Setting dann in XFS formatieren (nicht vergessen umzustellen!). Und dann kannst du die Platte wieder aus deinem Backup befüllen. Den Cache dieser Shares würde ich übrigens solange deaktivieren. Die NVMe werden sonst unnötig abgenutzt.

system ist der Standard-Share für das docker.img und libvirt.img

Da dort vermutlich /mnt/nvme_pool_name drin steht, kannst du das so lassen. Mein Pool heißt zB cache und mein Pfad entsprechend auch: Der ändert sich ja nicht, außer du willst den Pool neu erstellen und gibst ihm einen anderen Namen oder du willst die NVMe auf das Array leeren, aber dann machst du ja eh den VM Dienst hoffentlich aus 😉

/mnt/user/appdata verursacht mehr CPU Last als /mnt/diskX/appdata oder /mnt/pool_name/appdata, aber das soll dich jetzt erst mal nicht stören. Nach dem Umzug der Dateien kannst du das problemlos erneut ändern. Falls alle Docker Container verschwinden: Keine Angst, über Apps > Previous Apps kannst du sie wieder mit deinen Einstellungen starten. Normalerweise sollte aber alles so bleiben wie es ist. Wichtig ist nur, dass während dem Verschieben der Dateien kein Docker läuft. Und wenn du auch die VM Images bewegen solltest oder die ISOs oder die virtio Treiber Datei, dann natürlich auch den VM Dienst solange inaktiv lassen. Erst wenn du weiß, dass alles da ist, wo es hin soll, kannst du die Dienste wieder starten.

Du hast einen Ordner "disk1" unter "user"? Das wäre ungewöhnlich. Normalerweise ruft man die disks über /mnt/diskX auf. Und die User Shares (die sich ja auf mehreren Disks verteilen können) über /mnt/user/sharename. In den Grundeinstellungen hat Krusader keinen Zugriff auf die Disks. Nur auf User Shares. Das sollten wir denke ich in den Griff bekommen können. Kann es sein, dass du auch die User-Rechte von /boot versehentlich geändert hast? Also vom USB Stick? Vergleich mal mit meinem Ergebnis: ls -la /boot/config total 1280 drwx------ 11 root root 32768 Jul 10 17:31 ./ drwx------ 8 root root 32768 Jan 1 1970 ../ -rw------- 1 root root 256 Jun 21 08:55 Plus.key -rw------- 1 root root 8797 Jul 8 14:38 disk.cfg -rw------- 1 root root 8812 Jun 21 10:13 disk.old -rw------- 1 root root 370 Jul 8 14:06 docker.cfg -rw------- 1 root root 280 Jul 10 17:31 domain.cfg -rw------- 1 root root 8 Jul 8 11:07 drift -rw------- 1 root root 119 Jun 21 08:55 flash.cfg -rw------- 1 root root 0 Jul 8 14:38 forcesync -rw------- 1 root root 2724 Jun 30 09:05 go -rw------- 1 root root 2682 Jun 30 09:05 go.bak -rw------- 1 root root 662 Jul 8 14:37 ident.cfg -rw------- 1 root root 33 Jun 21 08:55 machine-id drwx------ 2 root root 32768 Jun 21 08:55 modprobe.d/ -rw------- 1 root root 375 Jun 21 10:12 network-rules.cfg -rw------- 1 root root 424 Jun 21 10:10 network.cfg -rw------- 1 root root 1356 Jul 5 13:07 parity-checks.log -rw------- 1 root root 1497 Jun 21 08:55 passwd drwx------ 25 root root 32768 Jul 10 13:42 plugins/ drwx------ 2 root root 32768 Jun 21 08:55 plugins-error/ drwx------ 2 root root 32768 Jul 8 22:29 plugins-removed/ drwx------ 2 root root 32768 Jun 21 08:55 pools/ -rw------- 1 root root 512 Jul 8 14:36 random-seed -rw------- 1 root root 168 Jun 21 08:55 rsyslog.cfg -rw------- 1 root root 3591 Jun 21 08:55 rsyslog.conf -rw------- 1 root root 1138 Jun 21 08:55 shadow -rw------- 1 root root 575 Jun 21 08:55 share.cfg drwx------ 2 root root 32768 Jul 7 12:05 shares/ -rw------- 1 root root 94 Jun 21 08:55 smart-one.cfg -rw------- 1 root root 999 Jul 8 14:38 smb-extra.conf -rw------- 1 root root 626 Jun 21 08:55 smbpasswd drwx------ 3 root root 32768 Jun 21 08:55 ssh/ drwx------ 3 root root 32768 Jun 21 08:55 ssl/ -rw------- 1 root root 4096 Jul 5 13:06 super.dat -rw------- 1 root root 4096 Jun 21 08:55 super.old drwx------ 2 root root 32768 Jun 21 08:55 wireguard/ root@thoth:~# Die Rechte deiner gemounteten Laufwerke sollten eigentlich nach einem Reboot wieder sauber sein: ls -la /mnt total 0 drwxr-xr-x 15 root root 300 Jul 10 17:33 ./ drwxr-xr-x 20 root root 460 Sep 28 2020 ../ drwxrwxrwx 5 nobody users 120 Jul 10 17:33 RecycleBin/ drwxrwxrwx 7 nobody users 110 Jul 8 14:48 cache/ drwxrwxrwx 4 nobody users 31 Jul 8 14:48 disk1/ drwxrwxrwx 3 nobody users 19 Jul 8 14:48 disk2/ drwxrwxrwx 3 nobody users 19 Jul 8 14:48 disk3/ drwxrwxrwx 3 nobody users 19 Jul 8 14:48 disk4/ drwxrwxrwx 4 nobody users 29 Jul 8 14:48 disk5/ drwxrwxrwx 14 nobody users 212 Jul 9 19:01 disk6/ drwxrwxrwx 3 nobody users 20 Jul 8 14:48 disk7/ drwxrwxrwt 2 nobody users 40 Jul 8 14:37 disks/ drwxrwxrwt 2 nobody users 40 Jul 8 14:37 remotes/ drwxrwxrwx 1 nobody users 31 Jul 9 19:01 user/ drwxrwxrwx 1 nobody users 31 Jul 9 19:01 user0/

Dass der Cache ebenfalls aktualisiert wird, ist doch vollkommen richtig?! Die einzigen sensiblen Rechte betreffen /mnt/user/appdata und der Share ist ja vom Tool ausgeschlossen.

Genau. Eventuell schaust du auch noch mal, dass keiner der Container direkt auf die SSD im Array verlinkt also zB einen Pfad wie /mnt/diskX/appdata/containername verwendet. Da sollte überall /mnt/user/appdata stehen. Am besten bei den Docker Containern die VOLUME MAPPINGS mal alle aufklappen. Ach ja. Das gilt natürlich auch für den Share "system". Dort liegt ja das docker.img. Das würde ich auch auf den Cache Pool verschieben.

Ach so, ich dachte du hast von einer SATA Karte gesprochen, die dein Board um weitere SATA Buchsen ergänzt. Na hoffentlich funktioniert die Reparatur. Stelle ich mir schwierig vor mit den Flachbandkabeln usw.

Wenn du das mit dem SSL Zertifikat hinbekommst, könntest du in den Advanced Settings das eintragen: server_name *.duckdns.org; Oder man bearbeitet mit "nano /mnt/user/appdata/npm/data/nginx/proxy_host/1.conf" die entsprechende Config Datei?!

War die Hardware kostenlos? Knapp 1200 Single Passmarkt Punkte sind ja mal gar nichts: https://www.cpubenchmark.net/cpu.php?cpu=AMD+Opteron+6380&id=2498&cpuCount=2 Der Verbrauch dürfte auch heftig sein oder ist der nicht so wichtig?

Benutz Tools > Docker Safe New Perms und gut ist. Wenn du Fix Common Problems installiert hast, kannst du bei Bedarf auch Verzeichnisse ausschließen:

Wieso? Das Tool der GUI führt sich auch nur diese Kommandos aus.

Müssen Verzeichnisse nicht 777 haben?! Meins:

Nur als Info: Der Nginx Proxy Manager macht das automatisch 😉

Nach deinem Beitrag musst du wohl eher drauf legen 😅

1x groß und 1x klein?!

Die meisten nutzen das Fractal Define R5. Auch gut ist das Nanoxia Silence 4. Kommt auch drauf an wie groß dein Board ist. Welchen hast du bestellt? Nein, das passiert nur bei "Yes". Bei "Prefer" verbleiben sie auf dem Cache: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=951565

Prüfe mit "ls -la /mnt/user/deinpfad" welche Rechte die Dateien / Ordner haben.

Ja würde ich auch so sehen. Irgendwas hat der alte Controller anders gemacht mit der Signatur. Wobei das wirklich komisch ist. Da ich keine Möglichkeit kenne diese Signatur zu reparieren, würde ich sagen, dass man jetzt nur hingehen kann und alle Daten verschieben muss. Ich würde dazu hingehen und eine der Parity Disks als Disk 1 zuweisen und dann die alte Disk 1 mounten und die Dateien mit "cp -rp quelle ziel" die Dateien kopieren.

Zuerst deaktivierst du den Docker Dienst. Dann aktivierst du für den appdata Share den NVMe Cache Pool und stellst ihn auf "Prefer". Dann den Mover starten. Nun sollte Unraid alle Dateien von der SATA SSD auf den NVMe Pool verschieben. Ist das erledigt noch mal auf der SATA SSD nachschauen ob sie wirklich leer ist. Ist das der Fall, dann kannst einen Screenshot von der Disk Übersicht machen und über Tools > New Config (Pools behalten) alle Platten wieder dem Array so zuordnen wie sie vorher waren, nur du lässt die SATA SSD eben weg. Willst du zB aus dem RAID0 NVMe Pool einen RAID1 Pool machen, wäre es ähnlich. Alle Shares müssten dafür auf "Yes" gestellt werden, Docker und VM deaktiviert und wenn der Mover alle Dateien auf das Array verschoben hat, also die SSDs leer sind, kannst du über Tools > New Config (Array behalten) die Pools neu erstellen.

Die hat nichts im Array zu suchen. Die verhindert nur, dass die Parity HDD schlafen kann. Überhaupt würde ich sie komplett abschaffen und Docker auf die 1TB NVMe legen und Transcode in den RAM: https://forums.unraid.net/topic/35878-plex-guide-to-moving-transcoding-to-ram/page/12/?tab=comments#comment-894460 MagentaCloud unterstützt scheinbar WebDAV: https://cloud.telekom-dienste.de/hilfe/einrichten/zugriff-magentacloud Dann würde ich rclone installieren: Dann folgendes im Terminal ausführen und allen Schritten folgen um ein WebDAV "remote" hinzuzufügen: rclone config Dann User Scripts installieren: Und das folgende Script hinzufügen und nach einem beliebigten Zeitplan ausführen lassen: #!/bin/bash # make script race condition safe if [[ -d "/tmp/${0///}" ]] || ! mkdir "/tmp/${0///}"; then exit 1; fi; trap 'rmdir "/tmp/${0///}"' EXIT; # sync files with external WebDAV server rclone sync /mnt/user/Max magentacloud:Backups/Max --create-empty-src-dirs --ignore-checksum --bwlimit 3M --checkers 2 --transfers 1 -vv --stats 10s Genau das solltest du machen. Weg mit dem TR-004. 👍 Oder passen die Platten gar nicht in dein Server Gehäuse? Das kannst du handhaben wie du willst. Du kannst auch alles "wild" auf den Platten verteilen lassen. Über das Netzwerk siehst du eh nicht auf welchen Platten die Dateien liegen. Der Pfad /mnt/user/Kamera zeigt zB alle Fotos an, egal auf welcher Platte sie gerade liegen. Aber natürlich macht es Sinn das auf einer Disk zu konzentrieren, da dann nicht mehrere Disks parallel hochfahren müssen, wenn du dir mal Fotos anschauen möchtest. Dann ist das so. Aktuell fährst du volles Risiko. Wenn eine der NVMe stirbt, sind die Daten weg. Davon abgesehen sollte man vielleicht darüber nachdenken die VMs zu verkleinern. Warum belegen die überhaupt so viel Platz? Eine VM Disk sollte eigentlich nur System-Dateien enthalten. Den Rest lagerst du ins Netzwerk (Unraid Server) aus. Alternative: 2x 2TB kaufen 🤑 Oder du machst es wie ich und machst regelmäßig Backups von der SSD ins Array und lebst mit einem evtl Datenverlust von x Stunden. Also du willst aus der VM heraus Dateien möglichst schnell auf den Unraid Server kopieren? Naja, die landen doch, wenn du den NVMe Pool als Cache für dein Array nutzt, erstmal auf dem NVMe Pool. Keine Ahnung wie stark deine CPU hier limitiert, aber theoretisch wären dann über 1000 MB/s möglich. Das sollte doch reichen?! Wenn du die HDDs als RAID5 in einen separaten Pool packen würdest, kämst du vielleicht auf 450 MB/s (kommt auf die Platten an). Und du musst damit leben, dass das RAID5 24/7 läuft. Die Platten im Unraid Array stehen dagegen den ganzen Tag bis der Mover die Dateien vom NVMe Pool auf das Array verschiebt (wovon du nichts mitbekommst).