Gibt es einen Grund warum die Home-Dirs bei dir auf read only bei gesetzt werden? Dann können die User ja gar nicht in ihre eigenen Home-Verzeichnisse schreiben.TomL hat geschrieben:Code: Alles auswählen
[homes] read only = yes
[gelöst] Samba: User verstehen
Re: Samba: User verstehen
Re: Samba: User verstehen
Selbstverständlich haben die Anwender in meiner Konfiguration auch ein Schreib-Recht auf die an dieser Stelle gespeicherten Daten. Wie ich schon sagte, das ist nicht 'meine' smb.conf, sondern nur ein Anschauungsobjekt, worauf ich hin- und wieder zurückgreife.... so, wie jetzt hier im Thread eben auch. Aber Du hast natürlich Recht, im Kontext dieses Threads passt das überhaupt nicht zusammen. Deswegen habe ich das jetzt gerade oben korrigiert, so das nun alles zusammen ein stimmiges Bild ergibt.
Haben Dir meine Ausführungen bei Deiner Lösung ein wenig geholfen...?... das würde mich freuen......! Dabei gings mir mehr um das Verstehen der Zusammenhänge, und weniger um stupides Abarbeiten von Befehlsreihenfolgen. Wenn ja, ist das hier vielleicht noch mal verwendbar, denn diese Fragen kommen immer wieder neu.
Haben Dir meine Ausführungen bei Deiner Lösung ein wenig geholfen...?... das würde mich freuen......! Dabei gings mir mehr um das Verstehen der Zusammenhänge, und weniger um stupides Abarbeiten von Befehlsreihenfolgen. Wenn ja, ist das hier vielleicht noch mal verwendbar, denn diese Fragen kommen immer wieder neu.
Re: Samba: User verstehen
Das hat absolut geholfen! Bin noch am Austesten. Wie gesagt, sollte man diesen Thread auf jeden Fall in einem Wiki/Blog verarbeiten. Besonders die Erklärung des Zusammenhangs von Linux- und Samba-Usern und der Ansatz mit dem "binds", war mir so bisher nicht untergekommen. Noch n kleiner Lesetip zum Thema User-Rechte in Samba: Endlich verstehen: Samba-Rechtevergabe.TomL hat geschrieben:Haben Dir meine Ausführungen bei Deiner Lösung ein wenig geholfen...?... das würde mich freuen......! Dabei gings mir mehr um das Verstehen der Zusammenhänge, und weniger um stupides Abarbeiten von Befehlsreihenfolgen. Wenn ja, ist das hier vielleicht noch mal verwendbar, denn diese Fragen kommen immer wieder neu.
Re: Samba: User verstehen
Diesmal kein Problem, sondern einen alternativen Lösungsvorschlag für mein bereits genanntes Szenario. Hier zur Dokumentation für andere, oder zum Zerreisen durch erfahrene Samba-Admins.
Szenario: In meinem Netz gibt es einen Windows-User (ayako). Das erachte ich grundsätzlich als risikoträchtig wegen Verschlüsselungstrojanern und anderer Schadsoftware, welche die Daten (u.a. auch Backups) gefärden würden. Es gibt ein Media-Verzeichnis in dem Videos, Musik usw für das gesamte lokale Netzwerk liegen. Der Linux/Samba-User media darf lesend darauf zugreifen. Alle Media-Player hier zu Hause (z.B. suspekte propritäre Geräte, Kodi, usw) nutzen diesen User, um Medieninhalte abzuspielen. Wenn ich was neues hinzufüge oder umschiebe, tue ich das als admin. Mein Windows-User möchte aber auch eigene Sachen da reinmachen können. Also bekommt er von mir Schreibrechte auf ein Unterverzeichnis in Media.
So!
Auf dem Server ist dieses reale Verzeichnis und das dazugehörige Unterverzeichnis für den Windows-User (auf einem RAID-Verbund).
Das erste "bind"e ich auf einen Share-Pfad.
Dazu der Abschnitt aus der smb.conf.
Man sieht schon: media und auch der Windows-User ayako dürfen hier lesend zugreifen. Und admin darf als Ausnahme auch schreiben.
Nun das zweite "bind" für den Windows-User. Hier wird das Media-Unterverzeichnis einfach in den Home-Ordner des Windows-Users ge"bind"et.
Der relevante Abschnitt dazu aus der smb.conf.
Also in meiner Test-Umgebung (mit VirtualBox) scheint es zu funktionieren. Übrigens hab ich die unix-extensions aktiviert (falls das relevant sein sollte?).
Ich würde das "nested shares" oder "verschachtelte Shares" oder "Sub-Shares" nennen. Zu diesen Begriffen hatte ich einiges im Netz gefunden, aber mit ziemlich exotischen hinte-durchs-Auge-Lösungen. Meine Lösung erscheint mir fast zu einfach! Hab ich was übersehen? Ich brauche ja nicht mal einen MediaRO, wie Eingangs vorgeschlagen wurde. Was meint ihr?
Szenario: In meinem Netz gibt es einen Windows-User (ayako). Das erachte ich grundsätzlich als risikoträchtig wegen Verschlüsselungstrojanern und anderer Schadsoftware, welche die Daten (u.a. auch Backups) gefärden würden. Es gibt ein Media-Verzeichnis in dem Videos, Musik usw für das gesamte lokale Netzwerk liegen. Der Linux/Samba-User media darf lesend darauf zugreifen. Alle Media-Player hier zu Hause (z.B. suspekte propritäre Geräte, Kodi, usw) nutzen diesen User, um Medieninhalte abzuspielen. Wenn ich was neues hinzufüge oder umschiebe, tue ich das als admin. Mein Windows-User möchte aber auch eigene Sachen da reinmachen können. Also bekommt er von mir Schreibrechte auf ein Unterverzeichnis in Media.
So!
Auf dem Server ist dieses reale Verzeichnis und das dazugehörige Unterverzeichnis für den Windows-User (auf einem RAID-Verbund).
Code: Alles auswählen
drwxr-xr-x 3 root root 4096 Feb 2 22:58 /mnt/raid/Media
drwxr-xr-x 5 ayako ayako 4096 Feb 3 10:58 /mnt/raid/Media/Ayako
Code: Alles auswählen
/mnt/raid/Media /media/Media none defaults,bind 0 0
Code: Alles auswählen
[Media]
path=/media/Media
browsable = yes
guest ok = no
# keine Schreibrechte = nur Lesen
writeable = no
# zugelassene Benutzer (nur Lesen)
valid users = media ayako
# Ausnahme-User, der auch Schreiben darf (unabhängig von Option writeable)
write list = admin
Nun das zweite "bind" für den Windows-User. Hier wird das Media-Unterverzeichnis einfach in den Home-Ordner des Windows-Users ge"bind"et.
Code: Alles auswählen
/mnt/raid/Media/Ayako /home/ayako/Media none defaults,bind 0 0
Code: Alles auswählen
[homes]
browsable = no
writeable = yes
create mask = 0700
directory mask = 0700
valid users = %S
Ich würde das "nested shares" oder "verschachtelte Shares" oder "Sub-Shares" nennen. Zu diesen Begriffen hatte ich einiges im Netz gefunden, aber mit ziemlich exotischen hinte-durchs-Auge-Lösungen. Meine Lösung erscheint mir fast zu einfach! Hab ich was übersehen? Ich brauche ja nicht mal einen MediaRO, wie Eingangs vorgeschlagen wurde. Was meint ihr?
Re: Samba: User verstehen
Woher kommt sambauser. Diese Gruppe existiert bei mir nicht.TomL hat geschrieben: Die Public-Shares kriegen bei mir alleCode: Alles auswählen
force user = thomas force group = sambauser create mask = 0660 directory mask = 0770 force create mode = 0660 force directory mode = 0770
Welche Linux-Dateirechte Owner und Gruppe hat das Public share. Alle müssen darauf lesen und schreiben können.
Nach meiner bisherigen Konfiguration, kann sich der Client zwar beim Public-Share einhängen, aber nix damit anstellen, weil er nicht die passenden Rechte hat.
Re: Samba: User verstehen
Das hatte ich hier erwähnt.MoonKid hat geschrieben:Woher kommt sambauser. Diese Gruppe existiert bei mir nicht.
Bei mir haben der Admin-Share, Private-Shares und die Public-Shares alle die gleichen Linuxrechte, und zwar 770. Das sind aber nur die "Haupt"-Verzeichnisse, deswegen das X-Flag, den dort angelegten Files ist nur 660 erlaubt, also rw- rw- ---, siehe hier das Beispiel force create mode = 0660 und force directory mode = 0770. Das sieht für die Linux-Verzeichnisse i.ü.S. so aus:;MoonKid hat geschrieben:Welche Linux-Dateirechte Owner und Gruppe hat das Public share. Alle müssen darauf lesen und schreiben können.
Code: Alles auswählen
U G O
770 rwx rwx --- Admin-Shares thomas:thomas
770 rwx rwx --- Public-Shares thomas:sambauser
770 rwx rwx --- Private-Shares in Server-Homedirs {UserName}:{UserName}
Re: Samba: User verstehen
Danke nochmal für die ausführliche Darstellung. Ah, (ich glaube) ich verstehe. Du hast die Gruppe sambauser selbst angelegt? Jeder deiner User ist dort Mitglied und hat daher die Gruppenrechte des Public-Verzeichnisses. Korrekt verstanden? Wenn ich das so sehe, erscheint es mir wieder so einfach.
Re: Samba: User verstehen
Yep!MoonKid hat geschrieben:Korrekt verstanden?
MoonKid hat geschrieben:Wenn ich das so sehe, erscheint es mir wieder so einfach.
Re: Samba: User verstehen
Zu der Verwendung von mount --bind würde mich nochmal genau interessieren, warum du das machst. Du könntest ja auch symlinks verwenden, oder?
Gibt es technische Gründe, oder ist es mehr eine Geschmackssache?
Bisher hatte ich nur verstanden, dass Backups dadurch für dich einfacher sind, weil du nur ein großes Verzeichnis anfassen musst.
Gibt es technische Gründe, oder ist es mehr eine Geschmackssache?
Bisher hatte ich nur verstanden, dass Backups dadurch für dich einfacher sind, weil du nur ein großes Verzeichnis anfassen musst.
Re: Samba: User verstehen
Die Frage 'Symlink' oder 'Mount --bind' hat imho keinen Einfluss auf die Frage "Alle Share-Dirs in einzentrales Sub-Dir" oder "Mit beliebigen Share-Dirs das root-Dir / zerfleddern". Und nicht nur die Backups sind hier ein relevanter Faktor. Ich fühle mich besser dabei, wenn ich die primär-wichtigen Dirs (Sicherheit) des OS von den sekundär-wichtigen Dirs (nur Daten) der Shares konsequent trenne. Das wird umso plausibler, wenn ich sogar noch einen Schritt weiter gehe und auf das Root-Dir des Servers aus Sicherheitsgründen überhaupt keine Zugriff zulasse, sondern die Shares vollständig auf eine externe Platte oder ggf. auch auf eine eigene Partition ausgelagert habe. Die externe Platte (bzw. Partition) wird einmalig nach /media gemountet und die relevanten Shares dieser Platte werden dann via "binds" ebenfalls nach /media repliziert. Aber wie gesagt, das ist halt subjektiv eingeschätzt und insofern nur ein Teil meiner Vorstellung von "Server-Hygiene".
Möglicherweise gibts noch andere Gründe.... dafür oder dagegen.... aber so fit bin ich auch nicht in dieser Materie.
Ja, hier gibt es technische Gründe. Ein symlink ist nur eine Datei, die auf ein Verzeichnis oder Datei absolut oder relativ verzeigert ist. Ein Mount hingegen ist ein Kernelobjekt, also ein Objekt auf deutlich "tieferer Systemebene". Bei einem Chroot z.B. ist der symlink einer Ressource nach 'außen' tot, der Mount nicht. Dann gibts halt Anwendungen, die Symlinks erkennen und besonders darauf reagieren. So fragt z.B. DoubleCommander beim Kopieren "Symlink folgen?". Sagt man "nein", kopiert er nur die Symlink-Datei, anstatt des Inhalts im Original. Ein Symlink ist also nur eine Datei... eine, die gelöscht, umbenannt, gemove'd werden kann. Mir wäre bei Symlinks das latent vorhandene Risiko zu gross, durch eine Unachtsamkeit bei Wartungsarbeiten meine Daten zu zerschießen.MoonKid hat geschrieben:Gibt es technische Gründe, oder ist es mehr eine Geschmackssache?
Möglicherweise gibts noch andere Gründe.... dafür oder dagegen.... aber so fit bin ich auch nicht in dieser Materie.