Montando NFS: donos são nobody: nogroup

Question

Eu montei um arquivo do NFS 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

Eu mostro os arquivos como nobody: nogroup:

Algumaideiaparacorrigiresteproblemaeexibirosproprietárioscertos?

EuusooUbuntu12.04.

Editar:

Ladodocliente(nãotenhoacessoaoservidorNFS):

rpcidmapdestáemexecução:

rpcinfo -p :

/etc/idmapd.conf:

    

Answer 1

Pedir suporte ou documentação local soa como uma boa ideia:).

No formulário da lista de verificação, acho que você precisa

1) o (s) usuário (s) requerido (s) criado (s) no sistema do 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 o LDAP.

2) mapeamento de usuários entre cliente e servidor. No NFS4 (implícito pela opção tcp) isso é tratado pelo idmapd, como 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ê quiser acessar qualquer arquivo como alguém que não seja "ninguém", isso é definitivamente necessário. Eu 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 no idmapd.conf.

ou com a 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. Isso é usado somente quando o servidor confia no cliente:).

    

Answer 2

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

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

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

Se você modificar o /etc/nsswitch.conf para mapear para algo diferente de arquivos (como ldap ou nis), então você precisa também assegurar que o ldap ou nis possua algum tipo de entrada para o nome de usuário ou grupo que você deseja a conversão de ID para. Se uma entrada não existir, o idmapd falhará ao mapear usuários / grupos com sucesso.

Em problemas relacionados que encontrei para o RHEL v7, o serviço idmapd.conf não precisa mais ser ativado para clientes NFS:

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

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

cat /proc/sys/kernel/keys/root_maxkeys    

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

/etc/sysctl.conf

e adicione ou modifique estas linhas da seguinte forma:

# 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, portanto, ajuste conforme necessário. Isso permitirá que todas as chaves de nomes de identidades permaneçam mapeadas durante o uso da montagem do 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 esses 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

O mais provável é que maxbytes e root_maxbytes sejam grandes o suficiente para armazenar todas as chaves:

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