NSFv4 share and ACL doing weird things

I thought I understood the concept of groups and users in the NSFv4 ACLs, but I don’t understand what’s happening here.

A dataset is at /mnt/A/B where A got the following NSFv4 ACLs nested to all child datasets:

owner@ - admin						Allow | Full Control
group@ - admin						Allow | Full Control
everyone@							Allow | Traverse
Group - builtin_administrators		Allow | Full Control
Group - apps						Allow | Modify
Group - nfs							Allow | Modify
User - nfs							Allow | Modify

I have set up an NFS share of B with mapall to the manually added user and group nfs:nfs (1000:1000) and security to SYS. The user nfs is only member of the group nfs.

I was hoping to be able to limit all access via NFS with the permissions of the group nfs while being able to mount the data to various apps.

First Issue:

In this configuration I can mount (with sudo) and read/write the data from a desktop system with the uid:gid 1000:1000. If I touch a new file it belongs to nfs:admin. But I also have permissions to chown. So it looks like Full Control.

But only with the last ALLOW for the USER nfs. Without the user in the ACL I have no access at all, no listing, no reading. I expected permissions for the group (allow Modify) to suffice for every member. Why does it not work in this case? Why do I have to add the user nfs even though the group already has permissions?

Second Issue:

If I switch the share of the dataset B to maproot nfs:nfs I have full control permissions with the user 1000:1000. If I touch a new file it belongs to nfs:admin. I still have the permissions for chown.

This does not work as expected.

Third Issue:

If I remove builtin_administrators - Allow Full Control from the ACL I have no chown rights anymore. But only root and admin are members of builtin_administrators. The client had the share mounted with a simple sudo mount -t nfs ... server:/mnt/A.


I’d appreciate any documentation I could read to get to the bottom of this. All I have seen so far prints a pretty easy and straight forward picture I cannot reproduce.

Running TrueNAS 25.04.1
NSF config: NFSv4 only, enabled Allow non-root mount, enabled Manage Groups Server-side

Regarding owner having permission to chown:

NFSv4 is designed for an enterprise environment with Kerberos. If you run with Kerberos your users will get mapped the way you expect them to and permissions will work correctly (except the implicitly assigned privileges to owners as above).

If you are running this at home / in a lab and do not have Kerberos I wrote a guide for how to setup Kerberos in TrueNAS in a container. It is easy to do with TrueNAS and Linux or Mac clients. GitHub - evan314159/truenas-home-kerberos: How To Setup Kerberos for a Home TrueNAS Environment.

Note that I am not saying that sec=sys cannot work, but it is not a good approach, IMHO, and I wasted a lot of time doing it wrong (with sec=sys) when doing it right (with Kerberos) is so easy.

1 Like

No real reason for NFS4, just to use the latest and greatest. Thx for the kerberos guide!

Being able to use Kerberos authentication is a good reason to use NFSv4 – it will work better, easier, and without hacks like mapall/maproot.

1 Like

OK, so being able to chown the files I own is working as intended in Linux.

Refer to Evan123’s feature request to change this in TrueNAS.