smbmount - Schreibrecht für alle/User
Tach Liste, hat jemand zufällig die Syntax für einen fstab-Eintrag zur Hand, mit dem man ein entferntes Samba-Share mounten kann, und zwar so, daß alle ein Schreibrecht drauf haben? Wenn ich schreibe: //srv/files /files smbfs user=x,password=y,uid=1000,gid=100 0 0 dann wird zwar das Share gemountet, aber nur als Root habe ich Schreibrechte. Der Eintrag uid=1000 wird einfach ignoriert, und folglich hat der User mit der ID 1000 auch kein Schreibrecht. Am liebsten wäre mir, wenn alle User einfach ein Schreibrecht auf das Share hätten. Aber wenn ich etwas wie umask=000 notiere, dann schlägt das Mounten des Shares von vornherein fehl. Danke+Gruß. Andy
Am Montag, 4. April 2005 10:53 schrieb Andreas Feile:
Tach Liste,
hat jemand zufällig die Syntax für einen fstab-Eintrag zur Hand, mit dem man ein entferntes Samba-Share mounten kann, und zwar so, daß alle ein Schreibrecht drauf haben?
Wenn ich schreibe:
//srv/files /files smbfs user=x,password=y,uid=1000,gid=100 0 0
//desktop/d /mnt/desktop/d smbfs password=xxx,uid=guido,gid=users,fmask=777,dmask=777,rw 0 0 Probier das mal. Gruß Guido
Guido Pinkernell, Montag, 4. April 2005 22:50:
//desktop/d /mnt/desktop/d smbfs password=xxx,uid=guido,gid=users,fmask=777,dmask=777,rw 0 0
Probier das mal.
Danke, bin Donnerstag wieder im Büro, da werde ich mir das mal ansehen. Gruß. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Guido Pinkernell, Montag, 4. April 2005 22:50:
//desktop/d /mnt/desktop/d smbfs password=xxx,uid=guido,gid=users,fmask=777,dmask=777,rw 0 0
Also ich habe jetzt folgende Zeile integriert: client79:~ # grep filesrv /etc/fstab //filesrv/files /lan/filesrv smbfs \ rw,uid=afeile,gid=users,password=y,fmask=777,dmask=777 0 0 Allerdings ändert das nichts: client79:/lan/filesrv # touch hallo client79:/lan/filesrv # dir hallo -rw-r----- 1 1015 users 0 Apr 5 14:13 hallo Wie man sieht "gehört" die Datei hallo dem User 1015, den es auf dem importierenden System aber nicht gibt. Der Benutzer afeile hat die ID 1000, und folglich kann er nur lesend auf die Datei zugreifen. Die smb.conf auf dem exportierenden System sieht so aus: [files] comment = Fileserver path = /srv/filesrv/data/files writeable = Yes browseable = Yes force user = server guest ok = Yes create mask = 0770 directory mask = 0770 Der User server hat die ID 1015. Wie kommt das importierende System dazu, die UID der importierten Dateien gleich mit zu übernehmen? Warum richtet sich das importierende System nicht nach meinen Vorgaben in der fstab? Danke für eure Hilfe. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Dienstag, 5. April 2005 14:19 schrieb Andreas Feile:
Warum richtet sich das importierende System nicht nach meinen Vorgaben in der fstab?
Ich hatte das Problem mal unter SuSE 9.2 mit automatisch gemounteten USB-Geräten. Habe dann Hotplug deaktiviert und udev passend konfiguriert, dass die USB-Geräte entsprechend der fstab gemountet wurden. Bei dir sind aber offensichtlich keine USB Geräte im Spiel. Da weiss ich als relativer Linuxanfänger jetzt auch nicht weiter ... Guido
Guido Pinkernell, Montag, 4. April 2005 22:50: ................................................ Die smb.conf auf dem exportierenden System sieht so aus:
[files] comment = Fileserver path = /srv/filesrv/data/files writeable = Yes browseable = Yes force user = server guest ok = Yes create mask = 0770 directory mask = 0770
Der User server hat die ID 1015. Wie kommt das importierende System dazu, die UID der importierten Dateien gleich mit zu übernehmen?
Warum richtet sich das importierende System nicht nach meinen Vorgaben in der fstab?
Der User afeile "kommt zwar an", wird aber wegen force user = server auf den user server "gemappt". Zitat aus http://www.15bit.de/sambaref/sambaref_F.html: Wenn in einer Service-Sektion dieser Parameter mit einem User-Namen belegt wird, so bekommen alle Clients, die diesen Dienst verwenden, den "force user"-Namen. Mit diesem Parameter läßt sich die Mitbenutzung von Dateien auf recht einfache Weise konfigurieren. Da der User-name erst dann dem Client zugewiesen wird, wenn die Verbindung zum Server etabliert ist, muß sich natürlich der Client zuerst mit seinem richtigen Namen und Passwort beim Server authentifizieren, erst dann werden alle Dienste als "forced user" ausgeführt, egal welchen Namen der Client tatsächlich hat. Zitatende. Gruss Rainer -- Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
Rainer Kulhanek, Dienstag, 5. April 2005 16:47:
Der User afeile "kommt zwar an", wird aber wegen force user = server auf den user server "gemappt". [...] Zitat aus http://www.15bit.de/sambaref/sambaref_F.html: [...]
Das ist korrekt so, und soll ja auch so sein. Was mich stört ist, daß es mir nicht gelingt, den mittels fstab-Eintrag importierten Verzeichnisbaum mit Rechten zu versehen, die jedem User einen Zugriff ermöglichen, und nicht nur Root. Es geht also nicht darum, wie der Server die User handhabt, sondern wie es der Client tut. Beim Mounten einer DOS-Partition kann ich doch zB mit umask=000 festlegen, mit welchen Rechten das dosfs gemountet wird. Das ist nötig, weil dosfs die Unix-Rechte nicht kennt. Ebenso müßte es sich doch bei Samba verhalten. Das smb-Protokoll kennt die Unix-Rechtearchitektur nicht. Folglich müßte es auf irgend eine Weise möglich sein, dem importierten FS beim mounten Rechte zuzuweisen. Oder irre ich da? -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Rainer Kulhanek, Dienstag, 5. April 2005 16:47: .................................................
Das ist korrekt so, und soll ja auch so sein.
Was mich stört ist, daß es mir nicht gelingt, den mittels fstab-Eintrag importierten Verzeichnisbaum mit Rechten zu versehen, die jedem User einen Zugriff ermöglichen, und nicht nur Root.
Es geht also nicht darum, wie der Server die User handhabt, sondern wie es der Client tut.
Wahrscheinlich verstehe ich Dich falsch :-(
Beim Mounten einer DOS-Partition kann ich doch zB mit umask=000 festlegen, mit welchen Rechten das dosfs gemountet wird. Das ist nötig, weil dosfs die Unix-Rechte nicht kennt.
Korrekt.
Ebenso müßte es sich doch bei Samba verhalten. Das smb-Protokoll kennt die Unix-Rechtearchitektur nicht.
Korrekt. Jedoch "spricht" Samba dann mit dem Unixsystem und das kennt Rechte! Also wird der "Sambazugriff" an den Unixrechten abgeprüft.
Folglich müßte es auf irgend eine Weise möglich sein, dem importierten FS beim mounten Rechte zuzuweisen.
Die Rechte hängen am Dateisystem. Das heisst der Server (der die Freigabe stellt) bestimmt auf der Unixseite die Rechte. Beispiel: Sambazugriff von User Alfred auf einen share. Der *Share* ist für Alfred mit Vollzugriff freigegeben. Auf der Unixseite hat das freigegebene Verzeichnis die Rechte rwx rwx --- für root root andere. Dann scheitert der Zugriff von Alfred auf den Share. Ist praktisch genauso wie unter Windows: Die Rechte der Dateiebene haben Vorrang. Kannst Du auf der Dateiebene nur lesen hilft Dir die Freigabe mit Vollzugriff nicht. In fstab/smbfstab legst Du fest als welcher User Du Dich mit der Freigabe verbindest und mit der maske kannst Du die Rechte des auf dem Server befindlichen Verzeichnisses weiter *einschränken*. Diese Maske wird UND-verknüpft mit den "Orginal"-Rechten auf dem Server. Du solltest also evtl. das Verzeichnis das Du freigibst entsprechend ausstatten. Zum Test vielleicht einfach mal mit rwx rwx rwx root users andere. Hm, war es das oder hab ich Dich voll daneben verstanden? Gruss Rainer -- Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
Servus Rainer. Rainer Kulhanek, Dienstag, 5. April 2005 18:43:
Korrekt. Jedoch "spricht" Samba dann mit dem Unixsystem und das kennt Rechte! Also wird der "Sambazugriff" an den Unixrechten abgeprüft.
Ah, das war mir nicht klar. Ich wußte nicht, daß sich ein samba mit einem smbmount in der Weise unterhalten kann, daß dann Unix-Rechte transportiert werden. Das erklärt natürlich mein Problem, und ich muß es serverseitig angehen. Aber nur damit ich es auch vollständig verstanden habe: Wenn ein Windows-Client sich mit samba verbindet, dann unterhält sich samba mit diesem Client nur deswegen nicht über die Rechte auf Dateisystemebene, weil Windows sie nicht kennt. Samba mappt dann in meinem Fall wegen force user... alles auf diesen User, und fertig. Verbindet sich dagegen ein Unix-System via smbmount mit samba, dann unterhält sich samba mit dem Unix über die Rechte auf Dateisystemebene, einfach deswegen, weil das Unix-System das Rechtesystem kennt. Richtig? Woher weiß samba, welches OS Clientseitig läuft? Ist das denn im smb-Protokoll vorgesehen?
Hm, war es das oder hab ich Dich voll daneben verstanden?
Nein, Du hast mich sehr richtig verstanden. Vielen Dank für die Mühe, das alles aufzuschreiben. Andy -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Dienstag, 5. April 2005 19:29 schrieb Andreas Feile: .....................................
Also wird der "Sambazugriff" an den Unixrechten abgeprüft.
Ah, das war mir nicht klar. Ich wußte nicht, daß sich ein samba mit einem smbmount in der Weise unterhalten kann, daß dann Unix-Rechte transportiert werden. Das erklärt natürlich mein Problem, und ich muß es serverseitig angehen.
Ein klares jein! Sieh Samba einfach als Übersetzer zwischen SMB-"Sprache" und Unix-"Sprache". Samba hat sowohl einen Serverteil als auch einen Clientteil. Mit smbmount übersetzt Du Unix in SMB. Das versteht ein SMB-Server (egal ob Windows oder Samba). Dieser SMB-Server spricht nun mit der Betriebssystemebene die den Dateizugriff macht (auch hier egal ob Windows oder Samba). Dieses "Wirtssystem" überprüft ob die (beim Wirtssystem) geltenden Rechte dies zulassen. Ok, die Erklärung holpert jetzt, aber ich glaube so kommts gut rüber. smbmount ist einfach ein Programm aus der "Samba Client Suite", gehört also zu Samba.
Aber nur damit ich es auch vollständig verstanden habe:
Wenn ein Windows-Client sich mit samba verbindet, dann unterhält sich samba mit diesem Client nur deswegen nicht über die Rechte auf Dateisystemebene, weil Windows sie nicht kennt.
Samba unterhält sich mit dem Client nur über die Freigabe(SMB)-Rechte.
Samba mappt dann in meinem Fall wegen force user... alles auf diesen User, und fertig.
Samba mappt weil die Angabe force user = xy in der Beschreibung der Freigabe vorhanden ist.
Verbindet sich dagegen ein Unix-System via smbmount mit samba, dann unterhält sich samba mit dem Unix über die Rechte auf Dateisystemebene, einfach deswegen, weil das Unix-System das Rechtesystem kennt.
Nein, sondern (siehe oben): Samba unterhält sich mit dem Client nur über die Freigabe(SMB)-Rechte. Sieh es mal so: DateiSystem = DS BetriebsSystem = BS NetzwerkFreigabeRoutinen = NFR DS <---> BS <--> NFR <--> SMB-Protokollsprache <--> NFR <--> BS <--> DS Egal ob das BS zweimal Unix, zweimal Windows, oder gemischt ist und egal ob links oder rechts eines Server ist, es gilt immer: Es zählen für die Zugriffe von BS auf DS die jeweiligen Rechte des BS und von NFR zu NFR die Rechte der Freigabe. Auch im reinen Windowsnetzwerk!
Richtig? Woher weiß samba, welches OS Clientseitig läuft? Ist das denn im smb-Protokoll vorgesehen?
Du siehst, Samba muss es nicht wissen! Es handelt nach aussen in der Sprache des SMB-Protokolls, nach innen in der Sprache des Systems. Gruss Rainer
Andreas Feile schrieb:
Tach Liste,
hat jemand zufällig die Syntax für einen fstab-Eintrag zur Hand, mit dem man ein entferntes Samba-Share mounten kann, und zwar so, daß alle ein Schreibrecht drauf haben?
Wenn ich schreibe:
//srv/files /files smbfs user=x,password=y,uid=1000,gid=100 0 0
Mit folgendem Eintrag gehts bei mir: //composter/daten /home/windows smbfs fmask=0707,dmask=0707,username=xxx,password=yyyy Allerdings habe ich den Eintrag nicht in der fstab sondern in der smbfstab. Hatte den Eintrag auch vorher in der fstab und da hat es nicht so richtig Funktioniert. Die smbfstab ist unter /etc/samba zu finden. Gruß Stefan
Das liegt daran, das du beim Samba-Server //srv die "unix extensions" aktiviert hast. Hm, so wie smb.conf grad verstehe, kann es sein, das es reicht das auf dem Client zu deaktivieren... -- Peter
Peter Wiersig, Dienstag, 5. April 2005 19:53:
Das liegt daran, das du beim Samba-Server //srv die "unix extensions" aktiviert hast.
Das wars, danke. Wieder ziemlich viel gelernt in diesem Thread. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
participants (6)
-
Andreas Feile -
Andreas Feile -
Guido Pinkernell -
Peter Wiersig -
Rainer Kulhanek -
Stefan Schmid