Samba access/permissions in share's subdirectories

I just set up a samba share which is accessed from Windows clients. The share is like this:


And so on, meaning it’s quite a big tree with many subfolders of subfolders. The share is allowed for unix group “grp1”, so in smb.conf I have “valid users = @grp1”. User1, user2, user3 and user4 are all part of this group. The share folder and all its stuff inside has these attributes: root:grp1 drwxrws—. This because I also used parameter “inherit permissions = yes”.

Now, I need to restrict user4 access to some subdirectories, say for example, direc1 and fdr2, to nothing, i.e., no read, no write, no execute/transverse, without affecting the user’s access to the rest of the complicated tree.

I was told to just add more share definitions in smb.conf for each folder I wanted to set special accesses, but for some reason this seemed to be a bit… cheesy…
So I tried to use posix acls. Tried “setfacl -Rdm u:user4:0 /path/to/…]direc1”, rebooted system just in case, logged in with user4 from a windows client, and I was still lable to read and even write a -previously modified- xls file inside direc1 folder. I checked getfacl and acls were indeed correctly set.
Then tried setting “inherit permissions = no”, still no dice.

By the way, I did take into account this , page 206: “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, Word then renames the new document to the original document name”. Yes, ms office saves the newly modified file with some fancy extended acls by default…

Could someone help?
Thanks beforehand.

I can’t answer to what you should do exactly, but some general principles…

  • Keep in mind that when a User writes a new file, he becomes the new owner of the file.
  • There is a difference between simply not granting permissions vs explicitly denying permissions. Consider which you should or need to implement. Hint - designed correctly, you may not need to explicitly deny.
  • Whether implemented entirely in the actual file system, keep in mind that at least logically there is the underlying file permissions and then there are the share permissions that overlay. Actual effective permissions are a combination result of the two, but it can be complex manipulating both at once. That is why a “Best Practice” is to set a very permissive permission throughout at the underlying file system level and then manage share permissions only. This works fine when Users don’t have local access and can only access using network shares.
  • “Manage by groups.” Don’t manage by a flat permissions hierarchy. Design your permissions to be parents and children. This should apply not only to resources(files and directories) but also Users. Your question suggests that you may not be designing properly… You should either create a new, different share or re-organize your hierarchy. Properly done, your hierarchy should have an elegant flow with zero exceptions.