What happens: $ umask 777 $ touch afile > The file has a mode of 644 What should happen: $ umask 777 $ touch afile > The file should have mode 000 Share definition: [userdata] comment = Homes writable = yes path = /srv/drbd/home map archive = no delete readonly = yes preserve case = yes case sensitive = yes short preserve case = yes This bug is trigered when acls are enabled, mounting it with noacl produces the correct behaviour. Side note, the setuids option is enabled and no mode overrides are present in the smb.conf file. The file server is Samba version 3.0.21c.
What I am not sure is, which umask should take precedence or stand out if - I have specified umask on the mount command on the client - samba.conf on the server has a create mask entry - umask on the local file system on the server (the share that samba exports)! I am also not sure why noacl mount flag or absense of it should have any impact on the mode the file is created on the server.
cifstest4:/tmp/sharename # umask 0777 cifstest4:/tmp/sharename # ls -l total 20 drwxr-xr-x 2 root root 4096 Mar 25 05:49 cldir1 drwxr-xr-x 2 root root 4096 Mar 25 06:03 cldir2 Somehow samba server chooses the mask of 0022. I created these directories using smbclient. cifstest6: # smbclient //cifstest4/sharename -U root Enter root's password: Domain=[CIFSTEST4] OS=[Unix] Server=[Samba 3.0.22-3-SUSE-CODE10] smb: \> mkdir cldir2 smb: \> quit This is the stanza in samba.conf [sharename] path = /tmp/sharename browseable = Yes read only = No guest ok = Yes writable = yes I created a file on this share with umask of 0777 from a Windows XP client and the file was created with permissions with umask of 0022 excpet that user had executable bit on which is strange considering the default permissions before being masked with umask for a file are 666.
I think it is fixed now, it is not a bug anymore, I am using 1.54 version of cifs vfs client. //cifstest4/sharename /mnt/smb_a cifs rw,mand 0 0 cifstest6: # umask 0022 cifstest6: # touch /mnt/smb_a/umaskfile_0022 cifstest6: # ls -l /mnt/smb_a/umaskfile_0022 -rw-r--r-- 1 root root 0 Mar 25 22:55 /mnt/smb_a/umaskfile_0022 cifstest6: # umask 0777 cifstest6: # umask 0777 cifstest6: # touch /mnt/smb_a/umaskfile_0777 cifstest6: # ls -l /mnt/smb_a/umaskfile_0777 ---------- 1 root root 0 Mar 25 22:55 /mnt/smb_a/umaskfile_0777 So the umask of the process on the client which creates a file is taken into consideration.
with 1.55 version of the cifs, I see correct permissions on the files on the samba shares as per the umask of the process on the client that creates these files -rw-r--r-- 1 root root 0 Mar 26 03:23 cft4.0022 --w-r--r-- 1 root root 0 Mar 26 03:24 cft4.0522 --w--w-r-- 1 root root 0 Mar 26 03:36 cft4.0552
Yes, this is not a bug anymore, it is fixed in later version of cifs such as 1.55.
yes - verified that it is fixed now