Mounting NFS: owners are nobody:nogroup

Question

I mounted an NFS filesytem from the shell using the code:

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

I show the files as nobody:nogroup:

Any idea to fix this issue and display the right owners?

I use Ubuntu 12.04.

Edit:

Client-side (I don't have access to the NFS server):

rpcidmapd is running:

rpcinfo -p:

/etc/idmapd.conf:

Answer 1

Asking for local support or documentation sounds like a very good idea :).

In checklist form, I think you need

1) the required user(s) created on the client system. This can be done manually, but you should expect there to be an automatic "directory service" which you can configure. It might be LDAP.

2) user mapping between client and server. In NFS4 (implied by tcp option) this is handled by idmapd, as mentioned by gareth. You should just need to set the domain to match what the server thinks. Cross-domain doesn't work, I think it's a Linux limitation.

3) kerberos to authenticate yourself to the server (available in NFS4). If you want to access any files as someone other than "nobody", this is definitely needed. I suggest configuring and testing kerberos first of all. Configuring it will include setting a domain - you'll set the same domain in idmapd.conf.

or with NFS3-style auth, 3) is skipped and instead of 2) you just make sure the user's numerical UID matches that of the server. This is only used where the server trusts the client :).

Answer 2

I chased down a similar issue. Setting /etc/idmapd.conf Verbosity=3 helped to see some of the issues on Ubuntu, but not all. Here is a summary from my findings:

There is still the potential that your /etc/passwd and group files do not share the same user/groups as the machine which offers the share. Here is a hint your local machine must have a similar user/group name mapping via. /etc/nsswitch.conf or the mapping operation of idmapd will fail. Note here if running Verbosity=3 you will see an entry in /var/log/syslog, like:

idmapd[25193]: Client 64: (group) name "TheGroupNameYouExpected" -> id "65534

If you modify /etc/nsswitch.conf to map to something other than files (like ldap or nis), then you need to also ensure that ldap or nis has an actually entry of some kind for the username or group name you want ID translation for. If an entry does not exist idmapd will fail to successfully map users/groups.

In related issues I found for RHEL v7 the idmapd.conf service does not need to be enabled for NFS clients anymore:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

However there is a running issue in the above thread that by default the services that perform the automatic ID-username mapping have a very low number of ids that remain mapped in memory. Instead of logging an error idmapd just refuses to translate more than 200 users. You can verify this from your current kernel settings:

cat /proc/sys/kernel/keys/root_maxkeys    

Most likely 200 is the default setting. To allow the NFS mount points to properly map all the available users you need to change this file:

/etc/sysctl.conf

and add or modify these lines as follows:

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

Your system may not require as many user/id key mappings, so adjust as necessary. This will allow all id-name keys to remain mapped while using the NFS mount. Here is another related posting that shows the current kernel settings:

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

for these values:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

Most likely maxbytes and root_maxbytes must be large enough to store all the keys:

https://www.kernel.org/doc/Documentation/security/keys.txt

Answer 3

Yet another checklist, assuming you're doing NFSv4 with Kerberos:

• kinit, then look at klist. You should see a ticket; if not, look for answers on how to fix Kerberos auth first.
• is rpc.gssd running? You might want to start the service; also, on some distributions, it doesn't autostart unless you mention NFS mounts with krb5* in their options in your /etc/fstab.
• is rpc.idmapd running? (Again, this should typically be launched by a client-side nfs service; ls /etc/init.d/ is a good starting point.
• look at /etc/idmapd.conf. Does the "Domain" part match the actual domain of your NFS server? (... if nothing else, you could try using the Kerberos realm.) I've seen distributions where this wasn't needed and some where it was; maybe on some, it has more reasonable defaults for an FQDN.
• also add GSS_principal_attr = GSSAuthName to the file. Just the domain might fix some ownership issues, but looks like this is also needed for e.g. directories.
• restart at least rpc.idmapd once adjusting the config. A remount shouldn't be necessary after adjusting the config, but it doesn't hurt.
• also! nfsidmap -c. Apparently, there is a cache that doesn't get cleared even with a restart; this will clear it. (Otherwise you might keep thinking the fix doesn't work even if it did.)