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 have nfs4 configured between a RHEL 5.3 server (charlie) and a RHEL 5.4 client (simcom1). The machines are configured to authenticate users via kerberos by a Windows Server 2008 active directory machine called "alpha." Alpha also serves as a dns and dhcp machine for the local network.

I notice that when a user logs in to a RHEL machine for the first time they are issued a unique uid to that machine; The first user to log on gets 10001. So, what I see is that users between simcom1 and charlie have different UIDs. When a user does an 'ls -la' command from within an nfs4 mount I would have thought that the usernames in the owner column would indicate 'nobody' or at least the wrong user name - since UIDs are different between the machines for each user, and not all users have logged into each machine.

However, the simcom1 is able to resolve usernames in an 'ls -la' executed on files residing on charlie via nfs4 correctly. Most troubling is that users are unable to write to files across the nfs mount.

The server, charlie, has the root directory exported as rw. The client, simcom1, mounts the export as rw. My configurations are shown below.

My question is, how do I configure the RHEL machines to allow users to write files across nfs4 that is already mounted as read/write?

[root@charlie ~]# more /etc/exports

[root@charlie ~]#cat /etc/sysconfig/nfs
# Define which protocol versions mountd
# will advertise. The values are "no" or "yes"
# with yes being the default
# Path to remote quota server. See rquotad(8)
# Port rquotad should listen on.
# Optinal options passed to rquotad
# TCP port rpc.lockd should listen on.
# UDP port rpc.lockd should listen on.
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
# Turn off v2 and v3 protocol support
# Turn off v4 protocol support
# Number of nfs server processes to be started.
# The default is 8.
# Stop the nfsd module from being pre-loaded
# Optional arguments passed to rpc.mountd. See rpc.mountd(8)
# Port rpc.mountd should listen on.
# Optional arguments passed to rpc.statd. See rpc.statd(8)
# Set to turn on Secure NFS mounts.
# Optional arguments passed to rpc.gssd. See rpc.gssd(8)
# Optional arguments passed to rpc.svcgssd. See rpc.svcgssd(8)
# Don't load security modules in to the kernel
# Don't load sunrpc module.

[root@simcom1 ~]# cat /etc/fstab
--start snip--
charlie:/home /usr/local/dev/charlie nfs4 rw,nosuid, 0 0
--end snip--

[brendanmac@simcom1 /usr/local/dev/charlie/brendanmac]# touch file
touch: cannot touch 'file': Permission denied

[brendanmac@simcom1 /usr/local/dev/charlie/brendanmac]# su
[root@simcom1 /usr/local/dev/charlie/brendanmac]# touch file
[root@simcom1 /usr/local/dev/charlie/brendanmac]# ls -la file
-rw------- 1 root root 0 May 26 10:43 file
share|improve this question

I have the exact same issue and found out what the problem is: the problem is that nfsv4 uses idmapd and idmapd does mapping between userid => names but not the other way around. In other words, it can't work. It is just fancy and confusing to see the correct permissions user and group, however when you use the filesystem it will still use the old way of mapping through uid. So the uid on the server side should be the same as on the client side for that user. Otherwhise creating files, ... will fail with permission denied. Unless the uid match of course.


share|improve this answer

Your Answer


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