Wie Dateiattribute/Dateisystemberechtigungen im Share/auf Disk setzen?


Recommended Posts

6 minutes ago, DataCollector said:

Auch kann der krisader weiterhin die Verzeichnisse auf den Disks nicht betreten.

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.

 

6 minutes ago, DataCollector said:

Das ist leider weiterhin komplett leer.

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/

 

 

Link to comment
8 hours ago, hawihoney said:

Ich persönlich habe dieses Tool noch nie verwendet, da ich ausschließlich mit Disk Shares arbeite und weiß wohin was geht. Außerdem habe auch ich gerne die Kontrolle

 

Disk Shares nutze ich auch, hatte dennoch noch nie Probleme mit dem Tool. Aber gerade Dateien, welche von Dockern erstellt wurden, haben ab und zu Probleme mit den Rechten. Dublicacy beim Wiederherstelllen von Datein ist da so ein Kandidat.

 

Bevor ich da nun in die Konsole gehe und die Befehle Tippe, habe ich schneller den Button gedrückt. In der Zeit gehe ich nen Kaffee trinken, und das Problem ist behoben. Appdata wird nicht angepasst, es können keine Fehler durch Tippfehler entstehen, usw. Leichter gehts nicht. :)

 

 

36 minutes ago, DataCollector said:

 

UNraid-krusader.png

 

Dieser Pfad ist etwas verwirrend. Unter /mnt/user liegen normalerweiße deine Shares und keine Laufwerke. Array Laufwerke findest du einen ebene höher, also unter /mnt/disk1, usw. Laufwerke ausserhalb des Arrays findest du unter /mnt/disks.

 

Wie sehen denn die Konfigs deiner Shares aus?

Edited by Gorosch
Link to comment
40 minutes ago, mgutt said:

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.

 

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.

 

 

Quote

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?

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)

 

Quote

Also vom USB Stick? Vergleich mal mit meinem Ergebnis:

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/

 

 

Quote

Die Rechte deiner gemounteten Laufwerke sollten eigentlich nach einem Reboot wieder sauber sein:

 

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/

 

#1UNRAID-USERVIEW.png

#2UNRAID-krusader-DISK1.png

#3UNRAID-Krusader-USER.png

#4UNRAID-SHARES-WEG.png

Edited by DataCollector
Hatte vergessen Screenshots anzuhängen
Link to comment
4 minutes ago, DataCollector said:

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.

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:

image.png.91f86760a6279973f06c44b108b33ebd.png

 

In das geändert:

image.png.b8796f2cbf542379cb5b2576e6716548.png

 

Dadurch sehen die Pfade bei dir im Krusader nun "falsch" aus, sind aber nach wie vor richtig. "Korrekter" wäre es so gewesen:

image.png.0cc0c5885d8c711bed79aea0b27f7ba5.png

 

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".

Link to comment
8 minutes ago, DataCollector said:

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).

 

Ich glaube, ich weiß, was du meinst. Dann passt aber irgendwas mit deiner Krusader Config nicht.

 

Das /mnt Verzeichniss müsste, je nach Platten im Array und Pools, ungefähr so aussehen:

 

grafik.png.8162e885bce64054b01b0c825d7dda70.png

 

Im /mnt/user Verzeichniss werden hingegen nur deine Shares angezeigt, unabhängig davon, auf welcher Disk die liegen. Bei mir sieht es z.B. so aus:

 

grafik.png.fc3702fc45af5476c86e74956fd60083.png

 

Die Disks wurden noch nie im User Verzeichniss angezeigt, seit ich Unraid in der Version 6 seit 2016 nutze. Alles, was davor war, kann ich dir nicht sagen, kann mir aber nicht vorstellen, dass es da anders war.

Link to comment

Hallo

 

18 minutes ago, Gorosch said:

Disk Shares nutze ich auch, hatte dennoch noch nie Probleme mit dem Tool.

 

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.

 

18 minutes ago, Gorosch said:

Aber gerade Dateien, welche von Dockern erstellt wurden, haben ab und zu Probleme mit den Rechten.

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.

 

Link to comment
8 minutes ago, DataCollector said:

Anscheinend fehlen mir bei den Verzeichnissen auch nach dem tool und Reboot die x Berechtigungen

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/

image.png.2acc72f16a977674155da580586b4314.png

 

Mich wundert das Unraid nun 666 gesetzt hat:

image.png.89f561968b7e77951aad7e519ba51156.png

 

 

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.

Link to comment
5 minutes ago, DataCollector said:

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.

 

Genau. Beispiel Dokumente Share, welcher ausschließlich auf der Disk 3 bei mir liegt:

 

grafik.png.623c536b1ebfac85f3f6500874b6bda2.png

 

Dennoch solltest du auch da immer über das "/mnt/user" Verzichniss die Shares befüllen. Unraid packkt die Daten dann von ganz allein gemäß den Einstellungen auf die jeweilige Disk. Wenn du die Platten jedoch über "/mnt/diskX" befüllst, kann dies erhebliche Probleme mit sich bringen. Angefangen davon, dass der Mover nicht mehr macht, was er soll - bis hin zu Datenverlust bei falscher Handhabung.

Edited by Gorosch
Link to comment
15 minutes ago, DataCollector said:

Ich kann mich nur wiederholen (siehe Screenshot+1 oben) das sah eigentlich schon immer so aus.

Wie gesagt. Deine Krusader Config ist "falsch". Du musst /mnt mit /mnt verlinken. Dann sieht es auch in Krusader richtig aus.

 

15 minutes ago, DataCollector said:

Mit Disk Shares sind die Shares gemeint, die man mit unraid unter "Shares" anlegen kann?

Nein. Disk Share Pfade sind das:

/mnt/disk1/

/mnt/disk2/

/mnt/poolname/

 

Und sie werden in den Global Share Settings separat aktiviert:

1260423152_2021-07-1018_42_34.png.4a80971d7249dcd6635f49edaca931ec.png

 

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" 😉

Link to comment
12 minutes ago, Gorosch said:

Genau. Beispiel Dokumente Ordner, welcher ausschließlich auf der Disk 3 bei mir liegt:

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:

1505608412_2021-07-1018_45_50.png.85eb0698654ab72c19d1e08343fdb0a8.png

 

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:

919436385_2021-07-1018_46_35.png.06c095bb5d31b772d1de55ff7cb06718.png

 

 

Also noch mal:

/mnt/diskX = Disk Share

/mnt/user/sharename = User Share

 

 

Link to comment
22 minutes ago, mgutt said:

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.

😬

 

22 minutes ago, mgutt said:

Das bezweifle ich. Normal ist es so:

/mnt/user/sharename

 

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.

 

 

 

 

22 minutes ago, mgutt said:

oder:

/mnt/disk1/sharename

/mnt/disk2/sharename

usw

 

Dass auf den Disks die Shares (sharename1....) zu sehen ist ist ja auch bei mir

 

 

22 minutes ago, mgutt said:

Wenn Du in Krusader auch die Pfade "remotes" usw siehst, dann hast du vermutlich das:

image.png.91f86760a6279973f06c44b108b33ebd.png

 

In das geändert:

image.png.b8796f2cbf542379cb5b2576e6716548.png

 

Dadurch sehen die Pfade bei dir im Krusader nun "falsch" aus, sind aber nach wie vor richtig.

Das sah ich so in einem anderen Tutorial, Leider weiß ich nicht mehr in welchem.

 

 

22 minutes ago, mgutt said:

"Korrekter" wäre es so gewesen:

image.png.0cc0c5885d8c711bed79aea0b27f7ba5.png

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".

Den werde ich demnächst korrigieren.

Danke!

 

 

Unraid-krusader-edit-sapcei.png

Link to comment

Hallo.

 

Im MC sieht es ja auch so aus, wie Du es ebenfalls dargestellt hast

Siehe mein Screenshot unten angehängt.

 

Quote

Ich glaube, ich weiß, was du meinst. Dann passt aber irgendwas mit deiner Krusader Config nicht.

Das vermutet mgutt auch und ja, ich habe wohl einen Pfad für den dockercontainer falsch angepasst, wodurch es aber wohl nur falsch aussieht.

unraid-mc-array.png

Edited by DataCollector
Link to comment
15 minutes ago, mgutt said:

Das ist kein Disk Share, sondern ein User Share.

 

Stimmt, du hast Recht. Von der Erklärung her sollte es aber dennoch stimmen, was ich gemeint habe. Wenn nicht, bitte korregieren.

 

12 minutes ago, DataCollector said:

Und im Video bei 6:33 ist zu sehen, daß dort eben die Disk1 bei cache remotes und so weiter zu sehen ist.

 

Das liegt aber daran, dass der Container Pfad "/unraid" auf den Server Pfad "/mnt" führt. Und in "/mnt" liegen eben, wie oben beschrieben diese Verzeichnisse. Abgesehen davon gibt es bezüglich Krusader ein neueres Video, was dies noch mal besser erklärt. Hier wird sogar empfohlen, den Host Pfad "/mnt/user" zu entfernen und eigene Pfade zu nutzen. Warum, wird im Video besser und schneller erklärt, als es hier zu tippen.

 

Zu diesem Thema gibt es sogar eine ganze Videoreihe, welche alle Möglichkeiten aufzeigt, Daten in Unraid, um Unraid und um Unraid herum zu bewegen. Sollte dir sicherlich weiterhelfen.

 

 

Edited by Gorosch
Link to comment
29 minutes ago, mgutt said:

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:

Mich wundert das Unraid nun 666 gesetzt hat:

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.

 

29 minutes ago, mgutt said:

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/*

 

Scheint geklappt zu haben

 

 

29 minutes ago, mgutt said:

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?

Beides Mal: ja.

Ich sehe die Shares wieder in Unraid.

 

 

29 minutes ago, mgutt said:

Wenn ja, bitte neu starten und schauen ob das dann auch noch so ist.

 

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!!

  • Like 1
Link to comment

Hallo @Gorosch

 

34 minutes ago, Gorosch said:

Das liegt aber daran, dass der Container Pfad "/unraid" auf den Server Pfad "/mnt" führt. Und in "/mnt" liegen eben, wie oben beschrieben diese Verzeichnisse.

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.

 

 

34 minutes ago, Gorosch said:

Abgesehen davon gibt es bezüglich Krusader ein neueres Video, was dies noch mal besser erklärt. Hier wird sogar empfohlen, den Host Pfad "/mnt/user" zu entfernen und eigene Pfade zu nutzen. Warum, wird im Video besser und schneller erklärt, als es hier zu tippen.

 

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.

 

34 minutes ago, Gorosch said:

Zu diesem Thema gibt es sogar eine ganze Videoreihe, welche alle Möglichkeiten aufzeigt, Daten in Unraid, um Unraid und um Unraid herum zu bewegen. Sollte dir sicherlich weiterhelfen.

Das ist die Reihe von 2017. Das war ja die ausschlaggebende Vorlage fuer (fast) Alles.

Link to comment
4 minutes ago, DataCollector said:

Das ist die Reihe von 2017. Das war ja die ausschlaggebende Vorlage fuer (fast) Alles.

 

Das ist richtig. Genau von dieser Reihe gibt es aber eine neuere Version, da in 6.9 doch ein paar Dinge dazu gekommen sind. Das macht die alte Reihe sicher nicht schlechter. Die Neue bezieht sich nur eben auf den aktuellen Stand und erklärt ein paar Dinge nochmals besser.

Edited by Gorosch
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.