Setting up a FreeBSD NFSv4 client with Kerberos and AutoFS in the Linux network


This HowTo is intended for the experienced Administrators who wish to mount a Linux NFSv4 directory with Kerberos protection and AutoFS using FreeBSD.

Are you interested in setting up FreeBSD as SMBFS client with AutoFs ?


An working network with Kerberos and NFSv4 and NTP. In our scenario, the Kerberos KDC, Kerberos admin, and NFSv4 server are installed on the same host, called nasserver. The users and their principals are created and checked. The domain should be named and the realm EXAMPLE.NET.


User name, UID and GID are identical on the Linux server “nasserver” and the FreeBSD client “nasclient”. This can be achieved by, for example, NIS, ldap or manual setup. In this case, the manual creation of the user is sufficient. Our virtual user is called “nasuser” with the UID 1001 and GID 1001.


nasclient$ adduser

Username: nasuser
Full name: nasuser
Uid (Leave empty for default):
Login group [nasuser]:
Login group is jru. Invite nasuser into other groups? []: wheel
Login class [default]:
Shell (sh csh tcsh zsh nologin) [sh]: bash
Home directory [/home/nasuser]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]:
Use an empty password? (yes/no) [no]:
Use a random password? (yes/no) [no]:
Enter password:
Enter password again:
Lock out the account after creation? [no]:
Username : nasuser
Password : ****
Full Name : nas
Uid : 1001
Class :
Groups : nasuser wheel
Home : /home/nasuser
Shell : /usr/local/bin/bash
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (nasuser) to the user database.
Add another user? (yes/no): no


Necessary is the complete (including domain) hostname of the FreeBSD client. So we need a working DNS service or at least a maintained /etc/hosts on the client and the server. Our computer is called “nasclient”, the domain “”.

nasclient$ nano /etc/rc.conf

hostname = #lowercase letters !

nasclient$ nano /etc/hosts


The FreeBSD Kerberos client has Heimdal as standard, our Linux KDC is a MIT Kerberos KDC. We install MIT first:

nasclient$ pkg install krb5

Then we create or copy the /etc/krb5.conf with our realm EXAMPLE.NET

nasclient$ nano /etc/krb5.conf

default_realm = EXAMPLE.NET
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
kdc =
admin_server =


The principal of the nfs service on nasclient still needs to be generated. This we do on the Linux (Debian) host.

#nasserver$ kadmin -p admin/admin
kadmin> addprinc -randkey host/
kadmin> addprinc -randkey nfs/

Then we test our configuration on the FreeBSD client:

nasclient$ kinit nasuser

nasclient$ klist

For a working NFSv4 with Kerberos, you need the gssd service, which accesses the file /etc/krb5.keytab for the keys. (see man gssd). Important ! The gssd service requires lowercase hostnames for proper work. MIT programs are located in /usr/local/bin, so nasclient$ ktutil starts the Heimdal version. We want MIT.

nasclient$ /usr/local/bin/kadmin -p admin/admin
kadmin> ktadd host/
kadmin> ktadd nfs/

Password for admin/admin@EXAMPLE.NET:
Entry for principal   host/ with kvno 2,enc
Entry for principal   host/ with kvno 2,enc
Entry for principal   host/ with kvno 2,enc
Entry for principal   host/ with kvno 2,enc
Entry for principal   nfs/ with kvno 2,enc
Entry for principal   nfs/ with kvno 2,enc
Entry for principal   nfs/ with kvno 2,enc
Entry for principal   nfs/ with kvno 2,enc


Let’s check the /etc/krb5.keytab on nasclient:

nasclient$ ktutil list (Heimdal is also ok)

Vno Type                    Principal
2 aes256-cts-hmac-sha1-96  host/
2 arcfour-hmac-md5         host/
2 des3-cbc-sha1            host/
2 des-cbc-crc              host/
2 aes256-cts-hmac-sha1-96  nfs/
2 arcfour-hmac-md5         nfs/
2 des3-cbc-sha1            nfs/
2 des-cbc-crc              nfs/


Or with MIT.

nasclient$ /usr/local/bin/ktutil

ktutil: rkt /etc/krb5.keytab
ktutil: list

slot KVNO Principal
—- —- ———————————————————————
1 2 host/
2 2 host/
3 2 host/
4 2 host/
5 2 nfs/
6 2 nfs/
7 2 nfs/
8 2 nfs/


Nasclient needs three more services that we add to /etc/rc.conf.

gssd = the security service
nfsuserd= is needed for GID/UID mapping
nfscbd = callback from NFSv4-Server to the NFSv4-Client

nasclient$ nano /etc/rc.conf



For testing, we start gssd with verbose, debug and the “host-based initiator creditals support” . Kerberos NFS mounts are allowed when the service principal “nfs/” is already in the /etc/krb5.keytab.

nasclient$ gssd -vhd

If faultless, we can start the services.

nasclient$service nfsuserd start
nasclient$service nfscbd start
nasclient$service gssd start

Suppose our /etc/exports on the NFSv4-Server is like this:

nasserver# cat /etc/exports



If the rights of nasuser (UID 1001/GID 1001) for the share directory are set correctly and the ticket is still valid, then you should mount the share /mnt/share. (vfs.usermount=1 and vfs.nfs.enable_uidtostring are set in sysclt.conf)

mount_nfs -o sec=krb5,vers=4,soft,intr,gssname=nfs /mnt/share


nasclient $ nano /etc/fstab    /mnt/share   nfs bg,rw,soft,sec=krb5,nfsv4,gssname=nfs,late    0  0


Optional : Login with pam_krb5


nasclient$ pkg install pam_krb5

Switch on PAM-Kerberos in /etc/pam.d/system.

nasclient$ nano /etc/pam.d/system

# auth
auth       sufficient no_warn no_fake_prompts
auth       requisite no_warn allow_local
auth       sufficient no_warn try_first_pass
#auth      sufficient no_warn try_first_pass
auth       required no_warn try_first_pass
#account     required
account       required
account       required
account       required try_first_pass
# session
#session     optional want_agent
session       required no_fail
# password
password     sufficient no_warn try_first_pass
password     requiered no_warn try_first_pass


Attention ! If a /root/.k5login is present, check it for a correct principal, otherwise you will be locked out! If this is the case then boot in “single user mode” and make the partition writable with /sbin/mount -u /.

From now on, the ticket should be generated upon login.


Automatically mount network shares with AutoFS


Automount is the optimal supplement. With autofs (man autofs) you can easily integrate devices or network shares when needed. In contrast to static integration, unmounting is done automatically without access. Autofs reads in the /etc/auto_master the mountpoints and its map-file. The map-file contains the mount command. Another advantage is, that for NFS the mount commands for BSD and Linux are almost identical.


In our scenario we want to mount the share “share” under the mountpoint “/mnt/NFSv4/”.

nasclient$ mkdir /mnt/NFSv4/
nasclient$ nano /etc/auto_master

#mountpoint map-file
/mnt/NFSv4 /etc/


nasclient$ nano /etc/

# share           mount-command
nasserver/share -fstype=nfs,sec=krb5,vers=4,gssname=nfs

On FreeBSD, you have to enable autofs in the /etc/rc.conf.

nasclient$ nano /etc/rc.conf

autofs_enable = “YES”


nasclient$ service automount (re)start
nasclient$ service automountd (re)start
nasclient$ service autounmountd (re)start


If automount fails, you can use nasclient $ automount -v and nasclient $ tail /var/log/ messages to narrow down the error. Often, only the Kerberos ticket is invalid. A kdestroy and kinit are then the solution. For computers that are continuously in operation, you should possibly extend the ticket periodically with a cronjob.

0 * * * * /usr/local/bin/kinit -R #MIT


Testing environment: FreeBSD 11,12,12.1 and NFSv4 on Devuan Ascii (10/20)


Feel free to contact us if you have any comments or improvements.


Feinwerk Hamburg Meeresgott

Feine Mechanik, nachhaltig gefertigt.

Wir beherrschen das.

Feinwerk Hamburg Wortmarke



Feinwerk Hamburg ist ein Angebot der Wassermann Dental-Maschinen GmbH.
Rudorffweg 15–17, 21031 Hamburg, Germany