Permissions for user/group from NFSv4 ACLs are ignored when mounting shares via NFSv4

I have just managed to use NFS shares for the first time, except I can only read from the share. Trying to create a new folder or file fails.

My system is TrueNAS SCALE 25.10.2.1 - Goldeye and it is part of an Active Directory domain driven by a Samba domain controller (home lab).

The NAS shows AD accounts fine and SMB shares work perfectly (honoring read/write ACLs).

I have now created a dataset called mydata as a Multiprotocol dataset:

  • I enabled both SMB and NFS sharing.
  • In the security type for NFS I have set KRB5/KRB5I/KRB5P as enabled (no SYS)
  • In edit permissions I have set an ACL with
    • @ownerownerownerowner full contro@groupgroup
    • @group full c@ev@everyoneryonentrol
    • @everyone read
    • Set the user to “HOME\myuser” and the domain to “HOME\domain users”

In the NFS service I have enabled only NFSv4 (no v3) and the checkbox “Require Kerberos for NFSv4” is checked (enabled).

Via SMB I can access the share fine and I can read/write to it.

Via NFS I can mount the share fine and read from it, but I cannot write (get permission denied) even though the “Read only” checkbox in the share is clear.

What can I check for what the cause of this is?

In TrueNAS:

nas% pwd
/mnt/family-tank/mydata

nas% ls -al
total 17
drwxr-xr-x  2 HOME\myuser HOME\domain users  2 Mar 11 13:37 .
drwxr-xr-x 10 root        root              11 Mar 11 13:37 ..

nas% id
uid=100001104(HOME\myuser) gid=100000514(HOME\domain users) groups=100000514(HOME\domain users),100001104(HOME\myuser),100001108(HOME\library users),100001113(HOME\nextcloud users),100003112(HOME\sudoers),100003601(HOME\remote desktop domain users)

nas% mkdir test
nas% echo fine-from-nas > test/myfile
nas% cat test/myfile 
fine-from-nas

nas% nfs4xdr_getfacl .
# File: .
# owner: 100001104
# group: 100000514
# mode: 0o40755
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWc--s:-din---:allow
         everyone@:r-x---a-R-c---:-------:allow

As you can see the ACL seems correct, I can create folders/files and everything seems fine.

Now this is from my laptop via SMB:

❯ smbclient //nas.ad.home.lan/mydata -U HOME/myuser
Password for [HOME\myuser]:
Try "help" to get a list of possible commands.
smb: \> cd test
smb: \test\> get myfile
getting file \test\myfile of size 14 as myfile (1.1 KiloBytes/sec) (average 1.1 KiloBytes/sec)
smb: \test\> cd ..

smb: \> mkdir smb-created
smb: \> cd smb-created
smb: \smb-created\> put myfile
putting file myfile as \smb-created\myfile (2.0 kB/s) (average 2.0 kB/s)

smb: \> ls
  .                                   D        0  Wed Mar 11 14:12:52 2026
  ..                                  D        0  Wed Mar 11 14:12:52 2026
  smb-created                         D        0  Wed Mar 11 14:12:57 2026
  test                                D        0  Wed Mar 11 14:08:47 2026

So everything so far is fine, but when I try to use NFSv4 from Alma Linux:

root@mydesktop:~# cat /etc/sssd/sssd.conf 

[sssd]
domains = ad.home.lan
config_file_version = 2
services = nss, pam


[domain/ad.home.lan]
default_shell = /bin/zsh
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.HOME.LAN
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
fallback_homedir = /home/%u@%d
#fallback_homedir = /home/%d/%u
ad_netbios_name = HOME
full_name_format = %3$s\%1$s
ad_domain = ad.home.lan
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = simple
simple_allow_groups = domain users@ad.home.lan

root@mydesktop:~# grep mydata /etc/fstab 
nas.ad.home.lan:/mnt/family-tank/mydata		/mnt/mydata	nfs4    sec=krb5,_netdev,noatime,nofail    0 0

root@mydesktop:~# mount | grep mydata
nas.ad.home.lan:/mnt/family-tank/mydata on /mnt/mydata type nfs4 (rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.9.198,local_lock=none,addr=192.168.9.250,_netdev)


root@mydesktop:~# su - 'HOME\myuser'
Last login: Wed Mar 11 10:59:03 GMT 2026 from 192.168.9.151 on pts/2

[HOME\myuser@mydesktop]~% id
uid=1400601103(HOME\myuser) gid=1400600513(HOME\domain users) groups=1400600513(HOME\domain users),1400601107(HOME\library users),1400601112(HOME\nextcloud users),1400603111(HOME\sudoers),1400603600(HOME\remote desktop domain users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[HOME\myuser@mydesktop]~% ls -al /mnt/mydata 
ls: /mnt/mydata/smb-created: Operation not permitted
ls: /mnt/mydata/test: Operation not permitted
total 42
drwxr-xr-x+ 4 HOME\myuser HOME\domain users  4 Mar 11 14:12 .
drwxr-xr-x. 4 root         root              31 Mar 11 13:39 ..
drwxrwx---. 2 HOME\myuser HOME\domain users  3 Mar 11 14:12 smb-created
drwxrwx---. 2 HOME\myuser HOME\domain users  3 Mar 11 14:08 test

[HOME\myuser@mydesktop]~% cat /mnt/mydata/test/myfile    
cat: /mnt/mydata/test/myfile: Permission denied

[HOME\myuser@mydesktop]~% mkdir /mnt/mydata/nfs-created
mkdir: cannot create directory ‘/mnt/mydata/nfs-created’: Permission denied

As you can see “sec=krb5” and they are in the same domain. The uid/gid values are different as mapping is different, but this should not matter as NFS afaik sends the strings like ‘HOME\myuser’ and as you can see in the “ls” output the owner/group are resolved correctly.

What could be the problem? On the NAS itself, I see that the created folders have dropped permission for “everyone”:

nas% pwd                 
/mnt/family-tank/mydata
nas% nfs4xdr_getfacl test
# File: test
# owner: 100001104
# group: 100000514
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWc--s:------I:allow

nas% nfs4xdr_getfacl smb-created 
# File: smb-created
# owner: 100001104
# group: 100000514
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWc--s:------@ev@everyoneryone:allow

Why was @everyone not inherited? This makes me wonder whether the only reason NFS ca@everyone read the top level is due to @everyone EDIT 1: this was simply that Inherit was not set; I have changed that and @everyone is now preserved in folders created (locally in the NAS command line, or via SMB). But the main problem persists: I cannot create folders using NFS.

Any pointers/hints on what to check?

After a lot of trials I have made the following discovery:

  • Opening up write access to “@everyone” allows me to update content. It seems that there is some issue with owner/group evaluation of ACL in TrueNAS.
  • As a workaround, I have discovered the “Mapall User” and “Mapall Group“ settings in the NFS share. I have set these to “HOME\myuser” and “HOME\domain users” which also works.

I honestly believe this is a bug in TrueNAS SCALE - I am on 25.10.2.1 - Goldeye

I wonder if I should try and file a bug report for this. Everything works except for allowing operations based on the ACL:

  • Mount succeeds, auth via Kerberos works (klist shows nfs principal)
  • Local creation in TrueNAS using the AD account works (so the ACL is permissive enough)
  • Remote read works (likely from “everyone” allowed access)
  • Write/Create however:
    • Work when supplied via “everyone”
    • Fail when supplied via owner/group

It seems to me that somehow TrueNAS does not check for allowed actions via the owner/group of the client request and only checks access for “everyone”.

Forcing the action via “Mapall user/group” to some specific account makes it work, so somehow it seems that the principal supplied via NFSv4 is not parsed properly by TrueNAS and thus not used when checking for allowed actions…

I have filed this as it definitely seems like a bug to me:

1 Like

I think I may have come across the issue being discussed here:

It seems this is definitely a bug and another workaround is to switch from gssproxy to rpc.svcgssd.