fstab für usb-hdd / freigabe

[miriki]

Moinsens!

Ich habe hier am Linux eine USB-HDD, die ich gerne mal mit den passenden Optionen in /etc/fstab einbinden möchte.

Diese HDD ist einerseits File-Server, wird aber sowohl lokal vom Linux, wie auch von Win10 mit Dateien bestückt.

Bislang werden lokal Files und Dirs mit miriki:miriki (einziger User neben root, auto-login KDE) 0644 angelegt. Mit sudo auf root gewechselt werden die mit root:root 0644 angelegt. Von Win10 über's Netz werden die mit nouser:nogroup 0744 angelegt.

Code: Alles auswählen

-rw-r--r-- 1 miriki miriki  2  1. Jun 14:45 miriki.miriki.txt
-rw-r--r-- 1 root   root    2  1. Jun 14:44 root.root.txt
-rwxr--r-- 1 nobody nogroup 4  1. Jun 14:46 win10.win10.txt

Wünschenswert wäre eigentlich, dass die Files sowohl lokal wie auch von Remote mit user:group 0777 (oder 0555? oder 0755/0777 mit noexec?) angelegt werden, wobei ich mir schon bei "user" und "group" nicht sicher bin. Z.Z. behelfe ich mir mit einem usbroot.sh in /media, welches ich von Zeit zu Zeit mal aufrufe und das mit chown und chmod rekursiv alles auf root:root 0777 setzt. Wahrscheinlich ist root nicht die beste Wahl...

Insbesondere: Ich sehe irgendwie nicht, dass umask, dmask und fmask mal genauer beschrieben sind, was sie bewirken usw. Auch bei suid verstehe ich nicht so recht, was es soll.

Mit defaults sollen rw,suid,dev,exec,auto,nouser,async gesetzt sein. Aber ich denke, davon abweichend bräuchte ich eher sync, vielleicht noexec und ein nofail,noatime in den Optionen, oder?

Wär prima, wenn mir hier jemand etwas Licht ins Dunkle schaffen könnte.

Gruß, Michael

[DeletedUserReAsG]

Hast du mal in die Manpage von mount geschaut? Dort sind die Optionen eigentlich recht detailliert beschrieben.

[miriki]

Manpage von mount [...] eigentlich recht detailliert

Findest Du? Naja... Ich hatte mich da schon mal durchgeblättert und hatte mir eigentlich ein "nur nicht noch mal!" vorgenommen. Lieber browse ich durch mehrere Websites. Nur mal als Beispiel, so ca. Zeile 740(!):

Code: Alles auswählen

suid   respektiert die Bits oder Datei-Capabilities »set-user-ID« und »set-group-ID« bei der Ausführung
              von Programmen von diesem Dateisystem.
nosuid respektiert die Bits oder Datei-Capabilities »set-user-ID« und »set-group-ID« bei der Ausführung
              von Programmen von diesem Dateisystem nicht.

Das eine macht was, das andere macht was nicht. Na toll.
Schön aber auch, direkt dahinter:

Code: Alles auswählen

silent aktiviert den Silent-Schalter.
loud   deaktiviert den Silent-Schalter.

Jetzt weiss man doch endlich mal, wie man den Silent-Schalter benutzt, auch wenn man noch immer nicht weiss, was zum Geier das überhaupt für ein Schalter ist.

Zumindest bis ca. Zeile 850 scheinen uid oder gid ja nicht allgemeingültig zu sein, also spezifisch für ext4 --> man ext4(5) - Hm, ok, ext4 Optionen nix dabei, aber ext3 gelten auch. ext3 Optionen sehe ich auch nix, aber ext2 gelten auch. Und auch bei ext2 finde ich nix, ausser vielleicht grpid. Kenne ich nicht, experimentier ich ungern mit.

Weisst jetzt, warum ich hier frage?

Gruß, Michael

[heisenberg]

Insbesondere: Ich sehe irgendwie nicht, dass umask, mask und fmask mal genauer beschrieben sind, was sie bewirken usw.

Das Hauptkommando für die Hilfeseiten unter Linux ist man und auch apropos.

apropos zeigt Dir welche Hilfeseiten es zu einem Stichwort gibt:

Code: Alles auswählen

$ apropos umask
getumask (3)         - get file creation mask
pam_umask (8)        - PAM module to set the file mode creation mask
umask (2)            - set file mode creation mask

Die man-page zu umask(2) enthält eine kurze Beschreibung.

Gibt's auch in deutsch online:

https://man.cx/umask(2)/de

Auch bei suid verstehe ich nicht so recht, was es soll.

suid = set-user-id ist ein Leistungsmerkmal von Linux(-Dateisytemen) dass man an Dateien oder Verzeichnissen setzen kann. Bei ausführbaren Dateien wird dann die Datei nicht im Rechtekontext des Benutzers sondern des Eigentümers der Datei ausgeführt. Wenn also eine Datei rumliegt, die root gehört und man bei der Datei das suid-Flag setzt, dann hat jeder der diese Datei ausführen kann bei dem, was diese Datei/dieses Programm tut, root-Rechte. Das ist also sehr sicherheitsrelevant. Das kann man bei einem reinen Speichergerät für Nutzdaten abschalten.

Eine legitime Anwendung von suid ist z. B. der Systembefehl passwd. Dieser hat auch suid gesetzt und erlaubt dem normalen Benutzer sein Passwort in einer für Ihn direkt nicht beschreibbaren Datei zu ändern.

[heisenberg]

Jetzt weiss man doch endlich mal, wie man den Silent-Schalter benutzt, auch wenn man noch immer nicht weiss, was zum Geier das überhaupt für ein Schalter ist.

Aus der Manpage:

Code: Alles auswählen

...
mount [-fnrsvw] [-o Optionen]
...
     -o, --options Optionen
              verwendet die angegebenen Einhängeoptionen. Das Argument Optionen ist eine durch Kommata getrennte Liste. Zum Beispiel:

                     mount LABEL=mydisk -o noatime,nodev,nosuid

              Weitere Details finden Sie in den Abschnitten VOM DATEISYSTEM UNABHÄNGIGE EINHÄNGEOPTIONEN und DATEISYSTEMSPEZIFISCHE EINHÄNGEOPTIONEN.
...
VOM DATEISYSTEM UNABHÄNGIGE EINHÄNGEOPTIONEN
       Einige dieser Optionen sind nur sinnvoll, wenn sie in der Datei /etc/fstab eingetragen sind.
...
       silent aktiviert den Silent-Schalter.

       loud   deaktiviert den Silent-Schalter.

Ergo: Sowohl loud als auch silent sind Optionen, die man gemäß obigem Text mit dem mount Kommando mittels mount -o loud ... nutzt.

[miriki]

Insbesondere: Ich sehe irgendwie nicht, dass umask, mask und fmask mal genauer beschrieben sind, was sie bewirken usw.

Das eine sollte übrigens dmask heissen, 'd' vergessen...

Die man-page zu umask(2) enthält eine kurze Beschreibung.

Yup, danke. Die kannte ich aber auch schon. Mein Problem geht ja mehr in die Richtung: Kann ich [u|d|f]mask überhaupt in den Mount-Optionen in der fstab benutzen, und wenn ja: wie? Meine Vermutung bisher wäre ein umask=0777, ohne mich um d und f mask kümmern zu müssen. (gewünschtes) Resultat: Alle Files werden mit 0777 angelegt. Aber in man fstab oder man ext4 finde ich dazu nichts. Gleiches Problem mit uid/gid: Scheint für ext4 gar nicht gültig zu sein, oder?

Auch bei suid verstehe ich nicht so recht, was es soll.

passwd. Dieser hat auch suid gesetzt und erlaubt dem normalen Benutzer sein Passwort in einer für Ihn direkt nicht beschreibbaren Datei zu ändern.

Ah, danke! Also: suid beachtet das Bit, nosuid würde es ignorieren. Was bedeutet das konkret für die USB-Platte? Wenn sowieso alle Files auf 0777 stehen, kann doch eh jeder alle lesen / schreiben, richtig? Dann könnte ich auch nosuid benutzen, macht dann eh keinen Unterschied mehr, richtig?

Ich bräuchte dann schon eher sowas wie 0744 auf den Files und suid in den Optionen. Wer braucht dann das suid Bit? Die Datei, also z.B. eine Textdatei, auf der Platte? Oder der Editor, mit dem die Datei bearbeitet werden kann? Oder beide? Und wie setzt man es? Und wo sieht man es?

Gruß, Michael

[miriki]

Jetzt weiss man doch endlich mal, wie man den Silent-Schalter benutzt, auch wenn man noch immer nicht weiss, was zum Geier das überhaupt für ein Schalter ist.

Aus der Manpage:

Na, was meinst Du wohl, wo ich den Text herauskopiert hatte?

Beachte meine Satz ab "auch wenn ..."

Gruß, Michael

[heisenberg]

Beachte meine Satz ab "auch wenn ..."

..., auch wenn man noch immer nicht weiss, was zum Geier das überhaupt für ein Schalter ist.

Darauf erwartest Du doch jetzt nicht wirklich eine Antwort?

Die umask/dmask/fmask Werte sind laut manpage nur für FAT möglich, weil die Rechtevergabe nicht im Dateisystem abbildbar ist. Ext4 braucht diese Werte nicht, weil es die jeweils gesetzte umask vollumfänglich im Dateisystem abbilden kann.

Ansonsten ist es auch hilfreich sich Erklärungen für Standardwissen via Suchmaschine zu suchen.

Zum Thema umask:
https://openbook.rheinwerk-verlag.de/sh ... 11_003.htm

Mein Problem geht ja mehr in die Richtung: Kann ich [u|d|f]mask überhaupt in den Mount-Optionen in der fstab benutzen, und wenn ja: wie?

Antwort steht hier:

Code: Alles auswählen

man fstab
...
       Das vierte Feld (fs_mntops).
              Dieses Feld beschreibt die zum Dateisystem gehörenden Einhängeoptionen.

              Es wird als eine Liste von Optionen formatiert, die durch Kommata getrennt 
              sind. Es enthält mindestens die Art des Einhängens (ro oder  rw)  sowie  eine
              beliebige  Anzahl  weiterer  Optionen,  die  für  den  Dateisystemtyp  zulässig 
              sind (inklusive Optionen zur Steigerung der Leistung). Für Details siehe
              mount(8) oder swapon(8).

Win10 über's Netz werden die mit nouser:nogroup 0744 angelegt.

Wie schreibst Du mit Win10 über's Netz auf die Platte? (NFS? Samba? SSH? SCP?)

[MSfree]

Mein Problem geht ja mehr in die Richtung: Kann ich [u|d|f]mask überhaupt in den Mount-Optionen in der fstab benutzen, und wenn ja: wie?

Dein "Problem" hat überhaupt nichts mit Mountoptionen zu tun.

(gewünschtes) Resultat: Alle Files werden mit 0777 angelegt.

0777 ist so ziemlich das falscheste, was man machen kann. Weißt du denn überhaupt, für was die 4 Zahlern stehen? Vermutlich nicht, sonst würdest du nicht so einen Wunsch äussern.

[miriki]

Mein Problem geht ja mehr in die Richtung: Kann ich [u|d|f]mask überhaupt in den Mount-Optionen in der fstab benutzen, und wenn ja: wie?

Dein "Problem" hat überhaupt nichts mit Mountoptionen zu tun.

Also: Nein?

(gewünschtes) Resultat: Alle Files werden mit 0777 angelegt.

0777 ist so ziemlich das falscheste, was man machen kann. Weißt du denn überhaupt, für was die 4 Zahlern stehen? Vermutlich nicht, sonst würdest du nicht so einen Wunsch äussern.

Jingelchen, überlass doch bitte erstmal mir, was ich hier in meinem Netz mit meiner Platte an meinem Rechner veranstalten möchte, bevor Du hier irgendetwas unterstellst. Dass root:root 0777 nicht die beste Variante (und nur hilfsweise vorläufig) ist, schrieb ich bereits weiter oben. Du kannst Dich also wieder hinsetzen.

Und es ist eine Fileserver-Platte, primär Daten, die von mehreren Rechnern raufkopiert, geändert, verschoben und auch wieder gelöscht werden. Im ersten Anlauf suche ich zunächst mal den gemeinsamen Nenner. Finetuning kommt dann später. Im Moment hilft es mir aber nicht, wenn lokal miriki 0644 anlegt, ich diese Datei aber als remote nouser nicht mehr bearbeiten kann. Und auch umgekehrt remote nouser 0744 Files bleiben für lokal miriki gesperrt. Letztendlich brauche ich ein 0666 (x nicht notwendig), damit jeder erstellen und bearbeiten kann.

Wenn das mit fstab nicht geht, dann vielleicht mit smb.conf? Da hier noch keiner in die Richtung was schrieb, ist das aber sicher auch nicht möglich, oder? Aber heisenberg's Frage in die Richtung scheint mir da hilfreich. Es müsste smb sein, nicht nfs.

Gruß, Michael

[miriki]

Win10 über's Netz werden die mit nouser:nogroup 0744 angelegt.

Wie schreibst Du mit Win10 über's Netz auf die Platte? (NFS? Samba? SSH? SCP?)

Ich sach ma sooo...
File-Explorer - Netzwerk - rechte Maustaste - Netzwerklaufwerk verbinden
T: --> \\192.168.1.5\public

Und public ist in /etc/samba/smb.conf

Code: Alles auswählen

[public]
path = /media/usb/
public = yes
writable = yes
comment = smb share
printable = no
guest ok = yes

Wenn fstab mich nicht weiter bringt, dann also vielleicht eher hier?

Gruß, Michael

[heisenberg]

Ja. smb.conf ist der richtige Ort.

Und du ahnst vielleicht auch schon, wo Du weitere Informationen darüber findest?

Ja, es ist...

Code: Alles auswählen

man smb.conf

Und auch hier hilft Dir wieder die Suchmaschine Deines Vertrauens, wenn Du etwas besser aufbereitetes dazu im Internet finden möchtest.

Jingelchen...

Ich geh' mal meinen Popcornvorrat auffüllen.

[eggy]

@all: man man man ... der dritte Thread in dem das so läuft.

@miriki: was msfree Dir sagen wollte: Du hast komplett missverstanden, wie umask funktioniert. Also nochmal: schau Dir an, was die Zahlen (in Bezug auf umask) bedeuten.

[heisenberg]

@all: man man man ... der dritte Thread in dem das so läuft.

Indem das wie läuft?

[miriki]

@miriki: was msfree Dir sagen wollte: Du hast komplett missverstanden, wie umask funktioniert.

Naja, nicht missverstanden, sondern eher erstmal gar nicht.

Denn ob da was mit AND oder OR auf den aktuellen user:group gemacht wird, ist ja schon ein Unterschied. Mein "Wunsch" war ja, dass umask=0777 als Mount-Option z.B. alle Files mit ebendiesem 0777 erstellt, also ein OR mit dem aktuellen Prozess macht. Wenn es aber ein z.B. 0644 mit AND draufpackt, wär's wiederum Essig und ich würde nie Files mit 0755 bekommen. Und letztlich habe ich bei fstab / mount und ext4 eh nichts über umask gesehen. Ok, wenn es nur Behelf für FS ist, die's nicht direkt können, dann ist das eben so. Also kann ich umask schlicht und ergreifend ignorieren.

Gruß, Michael

[miriki]

Ja. smb.conf ist der richtige Ort.

Ich weiss noch nicht so recht, ob

Code: Alles auswählen

create mask 0666  
directory mask = 0666
force create mode = 0666
force directory mode = 0666
force group = 
force user =

in die richtige Richtung geht. Vor allem mit user:group stehe ich noch in Verhandlungen... Letztendlich müssten so doch alle E(x)ecute rausgefiltert, dafür aber alle (r)ead und (w)rite für User, Group und Other gesetzt werden.

Aber gilt das nicht nur für Files, die von Remote, also über Samba, kommen? Wenn ich lokal eine 0755 per USB auf die HDD schiebe, geht das doch an Samba vorbei, oder nicht?

Gruß, Michael

[MSfree]

Die umask gilt nur für Dateien, die der Benutzer unter Linux erstellt. Die umask definiert die Rechte-Bits, die beim Erstellen einer neuen Datei nicht gesetzt werden sollen. umask 777 bewirkt also, daß Dateien mit 000 erzeugt werden.

Für Dateien, die von Windows aus (Netzlaufwerk verbinden...) erstellt werden, gilt die umask nicht. Da ist die smb.conf für zuständig.

[MSfree]

Ja. smb.conf ist der richtige Ort.

Ich weiss noch nicht so recht, ob

Code: Alles auswählen

create mask 0666  
directory mask = 0666
force create mode = 0666
force directory mode = 0666
force group = 
force user =

Für Verzeichnisse ist es notwendig, daß das Execute-Bit gesetzt wird, sonst darf man nachher nicht in das Verzeichnis wechseln.

Code: Alles auswählen

force directory mode = 0777

Ist hier also notwendig. Für normale Dateien wird das Execute-Bit nicht benötigt, ergo 666.

[miriki]

Code: Alles auswählen

force directory mode = 0777

Ist hier also notwendig. Für normale Dateien wird das Execute-Bit nicht benötigt, ergo 666.

Argl, copy/paste... Aber ja, hast natürlich völlig Recht.

Gruß, Michael

[heisenberg]

Die umask gilt nur für Dateien, die der Benutzer unter Linux erstellt. Die umask definiert die Rechte-Bits, die beim Erstellen einer neuen Datei nicht gesetzt werden sollen. umask 777 bewirkt also, daß Dateien mit 000 erzeugt werden.

Genau das steht in dem von mir verlinkten Artikel. Mit Beispiel. Ich möchte andere Menschen hier dazu ermuntern, sich das Wissen hier selbst zu erarbeiten um einen Beitrag zur Selbständigkeit zu leisten. Wer das nicht liest, dem sage ich höchstens noch, er möge es nochmal lesen. Das, was verlinkt und nicht gelesen wurde zusätzlich ohne Not zu erklären bewerte ich als Förderung von Unselbständigkeit.

Der Frust, dass ein Problem nicht gelöst werden kann, bewirkt dann vielleicht doch die Motivation, das empfohlene nochmals zu lesen.

[miriki]

Genau das steht in dem von mir verlinkten Artikel.

Ja, das mag ja auch alles richtig sein. Es geht aber nach wie vor an der eigentlichen Frage vorbei. Die Frage war, wie es doch im 1. Post ausführlich genug stehen sollte:

Wie kann ich dafür sorgen, dass auf dem Medium (also /dev/sdb1 bzw /media/usb) Dateien sowohl lokal (Linux), wie auch von remote (Win10, Samba), automatisch mit bestimmten Rechten erstellt werden.

Diese Frage ist nach wie vor nicht geklärt. Einzig geklärt ist bislang, dass umask für ext4 wohl keine (gültige, wirksame) Option in der fstab ist. Es geht nicht darum, lokal im Linux erstmal an der CLI per umask zu drehen, wenn ich eine Datei in /media/usb ersellen will, um es danach wieder zurück zu drehen. Das, genau das, soll ja Linux für mich machen. Während allgemein 0022 als Maske gilt, soll auf dem Medium, und nur dort und automatisch, dann eben 0111 benutzt werden. Mein Gedanke wäre ja auch eher ein "force" auf z.B. 666, also der Weg "anders herum", gewesen. Aber ich weiss nach wie vor nicht, wie das Eine oder das Andere gehen soll.

Also nochmal: Es ist mir prinzipiell völlig wumpe, ob eine Datei beim Erstellen, ob lokal oder remote, ab /media/usb abwärts von 0777 mit einer Maske 0111 dann auf den Mode 0666 umgestellt wird, oder ob sie von 0755 mit einem "force" auf 0666 geändert wird. Solange es nur überhaupt passiert! Mein Gedanke war halt in Richtung der fstab. Wenn das nicht geht, ok. Aber dann: wie?

Und remote... Teilergebnis: Der Besitzer wird auf miriki:miriki umgestellt, ich bin also das blöde nobody:nogroup los. Aber die Rechte sind trotz der (s.o.) Optionen in smb.conf falsch:

Code: Alles auswählen

-rwxrw-rw- 1 miriki miriki  4  2. Jun 07:16 /media/usb/blablubb.txt
-rw-r--r-- 1 root   root    2  2. Jun 07:23 /media/usb/blipblop.txt
-rw-r--r-- 1 miriki miriki  2  2. Jun 07:19 /media/usb/gnagnutz.txt

Die oberste blablubb.txt kommt von remote. Zumindest die hätte doch jetzt (create mask, force create mode) 0666 bekommen müssen. Wieso bleibt die x?

Gruß, Michael

[DeletedUserReAsG]

Es ist mir prinzipiell völlig wumpe, ob eine Datei beim Erstellen, ob lokal oder remote, ab /media/usb abwärts von 0777 mit einer Maske 0111 dann auf den Mode 0666 umgestellt wird, oder ob sie von 0755 mit einem "force" auf 0666 geändert wird. Solange es nur überhaupt passiert!

Die Dateisysteme, die Windows von Haus aus bearbeiten kann, kennen diese Art der Rechte nicht. Die Aussage, dass das Laufwerk auch lokal von Win10 mit Dateien bestückt würde, lässt drauf schließen, dass ein solches Dateisystem zur Anwendung kommt – eine konkrete Angabe zum verwendeten Dateisystem wurde ja noch nicht gemacht (oder ich hab’s überlesen).

Wenn also ein solches Dateisystem (FAT, NTFS) zum Einsatz kommt, wird nicht passieren können, was du da möchtest. Du kannst allenfalls das Dateisystem mit einer Maske einhängen, die dann auf alle Dateien angewendet wird, solange das Dateisystem halt mit dieser Maske eingehängt ist. Das hat aber keine Auswirkungen darauf, wie die Dateien tatsächlich erstellt werden.

[miriki]

Die Aussage, dass das Laufwerk auch lokal von Win10 mit Dateien bestückt würde,

Nein, halt, stop... "lokal" ist hier Linux, Win10 ist remote.

Aber wenn ich

Code: Alles auswählen

miriki@lxdeb1130:~$ echo . > test.txt

mache, habe ich im Home

Code: Alles auswählen

miriki@lxdeb1130:~$ ls -l test.txt
-rw-r--r-- 1 miriki miriki 2  2. Jun 15:08 test.txt

eine 644 Datei erzeugt. Wenn ich diese mit

Code: Alles auswählen

miriki@lxdeb1130:~$ cp test.txt /media/usb/
miriki@lxdeb1130:~$ ls -l /media/usb/test.txt
-rw-r--r-- 1 miriki miriki 2  2. Jun 15:10 /media/usb/test.txt

auf die ext. hdd kopiere, bleibt es eine 644er. Und spätestens (oder eigentlich genau da) beim "cp" hätte ich gerne eine Änderung auf 666.

Ich kann z.Z. diese Datei von remote Win10 bearbeiten, weil Samba den remote-User auf (ebenfalls) miriki:miriki setzt:

Code: Alles auswählen

miriki@lxdeb1130:~$ cat /media/usb/test.txt
x

Es ist nicht mehr der "." vom echo drin, sondern jetzt ein "x".

Das Problem stellt sich, wenn lokal (also Linux) die Dateien nicht mit dem User miriki erstellt werden, sondern vielleicht von root, kasiki, kiprfl oder wem auch immer. Das Problem stellte sich vorher schon, als remote (also Win10 Samba) mit dem User nobody reinkam. Da konnte ich die Dateien nur lesen, aber nicht verändern.

Jetzt hab ich noch eine Datei test2.txt in der cmd vom remote erstellt, also auch dort im DOS-Fenster ein

Code: Alles auswählen

t:\>echo . > test2.txt

Dabei kommt raus:

Code: Alles auswählen

miriki@lxdeb1130:~$ ls -l /media/usb/test*.txt
-rwxrw-rw- 1 miriki miriki 4  2. Jun 15:19 /media/usb/test2.txt
-rw-r--r-- 1 miriki miriki 2  2. Jun 15:12 /media/usb/test.txt

Jetzt hab ich zwar eine Datei, die auch von anderen Usern bearbeitet werden kann,

Code: Alles auswählen

miriki@lxdeb1130:~$ nano /media/usb/test2.txt
miriki@lxdeb1130:~$ cat /media/usb/test2.txt
y 

aber 766 ist auch nicht so ganz das Wahre...

Ich vergaß, der Vollständigkeit halber:

Code: Alles auswählen

miriki@lxdeb1130:~$ /media/usb/test2.txt
/media/usb/test2.txt: Zeile 1: y: Kommando nicht gefunden.

wohingegen sich

Code: Alles auswählen

miriki@lxdeb1130:~$ /media/usb/test.txt
bash: /media/usb/test.txt: Keine Berechtigung

sozusagen "korrekt" verhält.

Gruß, Michael

[heisenberg]

Wie kann ich dafür sorgen, dass auf dem Medium (also /dev/sdb1 bzw /media/usb) Dateien sowohl lokal (Linux), wie auch von remote (Win10, Samba), automatisch mit bestimmten Rechten erstellt werden.

Hallo Michael,

danke, dass Du die Frage nochmal konkret stellst.

Um das bisherige nochmal zusammen zu fassen:

Lokal -> Der Befehl umask (Für alle geeignete Dateisysteme(z. B. ext4 oder btrfs))
Von Windows per Samba -> smb.conf

Während allgemein 0022 als Maske gilt, soll auf dem Medium, und nur dort und automatisch, dann eben 0111 benutzt werden.

Die umask gilt nicht gerätebezogen. Sie gilt grundsätzlich in der Umgebung in der sie gesetzt wird global für alle Speichergeräte. Eine umask von 0111 ergibt keinen Sinn. Die Doku, die ich Dir zum Thema umask verlinkt habe, sagt warum. Hast Du die oktale Darstellung der Berechtigungen verstanden?

Global kann man die umask für Login-Shells(also auch die Desktopumgebung) in /etc/profile setzen.

Warum das x-bit bei der Datei gesetzt ist, kann ich Dir auch nicht sagen. IMO sollte es das nicht sein. Was ist das Dateisystem auf der USB-Platte?

Mir ist klar, dass das die Frage noch nicht ausreichend beantwortet.

Grüße,
h.

PS: Das mit dem gemeinsamen Zugriff würde ich wohl über Gruppen in Verbindung mit dem bisher besprochenen regeln.

[miriki]

Wie kann ich dafür sorgen, dass auf dem Medium (also /dev/sdb1 bzw /media/usb) Dateien sowohl lokal (Linux), wie auch von remote (Win10, Samba), automatisch mit bestimmten Rechten erstellt werden.

Die umask gilt nicht gerätebezogen. Sie gilt grundsätzlich in der Umgebung in der sie gesetzt wird global für alle Speichergeräte.

Das ist schade, aber es gibt ja vielleicht einen anderen Mechanismus? Wie gesagt: Mir ging es nicht um umask an der Konsole für die Session, sondern als Option in der fstab für das Device. Da hatte ich gehofft, gibt es eine Geräte-bezogene Maskierung. Alternativ ein umode=666, was aber bei ext4 ja wohl auch nicht geht.

Eine umask von 0111 ergibt keinen Sinn.

Naja, auf diesem Gerät speziell dann doch wohl schon, oder? Mit 0111 verhindere ich dann doch grundsätzlich ein "x" für die Files, für Besitzer, Gruppe und Andere, so wie ich es per Samba (theoretisch) ja auch machen kann. Mit 0022 kann ich ja Files als 755 erstellen, womit der Besitzer ausführbare Files erzeugen kann, was ich eben verhindern will. Und auch 0011 würde immer noch das "x" für den Besitzer erlauben. Ich sehe keine Alternative zu 0111, oder? Ich hätte nur keine Lust, im Linux die umask auf 0111 zu setzen, Files auf /dev/usb zu erstellen und dann die umask wieder auf 0022 zurück zu ändern.

Warum das x-bit bei der Datei gesetzt ist, kann ich Dir auch nicht sagen. IMO sollte es das nicht sein. Was ist das Dateisystem auf der USB-Platte?

ext4, schrieb ich schon weiter oben. Ich hatte es ursprünglich auf ntfs (factory formatted), aber da hatte ich nur 50 kb/s.

Ich bin schon am Überlegen, wenn es mit dem Samba force mode 0666 doch noch mal irgendwie klappt, ob ich die Platte lokal nicht auch über Samba mounten kann. Dann würde ich das erreichen, was ich mir vorstelle mit den Rechten.

Gruß, Michael