NFSv4 ACL group-based permissions not honored for mapall_user NFS exports on SCALE

TrueNAS General
,
1

Hello,

System: TrueNAS SCALE 25.10.7 (Goldeye), clean install, migrated pools (ZFS, NFSv4 ACL type) from a TrueNAS CORE 13.3 system.

Setup:

  • Dataset tank/photo, NFSv4 ACL granting Read to a named group (tank_photo_ro)
  • NFS share on this dataset with mapall_user set to a local user (pix), whose only group membership is tank_photo_ro
  • This exact configuration worked correctly for years on TrueNAS CORE

Symptom:
Mounting this export on any NFS client (tested: Debian, CoreELEC) results in Permission denied when listing the mounted directory. Tested and ruled out:

  • NFSv3, NFSv4.1, NFSv4.2 → same failure on all three
  • “Manage Groups Server-side” option → enabled, no change
  • Adding mapall_group alongside mapall_user → no change, access still denied
  • NFSv4 DNS Domain mismatch → ruled out since NFSv3 (no idmapping involved) fails identically
  • Local access as the mapped user (sudo -u pix ls /mnt/tank/photo) → succeeds without issue

Working workaround:
Replacing or adding the group-based ACE with a named-user ACE (User - pix, Read) on the dataset resolves the issue immediately → same effective permission level, but matched by UID directly instead of group membership.

Conclusion: this points to the “unix token” built for a squashed (mapall_user) NFS connection not correctly carrying the mapped user’s supplementary group memberships during ACL evaluation, even though id <user> reports them correctly and Manage Groups Server-side is enabled. Group-based ACL matching appears to only work reliably for non-squashed (real client identity) NFS connections.

Is this a known/reported issue?

2

yeah ive hit this on SCALE after a CORE migrate. mapall_user on linux nfsd can skip the supplementary groups when it builds the token for the nfs4 acl check, even when id pix looks fine.

stuff that helped me:
-usermod -g tank_photo_ro pix so the group is primary, not only supplementary
-nfs4_getfacl /mnt/tank/photo and confirm the group ace survived the migrate
-keep the named-user ACE for pix on the squash path (what u already found works)
-Services → NFS → double check Manage Groups Server-side is still on after the clean goldeye install

id file a bug on the mapall supplementary group token. CORE behaved different here for years.

3

Thanks for confirming. One correction on my end, in my case the group was already primary from the start (id pix → gid=1047(tank_photo_ro)), in CORE then in SCALE, not supplementary, and it still failed. So this doesn’t seem limited to supplementary group resolution; the primary group isn’t making it into the token either on the mapall_user/squash path. Might point to something more fundamental in how the token gets built for squashed NFS connections, not just a supplementary-groups oversight.

Bug filed:

I have checked the “Manage Groups Server-side” option before posting on the forum, but it didn’t change anything.

truenas% sudo nfs4_getfacl /mnt/tank/photo
Operation to request attribute not supported: /mnt/tank/photo
truenas% sudo nfs4xdr_getfacl /mnt/tank/photo
File: /mnt/tank/photo
owner: 10XX
group: 10YY
mode: 0o40770
trivial_acl: false
ACL flags: none
        owner@:rwxpDdaARWcCos:fd-----:allow
        group@:rwxpDdaARWc--s:fd-----:allow

group:tank_photo_ro:r-x---a-R-c---:fd-----:allow
user:pix:r-x---a-R-c---:fd-----:allow

Here, the only change I had to do to make it work, was to add the user pix:
user:pix:r-x---a-R-c---:fd-----:allow

4

yeah if primary gid was already tank_photo_ro and mapall still denies, that points at the squash token on SCALE nfsd for me.

id try next:
-export once w/ mapall_user empty, mount as the real user that owns the ACE, confirm ls works
-then put mapall_user=pix back and also set mapall_group / anonymous GID to tank_photo_ro if the share UI exposes it
-nfs4_getfacl /mnt/tank/photo and paste the group ACE line

worth a jira w/ SCALE 25.10.7 + that primary gid was already correct and list still Permission denied under mapall.