Unable to set ACL (Access Denied) on folder I own

TrueNAS General
,
1

I have set up a test Nas Server running True Nas Scale 25.10.

I have set up test datasets, connection to AD and shares.

Now I am testing how to set proper ACLs for specific use cases and am now running into an issue.

I have set up the share ACLs so that users of TestGroup can access the share and have full control, but this right is not to be inherited. I have also set up things so that the owner has full control and this right is inheritable. Idea being someone can access the share, make their own folder and add their files to it while other TestGroup members can’t access their things. There is also an Administration group that can see all the files because they have Full Control on all folders subfolders and files in the share.

But now I am having an issue with creating the folder and more importantly the user granting themselves full rights on that folder. Without that step if an Admin user makes a folder within TestUser’s folder TestUser will not have access by default.

But let’s illustrate it with an example. I will be running powershell commands to show what is the issue.

Both users (TestUser and Admin) shown here are Active Domain users, which can be determined from their names.

These are ran under TestUser:

PS \\fileserver3\TestShare> mkdir TestFolder


    Directory: \\fileserver3\TestShare


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        30.6.2026.     09:03                TestFolder


PS \\fileserver3\TestShare> icacls TestFolder
TestFolder AD1\TestUser:(I)(F)
           CREATOR OWNER:(I)(OI)(CI)(IO)(F)
           S-1-5-21-3358352355-3030398631-1753033928-200091:(I)(OI)(CI)(M,DC)
           S-1-5-21-3358352355-3030398631-1753033928-512:(I)(OI)(CI)(F)
           AD1\Domain Admins:(I)(OI)(CI)(F)
           AD1\Admin-Group:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files
PS \\fileserver3\TestShare> (Get-Acl .\TestFolder).Owner
AD1\TestUser
PS \\fileserver3\TestShare> icacls TestFolder /grant "AD1\TestUser:(OI)(CI)F"
TestFolder: Access is denied.
Successfully processed 0 files; Failed processing 1 files

As you can see, Test User has made a folder TestFolder. They are both the owner and have FullControl rights on the aforementioned folder. Yet, granting themselves full rights that would propagate to all items in it is denied.

To make things MORE strange baffling, if I switch to Admin user, that is member of Domain Admins and Admin-Group and give ANY right to TestUser. Even a simple READ right…

S \\fileserver3\TestShare> icacls TestFolder /grant "AD1\TestUser:R"
processed file: TestFolder
Successfully processed 1 files; Failed processing 0 files
PS \\fileserver3\TestShare> icacls TestFolder
TestFolder AD1\TestUser:(R)
           AD1\TestUser:(I)(F)
           CREATOR OWNER:(I)(OI)(CI)(IO)(F)
           S-1-5-21-3358352355-3030398631-1753033928-200091:(I)(OI)(CI)(M,DC)
           S-1-5-21-3358352355-3030398631-1753033928-512:(I)(OI)(CI)(F)
           AD1\Domain Admins:(I)(OI)(CI)(F)
           AD1\Admin-Group:(I)(OI)(CI)(F)

results in TestUser now being able to run the command that previously did not work.

PS \\fileserver3\TestShare> icacls TestFolder /grant "AD1\TestUser:(OI)(CI)F"
processed file: TestFolder
Successfully processed 1 files; Failed processing 0 files
PS \\fileserver3\TestShare> icacls TestFolder
TestFolder AD1\TestUser:(R)
           AD1\TestUser:(OI)(CI)(F)
           AD1\TestUser:(I)(F)
           CREATOR OWNER:(I)(OI)(CI)(IO)(F)
           S-1-5-21-3358352355-3030398631-1753033928-200091:(I)(OI)(CI)(M,DC)
           S-1-5-21-3358352355-3030398631-1753033928-512:(I)(OI)(CI)(F)
           AD1\Domain Admins:(I)(OI)(CI)(F)
           AD1\Admin-Group:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

Being granted Read rights, which user should already have given they have FullControl, should not lead to suddenly allowing a user to set ACLs as far as I understand… sooo why the heck is this happening?

Why is access being denied unless an Admin user adds ANY right for the user on a folder?!?

This MIGHT be a Windows thing, but it still feels like there is some sort of issue in how these ACLs are implemented on whatever TrueNAS system works with them, so I’m posting this here, and not on a Windows general specific board.

2

This has to do with NAS-138343 / Fix handling for ACE_WRITE_OWNER and ACE_WRITE_ACL (#325) · truenas/zfs@479d506 · GitHub which was a critical fix for multiprotocol access and reconciling ACLs and posix mode behavior, and made some truenas (linux) ACL behavior consistent with truenas (freebsd) ACL behavior. The icacls is kind of obscuring what’s happening in the filesystem layer.

Basically you’re trying to rely on granting full control to OWNER@ to give the owner of the file ability to modify its ACL in the first case. Samba because of the ACL translation layer fans this out into two ACL entries when constructing a Windows security descriptor, but the underlying kernel privilege remains the same one that gates off owner from modifying the ACL on-disk.

When you have an admin set a privilege for the user, it gets collapsed by the client into an explicit entry for the user granting full control, which then steps around the gate for the NFS4 special entries.

Basically, I’d say revise your design to not rely on CREATOR-OWNER permissions / owner@ implicit permissions, and use either explicit group ACLs or user ACLs. Using CREATOR-OWNER has always been an anti-pattern with windows shares in enterprise (which it looks like what you’re doing here). There used to be some technet / msdn articles to this effect, but they probably would be difficult to trace down these days.

I made a change to make it more visible via SMB clients.

1 Like
3

First of all, thanks for quick reply.

Sorry if I am missunderstanding due to lack of knowledge of the backend, from what you are saying the issue is those ACLs pinned to OWNER qualifier.

Okay, so I removed OWNER privileges, thinking, since TestGroup does have FullControl on the share but not inside subfolders a member of TestGroup would be able to create a folder and then edit it’s ACLs.

But that doesn’t work. Well, part of it doesn’t work. It seems when the user tries to create a folder, the folder does get made (Windows Explorer makes New Folder (x) while waiting for the name and powershell sets name properly), and the user is set as it’s owner, but since they don’t have any other privileges (Full Control without inheritance does not extend to being able to do anything to a subfolder) windows and powershell both report that the command failed because lack of access. I suspect both essentially run Exists test, and since they can’t see it they conclude it’s not there.

This to me means that there is no way it seems to automate creation of user work folder in the share through some script during first loggon, and Admin needs to create them on their own and set proper ACLs by hand or by script.

I hope you notice this is kinda odd. Especially given that the user who can’t change the ACLs still can delete the whole folder.

Is there a tool on Windows, through which one can read properly what the actual ACLs are. I used powershell because it looked to summarize them most concisely. But Windows most definitely looks to be confused on how things work given that it claims TestUser can change ACLs on one of those folders that failed to be fully made.

4

This goes beyond the typical sorts of feedback I give in our community forums (just helping mostly home users) and drifts more into the lines of enterprise support. If you have a support contract feel free to reach out to the support team, or you can ask around here. There are limits to how far I’ll dig into people’s particular use-cases in the forums.

5

Ah. I now see. If the user could set ACLs if they have FullControl on present folder, than other users could give themselves rights to other user folders.

6

This is tehnically enterprise, small school in Eastern Europe, but we definitely do not have the funds for paid versions. Still I understand limitations under which you were already very helpful even if I wasn’t able to resolve the problem the way I wanted to.

Still it would be nice in future for owner tag to work as one would expect it to work.

Thanks.