PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba, Dateirechte sind stets auf 755



dipesh
26.03.03, 16:49
Nach mehrstündiger erfolgloser Suchen nach Lösungsansätzen zu dem Thema...

Von einem Linux-Client (SuSE 8.0, Samba 2.2.3a) aus mounte ich ein Netzwerkshare von einem anderem Linux-System (Woody r1, Samba 2.2.3a-12.1).
Die Rechte von /var/public sind auf 770 gesetzt. Owner ist "hossa" und Gruppe "users". Nach dem mounten von "pub" ist der Eigentümer sämtlicher Dateien und Verzeichnisse jedoch der User "myuser"??? und die Dateirechte sind auf 755 gesetzt???
Hier sollte man doch eigentlich erwarten, dass das Netzlaufwerk die rechte korrekt darstellt, wie sie auch auf dem Server gesetzt wurden.

Woran kann das liegen bzw. wie lässt sich das zu erwartende Ergebnis herstellen?

Hierzu ein Auszug aus der fstab des Clients:


//10.10.10.2/pub /mnt/public smbfs noauto,user,username=myuser,password=mypass 0 0


und die smb.conf des Servers:


[global]
workgroup = doener
interfaces = eth1 10.10.10.2
bind interfaces only = yes
hosts allow = 10.10.10.
netbios name = server2
server string = %h server (Samba %v)
character set = ISO8859-15
time server = yes
load printers = yes
printcap name = /etc/printcap
invalid users = root
log file = /var/log/samba/log.%m
max log size = 500
syslog only = no
syslog = 0
security = user
encrypt passwords = yes
update encrypted = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = yes
os level = 20
domain master = yes
preferred master = yes
wins support = yes
dns proxy = no
name resolve order = lmhosts host wins bcast
preserve case = yes
short preserve case = yes
unix password sync = true
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
obey pam restrictions = yes

[pub]
path = /var/public
comment = Public Share Directory
browseable = yes
writeable = yes
create mask = 0770
directory mask = 0770
#public = yes
#force group = users
#inherit permissions = yes
valid users = @users


Dickes danke im voraus!

LKH
26.03.03, 17:34
Hi,

wenn du mit der Userkennung von "myuser" mountest ist die Sache mit dem User schon mal geklärt. Und das mit den Rechten gehört zum worst case scenario von smbmount, besonders wenn / freigegeben ist. :ugly: Verändern kannst du dieses Verhalten durch die in man smbmount beschriebenen Parameter uid, gid, fmask und dmask.

Hoff es hilft,

dipesh
26.03.03, 17:48
Danke für die schnelle Antwort!

Scheint so, als würden fmask und dmask lediglich die Darstellung (?) ändern. Es ist mir noch imemr nicht möglich Dateien welche der Gruppe "users" gehören zu löschen, obwohl "myuser" zu dieser Gruppe gehört...
Selbst ein gid=users (und ein uid=myuser) bringt da nicht viel...
Selbes Resultat (keine Berechtigung zum loeschen) triet auch auf, wenn der root des clients das share mounted und versucht dieses zu loeschen. Es kann doch nicht sein, dass es bei einer netzwerkressource nur dem Owner erlaubt ist Verzeichnisse/Dateien zu loeschen. Wozu dienen dann die Dateirechte welche auf 770 gesetzt sind?

<me zustand="planlos" />

dipesh
26.03.03, 17:59
*Arg*

Habe des Rätsels Ursache gerade gefunden! Es lag am sticky-bit welches das Verzeichnis besass in welchem die bewussten Dateien lagen. Nach einem chmod -t public ist ein löschender Zugriff möglich. Nur die Logik dahinter fehlt mir...