Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 two servers running RHEL6. I have root access to both. The main server, which I will refer to as server, is a database server. The application server, which I will refer to as client, mounts a directory from server via NFS.

There is a user, appuser, on both client and server. However, appuser's UID on client is 502. appuser's UID on server is 506.

Both users need read and write capability on the NFS share. To facilitate this, I made the share owned by appuser on server.

Running id appuser on each yields: uid=506(appuser).

Of course, client does not recognize that ownership, since appuser has a different id on client. So I did the following:

  • Changed UID of user in /etc/passwd on client to be 506.

  • Changed ownership of appuser's $HOME on client to be appuser again so that I could log in.

Now, when I go to look at the NFS share from the client side, I see that it is owned by 502. 502 is the OLD id for appuser on client. I can't change ownership of the NFS share from client, since that is a volume that physically resides on server.

I need to make sure that the NFS share shows ownership of appuser from both server and client.

What step have I missed since changing the appuser id on client?

NOTE: I have not rebooted client (or anything else.)

share|improve this question

id appuser will likely show you that the shell still sees the old UID for the user. Logout and log back in.

share|improve this answer
They are both showing the same thing. – AKWF Oct 11 '12 at 3:28
up vote 2 down vote accepted

OK! I have got it. Found it on Bing after trying many times. Still not certain exactly WHICH thing fixed by problem, of two possibilities. But here they are.

There is "tell" on the internet that there can be client ownership permission problems with NFS v4. I don't know if that's true, and I don't care. Somebody had something they called a solution. So I followed the instructions to force the client to mount the drive as NFS version 3. So the first thing I did was change my mount line permissions in /etc/fstab from this:


to this:


Also, I started the nfs daemon on the client, just because someone said to do it:

service nfs start

Then, because I was following some dated instructions, I checked to see if the portmap service was running on the client:

service portmap status

and was greeted with:

portmap: unrecognized service

Then I found that portmap is now rolled into rpcbind. So:

service rpcbind status

And I saw:

rpcbind dead but pid file exists


[root@myserver customers]# service rpcbind restart
Stopping rpcbind:                                          [FAILED]
Starting rpcbind:                                          [  OK  ]

Then I checked the ownership of the NFS share, and it was CORRECT!

share|improve this answer

File ownership is saved with user ids. When you were looking at those files and seeing them as owned by appuser before the 502 -> 506 change, they were actually owned by user id 502 (ls -n will confirm). This has not changed.

Therefore, if you want to see appuser as the owner, you will have to change the ownership of the files from 502 to 506. And you may have to do that on the server if you do not have permissions on the client.

How to change the permissions is a different topic. If you do not have access to the server you can try copying the files using your new user (assuming you have read only access) and removing them later. It may be easier if you temporarily create a user with id 502 which will be able to change the permissions (but not the ownership) of the files owned by 502, rename them, or remove them after you copy them.

share|improve this answer
This is not correct. The ownership of 506 on the server is correct, it is being mapped to 502 by NFS on the client. Restarting client fixed this problem for me, although there may be a less heavy-weight way of solving this problem. – dwurf Sep 3 '14 at 1:56

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.