mgutt

Manchmal sind selbst 40 € noch zu viel. Ich mein der Rest kostet ja auch Geld und jetzt noch ein 850W Netzteil. Oder baust du gerade ein Storage Rack mit 20 und mehr Einschüben? Kommst du aus DE? Bei unseren Strompreisen finanziert sich neuere Hardware ja quasi von alleine. Daher solltest du nicht nur den Kaufpreis, sondern auch die laufenden Kosten berücksichtigen. Ich will dir ungern die Hardware madig reden, aber besser jetzt als später das böse Erwachen.

Einfach damit du das weißt: Unraid ist ziemlich einfach aufgebaut. Ein Ordner auf einer Festplatte im Array ist ein Share. Also wenn du jetzt mit "mkdir /mnt/disk3/videosammlung" einen Ordner auf Disk 3 erstellst, hättest du damit bereits einen User Share erstellt. Und Unraid ist es auch völlig egal wo diese Disk nachher im Array zugewiesen wird. Du kannst also auch über New Config zB disk1 mit disk3 tauschen. Die User Shares mit ihren enthaltenen Dateien bleiben so wie sie sind (da es einfach nur Ordner sind auf die sich Unraid bezieht). Man sollte nur natürlich niemals eine Datendisk als Parity zuweisen. Dann wären die Daten gelöscht. Daher sagen wir auch immer, dass man einen Screenshot machen soll, bevor man eine New Config startet.

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.