Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The situation is an nfs4 server and client using rpc.idmapd to map ids. The id mapping is working on the client for existing files served up from the server.

On the server:

[root@server ~]# id user1
uid=500(user1) gid=502(user1) groups=502(user1)
[root@server ~]# ls -l /mnt/san/temp
total 0
-rw-r--r-- 1 user1 user1 0 Aug 27 11:46 test1
[root@server ~]# ls -ln /mnt/san/temp
total 0
-rw-r--r-- 1 500 502 0 Aug 27 11:46 test1

On the client:

[user1@client ~]$ id user1
uid=504(user1) gid=506(user1) groups=506(user1)
[user1@client ~]$ ls -l /mnt/san/temp
total 0
-rw-r--r-- 1 user1 user1 0 Aug 27 11:46 test1
[user1@client ~]$ ls -ln /mnt/san/temp
total 0
-rw-r--r-- 1 504 506 0 Aug 27 11:46 test1

So that's fine.

However creating a file from the client:

[user1@client ~]$ touch /mnt/san/temp/test2
[user1@client ~]$ ls -l /mnt/san/temp
total 0
-rw-r--r-- 1 user1 user1 0 Aug 27 11:46 test1
-rw-rw-r-- 1 user2 user2 0 Aug 27 11:49 test2
[user1@client ~]$ ls -ln /mnt/san/temp
total 0
-rw-r--r-- 1 504 506 0 Aug 27 11:46 test1
-rw-rw-r-- 1 505 507 0 Aug 27 11:49 test2

It doesn't appear to do the id->name mapping on the client-side at this point.

Both systems are CentOS 5.x. Incidentally the files /proc/net/rpc/nfs4.nametoid/content and /proc/net/rpc/nfs4.idtoname/content are empty on the client, but have entries on the server.

I turned up logging on rpc.idmapd on the client and /var/log/messages shows it is being used for name to id mappings, eg: Aug 27 11:49:27 fw01 rpc.idmapd[11773]: Client 23: (user) name "user2@localdomain" -> id "505" I was expecting corresponding id->name lookups to happen at the point a file is created client-side.

The simple solution of synchronising ids and using nfsv3 isn't really an option (as in not simple!).

EDIT:

sorry for the confusion:

[user1@client ~]$ getent passwd 504 505
user1:x:504:506::...
user2:x:505:507::...
[user1@client ~]$ getent group 506 507
user1:x:506:
user2:x:507:

[root@server ~]# getent passwd 504 505
user2:x:504:506::...
[root@server ~]# getent group 506 507
user2:x:506:

ie what appears to happening is creating files on client as user1 (uid 504/gid 506) does not get translated before creation on the server. It is created as 504/506 on the server. This on the server is user2/user2, so it's returned to client wrong after that point.

share|improve this question
    
gid 507 on test2 file? Where does that gid come from? I'm a bit lost here. –  Janne Pikkarainen Aug 27 '10 at 12:06
    
Yea, to clear things up, please add output of getent passwd 504 + 505 getent group 506 + 506 from both client and server. –  al. Aug 27 '10 at 12:40
    
see edit above (comments don't seem to format as wiki) –  bee Aug 27 '10 at 13:28
add comment

1 Answer

I also had the same problem and spent some time researching the answer. It does seem that rpc.idmapd doesn't support ID to name mapping that would let you make changes to the file system. However I have seen reference to the fact this might work if you mount with Kerberos authentication (http://permalink.gmane.org/gmane.linux.nfsv4/11363). I haven't tried this myself yet as Kerberos seems to be a bit of a pain to set up. I'm going to just sync up the UIDs for simplicity at this point.

share|improve this answer
add comment

Your Answer

 
discard

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.