I figured I'd share my personal Notes on this particular Topic since Documentation on this is hard to find and most of it is outdated or scattered or leaves out certain details.

Maybe someone out there can find some of this useful.

How to setup Kerberos with NFSv4 on Linux in 2025:

• This Guide assumes that:
  • You are familiar with Kerberos, NFS, DNS, Linux and UNIX-like Operating Systems in General.
  • All of the Machines involved can talk to each other.
  • All of the Machines involved have their System Date and Time synchronized.
  • All of the Machines involved have relatively up-to-date Software.
  • You have a running Server with:
    • A working default NFS Installation with Shares that can be mounted by Clients.
    • A working Kerberos V Installation where Clients can successfully authenticate and receive Tickets.
  • You are using the MIT implementation of Kerberos V. Heimdal and others may work, but haven't been tested.

1: Server-Side

1.1: Principals

kadmin into your Kerberos Server and add a Service Principal for NFS and a Machine Principal for each one of your Clients:

addprinc -nokey nfs/<Server's Hostname>
addprinc -nokey root/<Client-1 Hostname>
addprinc -nokey root/<Client-2 Hostname>
addprinc -nokey root/<Client-3 Hostname>
... etc ...

IMPORTANT: If you're using your own DNS Server and have multiple reverse (PTR) Records configured to resolve to your NFS Server's IP Address, then you MUST also add a Service Principal for each one of those Records.
For Example, if you have the Records my-nfs-server.lan and awesome-nfs-server.lan pointing at the same IP Address you do:

addprinc -nokey nfs/my-nfs-server.lan
addprinc -nokey nfs/awesome-nfs-server.lan

The reason for this is because Kerberos may try any Domain Name that is associated with your NFS Server's IP Address.

Next, make sure to add all the newly created Service Principal(s) to the Server's keytab:

ktadd nfs/<Server's Hostname>
ktadd nfs/my-nfs-server.lan
... etc ...

Then add each of the Machine Principals to their own keytab:

ktadd -k client-1.keytab root/<Client-1 Hostname>
ktadd -k client-2.keytab root/<Client-2 Hostname>
ktadd -k client-3.keytab root/<Client-3 Hostname>
... etc ...

Now quit out of the Admin Program and copy the newly created Kerberos keytab Files to all of your Clients!

1.2: rpc.svcgssd is dead

If your NFS Server Installation is mostly unmodified then there is a good chance that it's configured to use rpc.svcgssd for GSS authentication. But the reality of the Situation is that this Daemon is dead and in fact has been removed a long time ago.

gssproxy is its replacement, however it's a separate Component that needs to be installed manually.
It should be available in your Operating System's Package Manager. If not, make sure to look through the AUR and pkgsrc.
If for some reason none of them have it, then grab the source code and compile it manually:

$ git clone https://github.com/gssapi/gssproxy
$ cd gssproxy
$ vim BUILD.txt

gssproxy should also come with a couple of config files in /etc/gssproxy.
Specifically the Files 24-nfs-server.conf and 99-network-fs-clients.conf need to be present.
If for some reason you don't have them on your System, grab them from the gssproxy Git Repository. They are in the examples directory.

If everything looks OK start gssproxy (either via a Service File or manually).
Make sure that it stays running and doesn't print any errors. It should be treated as a part of NFS and needs to start with NFS Server Daemons.

1.3: exports

Any NFS Share that you want to use with Kerberos needs to have the sec mount option set.
For Example, if you have an /etc/exports File with an Entry like this:

/export/movies                          *(rw,async,no_subtree_check,no_root_squash)

Then you need to change it to look like this to "Kerberize" it:

/export/movies                          *(rw,async,no_subtree_check,no_root_squash,sec=krb5)

NOTE: NFS offers multiple ways to use Kerberos:

• sec=krb5 is the most basic Option uses Kerberos for Authentication only.
• sec=krb5i uses Kerberos for Authentication and verifies Data Integrity.
• sec=krb5p uses Kerberos for Authentication, verifies Data Integrity and encrypts traffic.

If you want to use your NFS Shares in a Network with many different Users then krb5p is highly recommended.

Don't forget to run # exportfs -arv to reload your exports!

1.4: NFS idmapd.conf

Under [General] change Domain to your Kerberos Realm and make sure that [Translation] is using the nsswitch method.
Save the changes and restart the rpc.idmapd Daemon. Verify that your Domain is set correctly by running:

# nfsidmap -d

That should print your Kerberos Realm's Domain Name.

2: Client-Side

Make sure rpc.statd is always running.
IMPORTANT: Start rpc.gssd with the GSS_USE_PROXY Environment Variable set to 1 and make sure it is also always running!
Example:

# env GSS_USE_PROXY=1 rpc.gssd -f

If you have a Service File for rpc.gssd on your System, make sure it sets that Environment Variable! Edit the Service File if you must!
If for some reason rpc.gssd crashes and complains about some rpc_pipefs being empty then you need to mount that pseudo-Filesystem manually:

# mount sunrpc /var/lib/nfs/rpc_pipefs -t rpc_pipefs -o nodev

If rpc_pipefs doesn't exist then you need to load the sunrpc Kernel Module first:

# modprobe sunrpc

At this point you should be able to mount your NFS Shares on the Client:

# mount my-nfs-server.lan:/export/movies /mnt

You may need to be a bit more specific though:

# mount -t nfs -o sec=krb5p,vers=4.2 my-nfs-server.lan:/export/movies /mnt

If no errors occurred, confirm that the Shares are mounted correctly:

$ mount
...
my-nfs-server.lan:/export/movies on /mnt type nfs4 (rw,relatime,vers=4.2,sec=krb5p,etc.)
...

If everything looks good, you need to grab a Ticket for your User via your personal Principal:

$ kinit
Password for user@KERBEROSREALM.ORG: 

Now your User should be able to see and access the mounted NFS Shares:

$ touch /mnt/test
$ ls -l /mnt/test
-rw-r--r-- 1 user user 0 Jan 23 07:33 /mnt/test
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user@KERBEROSREALM.ORG

Valid starting     Expires            Service principal
01/23/25 03:28:00  01/23/25 13:28:00  krbtgt/KERBEROSREALM.ORG@KERBEROSREALM.ORG
01/23/25 03:28:00  01/23/25 13:28:00  nfs/my-nfs-server.lan@KERBEROSREALM.ORG

NOTE: Once your Ticket is expired your User will no longer be able to access the Shares until a new Ticket is acquired.

Website: https://www.openkylin.top/index-en.html

Git repositories: https://gitee.com/openkylin

I haven't tried it myself yet but I might give it a spin since it has a unique Desktop environment.