Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently trying to set up an NFSv4 server on FreeBSD. I have extensive experience with doing this on other Unices (Solaris and Linux), but I'm fairly new to FreeBSD.

My goal is to achieve the following:

  • Files served from the FreeBSD system
  • The only security model should be krb5p
  • Clients are Linux (Ubuntu) and OSX

Currently, I have managed to set things up so that I need a valid TGT in order to access the file system. After an attempt to access those files, I can run klist on the client and I can see that the nfs/domainname principal has been retrieved. This suggests that the Kerberos part of the NFS mount is correct.

My problem is that all client accesses are still performed using the nobody user. I can see the permissions when I do ls -l. Even the user mapping works correctly, but unless nobody has permission to do anything with the files, I get a permission denied.

Here's an example interaction from the client (Ubuntu in this case, but the same thing happens from OSX). In this example, /export/shared/testshare is the shared directory from the FreeBSD server:

(I have changed the actual domain name to domain and the Kerberos realm name to REALM)

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare /mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw------- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Server configuration

I have had quite some problems in finding a comprehensive guide to setting up NFSv4 on FreeBSD. This is somewhat surprising in itself as I have found that information on how to do things in FreeBSD to be very good.

Here are the relevant lines in /etc/rc.conf:


Here is the content of /etc/exports:

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Another interesting aspect is that when I used tcpdump to record the NFS network traffic between the client and the server, I saw NFS3 packets together with the NFS4 packets. Both of these packet types contained encrypted data, so I still think Kerberos was used, but given the configuration above, I would have expected there to be nothing but NFS4 traffic.

share|improve this question
  1. Need to disable nfs3 with vfs.nfsd.server_min_nfsvers=4.
  2. To avoid "nobody", NFSv4 client and server should be in the same domain realm.
share|improve this answer
I did number 1 already, and it had no effect. As for number 2, are you referring to the DNS domain or the Kerberos realm? – Elias Mårtenson Feb 15 '13 at 5:38
Sorry, I meant "realm". Of course, it shouldn't be necessary but it's been easy when possible. A close second is add them to "Local-Realms" in the idmapd.conf. – igelkott Feb 15 '13 at 23:47
They are both in the same realm though (and the same domain). – Elias Mårtenson Feb 16 '13 at 16:30

Simply put, there has to be some way to map usernames between the systems. Are you running idmapd on both server and client? Ldap?

At least as a test, try making specific mappings between names ... other than root, at least initially.

share|improve this answer
The mapping works. I get the correct user names displayed. However, the actual permissions that are being applied are for "nobody". – Elias Mårtenson Feb 16 '13 at 13:58
So, everything's working but it still fails. Sorry I couldn't really help. – igelkott Feb 16 '13 at 16:03
up vote 0 down vote accepted

I solved the problem. After going through the code I found that the cause was a bug in the GSS library. The problem was caused by a buffer sent to getpwnam_r that was too small.

All the details can be found in the discussion on the mailing list

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.