SMB Sharing sub folder with traverse

[Malakym]

Having some trouble currently sharing a sub folder in a parent folder that has no permissions. It should allow access direct to that folder (via UNC/shortcut etc) without any other settings according to some, yet others say you need the traverse permissions.

In my own testing I need traverse on the parent, and this works fine when sharing from a windows machine, but not from freenas (that has joined the domain). I've scaled back the options like group for testing currently by using a specific user to avoid any problems with nested groups with no luck.

As an example...

Parent (R/W for all users)
----Dir1 (no inherit, r/w for UserA)
--------SubDir1 (inherit + r/w for UserB)
----Dir2 (no inherit, r/w for UserB)

UserA cannot see/access Dir2 as expected, and UserB cannot see/access Dir1 as expected - thus access based enumeration seems to be on, even though docs says its default off? and its not on in the freenas config.

What we want is UserB to access a single folder inside a folder that is normally only for UserA, without having full access to everything.

In a windows server, setting r/w on SubDir1 is not enough, but putting Traverse on Dir1 allows UserB direct access to SubDir1 - this is okay.

Similar setting on as FreeNAS share does not work, we have even tried putting Traverse+List Folder on Dir1 and UserB cannot even browse through the folders either.

 

[anodos]

Having some trouble currently sharing a sub folder in a parent folder that has no permissions. It should allow access direct to that folder (via UNC/shortcut etc) without any other settings according to some, yet others say you need the traverse permissions.

In my own testing I need traverse on the parent, and this works fine when sharing from a windows machine, but not from freenas (that has joined the domain). I've scaled back the options like group for testing currently by using a specific user to avoid any problems with nested groups with no luck.

As an example...

Parent (R/W for all users)
----Dir1 (no inherit, r/w for UserA)
--------SubDir1 (inherit + r/w for UserB)
----Dir2 (no inherit, r/w for UserB)

UserA cannot see/access Dir2 as expected, and UserB cannot see/access Dir1 as expected - thus access based enumeration seems to be on, even though docs says its default off? and its not on in the freenas config.

What we want is UserB to access a single folder inside a folder that is normally only for UserA, without having full access to everything.

In a windows server, setting r/w on SubDir1 is not enough, but putting Traverse on Dir1 allows UserB direct access to SubDir1 - this is okay.

Similar setting on as FreeNAS share does not work, we have even tried putting Traverse+List Folder on Dir1 and UserB cannot even browse through the folders either.

Access-based enumeration applies only to shares. It's something that's defined through a combination of smb.conf parameters and Share ACLs (not filesystem ACLs).

What you're observing is a side-effect of the interaction between Samba (the SMB service) and the underlying filesystem ACLs. In order for folders / files to be visible a user needs to be able to stat() the file / folder. In the windows "advanced" permissions editor having "read attributes" and "read extended attributes". To make it so that all folders are visible to all users with access to a share, you can add an "Everyone" ACE with the aforementioned permissions. Since the users won't have "read data", they will be unable to traverse the folders even though they can see them.

There isn't really a way to make ZFS ACLs to act precisely like NTFS ACLs in this way. I'd say that they are 95% similar, but it's important to understand the differences if you're planning to use FreeNAS in production in a business environment.

 

[Malakym]

Thanks for that - I was aware there were some differences but never hit anything in practice until now.

To test quickly I dropped read attr./extend. on everyone and Dir1 folder showed in the Parent list. UNC directly to the sub folder (SubDir1) in question worked. As I cleaned up the permissions though and started from scratch this doesn't seem to do the trick - even though I can still see Dir1 in the Parent list.

 

[anodos]

Thanks for that - I was aware there were some differences but never hit anything in practice until now.

To test quickly I dropped read attr./extend. on everyone and Dir1 folder showed in the Parent list. UNC directly to the sub folder (SubDir1) in question worked. As I cleaned up the permissions though and started from scratch this doesn't seem to do the trick - even though I can still see Dir1 in the Parent list.

Well a few quick points about ACLs in FreeNAS.

• The volume permissions you set through the FreeNAS webgui (owner / owner group) equate to "CREATOR OWNER" and "CREATOR OWNER GROUP" in Windows... even though they don't look like it through Windows Explorer. See discussion here: https://bugs.freenas.org/issues/21603 This means you'll want to add additional access control entries to define permissions for your users and groups.
• Because of the way that NFSv4 permissions work, I believe users will need (at a minimum) read access (I thought "read attributes / xattrs" would be enough, but I may be wrong) to the full path of the directory that they're accessing (within the context of the share).

For example, for a user to write to \\server\share\foo\bar he will need read access to:

• \\server\share
• \\server\share\foo
• \\server\share\foo\bar

You will want to verify the ACLs from the CLI on your freenas server via the following commands:
getfacl /mnt/Tank/<share dataset name>
getfacl /mnt/Tank/<share dataset name>/foo
getfacl /mnt/Tank/<share dataset name>/foo/bar

The output for all of the above should show an "Everyone@" ACE with read permissions of some sort. If permissions are set right, you should be able to do something like this from the cli
su <username> - switch users to one of User A or User B
stat /mnt/Tank/<share dataset name>
stat /mnt/Tank/<share dataset name>/foo
stat /mnt/Tank/<share dataset name>/foo/bar
and not return an error code.