DataCollector

Soweit ich das Handbuch und die Intel Specs Vol1 fuer 11th Generation Intel richtig verstanden habe: # M2_1 PCIe 4.0 x4 funktioniert nur mit 11th Gen CPU (aber die willst Du ja einsetzen) ist laut Handbuch auch PCIe bifurcation fähig (x8x4x4). # M2_2 PCIe 3.0 x4 sollte funktionieren (haengt vermutlich aber am Z590 und teilt sich somit die Bandbreite mit M2_3 und PCIe4) # M2_3 PCIe 3.0 x4 sollte funktionieren (haengt vermutlich aber am Z590 und teilt sich somit die Bandbreite mit M2_2 und PCIe4) # PCIe16_1 PCIe 4.0 (oder bei aelteren CPU 3.0) entweder x16 exklusiv oder x8 (wenn PCIe16_2 (max x4) & PCIe16_3 (max x4) verwendet werden.) # PCIe16_2 PCIe 4.0 (oder bei aelteren CPU 3.0) max x4 (dann PCIe 16_1 nur x8) # PCIe16_3 PCIe 4.0 (oder bei aelteren CPU 3.0) max x4 (dann PCIe 16_1 nur x8) # PCIe4 3.0 x4 am Chipset Z590 (teilt sich somit vermutlich die Verbindung zwischen CPU und Z590 mit den beiden M2_2 + M2_3 + TB) Wenn ich richtig gelesen habe hat der Z590 aber 8 statt nur 4 DMI 3.0 Verbindungen zur CPU, womit sich der Engpass zwischen Z590 und CPU nicht so stark auswirken sollte wie bei frueheren Versionen mit nur 4 DMI). Wenn Du also wirklich nur den obersten x16_1 4.0 (hängt an 11th Gen CPU für Grafikkarte) und den PCIe x4 3.0 (hängt am Z590) belegst, solltest Du volle Nutzung aller SATA Ports und dieser Slots haben. Aber sobald Du auch alle M.2 gleichzeitig benutzen willst könnte der breitere DMI dennoch bei maximaler Nutzung aller Komponenten da einen Flaschenhals bilden (aber weniger schlimm als bei den vorherigen 4x DMI Anbindungen). Aber ehrlich gesagt wird man einen Engpass in der Anbindung als normaler Anwender wohl nicht bemerken.

Hallo @ViRtualRealitY Nur um sicher zu gehen und weil der Teufel meist im Detail liegt [Siehe auch PDF-Manual (Kapitel 4.1.3 ASUS CrashFree BIOS 3 Utility ab Seite 72)] https://dlcdnets.asus.com/pub/ASUS/mb/SocketG34(1944)/KGPE-D16/Menual_QVL/E8847_KGPE-D16.pdf Soweit ich das Handbuch und die sonst üblichen Prozeduren verstehe/kenne: 01. BIOS: KGPE-D16-ASUS-3309.zip downloaden und entpacken. 02. Die darin enthaltene KGPE-D16-ASUS-3309.ROM auf einen leeren FAT formatierten USB Stick kopieren (zur Sicherheit sollte er klein/kleiner 32GB sein. Da das Board USB3.0 nicht kennt, bevorzugt ein USB2.0 Stick). Die ebenfalls enthaltene BUPDATER.EXE ist für das eingebaute Recovery egal, also nicht aufkopieren. 03. Zu flashendes Mainboard/System vom Strom trennen (Netzteil ausstecken und etwas warten, bis es sich entladen hat). 04. BIOS Recovery Setting auf PINS 2+3 (mitte+rechts/Recovery) umstellen 05. USB Stick einstecken (es ist kein spezieller Port angegegen, aber ich würde es mit einem der beiden hinteren neben den PS/2 versuchen und keinem an einer vielleicht zusätzlich eingesteckten Karte oder so.) 06. Strom anschließen und System einschalten. 07. Etwas warten (es ist keine Zeit angegeben, ich würde mal 10 Minuten warten. Grosse Speicherbausteine flashen nicht unbedingt schnell.) Angeblich soll das System sogar selbstständig nach dem flash restetten. Ob man das aber erkennt, weiß ich nicht. 08. Power off 09. BIOS Recovery Setting auf PINS 1+2 (mitte+links/default) zurück stellen 10. USB Stick entfernen 11. Neu einschalten. Dann sollte der PC grundlegend starten. Sollte es nicht klappen versuchen das Selbe mit einem FAT32 formatierten USB Stick durchzuführen. Einige sehr alte Recoverysysteme machen da einen Unterschied. Ich habe die KGPE-D16-ASUS-3309.zip von Asus geladen. Es ist nur die ROM und die Exe drin. KGPE-D16-ASUS-3309.ROM BUPDATER.EXE Die sonst übliche Readme oder Flashanleitung ist leider nicht dabei. Wenn das nichts bringt: Auf der Webseite gibt es eine Anleitung https://dlcdnets.asus.com/pub/ASUS/mb/SocketG34(1944)/KGPE-D16/Menual_QVL/KGPE-D16_Interlagos_Support_new.pdf Version -2011/10/06 update 478.25 KBytes -How to identify MB default loaded Opteron 6200 CPU BIOS. -How to make your KGPE-D16 to support Opteron 6200 series CPU. Vielleicht kann das helfen bei einem Update wegen Opteron/CPU Problemen. Viel Erfolg!

Hallo @mgutt Auf https://www.ocinside.de/test/mainboard_asrock_b550_taichi_razer_edition_d/3/ haben die das Ding etwas naeher gezeigt. Im dritten Bild kann man bei starker Vergrößerung rechts unterhalb des Chipsatzes 2 gleichförmige Chips erkennen. Das deutet darauf hin, daß es 2 ASM1061 sein könnten. Dann hätte man wenigstens bei einer je x1 Lane Anbindung die volle Performance (bei doppeltem Energiebedarf).

Hallo Die Aussage in dem Screenshot wundert mich etwas. Laut Webseite von ASM ist der 1061 ein DualPort Kontroller. Wenn der 4 Ports bereit stellt ist entweder ein Portmultiplier im Spiel oder die haben sogar 2 von den Dingern verbaut. https://www.asmedia.com.tw/product/77BYq58SX3HyepH7/58dYQ8bxZ4UR9wG5 "...The ASM1061, x1 PCI Express to two ports of Serial ATA, enables Serial ATA PHY up to 6Gbps high speed interface, following Serial ATA Revision 3.0 specification..." Beide Varianten würden den Stromverbrauch nochmal minimal heben.

Hallo Meiner Meinung nach ist das aktuell wirklich ein gutes Angebot. Ich habe mir ende letztes Jahr schon eine STEB16000402 geholt und die läuft seitdem bei mir extern durchgehend ohne Probleme 24/7. Damals war sie im Sonderangebot für 289 Euro zu haben. Wenn man die aktuelle Situation und Preislage betrachtet empfinde ich den Preis von 297,99 Euro (zwar etwas höher) aber gut. Meine letzten 16TB habe ich vor einigen Tagen noch für rund 350 Euro gekauft (dafür aber mit 5 Jahren Garantie). Nun ist für diesen Monat aber alles Geld für ungeplante Hobbyausgaben bei mir futsch

Hallo @Gorosch Ja. Und da ich eben auch den Zugriff auf die Disks wollte habe ich eben direkt auf /mnt/ gekürzt. Ich ahbe es jetzt wieder auf /mnt/user/ verlängert. aber da mir dann der Zugriff auf die Disks fehlt um über die Disks hinweg Verzeichnisse & Dateien verschieben zu können habe ich nun einen Extra Path angelegt, der wieder auf /mnt/ zeigt. Damit habe ich nun das Selbe, nur man sieht am Path nun, dass es ein manuell erzeugter Pfad ist. Also die 3 Part Spaceinvaderone-reihe kenne ich. Dadurch habe ich es ja mit rsync probiert udn bin zuerst in die Falle mit den Berechtigungen getappt. Und dere SpaceinvaderOne Teil mit krusader war auch meien Vorlage, doch, da ich den neueren conta8iner von ich777 verwende, welcher nicht die selben Pfade zeigt, musste ich eben anpassen. Das ist die Reihe von 2017. Das war ja die ausschlaggebende Vorlage fuer (fast) Alles.

Das wundert mich weniger, da ich ja den vorgeschlagenen Befehl angepasst hatte hawihoney hatte ja fuer seine Situation passend vorgeschlagen: find /mnt/disk1/Filme -type f -name *mkv -not -perm 666 -exec chmod 666 {} \; Und ich hatte es (falsch) angepasst, weil ich ja nicht mkv Dateien, sondern alles wieder zugänglich haben wollte. find /mnt/disk1 -not -perm 666 -exec chmod 666 {} \; Somit habe ich die 666 selber gesetzt. Scheint geklappt zu haben Beides Mal: ja. Ich sehe die Shares wieder in Unraid. System bootet gerade neu (und hat mich gerade mit einem Read Error auf Disk11 überrascht, obwohl ich ja seit Stunden gar nicht auf dem unraid herumschreibe ... ). Ja, nach dem Booten sind die Shares wieder zu sehen. Ich hatte erwartet nur auf die oberste Ebene der Shares zugreifen zu können, doch es scheint, als gelange ich wieder an alles heran, auch an darunter liegende Verzeichnisse und die Dateien darin. Sieht bisher wieder gut aus. Ich werde nun ein bisschen herum suchen und probieren ob damit die rsync Verzeichnisse auch zugänglich sind (wenn ich noch herausfinde, welche es waren). Bis her hin schon einmal Danke für die Geduld und Hilfe!!

Hallo. Im MC sieht es ja auch so aus, wie Du es ebenfalls dargestellt hast Siehe mein Screenshot unten angehängt. Das vermutet mgutt auch und ja, ich habe wohl einen Pfad für den dockercontainer falsch angepasst, wodurch es aber wohl nur falsch aussieht.

Hallo. Zuerst: Da mich die Forumsoftware zur Verzweifelung treibt bin ich leider nicht so schnell, wie die ganzen Replies. Ein falscher Klick oder der Versuch eine überflüßige Zeile zu löschen udn schon scheint das ganze weitere Quote drunter unwiderbringlich weg zu sein und ich kann mit dem Beitrag komplett von vorne anfangen. 🤢 Dann schaffe ich es auch nicht kleine Bilder ins Posting zu bekommen, deshalb kann ich nru Dateien anhängen, das ueber externes Speichern geht und ebenfalls Zeit raubt. Und dann gibt man nur einen Link an und schon wird gleich das Video eingebaut (unten). Ich bin Foren einfach nicht gewohnt. 😬 Das mag normal sein. ich habe unraid normal eingerichtet, dann den krusader als dockercontainer installiert (siehe beiliegenden Screenshot der Einstellungen) und dann festgestellt, dass ich unter /mnt/ eben genau das sehe, was bei dem Tutorial von SpaceinvaderOne unter /UNRAID (gleichgesetzt mit /mnt/) zu sehen ist. Da ich den ich777 krusader gewählt habe habe ich nicht die identischen Pfade gehabt, wie im Video Part 2 Moving ... in Array ca. 5 Min:47 /UNRAID <> /mnt/ Also sind die Sachen, die ich suche in /mnt/ Und im Video bei 6:33 ist zu sehen, daß dort eben die Disk1 bei cache remotes und so weiter zu sehen ist. Dass auf den Disks die Shares (sharename1....) zu sehen ist ist ja auch bei mir Das sah ich so in einem anderen Tutorial, Leider weiß ich nicht mehr in welchem. Den werde ich demnächst korrigieren. Danke!

Hallo Mit Disk Shares sind die Shares gemeint, die man mit unraid unter "Shares" anlegen kann? So habe ich meien auch erstellt. Dann von aussen rein geschrieben und das war alles okay. Auch habe ich mit krusader dann zwischen den Disks Dateien und Verzeichnisse verschiben (zum sortieren), das ging gut. Die jetzigen Probleme begannen erst, als ich mit Rsync Daten auf den urnairdserver kopiert (gezogen) habe. Der krusader im Docker hatte diese Probleme nicht verursacht. Er hat sie nur gezeigt, weil er auf einmal in die rsync erzeugten Bereiche nicht mehr rein kam. Zu den Pfad: Ich kann mich nur wiederholen (siehe Screenshot+1 oben) das sah eigentlich schon immer so aus. die disk1,disk2,disk3, liegen alsl neben remotes, disks, user user0 und wenn ich dann in disk1 (oder 2 ..3..4..5..) einsteigen will, zeigt krusader eben den Pfad an.

Du meinst Sysetm aus folgendem Listing weiter oben? root@URTESTER:~# ls -la /mnt/cache ... drwxrwxrwx 1 nobody users 26 Jun 13 03:27 system/ Da befindet sich das hier:

Krusader zeigt mir unter /mnt/user folgendes an. <Screenshot#1> Hier sind alle Disks zu sehen und ich konnte diese (auch remotes, disks und die shares unter dem user) vor der rsync-Aktion alle betreten und auch alle Verzeichnisse darin und auch die Dateien darin anzeigen. Nach Rsync konnte ich die vorher bestehenden Verzeichnisse und Dateien weiterhin wie vorher betreten... nur die mit rsync neu erstellten Verzeichnisse und darin dann enthaltenen Unterverzeichnisse und Dateienin auf den Disk1 bis Disk11 waren nicht mehr erreichbar, weil es abgelehnt wurde. Ich beschrieb es ja vorher. Dann führte ich die oben gelisteten Befehle mit find.... chmod ... aus und hatte es damit verschlimmert. Nun waren alle Zugänge über kruseder auf disk1 bis disk11 nicht mehr möglich. Auch waren damit alle Shares aus unraid verschwunden (Bildschirmkopie habe ich oben ja schon einmal angehängt. Dann habe ich jetzt das Tool Docker safe new perms laufen lassen, es besserte sich aber nichts. Dann Reboot. Aber weiter keine Besserung. <Screenshot#2> Es ist die Position /mnt/user/disk1 Dass dies ungewöhnlich wäre ist mir neu, denn das war immer so, wenn ich mit krusader gearbeitet habe und das ist auch bei diversen Tutorials so. Alle Disks bekommen einen nummerierten disk Eintrag neben den cache, remote und so weiteren Einträgen an der Stelle. Darüber habe ich immer mit krusader (Docker ich777 kontainer) gearbeitet (diese Position hatte ich aus dem Video von Spaceinvader One uebernommen und auch als Favorit hinterlegt). Die Shares sind dann unter dem weiteren Unterordner, der ebenfalls user heisst und auf Screenshot#1 weiter unten zu sehen ist. Siehe Screenshot#3 Uebrigens sind die Shares in unraid selber weiterhin nicht zu sehen Screenshot#4. Ich wüßte nicht wie/wo ich das getan haben sollte. Liegt /boot nicht auf dem Stick? Ich habe nur an den disks gefummelt. USB Stick oder SSD Cache wurden nicht von mir bewußt verändert. Nebenbei: Alle 3 Shares auf den Disks (realviedeo, data und ea hatten Cache: no. Somit sollte auch keine der Operationen den Cache betroffen haben. Dennoch sind die Shares auch für system, isos, appdata und domains auch nicht mehr unter Share von unraid zu sehen (Screenshot#4) Ich habe es auch mit dem befehl bei mir gelistet und sehe keinen signifikanmte Unterschied (ausser, dass bei mir ein prokey drin ist). root@URTESTER:~# ls -la /boot/config total 496 drwx------ 11 root root 16384 Jul 10 17:21 ./ drwx------ 7 root root 16384 Jan 1 1970 ../ -rw------- 1 root root 256 May 31 23:20 Pro.key -rw------- 1 root root 5300 Jul 10 17:21 disk.cfg -rw------- 1 root root 5300 Jul 6 11:29 disk.old -rw------- 1 root root 342 Jun 17 09:05 docker.cfg -rw------- 1 root root 274 Jul 8 22:18 domain.cfg -rw------- 1 root root 7 Jul 10 16:26 drift -rw------- 1 root root 125 Jun 13 05:58 flash.cfg -rw------- 1 root root 0 Jul 10 17:21 forcesync -rw------- 1 root root 71 Apr 7 18:48 go -rw------- 1 root root 677 Jul 10 17:18 ident.cfg -rw------- 1 root root 33 May 9 02:29 machine-id drwx------ 2 root root 16384 May 9 02:29 modprobe.d/ -rw------- 1 root root 450 Jun 27 13:32 network.cfg -rw------- 1 root root 565 Jul 10 14:42 passwd drwx------ 22 root root 16384 Jul 7 11:48 plugins/ drwx------ 2 root root 16384 Jun 13 01:20 plugins-error/ drwx------ 2 root root 16384 Jun 13 03:10 plugins-removed/ drwx------ 2 root root 16384 Jun 13 21:16 pools/ -rw------- 1 root root 512 Jul 10 17:16 random-seed -rw------- 1 root root 550 Jul 10 14:42 shadow -rw------- 1 root root 499 Jun 18 02:42 share.cfg drwx------ 2 root root 16384 Jul 3 22:12 shares/ -rw------- 1 root root 25 Jul 6 01:30 smart-all.cfg -rw------- 1 root root 141 Jun 13 01:52 smb-extra.conf -rw------- 1 root root 206 Jul 10 14:42 smbpasswd drwx------ 3 root root 16384 May 9 02:29 ssh/ drwx------ 3 root root 16384 May 9 02:29 ssl/ -rw------- 1 root root 4096 Jul 6 18:13 super.dat -rw------- 1 root root 4096 Jul 6 11:28 super.old drwx------ 2 root root 16384 May 9 02:29 wireguard/ Anscheinend fehlen mir bei den Verzeichnissen auch nach dem tool und Reboot die x Berechtigungen root@URTESTER:~# ls -la /mnt total 16 drwxr-xr-x 18 root root 360 Jul 10 17:21 ./ drwxr-xr-x 20 root root 440 Jul 10 17:21 ../ drwxrwxrwx 1 nobody users 48 Jul 10 17:31 cache/ drw-rw-rw- 3 nobody users 23 Jul 10 17:31 disk1/ drw-rw-rw- 3 nobody users 16 Jul 10 17:31 disk10/ drw-rw-rw- 3 nobody users 16 Jul 10 17:31 disk11/ drw-rw-rw- 3 nobody users 23 Jul 10 17:31 disk2/ drw-rw-rw- 3 nobody users 23 Jul 10 17:31 disk3/ drw-rw-rw- 3 nobody users 23 Jul 10 17:31 disk4/ drw-rw-rw- 3 nobody users 23 Jul 10 17:31 disk5/ drw-rw-rw- 3 nobody users 18 Jul 10 17:31 disk6/ drw-rw-rw- 3 nobody users 18 Jul 10 17:31 disk7/ drw-rw-rw- 3 nobody users 16 Jul 10 17:31 disk8/ drw-rw-rw- 3 nobody users 16 Jul 10 17:31 disk9/ drwxrwxrwt 2 nobody users 40 Jul 10 17:18 disks/ drwxrwxrwt 2 nobody users 40 Jul 10 17:18 remotes/ drw-rw-rw- 1 nobody users 23 Jul 10 17:31 user/ drw-rw-rw- 1 nobody users 23 Jul 10 17:31 user0/

Das habe ich durchlaufen lassen. Hat knapp über 1/2 Stunde gedauert. Danach habe ich ich in Shares nachgesehen. Das ist leider weiterhin komplett leer. Daraufhin ließ ich gerade neu Rebooten in der Hoffnung, daß irgendwelche Shares da wieder auftauchen. Leider Fehlanzeige. Auch kann der krisader weiterhin die Verzeichnisse auf den Disks nicht betreten. Aber da auch die nie angefassten (und auch bei dieser Aktion ausgeschlossenen (mit fix comond problems)) appdata, domains, system und isos verschwunden waren/bleiben, befürchte ich, daß es ich mit den Benutzeranpassungen auf Terminalebene wohl zuviel kaputt gemacht habe.

Ich habe mir extra Serie 7 Kontroller gekauft, weil die direkt HBA unterstützen. Dann scheint die Serie 6 wohl auch im JBOD Modus da etwas spezieller zu handhaben.

Hallo Und ich dachte ich hätte von Ordnern geschrieben. Das Dein Beispiel angepüasst werden musste war ja klar. Nur habe ich eben auch an den falschen Stellen angepasst. Mir geht es nicht um mkv Dateien, mir geht es um alles, was auf der Disk ist. Die anderen Sachen iso, appdata, domains und so weiter liegen ja auf den SSD Cache und wurde nicht angefasst. Wenn ich Daten über den normalen Weg von Win10 über LAN auf unraid Share kopiert habe war es normal erreichbar. Als ich von unraid per rsync die Daten (Verzeichnisse mit enthaltenen Dateien) herüber kopiert habe tauchte dieses Zugriffsproblem auf. Ich suchte einen Weg die per rsync kopierten Daten so anzupassen (deren Berechtigungen), dass ich sie genau so normal erreichen kann, wie es geht, wenn man sie sich von aussen auf das Share kopiert.

Nein, hatte manuell getippt. Sorry. Hier Copy: root@URTESTER:~# ls -la /mnt/disk2 total 0 drw-rw-rw- 3 nobody users 23 Jul 10 14:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drw-rw-rw- 3 nobody users 30 Jul 9 22:30 realvideo/

Hallo. root@URTESTER:~# ls -la /mnt/disk1 total 0 drw-rw-rw- 3 nobody users 23 Jul 10 14:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drw-rw-rw- 3 nobody users 30 Jul 3 22:15 realvideo/ root@URTESTER:~# ls -la /mnt/disk3 total 0 drw-rw-rw- 3 nobody users 23 Jul 10 14:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drw-rw-rw- 6 nobody users 98 Jul 3 22:15 realvideo/ root@URTESTER:~# ls -la /mnt/disk4 total 0 drw-rw-rw- 3 nobody users 23 Jul 10 14:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drw-rw-rw- 6 nobody users 98 Jul 3 22:15 realvideo/ und so weiter. Auf DIsk 6+7 liegt ein verzeichnis namens "data" mit Backups Auf Disk 8-11 liegen andere Videos in einem Verzeichnis "ea" Diese Sachen liegen auf dem Cache und ich habe die Befehle nur für disk1 bis disk11 angewendet. root@URTESTER:~# ls -la /mnt/cache total 16 drwxrwxrwx 1 nobody users 48 Jul 10 14:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drwxrwxrwx 1 nobody users 16 Jun 15 05:23 appdata/ drwxrwxrwx 1 nobody users 44 Jun 27 13:49 domains/ drwxrwxrwx 1 nobody users 132 Jun 17 08:11 isos/ drwxrwxrwx 1 nobody users 26 Jun 13 03:27 system/ Nein.

Hallo. Das Board unterstützt bis zu 128GB ECC Ram und auch beispielsweise einen I3-8100. Laut Intel Ark beherrscht der I3-8100 max 64GB Ram. Weiß jemand ob man in der Mainboard CPU Kombi die 64GB Grenze überschreiten und nutzen kann oder limitiert die CPU hier? Danke!

Hallo Nur der neugierde halber: Welcher Kontroller? Meine Erfahrung ist, daß es leider doch noch diverse Kontroller gibt, die es zwar JBOD oder SINGLE oder so ähnlich nennen, aber dennoch da ein bisschen was eigenes basteln, so daß damit benutzte Festplatten leider nicht wirklich simple formatierte Festplatten sind.

Hallo. Ichhabe zwischenzeitlich unraid mal nei rebootet. Jetzt sind auch im Tab Shares ueberhaupt keien Freigaben mehr zu sehen. root@URTESTER:~# ls -la /mnt/user/realvideo total 64 drw-rw-rw- 1 nobody users 32768 Jul 10 13:36 ##FILME/ drw-rw-rw- 1 nobody users 30 Jul 9 22:30 ./ drw-rw-rw- 1 nobody users 23 Jul 10 10:40 ../ drw-rw-rw- 1 nobody users 8192 Jul 10 10:28 DIVERSES/ drw-rw-rw- 1 nobody users 4096 Jul 7 22:13 DOKU/ drw-rw-rw- 1 nobody users 102 Jul 7 00:30 WEBCAM/ root@URTESTER:~# root@URTESTER:~# ls -la /mnt/disk2 total 0 drw-rw-rw- 3 nobody users 23 Jul 10 10:39 ./ drwxr-xr-x 18 root root 360 Jul 10 14:29 ../ drw-rw-rw- 3 nobody users 30 Jul 9 22:30 REALVIDEO/

Hallo. So, ich habe versucht mit Manpages und den Infos hier die Befehle anzupassen und nun hat krusader nicht einmal mehr Zugriff auf jedes Verzeichnis aller Disks. 🙄 Da ich alle Dateien und alle Verzeichnisse erreichen will, habe ich aus den Befehlen den Type und Namensfilter entfernt (so hatte ich eine Linux Manpage zu Find verstanden), als Startpunkt die jeweilige Disk angegeben (hier mal Disk1) und dann diese beiden Befehle drauf los gelassen. Berechtigungen auf die in unraid wohl ueblichen Rechte nobody:users find /mnt/disk1 -not -user nobody -exec chown nobody:users {} \; Und dann die Zugriffe auf der jeweiligen Disk ueberall anpassen: find /mnt/disk1 -not -perm 666 -exec chmod 666 {} \; Tja, und danach hat krusader keinen Zugriff mehr. Voila, ich habe da wohl doch irgendetwas falsch verstanden und gemacht. Wie schon mal gesagt; kein Datenverlust, weil die Datenquellen ja noch bestehen, aber irgendwie muß ich das Problem wohl doch noch besser verstehen, da ich irgendwie die falschen Schlüsse gezogen habe und es dadurch vielleicht besser lerne. So, koennte ich bitte eine Erkärung bekommen, wo ich falsch abgebogen bin? Danke sehr!

Hallo @hawihoney und hallo @mgutt Ich bedanke mich für die Informationen und Hilfen. Damit konnte ich mich besser dem Thema der Dateiberechtigung nähern (was ich wohl fälschschlich als Attribute interpretierte) und es etwas besser verstehen. Ich bin zwar noch nicht am Ziel, habe aber jetzt einen Ansatzpunkt, wie ich hoffentlich weiter lesen/lernen & machen kann. Ich habe nun auch dadurch als Zusatznutzen die Bedienung des MC unter default unraid etwas besser verstanden und herausprobieren können, wie ich die Modes auch mit dem MC setzten kann. Für die Änderung von Owner/Group scheinen abder die beiden Zeilen oben wirklich eine schnelle/bequeme Methode zu sein. Hierzu eine grundlegende Frage. Im MC kann ich die Berechtigungen auch auf x read by others x write by others x execute/search by others setzen, Ist dann die Änderung des Besitzers/User noch notwendig/ratsam?

Hallo. Also ehrlich ich habe nun wirklich lange gesucht, aber ich finde wohl nicht die richtigen Suchbegriffe. Langtext (Kurztext weiter unten): Ich habe Anfangs von einem externen Win10 PC per TotalCommander Dateien auf unraid Share kopiert. Zwischenzeitlich bin cih durch diverse Anleitungen, Tutorials und hier im Forum auf rsync gestossen. Ich habe also TC Kopiervorgang abgebrochen, von unraid aus ein SMB Share auf einen Win10 PC erstellt und dann von dort als Quelle in ein Verzeichnis in unraid kopieren lassen: rsync -avh "/mnt/remotes/QUELL_W1064_Z/VIDEODATEIEN" "/mnt/user/realvideo" Das hat auch eigentlich geklappt. Bis auf, daß ich auf das Problem stoße, mit krusader im ICH777 Docker nicht in die kopierten Verzeichnisse rein schauen zu können. "Fehler: Der Ordner /mnt/user/disk3/realvideo/Big_Buck kann nicht geöffnet werden" Mit dem MC kann ich die Quelle ansteuern und auch die darin liegende Videodatei sehen und auch auf eine andere Disk verschieben. Als ich das Problem bei vielen Verzeichnissen gefunden habe, habe ich Gemeinsamkeiten gesucht und es scheint nur die Rsync kopierten Verzeichnisse zu betreffen. Im krusader sah ich, dass die fraglichen Verzeichnisse keine Attribute haben. Ich komme in Verzeichnisse mit rwx problemlos rein. In die rsync kopieren Verzeichnisse bei denen dort nur --- steht habe ich das Problem. Ich habe wohl keien Berechtigung dafür. Nun suche ich schon seit über einer Stunde herum, finde aber keine Anleitung wie ich mit dem krusader Attribute bzw Dateisystemberechtigungen ändern kann. In den ganzen Anleitungen finde ich immer nur, dass er sie anzeigen kann, aber das war es. Ich habe auch mal versucht von Unraid aus im Share Grundeinstellungen des Share abzuändern um unraid dazu zu bewegen bei allem im Share die Attribute neu zu setzen, aber da bin ich wohl ander falschen Stelle. Hat nichts verbessert. Kurztext: Mit rsync von WIn10 auf unraid kopiert, kann mit krusader die kopierten Verzeichnisse nicht betreten, vermutlich Attribute irgendwie falsch gesetzt. Und wieder einmal: 1. Was mache ich falsch? 2 Wie kann ich es nun nachträglich anpassen? Danke!

Hallo Habe ich gemacht. Ich habe mich noch nicht getraut auf den Format Button zu drücken (aktuell beinhalten alle Festplatten Daten, die ich nicht verlieren will), aber obwohl ich den Destructive Modus in UD Disabled habe ist der Format Button nun Orange, was darauf hindeutet, dass es damit wohl funktionieren sollte, Danke, daß Du Dich dafür eingesetzt hast!

Hallo Ja, das hatte ich schon gelesen und auch verstanden. Ich verstehe auch, dass auch das 'destructive' ist. Aber ich sehe einen Unterschied zwischen der Zerstörung einer oder mehrerer Partitionen mit Daten drin und der simplen Funktion des Formatierens. (Vielleicht bin ich es auch nur von DOS/Windows her zu sehr gewohnt.) Ist zwar beides destructive, aber vielleicht sehe nur ich da einen Unterschied in der Intensitaet. Das Formatieren vergleiche ich mal mit dem Anlegen eines Feldes für den vorgesehenen Ackerbaubei dem man das Unkraut unter pflügt. Wobei ich die Vernichtung von Partitionen mit Daten durch druecken eines kleinen roten Kreuzes dann doch eher einer Sprengung der Landflächen gleich setzen moechte (um es mal in ein schräges Bild zu verwandeln). Ersteres waere doch nett mit ein paar Sicherheitsabfragen zu erreichen, wobei zweiteres schon eher hinter einem gesicherten Schalter beheimatet sein sollte. Aber das ist nur meine laienhafte Meinung. So wie es ist, ist es ja auch machbar, doch das gleichzeitige Freischalten beider Funktionen in einem bringt bei mir ein ungutes Gefuehl hervor.