File Permissions Masking with Mount.CIFS
I need some assistance in improving my understanding of file permissions and masks.
I have a basic understanding of file permissions--what r,w,x mean for user, group, other. I don't understand sticky bits but it sounds like I don't need to--please correct me if I'm wrong.
I believe where I really need to improve my knowledge is masks.
umask - I think this is a default mask applied to all files (regardless of their current permissions, assuming you have complete access to the file).
fmask (depreciated for file_mode) - I thought this would set the permissions of any newly file created.
dmask - sets dir permissions
Where I am running into trouble:
I mount a CIFS remote file system. When I copy a file to that system I need the permissions to come up -rwxrwxrwx. What happens is the permissions come up -rw-rw-r-- and it seems this mask is applied no matter what I do. Below you will see several examples I hope illustrate what's happening:
1st mount command: mount -t cifs //remotesystem/share1 ./localdir -o username="myusername"
after normal mount (no umask or any masks) and then copying TestFileC.txt
-rwxrwSrwt 1 root root 167705 May 16 00:41 TestFileA.txt
-rwxrwSrwt 1 root root 171681 Jun 2 10:27 TestFileB.txt
-rw-rw-r-- 1 root root 192374 Jun 2 10:59 TestFileC.txt
-rwxrwSrwt 1 root root 135626 Jun 1 13:00 TestFileD.txt
2nd mount command: mount -t cifs //remotesystem/share1 ./localdir -o username="myusername",umask=777
after mount with umask=777 and then copying TestFileE.txt
-rw-rw-r-- 1 root root 258297 Jun 2 12:00 TestFileE.txt
-rwxrwxrwx 1 root root 167705 May 16 00:41 TestFileA.txt
-rwxrwxrwx 1 root root 171681 Jun 2 10:27 TestFileB.txt
-rwxrwxrwx 1 root root 192374 Jun 2 10:59 TestFileC.txt
-rwxrwxrwx 1 root root 135626 Jun 1 13:00 TestFileD.txt
* Note TestFileC.txt received the correct mask. I suspect this is because of the way I mounted the share. When I copied in TestFileE.txt it recieved the wrong mask and appears -rw-rw-r--
3rd mount command: mount -t cifs //remotesystem/share1 ./localdir -o username="myusername",file_mode=0666
after mount with file_mode 0666 and then copying TestFileE.txt (deleted and then copied again)
-rw-rw-r-- 1 root root 258297 Jun 2 12:12 TestFileE.txt
-rw-rw-rw- 1 root root 167705 May 16 00:41 TestFileA.txt
-rw-rw-rw- 1 root root 171681 Jun 2 10:27 TestFileB.txt
-rw-rw-rw- 1 root root 192374 Jun 2 10:59 TestFileC.txt
-rw-rw-rw- 1 root root 135626 Jun 1 13:00 TestFileD.txt
A few additional details:
client is RHEL r5.1 (Tikanga)
fileserver ("remotesystem") is Windows 2000 AE
mount entry is not in /etc/fstab
I don't know if I have provided enough information. Please let me know if you need something more.
My goal and question:
How do I set up a mask so that when I copy or create new files in the share they receive the correct and default mask -rwxrwxrwx?
In case this is pertinent to my question, here is my fstab:
The one really important piece of information that you left out of your post is the permissions on the test files as they exist in the local file system. Those permissions should be carried over to the new file that is created on the CIFS file system.
I reread the man page on smbmount before I replied. The dmask and fmask options in the mount command are not umasks. Therefore they cannot be used to force file permissions onto files being created on the CIFS file system.
All of the mount parameters having to do with owner and permissions are pseudo permissions. They are created in the Samba interface when you access a mounted CIFS file system. Those permissions and file ownerships are not carried over to the remote file system. They only exist in the Samba interface.
More information can be found in the manual page for smbmount.
When it comes to creating a new file on any file system you cannot force Linux/UNIX to automatically set the execute bit. If your umask is 000 your new file will have the permissions of rw-rw-rw-. You always have to set the execute bit yourself after the file is created.
I wasn't 100% sure so I ran another quick test.
Here is the file in the dir of origin which is owned by user1:
-rwxrwxrwx 1 user1 user1 77202 Apr 23 13:36 Screenshot-TestIM.png
Here is the file on the file server after the copy:
-rw-rw-r-- 1 root root 77202 Jun 2 17:32 ./Screenshot-TestIM.png
All test files on the local system started like the original, above, and then ended up like the 2nd listing, also above.
I had noticed that dmask and fmask seemed to force the default attributes of existing files at the time of mount but not, as you said, something that forces permissions on newly created (or copied) files. I was hoping fmask would force files through a umask type operation but again, I've discovered that clearly isn't the case.
On my RHEL v5.1 client I have been using
When I try
it says "No manual entry for smbmount"
I did a quick -
rpm -qa | grep amba
to verify I have the samba client installed.
I am comfortable with the need to manually set the exe bit. I would be happy if I could just get to -rw-rw-rw once they are created in the file server directory.
So to summarize:
1. The files start out -rwxrwxrwx and end up -rw-rw-r-- (and I need -rw-rw-rw)
2. I don't have smbmount -- but may not be an issue as I can and have reviewed the man page for mount (but please let me know).
I'm going to read the man page again and see if I can find something I'm missing. If there's anything else I can supply to help with troubleshooting, please let me know.
Thank you very much for your help!
Maybe RH man pages have something along the lines of cifsmount? Anyway, on my system, the smbmount shows all of the parameters to use with mount -t cifs or mount -t smbfs. That's all it really is.
I'll have to admit that from the time that I started working with computers the behavior of file copies with respect to file ownership and permissions has always been elusive. At least now you know that Samba will create pseudo file permissions that only last as long as the connection lasts.
Read through the mount.cifs manpage. The cifs filesysten has support for Unix to Unix permissions. You can even use Linux acls if the target file system supports them. The umask and owner and group options are fallback smbfs like options in case the target filesystem or server don't support the cifs filesystem. If the cifs permissions are supported, the files will be created with those permissions. However if a filesystem like win32 is being shared, then they won't.
About the sticky bit. If you offer a writable share that more than one person can use, then you need to protect files from being deleted by anyone with write access to the parent directory. Deleting files removes the filename-inode from the directory, so it is an operation on the parent directory instead of the file. The sticky bit is used on the parent directory to protect the files inside. Suppose that as root you create a file in your home directory, owned by root with 700 permissions. You will still be able to delete the file even though you can't read, write or execute the file.
|All times are GMT -5. The time now is 11:29 AM.|