SMB with ACLs: Files Not Visible By Owner... What am I missing?

[Hibiki]

Hi,

I upgraded to TrueNAS 12.0-U1.1 and by following several tutorials, I'm trying to play with ACLs in order to tune a minimum the shares.

Here is my problem: Let's simplify it with "common" words :)

We have the group Parents and the group Kids. Parent1 and Parent2 are part of the group Parents and Kid1 / Kid 2 are part of the group Kids.

Each kid has its own share with:

Owner: Kid 1 (rwx)
Group: Parents (rwx)

Why the group is Parents? To be able to create file and monitor the content of their share.
And also avoid that Kid 2 is able to access the share of Kid 1.

The dataset is created with Share Type: Generic and I applied the classic Unix rights: 770 (everyone should not have any access to these personal shares).

Then I created the "Edit Permissions" with "USE ACL MANAGER". I chose the preset RESTRICTED.
I checked Apply User, Apply Group, Apply Permissions Recursively and Traverse.
I have the following ACL:

owner@ / Allow / Basic / Full Control / Basic / Inherit
group@ / Allow / Basic / Full Control / Basic / Inherit

getfacl is correct on the dataset:

# file: Test for Sharing
# owner: Kid 1
# group: Parents
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

When I'm connected as Parent 1 and Parent 2, I can create a file, change its content and delete it. Parent 1 can do whatever he wants on either Parent 1 or Parent 2 files / folders. And vice-versa.

But... Kid 1 is able to connect and to do the same things but... He is unable to see the files / folders from Parent 1 and Parent 2.
Why ?

I tried to an ACE with user / Kid 1 / Allow / Basic / Full Control / Basic / Inherit
And getfacl is updated as is:

# file: Test for Sharing
# owner: Kid 1
# group: Parents
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
user:Kid 1:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow

But even with this, he is not possible to see the files from Parent 1 or Parent 2.

What am I missing?

Thanks a lot for the help.

 

[KrisBee]

I would have expected your last change to work as you wanted if you had remembered to apply the change recursively so the change is applied to all pre-existing files/folders in the shared dataset.

Why were files/folder created by parent1 not visible to kid1 with your original ACL owner/group scheme? Log into the share as kid1 and you create a file owned by kid1 and with group parent. Log into the share as parent1 and you create a file owned by parent1 and with group parent (note the file owner here). Log back into the share as kid1, would you expect to see a file not owned by kid1?

PS As you are using SMB share, the dataset ought to be created with a share type of SMB. ( FYI, the first getfacl output you posted ,which is meant to be for a "restricted" ACL preset, doesn't look correct as group@ still has "full control". )

 

[Hibiki]

Thanks KrisBee for the answer.

>> For the RESTRICTED ACL preset, I change the group@ to Full Control manually. I just used the profile for guidelines.

>> For the share type, as I used also these datasets with a NFS sharing type, I preferred to keep it Generic. If I remembered well the documentation, the only difference is that in SMB type, you cannot use chmod (pure Unix approach for the right). Am I correct?
What can happen if I stick to Generic in this case?

>> I was very surprised not to see at least the files... However I did a getfacl on a file generated by Parent 1 for example and... the line user:kid 1 is not appearing so... I certainly forgot to apply it recursively.
So, I went back to Edit Permissions page of the dataset and I check these checkboxes.
I redid a getfacl on a file generated by Parent 1 and... the line user:kid 1 is present.
I connected again to the share and... it works!

Shame on me... Thanks for the hint (as I was sure to have done it at the beginning).

Thanks a lot!

 

[KrisBee]

What can happen if I stick to Generic in this case? In this case chmod will be allowed which is not correct for a SMB share and case sensitivity is incorrectly set which is immutable. You would need expert advice from @anodos to explain other possible side effects in the various ixsystems VFS modules that work in the background with SMB shares.

 

[Hibiki]

Thanks for the feedback.
To be honest, I watched a Youtube video from Lawrence Systems about this and as it stays in Generic, I thought it was not really "important".
With Generic, I change the Case Sensitiviy to Insensitive.

However what happens if I have a NFS share with a SMB dataset type: may I have (more) issue(s)?

 

[KrisBee]

Yes, because chmod will not function with a dataset created as share type SMB ( dataset property acltype is set to restricted in the background) and unix/linux would expect chmod to work and its normal to have case set to sensitive, wereas it would be set to insensitive. The sensitivty setting may not be crucial but there are some subtle side effects when it's not set as normal. Additionally, the way the webui works may force you into the ACL editor pages when it's not appropriate and by default a dataset created a SMB share type will have a default ACL which does not map to simple and standard rwx type unix permissions.

 

[Hibiki]

Thanks for the reply. But what if the same dataset is also shared in NFS?

As it is written in User Manual:
"Typically, a new dataset should be created when creating a new SMB share. It is recommended to use the SMB Share Type preset for the ZFS dataset. This will set the ZFS dataset’s aclmode property to “restricted”, case sensitivity to “insensitive”, and apply a default ACL on the newly created dataset. The default ACL is restrictive and will only grant access to the dataset owner and group. Further modification of this default ACL may be required depending on intended usage of the share".

The only thing that I missed in this case is the "ZFS dataset’s aclmode property to “restricted”"

However, I cannot change now the share type of any dataset without destroying it and copy again the data on it. Is there any workaround?

 

[KrisBee]

Thanks for the reply. But what if the same dataset is also shared in NFS?

If you mean the same dataset is shared both by using SMB and NFS with simultaneous access, then that's a recipe for inconsistent result. On a small home network with a mix of windows, macOS and linux clients you can use SMB throughout. In theory, as dataset case-sensitivity is immutable it is a case of recreation. But search the forum for a post where ixsystem's @anados discusses the issue of case-sensitivity.

 

[Hibiki]

Not really simultaneous access but I foresee to have VMs (such as Plex or DLNA server) which has access to the shares through NFS.
So I do not plan to allow both Windows and VMs to write simultaneously or I can... prey!

As another example, for newsgroups, I have SABnzbd in Jail that can read/write into a dataset Download for example which is shared with my Windows machine so I tried to stick with, as much as possible, standard unix rights for avoiding misfortune... (I agree that the Jail has a direct access to the dataset without the need to go through an access protocol such as NFS - I'm dumb but... I'm learning or at least trying to learn :)).

 

[KrisBee]

Your VMs can mount SMB shares and dealing with the likes of SABnzbd in jail is shown in this blog of 2020: https://www.ixsystems.com/blog/plex-permissions/

 

[Hibiki]

Thanks. I'm going to read this article.
Thanks!