Rechte von Ordnern

Moin,

irgendwie denk ich das müsste doch hier schon mal beschrieben sein, find's aber nicht.
Problemstellung vermutlich ähnlich zu http://forum.qnapclub.de/viewt…48404&hilit=rechte#p48379
Also:
Wenn ich Ordner von extern erstelle (smb mount, von Linux,
wie auch von Windows-Welt gleiches Verhalten....) haben diese keine Schreibrechte.
Beispiel:
Im Verzeichnis /share/HDA_DATA/schwerdt (auf TS109II) habe ich Unterordner erstellt -
z.B test3
Gemountet wird via SMB mount (Eintrag in /etc/samba/smbfstab vom entfernten Linuxrechner:
//nas1/schwerdt /nas1/schwerdt cifs username=schwerdt,password=MEINPASSWORT

Kommandozeile auf dem nas:
/share/HDA_DATA/schwerdt] # ll -d test*
drwxr-xr-x 2 schwerdt everyone 4.0k Apr 2 15:19 test/
drwxr-xr-x 2 schwerdt everyone 4.0k Apr 2 15:30 test3/
Diese Rechte sind m.E. OK

Vom externen Linuxrechner sieht das so aus:
linux-xzy0:/nas1/schwerdt # ls -ld test*
drwxr-xr-x 2 500 users 0 Apr 2 15:19 test
drwxr-xr-x 2 500 users 0 Apr 2 15:30 test3

Das Mapping der Benutzer funktioniert also offenbar nicht korrekt.
Im nas habe ich in /etc/config/smbusers eingetragen:
schwerdt = schwerdt

Dabei steht sowohl in der /etc/config/smbpasswd als auch in der /etc/passwd des nas:
schwerdt:500:..... beziehungsweise
schwerdt:x:500:100:Linux User,,,:/:/bin/sh
Also beides Mal der User mit der ID 500.

Die smb.conf im nas sieht wie folgt aus:
[global]
workgroup = NAS
security=user
server string=NAS Server
encrypt passwords = Yes
username level = 0
map to guest = Bad User
null passwords = yes
max log size = 10
name resolve order = bcast wins
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=32768 SO_RCVBUF=32768
os level = 32
preferred master = Yes
dns proxy = No
config file = /etc/config/smb.conf
smb passwd file=/etc/config/smbpasswd
username map = /etc/config/smbusers
guest account = guest
directory mask = 0777
create mask = 0777
oplocks = yes
locking = yes
disable spoolss = yes
load printers = no
dos charset = ISO8859-1
# force directory security mode = 0000
template shell = /bin/sh
veto files = /.AppleDB/.AppleDouble/.AppleDesktop/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/
delete veto files = yes
map archive = yes
map system = yes
map hidden = yes
map read only = yes
use sendfile = yes
case sensitive = auto
deadtime = 10
display charset = UTF8

Und der Abschnitt des speziellen Verzeichnisses habe ich jetzt schon sehr gutmütig angepasst:
[schwerdt]
comment = Ralphs - home auf NAS1
path = /share/HDA_DATA/schwerdt
browsable = yes
directory mask = 0777
create mask = 0777
public = yes
invalid users = guest
read list =
write list = schwerdt,admin,@"everyone",@"administrators",@"familie",@"freunde"
valid users = root,schwerdt,admin,@"everyone",@"administrators",@"familie",@"freunde"

in Qmultimedia ists nicht anders. Da ich nicht wirklich verstehe warum das nicht
geht, habe ich mal die Finger davon gelassen jetzt alle /etc/config/smb* - Dateien wild zu editieren.....
In der Weboberfläche hat der Benutzer schwerdt rw-Rechte auf sein Verzeichnis:
schwerdt.

Any idea?

Gruß "schwerdt"

Zitat von "Eraser-EMC2-"

Hallo schwerdt,

ich kenne mich mit dem cifs vom SAMBA nicht aus, aber so wie ich es überblicke,
müssen die UserIDs und GroupIDs auf Client und NAS identisch sein, damit es funktioniert (vergleichbar mit NFS).
Die Benutzerabfrage beim Verbinden ist notwendig, damit SAMBA weiß,
welche Rechte (RO,RW) der Verbindung zustehen.

Moin Stefan,
hmm, es scheint doch eher ein Problem der Benutzerverwaltung auf meinem client zu sein .... :roll:
Die Rechte:
drwxr-xr-x 2 500 users 0 2. Apr 18:25 test2
sind ja prinzipiell OK, aber mir ist völlig unklar, warum die externen Linux-Rechner die User ID
vom NAS als Benutzer erben
Dadurch sind dann die neu erstellten Verzeichnisse einfach nicht mehr schreibbar.
Habe das mit einem völlig neuen Share ausprobiert - gleiches Ergebnis.
Wie krieg' ich dem Linux rechner nun beigebogen,
dass er schwerdt ist und bleibt (und nicht ID 500) ???

Gruß
schwerdt

Zitat von "Eraser-EMC2-"

.... ich kenne mich mit dem cifs vom SAMBA nicht aus, ....

Das war der entscheidende Satz! :thumb: Er hat mich dazu bewogen doch noch mal genauer den Mountpoint auf dem Client anzusehen.

man mount.cifs

sagt:
uid=arg
sets the uid that will own all files on the mounted filesystem. It may be specified as either a
username or a numeric uid. For mounts to servers which do support the CIFS Unix extensions, such
as a properly configured Samba server, the server provides the uid, gid and mode so this parameter
should not be specified unless the server and client uid and gid numbering differ. If the server
and client are in the same domain (e.g. running winbind or nss_ldap) and the server supports the
Unix Extensions then the uid and gid can be retrieved from the server (and uid and gid would not
have to be specified on the mount. For servers which do not support the CIFS Unix extensions, the
default uid (and gid) returned on lookup of existing files will be the uid (gid) of the person who
executed the mount (root, except when mount.cifs is configured setuid for user mounts) unless the
"uid=" (gid) mount option is specified. For the uid (gid) of newly created files and directories,
ie files created since the last mount of the server share, the expected uid (gid) is cached as
long as the inode remains in memory on the client. Also note that permission checks (authorization
checks) on accesses to a file occur at the server, but there are cases in which an administrator
may want to restrict at the client as well. For those servers which do not report a uid/gid owner
(such as Windows), permissions can also be checked at the client, and a crude form of client side
permission checking can be enabled by specifying file_mode and dir_mode on the client. Note that
the mount.cifs helper must be at version 1.10 or higher to support specifying the uid (or gid) in
non-numeric form.

Es muss also heissen:

Zitat

mount.cifs //nas1/schwerdt /nas1/schwerdt -o user=schwerdt,uid=schwerdt

Und es stimmt auch, dass der Eintrag in der /etc/config/smbusers nix bringt. :oops:

Jedenfalls geht's jetzt.

Und ich hatte gelogen :oops: unter Windows war es anders, da ging das, ich hatte offenbar die Notebooks verwechselt .... :roll:

Wie setzt man den Eintrag auf "Gelöst" :mrgreen:

Gruß aus Gö von schwerdt