Hi, I have been pulling my hair out with this issue for a few days, hoping to get some advice. I will try to keep things as brief as possible.
I have a TrueNAS machine running 25.04.1. I have configured Active Directory by joining TrueNAS to my local AD DC. It has a functioning Kerberos Realm/Principal.
My goal is to access NFS shares hosted on TrueNAS from Linux clients that are joined to the domain using SSSD. For example, I have joined a Proxmox server to my domain using the realmd system, which works great. Now I have users on both my TrueNAS and Proxmox machines, both referencing a single source of truth for users. Theoretically, if I choose krb5 as the NFS share security option, and my client has a valid Kerberos ticket, I should be able to access my NFSv4 share using my user’s username+domain rather than UID/GID.
The issue I am facing arises when I want to provision access to users on the NFS clients. I can successfully mount the NFS share I have created in TrueNAS; however, users that should have permissions based on the NFSv4 ACLs in TrueNAS do not have access to the mounted directory.
My user, DOMAIN\user, as a member of DOMAIN\share admins, has full control of the path shared via NFS, see this in TrueNAS:
root@truenas[~]# su -c 'touch /mnt/slow/downloads/test.txt' user@domain
root@truenas[~]# ls -la /mnt/slow/downloads
total 3
drwxrwx--- 4 root DOMAIN\share admins 5 Jun 16 22:26 .
drwxr-xr-x 4 root root 4 Jun 16 22:16 ..
drwxrwx--- 4 root DOMAIN\share admins 4 Jun 13 20:51 media
-rwxrwx--- 1 DOMAIN\user DOMAIN\share admins 0 Jun 16 22:26 test.txt
Note that users and groups are presented in the “flat domain name” format of DOMAIN\user.
On my Proxmox server, I can mount the NFS share without a problem, but when I try to do the same action with my user:
root@pve1:~# mount 10.6.10.30:/mnt/slow/downloads /mnt/truenas-slow/downloads -v
mount.nfs: timeout set for Mon Jun 16 22:34:00 2025
mount.nfs: trying text-based options 'vers=4.2,addr=10.6.10.30,clientaddr=10.6.10.20'
root@pve1:~# nfsidmap -l
3 .id_resolver keys found:
uid:root@domain.com
gid:DOMAIN\share admins@domain.com
gid:root@domain.com
root@pve1:~# su -c 'touch /mnt/truenas-slow/downloads/test2.txt' user@domain
touch: cannot touch '/mnt/truenas-slow/downloads/test2.txt': Permission denied
Permission is denied! And even more importantly, check the content of the nfsidmap keyring cache. It has weirdly formatted the group id as DOMAIN\share admins@domain.com, with a domain reference on either side.
I can get around this issue by doing the following:
Selecting “Use Default Domain” in TrueNAS in my AD configuration:
This removes the
DOMAIN\ prefix from users and groups.
And also adding the following line to my sssd.conf file on the client:
use_fully_qualified_names = False
This removes the @domain.com suffix from users and groups.
Now, on my NFS client I have the appropriate permissions (after unmounting, clearing nfsidmap cache and remounting):
root@pve1:~# mount 10.6.10.30:/mnt/slow/downloads /mnt/truenas-slow/downloads -v
mount.nfs: timeout set for Mon Jun 16 22:55:10 2025
mount.nfs: trying text-based options 'vers=4.2,addr=10.6.10.30,clientaddr=10.6.10.20'
root@pve1:~# nfsidmap -l
3 .id_resolver keys found:
uid:root@domain.com
gid:share admins@domain.com
gid:root@domain.com
root@pve1:~# su -c 'touch /mnt/truenas-slow/downloads/test2.txt' user@domain
root@pve1:~# su -c 'ls -l /mnt/truenas-slow/downloads/test2.txt' user@domain
-rwxrwx--- 1 user share admins 0 Jun 16 22:53 /mnt/truenas-slow/downloads/test2.txt
Note the correctly formatted share admins@domain.com without the HOME\prefix.
I don’t think this kind of workaround should be necessary. In fact, I believe this should be configurable on the TrueNAS side to allow customising the format that AD users and groups use. This is because running the nfsidmap -d command on both TrueNAS and my client returns the same domain.com value. I also tried adjusting the sssd.conf file on my client by adding full_name_format = %3$s\%1$s (giving DOMAIN\user format to users and groups on client), however the @domain.com suffix was still present in the nfsidmap cache which again caused an id mismatch.
Sorry for the extremely long post, hopefully I’ve explained the problem clearly. Is there something I should be doing in TrueNAS to allow AD users on clients to access NFSv4 shares with sec=krb5 that I have missed, without relying on the default domain feature?