A situação é um servidor e cliente nfs4 usando rpc.idmapd para mapear ids. O mapeamento de id está trabalhando no cliente para arquivos existentes servidos a partir do servidor.
No servidor:
[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
No cliente:
[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
Então tudo bem.
No entanto, criar um arquivo do cliente:
[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
Não parece fazer o mapeamento de nomes id- > no lado do cliente neste momento.
Ambos os sistemas são o CentOS 5.x. Aliás os arquivos /proc/net/rpc/nfs4.nametoid/content e /proc/net/rpc/nfs4.idtoname/content estão vazios no cliente, mas possuem entradas no servidor.
Eu acessei o registro em rpc.idmapd no cliente e / var / log / messages mostra que ele está sendo usado para o nome nos mapeamentos de ID, por exemplo: Aug 27 11:49:27 fw01 rpc.idmapd [11773]: Cliente 23: (usuário) nome "user2 @ localdomain" - > id "505" Eu esperava que as pesquisas de nome id-> correspondentes acontecessem no momento em que um arquivo é criado no lado do cliente.
A simples solução de sincronizar ids e usar o nfsv3 não é realmente uma opção (como não é simples!).
EDITAR:
desculpa pela confusão:
[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:
, ou seja, o que parece acontecer é criar arquivos no cliente, pois o usuário1 (uid 504 / gid 506) não é traduzido antes da criação no servidor. É criado como 504/506 no servidor. Isso no servidor é user2 / user2, por isso é devolvido ao cliente errado depois desse ponto.
Eu também tive o mesmo problema e passei algum tempo pesquisando a resposta. Parece que o rpc.idmapd não suporta o ID para nomear o mapeamento que permitiria fazer alterações no sistema de arquivos. No entanto, tenho visto a referência ao fato de que isso pode funcionar se você montar com autenticação Kerberos ( link ). Eu não tentei isso ainda como Kerberos parece ser um pouco difícil de configurar. Eu vou apenas sincronizar os UIDs para simplificar neste momento.