Eu acho que você está montando o nfsv3 em máquinas cliente e o nfsv4 na Máquina B (servidor nis)
Se você estiver usando o autofs para montar diretórios pessoais, adicione a opção -nfsvers = 3 na Máquina B
Visão geral do software
Máquina A (servidor NIS): CentOS 6.2
Máquina B :( Servidor NFS) CentoS 6.2
Máquinas clientes: OpenSuse 12.3, CentOS 6.4 e CentOS 5.6
Introdução e configuração
Máquina A é um servidor NIS que serve um grupo de máquinas clientes. Os diretórios iniciais, conforme definido pelo mapeamento do NIS, provenientes de um servidor NFS (máquina B ) são montados automaticamente no login.
A máquina B é um servidor NFS que autentica usando o NIS.
Quando efetuo login em uma máquina cliente, posso ler / gravar em meu diretório pessoal e todos os arquivos são
alex users
em termos de permissão. O mesmo acontece quando eu faço login no servidor NFS.
NO ENTANTO quando eu logar no servidor NIS, meu diretório home é montado, eu posso escrever arquivos para ele, mas todos os arquivos aparecem como
nobody nobody
para permissão. Apesar disso, whoami yeilds alex
Teste: Criando arquivos no servidor NIS no diretório / home / alex
Se eu criar um arquivo no meu diretório pessoal enquanto estiver logado no servidor NIS
touch /home/alex/testfile
ls -l testfile # on server
-rw-r--r--. 1 nobody nobody 0 Mar 19 14:21 testfile
mas se eu executar ls -l em uma máquina cliente, obtenho
ls -l testfile # on client machine
-rw-r--r--. 1 alex users 0 Mar 19 14:21 testfile
Então, claramente, o arquivo está sendo criado, pois o usuário correto e as permissões estão sendo respeitadas no servidor NIS. Além de exibir meus arquivos como nobody nobody , tudo parece bem, mas estou preocupado que isso possa ser um sintoma de algo mais sério.
Teste: ypcat de comandos
Quando logado no servidor NIS eu posso rodar
ypcat passwd
e obtenha resultados.
No entanto, ypcat shadow produz
No such map shadow. Reason: Internal NIS error
Mas eu teria pensado que isso era porque eu tenho
MERGE_PASSWD=true
Defina meu /var/yp/Makefile
Redundância de senha indesejada
Como última reviravolta estranha - para alguns usuários, eles podem fazer o login via NIS usando senhas antigas que não devem mais funcionar. Eu não tenho ideia de como isso aconteceria porque há apenas uma entrada por usuário no / etc / passwd e / etc / shadow? Esse pode ser um problema não relacionado ou pode fornecer informações úteis.
A resposta de Gustavo foi basicamente correta, mas eu pensei em adicionar alguns detalhes dela em vez de um comentário
Sou montado como nsf4 em todos os lugares, mas por alguma razão o nsf4 não está funcionando no servidor NIS.
Adicionando defaultvers=3,nfsvers=3 ao mountline no auto.master seguido por um serviço tal que meu arquivo auto.master se parece com isso
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# "nosuid" and "nodev" options unless the "suid" and "dev"
# options are explicitly given.
#
/net -hosts
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master
/home yp:auto.home -rw,hard,bg,rsize=32768,wsize=32768,defaultvers=3,nfsvers=3
Seguido por um reinício autofs
service autofs restart
Coloque as coisas em funcionamento.
Um problema aleatório - eu estava fisicamente logado na máquina em nosso data center, mas não desconectado, então o usuário administrador /home não conseguiu ser remontado mesmo após a reinicialização, o que causou alguma confusão.
Tags permissions nfs nis yp nobody