Montando NFS: os proprietários não são ninguém:nogroup

Question

Montei um sistema de arquivos NFS a partir do shell usando o código:

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

Mostro os arquivos como ninguém:nogroup:

Alguma ideia para corrigir esse problema e exibir os proprietários corretos?

Eu uso Ubuntu 12.04.

Editar:

Lado do cliente (não tenho acesso ao servidor NFS):

rpcidmapdestá correndo:

rpcinfo -p:

/etc/idmapd.conf:

Answer 1

Pedir suporte local ou documentação parece uma ideia muito boa :).

Em forma de checklist, acho que você precisa

1) os usuários necessários criados no sistema cliente. Isso pode ser feito manualmente, mas você deve esperar que haja um "serviço de diretório" automático que você pode configurar. Pode ser LDAP.

2) mapeamento de usuários entre cliente e servidor. Em NFS4(implícito na opção tcp)isso é tratado pelo idmapd, conforme mencionado por gareth. Você só precisa definir o domínio para corresponder ao que o servidor pensa. O domínio cruzado não funciona, acho que é uma limitação do Linux.

3) Kerberos para se autenticar no servidor (disponível no NFS4). Se você deseja acessar qualquer arquivo como alguém que não seja "ninguém", isso é definitivamente necessário. Sugiro configurar e testar o Kerberos antes de tudo. A configuração incluirá a configuração de um domínio - você definirá o mesmo domínio em idmapd.conf.

ou com autenticação no estilo NFS3, 3) é ignorado e em vez de 2) você apenas verifica se o UID numérico do usuário corresponde ao do servidor. Isto é usado apenas quando o servidor confia no cliente :).

Answer 2

Eu persegui um problema semelhante. Definir /etc/idmapd.conf Verbosity=3 ajudou a ver alguns dos problemas no Ubuntu, mas não todos. Aqui está um resumo de minhas descobertas:

Ainda existe a possibilidade de que seus arquivos /etc/passwd e de grupo não compartilhem os mesmos usuários/grupos que a máquina que oferece o compartilhamento. Aqui está uma dica de que sua máquina local deve ter um mapeamento de nome de usuário/grupo semelhante. /etc/nsswitch.conf ou a operação de mapeamento do idmapd falhará. Observe aqui que se estiver executando Verbosity=3 você verá uma entrada em /var/log/syslog, como:

idmapd[25193]: Cliente 64: (grupo) nome "TheGroupNameYouExpected" -> id "65534

Se você modificar /etc/nsswitch.conf para mapear para algo diferente de arquivos (como ldap ou nis), então você também precisa garantir que ldap ou nis tenha algum tipo de entrada para o nome de usuário ou nome do grupo que você deseja traduzir o ID para. Se uma entrada não existir, o idmapd não conseguirá mapear usuários/grupos com êxito.

Em questões relacionadas que encontrei para RHEL v7, o serviço idmapd.conf não precisa mais ser habilitado para clientes NFS:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

No entanto, há um problema em andamento no thread acima: por padrão, os serviços que executam o mapeamento automático de ID-nome de usuário têm um número muito baixo de IDs que permanecem mapeados na memória. Em vez de registrar um erro, o idmapd simplesmente se recusa a traduzir mais de 200 usuários. Você pode verificar isso nas configurações atuais do kernel:

cat /proc/sys/kernel/keys/root_maxkeys    

Provavelmente 200 é a configuração padrão. Para permitir que os pontos de montagem do NFS mapeiem adequadamente todos os usuários disponíveis, você precisa alterar este arquivo:

/etc/sysctl.conf

e adicione ou modifique essas linhas da seguinte maneira:

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

Seu sistema pode não exigir tantos mapeamentos de chave de usuário/ID, então ajuste conforme necessário. Isso permitirá que todas as chaves de nome de identificação permaneçam mapeadas durante o uso da montagem NFS. Aqui está outra postagem relacionada que mostra as configurações atuais do kernel:

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

para estes valores:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

Muito provavelmente maxbytes e root_maxbytes devem ser grandes o suficiente para armazenar todas as chaves:

https://www.kernel.org/doc/Documentation/security/keys.txt

Answer 3

Mais uma lista de verificação, supondo que você esteja usando NFSv4 com Kerberos:

• kinit, então olhe para klist. Você deverá ver um ticket; caso contrário, procure primeiro respostas sobre como corrigir a autenticação Kerberos.
• está rpc.gssdcorrendo? Você pode querer iniciar o serviço; Além disso, em algumas distribuições, ele não inicia automaticamente, a menos que você mencione montagens NFS com krb5* em suas opções no seu arquivo /etc/fstab.
• está rpc.idmapdcorrendo? (Novamente, isso normalmente deve ser iniciado por um serviço NFS do lado do cliente; ls /etc/init.d/é um bom ponto de partida.
• Olhe para /etc/idmapd.conf. A parte "Domínio" corresponde ao domínio real do seu servidor NFS? (... se nada mais, você poderia tentar usar o domínio Kerberos.) Já vi distribuições onde isso não era necessário e algumas onde era; talvez em alguns, tenha padrões mais razoáveis ​​para um FQDN.
• também adicione GSS_principal_attr = GSSAuthNameao arquivo. Apenas o domínio pode resolver alguns problemas de propriedade, mas parece que isso também é necessário para, por exemplo, diretórios.
• reinicie pelo menos rpc.idmapduma vez ajustando a configuração. Uma remontagem não deve ser necessária após ajustar a configuração, mas não faz mal.
• também! nfsidmap -c. Aparentemente, há um cache que não é limpo mesmo após a reinicialização; isso irá limpar tudo. (Caso contrário, você pode continuar pensando que a correção não funciona, mesmo que funcionasse.)