Managing folder-level SMB ACLs — is there a better way?

TrueNAS General
,
1

After months of testing and provisioning TrueNAS SCALE 25, I’m getting more comfortable with its operation, and trying to implement more useful SMB permissions schemes for our projects.

It is common for us to need a scenario like this:

├ [Pool root]
|
└—PROJECT1_SHARE
   ├—ProjData
   ├—Staging
   └—Mailbox

For these users:

freelancer needs r/w access to ProjData and no access to the other folders
ioservice needs r/w access to Mailbox and no access to the other folders
staffer organizes data movement & preparation all around the share, needs full access
(nothing to do with the UNIX generic ‘staff’ group, just picking a descriptive moniker here.)

It’s proving to be far more complicated than expected.

Generally, the responses fall under “create multiple shares” and “use Windows”.

  1. Regarding multiple shares for one project:
  • Organizationally, it makes little sense to us. The freelancer and staffer should share the same “perspective” on the files, also so the apps they use together see the files in matching paths.
  • Folders allow deep hierarchies, but a server’s shares is just one list. If I have 10 projects, 10 shares makes perfect sense, but not multiplying that for various child shares.
  • Would child datasets help here? I still don’t quite understand what they’re useful for… but from my understanding, they won’t be useful to us.
    Specifically, the staffer routinely moves tens and hundreds of GB’s around. Keeping everything in the same share allows doing it very efficiently and nearly instantly, instead of lengthy, wasteful copy operations.
    It introduces the complexity that when you move a file… its ACL moves with it.
  1. Regarding Windows:
  • We’re a Mac-based environment. Adding a step “locate an available Windows system, log into it, authenticate to the NAS with appropriate Full permissions and tweak the ACL” is anything but streamlined.
  • Without a directory binding, how useful is Windows anyway to modify ACLs?
  1. Currently, setting up the above is a careful 37-step recipe. I’m relying on Deny entries for freelancer with ‘no-inherit’ to prevent them from accessing Mailbox, but allow the freelancer to see the files once the staffer moves them from Mailbox to ProjData.
    For the ioservice, I create a hidden child share to have a separate mounting point & ACL editing point.
  2. Is there a better/simpler/less-fragile way to do this? Is my scenario a complex, rare need? To us it seems like a pretty common one, which is why I’m trying to simplify it so my assistants could set things up, not just me.
  3. What I’m missing most is a File Browser, with an ACL effective permissions explorer, inside the TrueNAS web console.
  • A File Browser is a common feature in other mature NAS servers (Houston/Cockpit had it before I’d call it “mature”…) I saw some threads about a File Browser feature, is it a “nice-to-have” priority, maybe-2027 ETA?
  • Is it planned to support ACLs? Or wayy down the road?
  • AFAIK none of the available “Apps” help. (E.g. FileBrowser Quantum) I’d need to give them root access, they live separately from the GUI console, but most importantly, they can’t edit ACLs.
  • It was nice to discover Midnight Commander is bundled in TrueNAS, but I was disappointed to discover that this venerable tool never added ACL support.
  • Currently merely seeing ACLs on the NAS is so complicated (midclt call filesystem.getacl piped to jq , plus getent to decipher the UIDs).
  1. Is it correct that the TrueNAS Filesystem ACL editor works on any folder, it just happens to be tied to a share point currently?

I also ran into the following issues, in case they sound familiar / reproduced. I need to do more analysis to verify them but have a backlog…

  1. Modifying ownership requires checking “Apply Owner” and “Apply Group”. It looks these boxes apply them recursively but no, they’re little “safety levers”, a confusing & inconsistent design. I’d like to see these checkboxes gone and replaced with a disclaimer (if you “Save ACL” with ownership changes) that you’re about to change ownership, are you sure.
  2. If I modify the ownership entries as well as add ACL entries, the ownership entries weren’t getting updated.
  3. When I create a child share, TrueNAS asks “Do you want to configure the ACL?” If I choose yes [Configure], the Edit ACL page is missing ACL entries. If I choose No and go to the share > Filesystem ACL, the proper ACL entries do appear. It’s as if the ‘Configure’ option occurs too fast, it seems.

This was a long and winding post… but so are ACLs on TrueNAS, currently. I wanted to round up what I’m trying to do; why; why I do it this way and not another; what I find lacking; and what would help.

Trouble with Access-Based Share Enumeration