Hi, After some researches, it appears that the 'force user' parameter was bugged in Samba 4.1.11/ I explain : I've a share configured like this : [Admins] Path = /Share/Admins Force user = administrator Force group = "domain admins" Create mask = 0750 Directory mask = 0750 Read only = No Oplocks = Yes If I mount this share on a linux client (not member of the domain) : # mount -t cifs -ousername=administrator //fileserv/Admins FOO It works and an 'ls -l' reply: total 4 drwxr-x--- 5 10500 50512 0 août 12 14:32 . drwx------ 5 root root 4096 août 4 09:18 .. drwxr-x--- 4 10500 50512 0 août 12 14:33 Linux drwxr-x--- 6 10500 50512 0 août 7 17:27 Windows 10500 is the UID of user "administrator" and 50512 is the GID of group "domain Admins" If I do a 'touch FOO/bar' I get a Permission Denied. I get the same behaviour on a Win7 client (member of the domain). If I comment the "force user" parameter (and restart SAMBA), the touch above works great (on Win7 too). If I uncomment again the 'force user' parameter and try to remove the file 'bar' => "Permission Denied" It's really obvious.... Regards, Bruno.
(In reply to Bruno MACADRE from comment #0) Hey, Have you tried with recent samba version(Samba 4.10.0)? https://www.samba.org/ Meanwhile, I will try with 4.1.11 Thanks
Dear Bruno, I am able to create new file with effective "force user" permissions. samba-4.8.6 # id root1 uid=16777218(root1) gid=16777221(domain users) groups=16777221(domain users),16777223(test-group1),16777226(domain admins),16777225(denied rodc password replication group),16777217(BUILTIN\users),16777216(BUILTIN\administrators) smb.conf [myshare] path = /share force user = root1 force group = "domain admins" create mask = 0750 directory mask = 0750 writeable= yes # mount.cifs -o user=root1 //<smb-ip>/myshare /root/mount-pnt/ debug # cd /root/mount-pnt/ # ls -ltr -rwxr-xr-x. 1 root root 43 Mar 18 13:40 file-1 # touch file2 # ls -ltr -rwxr-xr-x. 1 root root 43 Mar 18 13:40 file-1 -rwxr-xr-x. 1 root root 0 Mar 31 08:32 file2 In log.smbd [2019/03/31 08:32:44.617035, 10, pid=2923, effective(16777218, 16777226), real(16777218, 0), class=smb2] ../source3/smbd/smb2_create.c:666(smbd_smb2_create_send) smbd_smb2_create_send: name [file2] [2019/03/31 08:32:44.617905, 10, pid=2923, effective(16777218, 16777226), real(16777218, 0), class=vfs] ../source3/smbd/vfs.c:1347(check_reduced_name) check_reduced_name realpath [file2] -> [/share/file2] [2019/03/31 08:32:44.618013, 10, pid=2923, effective(16777218, 16777226), real(16777218, 0)] ../source3/smbd/open.c:5017(create_file_unixpath) create_file_unixpath: access_mask = 0x40000080 file_attributes = 0x0, share_access = 0x7, create_disposition = 0x3 create_options = 0x40 oplock_request = 0x100 private_flags = 0x0 ea_list = 0x(nil), sd = 0x(nil), fname = file2 16777218->root1 16777226->domain admins Thanks
Why did nobody notice that the users and group on the Linux client are unknown ? They are all represented by numbers instead of names (except for 'root') So, of course he got permission denied. If nobody complains with a few days, I am going to close this.
OK, nobody complained, closing bug report.