How to secure an NFS export with Kerberos

An NFS export that still accepts sec=sys trusts client-supplied numeric user and group IDs, which is not enough for a share that should admit only Kerberos-authenticated users. Requiring Kerberos on the export moves access through RPCSEC_GSS so the server negotiates krb5, krb5i, or krb5p instead of accepting unauthenticated AUTH_SYS traffic.

The trust boundary crosses three systems: the KDC that issues principals, the NFS server that owns the exported filesystem, and the Linux client that mounts it. The server needs an nfs/<server-fqdn> service principal in /etc/krb5.keytab, the export needs a sec= option, and the client needs Kerberos-capable NFS tools plus a credential path for the user or host doing the mount.

The example uses files.example.net, workstation.example.net, realm EXAMPLE.NET, export path /srv/nfs/projects, mount point /mnt/projects, and sec=krb5p for authentication, integrity, and privacy protection. Use krb5i when integrity is required without payload encryption, or krb5 only when authentication is enough and unencrypted file data is acceptable on the network.

Steps to secure an NFS export with Kerberos:

Confirm that the server and client use stable fully qualified names in the Kerberos realm.
```
$ hostname --fqdn
files.example.net
```
The NFS service principal must match the canonical server name that clients use in the mount command. Avoid mounting Kerberized NFS by raw IP address or by a short name that resolves differently on clients.
Install the Kerberos and NFS server packages on the NFS server if they are not already present.
```
$ sudo apt install --assume-yes krb5-user nfs-kernel-server
```
Use the package names for the server distribution. On Ubuntu, krb5-user provides client-side Kerberos tools and nfs-kernel-server provides the server export utilities.

Related: How to install an NFS server on Ubuntu
Create an NFS service principal for the server in the Kerberos database.
```
$ kadmin -p admin/admin -q "addprinc -randkey nfs/files.example.net"
Authenticating as principal admin/admin with password.
Principal "nfs/files.example.net@EXAMPLE.NET" created.
```
Run the equivalent realm-management command when the KDC is provided by FreeIPA, Active Directory, or another Kerberos management system.

Add the server principal to the server keytab.

$ sudo kadmin -p admin/admin -q "ktadd nfs/files.example.net"
Authenticating as principal admin/admin with password.
Entry for principal nfs/files.example.net with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/files.example.net with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

/etc/krb5.keytab is a persistent secret for the server. Keep it readable only by root and replace the key if the file is copied outside the host's credential-control process.

Confirm that the server keytab contains the NFS service principal.

$ sudo klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/files.example.net@EXAMPLE.NET
   2 nfs/files.example.net@EXAMPLE.NET

Confirm that the export path is on a filesystem the NFS server can export.
```
$ findmnt -T /srv/nfs/projects
TARGET            SOURCE                   FSTYPE OPTIONS
/srv/nfs/projects /dev/mapper/vg0-projects xfs    rw,relatime
```
Some test or container filesystems cannot be exported by the kernel NFS server even when the export syntax is valid.
Open the export definition file on the server.
```
$ sudoedit /etc/exports
```
Set the export to require the chosen Kerberos security flavor.
```
/srv/nfs/projects 192.0.2.0/24(rw,sync,no_subtree_check,sec=krb5p,root_squash)
```
sec=krb5p requires authentication, integrity protection, and privacy protection. Keep the client selector narrow so only expected hosts can attempt the Kerberos mount.
Restart the NFS server after adding the keytab for the first time.
```
$ sudo systemctl restart nfs-server
```
On current Ubuntu packages, Kerberos-related NFS services are started when the packages detect /etc/krb5.keytab. Restarting the server after adding the first keytab avoids leaving the GSS pieces inactive.

Related: How to check NFS server status in Linux
Apply the export table.
```
$ sudo exportfs -ra
```
No output usually means exportfs accepted the saved export definitions. Fix any syntax or missing-path error before testing from a client.

Related: How to reload NFS exports
Verify that the active export requires Kerberos.
```
$ sudo exportfs -v
/srv/nfs/projects
		192.0.2.0/24(sync,wdelay,hide,no_subtree_check,sec=krb5p,rw,root_squash,no_all_squash)
```
The active table should show sec=krb5p, sec=krb5i, or sec=krb5 instead of only sec=sys.

Related: How to list NFS exports on a server
Install the Kerberos-capable NFS client tools on the Linux client.
```
$ sudo apt install --assume-yes krb5-user nfs-common
```
Related: How to install an NFS client on Ubuntu

Create a host principal for the client when root or system mounts need machine credentials.

$ kadmin -p admin/admin -q "addprinc -randkey host/workstation.example.net"
Authenticating as principal admin/admin with password.
Principal "host/workstation.example.net@EXAMPLE.NET" created.

Add the client host principal to the client keytab.

$ sudo kadmin -p admin/admin -q "ktadd host/workstation.example.net"
Authenticating as principal admin/admin with password.
Entry for principal host/workstation.example.net with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/workstation.example.net with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

rpc.gssd uses machine credentials from /etc/krb5.keytab for UID 0 by default. User file access still depends on the user's Kerberos ticket and server-side permissions.

Restart the client NFS target after adding the first Kerberos keytab.
```
$ sudo systemctl restart nfs-client.target
```
Create the local mount point on the client.
```
$ sudo mkdir --parents /mnt/projects
```
Files already inside the mount point become hidden while the NFS filesystem is mounted there.
Obtain a Kerberos ticket for the user who will access files through the mount.
```
$ kinit alice
Password for alice@EXAMPLE.NET:
```
Mount the export with the same security flavor required by the server.
```
$ sudo mount -t nfs4 -o sec=krb5p files.example.net:/srv/nfs/projects /mnt/projects
```
Use sec=krb5i or sec=krb5 here only when the server export allows the same flavor.

Related: How to manually mount an NFS export on Linux

Confirm that the mounted filesystem is using the Kerberos security option.

$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/projects
TARGET        SOURCE                              FSTYPE OPTIONS
/mnt/projects files.example.net:/srv/nfs/projects nfs4   rw,relatime,vers=4.2,sec=krb5p,##### snipped #####

Write a small file through the Kerberized mount as the authenticated user.
```
$ touch /mnt/projects/kerberos-check.txt
```

Confirm that the client obtained a service ticket for the NFS server.

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.NET

Valid starting       Expires              Service principal
06/06/2026 10:15:01  06/06/2026 20:15:01  krbtgt/EXAMPLE.NET@EXAMPLE.NET
06/06/2026 10:16:12  06/06/2026 20:15:01  nfs/files.example.net@EXAMPLE.NET

Remove the temporary test file if it was created only for validation.
```
$ rm /mnt/projects/kerberos-check.txt
```
Unmount the temporary client test mount.
```
$ sudo umount /mnt/projects
```