Can't see AD linked SMB share which is a Subfolder of another SMB Share

[fredbourdelier]

I've seen some similar questions, but not this exact scenario. Hopefully this one is easy to solve.

To start, let's avoid the 1000 word description and skip to the picture:
View attachment 65422
We're using SMB shares and TrueNAS with AD sync to a domain (all of which work).

More specifically:
We have a sample Domain Admin - someone who's authorized to see the root of the data set and the SMB share we set up at the root (MFGDATA is the data set, SH_MFG_ROOT is the share). Permissions on the root share are set up the way you'd expect:
View attachment 65423
MFG admins and Domain Admins (plus backup/restore functions) can access the root share, and no one else. Works - as expected.
View attachment 65424



We have another share (LDLS_PROCESSDATA_TLS) which is a subfolder a couple of layers down from that root. As expected, the domain admin can see it.
View attachment 65425



/////////////////////////////////
Now: we have a domain user, let's call him Lester.
View attachment 65426
Lester is a domain user, and a member of a couple of security groups - but not an admin.
View attachment 65427
Of particular significance for this issue is the membership in SG_ETI_TLSTEST_RW, because this happens to be the security group with permission to that LDLS_PROCESSDATA_TLS share that's a couple of layers down from the root share:
View attachment 65428
As you can see, Windows reports the group should have R/W permission. Lester is a member of this group. This is reported through Windows security manager (by the admin user, whose permissions work) so we can see that both the AD link and the security permissions for the folder are being seen by Windows as we expect.

Side Comment: You'll also notice that DOMAIN ADMINS group is in there - I tried adding it to see if Domain Users group would make the share work for Lester - didn't change the behavior at all - still fails - so just ignore it.


However, Lester can't access the share:
View attachment 65435
The admin CAN see the contents of the share:
View attachment 65436
This is NOT the expected behavior



In TrueNAS, at the data set level (MFGDATA) and the root share (SH_MFG_ROOT), beyond permissions for admins etc, domain users have traverse permission
View attachment 65429
View attachment 65430


Full Share and file ACL for the LDLS_PROCESSDATA_TLS share that doesn't work for Lester:
View attachment 65431

View attachment 65432

View attachment 65433

View attachment 65434
(Lester is a member of this security group - and should have access because of membership here)



CONFIG:

• Dell R730XD
• 2x Xeon E5-2690 14 core @ 2.6G
• 768 GB ECC DDR4-25600
• 2@Seagate Nytro 960GB SAS SSD 12GB (boot) [HW raid mirror]
• 4@WD200 3.84GB SAS SSD 12GB (MAIN_SSD_POOL) [HBA / TNAS Zdev2)
• 12@Seagate Exos x18 18TB SAS 12GB (MAIN_HDD_POOL) [HBA / TNAS Zdev2]
• DELL PERC H730p mini SAS split bus 8+8 1GB cache
• 2@DELL 1GB copper (builtin)
• 2@DELL 10GB copper (builtin)
• 1@2 port DELL 0xGRFF 10GB SFP+ (add on)
• TrueNAS CORE 13.0-U4 (updated 4/5/23)

TIA
Fred

 

[sretalla]

DELL PERC H730p mini SAS split bus 8+8 1GB cache

You're probably set up for data loss here.

What's all the noise about HBA's, and why can't I use a RAID controller?

This is relevant to FreeNAS and TrueNAS CORE. Some parts of it might also be relevant to Scale, but I don't really know how reliable the Linux drivers are. 1) An HBA is a Host Bus Adapter. This is a controller that allows SAS and SATA devices to be attached to, and communicate directly with...

www.truenas.com

More generally, you've made it really hard to look at your story by using that style of attachment, but I think I understood what you're talking about.

Have you applied the permissions at the dataset level recursively?

Have you edited permissions with the Windows Security dialog (and if so, did you apply those recursively)?

Are those really subdirectories, or child datasets?

 

[fredbourdelier]

You're probably set up for data loss here.

What's all the noise about HBA's, and why can't I use a RAID controller?

This is relevant to FreeNAS and TrueNAS CORE. Some parts of it might also be relevant to Scale, but I don't really know how reliable the Linux drivers are. 1) An HBA is a Host Bus Adapter. This is a controller that allows SAS and SATA devices to be attached to, and communicate directly with...

www.truenas.com

More generally, you've made it really hard to look at your story by using that style of attachment, but I think I understood what you're talking about.

Have you applied the permissions at the dataset level recursively?

Have you edited permissions with the Windows Security dialog (and if so, did you apply those recursively)?

Are those really subdirectories, or child datasets?

Sorry about the attachment style, this is my first post (though I've read a bunch). I'd put the images inline, I had no idea the forum would choose to remove them like that. I agree it's annoying to try and refer to images that aren't there.

Dataset permissions were applied recursively at the beginning, before the shares were created. The shares really are subdirectories, no child datasets.

Permissions were applied recursively for each share when created, and shares were created from the root down, though it should not matter as the access error/problem is at the specific folder which is the root of the "sub"share, no recursion should need to apply. Also, the users with permission at the root can see that sub share, it's the "new" permissions applied just at that share that don't work. File permissions were applied using Windows (as recommended in the docs) and those were "applied to this folder, all subfolders, and all files" (to note: there are no files yet, this is an empty tree and we're in testing only). As you can see in the screenshot, those permissions for that specific shared folder are correct.

Note on PERC: Only the boot drives are RAID, everything else is HBA mode as recommended. Controller cache is set to write through. External redundant backup power, redundant power supplies, and off-system and off-prem backups (will) exist for all data (when there is some).

 

[sretalla]

Only the boot drives are RAID, everything else is HBA mode as recommended. Controller cache is set to write through.

You need to read the post I linked, that's not recommended at all and you're set up to lose data.

I might find some time to reproduce your setup and see if I can get the same result, but I guess it will just be permissions not adding up how you think they do..

 

[Patrick M. Hausen]

Note on PERC: Only the boot drives are RAID, everything else is HBA mode as recommended. Controller cache is set to write through.

HBA mode is not suitable for ZFS. You need an HBA flashed to IT mode, i.e. a card without any RAID functionality at all. Anything else is a way to probable data loss.

 

[fredbourdelier]

HBA mode is not suitable for ZFS. You need an HBA flashed to IT mode, i.e. a card without any RAID functionality at all. Anything else is a way to probable data loss.

Understood. Thank you for being clear on this point.

 

[fredbourdelier]

You need to read the post I linked, that's not recommended at all and you're set up to lose data.

I might find some time to reproduce your setup and see if I can get the same result, but I guess it will just be permissions not adding up how you think they do..

I'm looking forward to your conclusions on the permissions. Unless there is another screen which shows additional information, from the screens I see, it's pretty straightforward. Anyone with only permissions to the share which is a subfolder of another share can't get in. Thank you again for the help.