Making the best out of two worlds
© 2010-2013 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later
Microsoft Windows has a different way of assigning rights. To get SAMBA to play nicely with both the GNU/Linux filesystem and the Windows system can sometimes be a problem. So let us have a look at how Windows assigns permissions to users and groups, this way we get a better understanding of what the problems are. The different permission settings in a Windows system are:
I expect the GNU/Linux system to be the basis of all access rights. All rights and ACLs should be changed through the use of GNU tools as described above. To accomplish this the first settings we are going to set in the smb.conf per share is the inherit permissions and inherit acls settings:
inherit permissions = yes inherit acls = yesRead the smb.conf manual page for a detailed decription.
With inheritance installed we do not need create mask, force create mode, directory mask and force directory mode, because that is overwritten by the inherit permissions setting, making our setup easier to read. Within SAMBA there are only a couple more entries that can be used to control the file permissions:
Normal documents and files do not have the eXecute bit set. SAMBA can use this X-bit to provide extra DOS file attributes, but one can also use the extended attributes to store the DOS attribute information.
The DOS file system has a READ ONLY bit. This means that if this bit is set, the file is regarded as read only. SAMBA can set this bit by using the map read only setting. The default for this setting is yes, which means that the POSIX user-write bit determines the state of READ ONLY bit. When the write bit is not set on the POSIX system, the READ ONLY bit is set in the DOS attributes. This is regardless of the owner being the user accessing the file.
Another option for this setting is: permissions. Then the state of the DOS READ ONLY attribute is set by the effective rights of the user trying to access the file.
If the option is set to no, then the state can only be set by the store dos attributes method, for all other use the read only bit is never set.
|map archive||yes||user||DOS archive attribute|
|map system||no||group||DOS system file attribute|
|map hidden||no default||world||DOS hidden file attribute|
If store dos attributes is set to yes then these parameters work as a fall back, unless you set them all to no. See the "Using extended attributes" section for more on this option.
SAMBA can use the extended user attributes to store the DOS file attributes. It can even put the inherit and protected access control entry flags stored in Windows ACLs into an extended attribute. To use this functionality the disk that provides the SAMBA shares should be mounted with the user_xattr option.
As of SAMBA version 3.3 there is a back ported VFS module called vfs_acl_xatter, which enables the full mapping of Windows ACLs on SAMBA servers. The ACLs received from a Windows system is stored in an Extended Attribute called security.NTACL. Note that this attribute is not shown by the getfattr -d filename, it can only be retreived by naming it as in: getfattr -n security.NTACL filename.
To enbale this feature for a share add to the share definition in you smb.conf the line:
vfs objects = acl_xattrThe file system on which you add this share should, of course, support the use of Extended Attribute! On ext3 and ext4 file systems this means that the mount option user_xattr should be used.
Next to storing the Windows ACL information into an Extended Attribute (EA), SAMBA will try to map the access rights to the rights of the underlying file system, as of SAMBA 3.5.6 this works very well. How well this works depends on the file system at hand. If you manually change an ACL on the host system, that is also having a Windows ACL in an EA, SAMBA will remove the Windows ACL from the EA and regenerate the EA from the host systems view on the file access rights. So if the goal is to maintain the Windows ACLs one should not fiddle with the ACLs on the host system.
The fact that SAMBA tries to map the Windows ACL into an ACL on the hosts file system means that the host machine must also support ACLs. For ext3 and ext4 you can add the acl option when mounting the file system. However the default ACLs (more or less the abandoned draft POSIX.1e standard), do not map well to the ACLs of Windows. Better support is provided by the NFSv4 ACLs, which are more or less a copy of the Windows ACLs. To enable this feature on ext3 use the acl=nfs4 mount option. For ext4 use the richacl mount option.
There is currently no way to ONLY store the Windows ACLs and not adjust the hosts ACLs. From a mailinglist post of Jeremy Allison dated Dec 13, 2004:
You could slot in a "null" ACL module underneath the acl_xattr layer that always allowed acl set and returned an "allow everyone" acl on read, but that isn't coded yet (shouldn't be too hard though). Currently if you want "native" NT ACLs only I suggest you use the NFSv4 module, which is pretty close to native Windows ACLs.
When requesting the ACLs on a file or directory from SAMBA using smbcacls or using Windows through Properties->Security the NTACLs are shown. The Windows ACLs can deny additional access, but not override the ACLs of the host system. Note that both ACL systems are considered when accessing a file!
Our normal settings for a group directory are 2750, and the files within that directory have 0770. This works perfectly, except for Microsoft Office. Via some dumb testing by changing all the different settings we found that it only worked when we have the directory on 2770. The SAMBA HOWTO Collection had the answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name.
So MS Office actually creates a new file, instead of rewritting the original file... I think this is another reason to use Open Office.
A bit dated document, but with a lot more information, can be found on the SAMBA site: Chapter 16