Please help me understand ACL permissions

TrueNAS General
1

Hello,

tl;dr I changed permissions with ACL and don’t know how to revert them back.

As the title says; I’m having troubles understanding ACL vs. the classic Linux permissions.

For the sake of an easy approach of the question, let’s assume the following structure:
/mnt/HDD/pictures/2024
/mnt/HDD/pictures/2025

Both directories have a bunch of pictures inside them, which is a result of a successful cloud migration with a corresponding tool (I only mention this to confirm that it was not a manual copy/synch, rather an automated process done by a docker app).
/mnt/HDD/pictures is set up as a dataset with default ACL permissions.
The files in both directories hold (held) the “-r–r----- apps apps” permission setup.

Now, once I needed to share the ./2025 with SMB directly, where I recursively applied a new permission for the smb_user (and a bunch of others that were already there) with ACL on the filesystem, which changed the permissions of all the files within to “-rwxr-x— apps apps”. However, when I deleted this SMB share, the permissions remained and I don’t know how I could revert it back to apply the least-privilege concept. “chmod -R u-wx,g-x ./2025” doesn’t work, somewhat understandibly, as ACL is a much richer and more complex way of permissions (I also understand I’m not supposed to edit the permissions via the cli anyway). The ACL setup is gone, becuase when you set up an SMB share on a directory, you can specify the ACL settings on that SMB directory - but otherwise this is only possible on the datasets; so once you delete the SMB share, the ACL filesystem level setting option is also gone for that directory.

What’s interesting is that I checked the setup with the nfs4xdr_getfacl command and the modes seem to represent my problem, i.e. # mode: 0o100440 # mode: 0o100750, given 440 is -r–r----- and 750 is -rwxr-x----.
I would like to change it all to 440, but I believe there’s more to the ACL setup that I don’t see (or haven’t seen yet) in the cli and makes me confused.

I’m really tired so not sure if all this makes sense, thank you if you read it until this point :slight_smile:

root@nas[/mnt/HDD/pictures]# diff -u
<(nfs4xdr_getfacl ./2024/fc061bdb.JPG)
<(nfs4xdr_getfacl ./2025/IMG_26.HEIC)
— /proc/self/fd/11 2026-09-10 20:59:53.597235044 +0200
+++ /proc/self/fd/12 2026-09-10 20:59:53.597235044 +0200
@@ -1,7 +1,7 @@
-# File: ./2024/fc061bdb.JPG
+# File: ./2025/IMG_26.HEIC
owner: 568
group: 568
-# mode: 0o100440
+# mode: 0o100750
trivial_acl: false
ACL flags: none
user:apps:rwxpDdaARWc–s:------I:allow

In ./2025:

-rwxr-x— 1 apps apps 785342 Jul 20 2025 ff9b3207.JPG
-rwxr-x— 1 apps apps 230097 Apr 14 2025 ffde16b2.JPG

In ./2024:

-r–r----- 1 apps apps 262610 Aug 30 2024 ff8ef364.JPG
-r–r----- 1 apps apps 495200 Mar 9 2024 ffc7cbb1.JPG

2

yeah you already spotted the important bit: the smb share acl editor wrote a different mode onto ./2025 and deleting the share does not roll the files back.

chmod -R will fight you here because nfs4 with trivial_acl:false is still owning those mode bits. easiest revert path for me:

  1. recreate a temporary smb share on /mnt/HDD/pictures (or on 2025 if that is its own dataset) so the gui acl editor comes back
  2. open edit acl, match what 2024 still has (owner/group apps, no execute on files / mode like 440), apply recursively to 2025
  3. delete the temporary share again if you do not want it

from shell, copying a good acl onto the bad tree with nfs4xdr_getfacl / nfs4xdr_setfacl (or truenas_getfacl / truenas_setfacl on newer builds) is the other path. i would not keep poking chmod while trivial_acl is false.

if 2025 is only a directory inside the pictures dataset, the durable acl home is still the dataset acl in the ui. recreate share, set recursive acl once, remove share.