Os arquivos montados no NFSv4 pertencem a 4294967294, UIDs e GIDs correspondem

23

Eu tenho duas máquinas linux idênticas (imagens idênticas lançadas no amazon EC2) e estou tentando montar um diretório exportado pelo NFSv4. Aqui está a aparência do diretório montado na máquina cliente:

root@server:~# ls -l /websites/
drwxr-xr-x  6 4294967294 4294967294   92 2010-01-01 20:21 logs
drwxr-xr-x  2 4294967294 4294967294   20 2009-12-23 01:14 monit.d
...

Verifiquei novamente para garantir que os UIDs estavam correspondendo

Aqui está o comando mount que eu corro a partir do cliente

/sbin/mount.nfs4 $MASTER_DN:/ /websites -o rw,_netdev,async

E aqui está a /etc/exportsentrada na máquina do servidor:

/websites 10.0.0.0/8(fsid=0,no_subtree_check,rw,no_root_squash)

linux permissions nfs

— jberryman
fonte

o serviço rpcidmapd está em execução? inicie-os usando comandos. /etc/init.d/rpcidmapd restart chkconfig rpcidmapd on

8

Conforme explicado em UID / GID com NFS e ZFS , o NFSv4 não usa UIDs. Eu estava tendo um problema semelhante e consegui solucionar o problema usando o NFSv3. Isso implica adicionar -o vers=3ao mountcomando. Obviamente, se você precisar usar o NFSv4, essa resposta não será muito útil para você.

— intuído
fonte

7

leia aqui http://blather.michaelwlucas.com/archives/796

Se os nomes de domínio do cliente e servidor NFSv4 não corresponderem, todos os nomes de usuário aparecerão como "ninguém".

edite /etc/idmapd.conf e defina Domínio no servidor e cliente como "localdomain"

[Geral]

Domínio = domínio local

[Tradução]

Método = nsswitch
altere o arquivo / etc / default / nfs-common (no servidor e no cliente): configure NEED_IDMAPD = yes
inicie o serviço idmapd

— vadim
fonte

Para mim, essa resposta resolveu o problema que eu tive (depois que o "idmapd" caiu por algum tempo).

— Henk

7

Este é um problema de mapeamento de identificação de usuário. Por alguma razão, o sistema está usando a conta "ninguém" em vez dos IDs reais da conta. Verifique suas opções de esmagamento e seu arquivo idmapd.conf.

Aqui está um tópico que eu descobri que discute o problema, que está relacionado ao post de interesse, http://www.mail-archive.com/rhelv5-list@redhat.com/msg03303.html .

FYI, 4294967294 é -2, se tratado como um número inteiro assinado de 32 bits. -1 ou -2 são usados em várias distribuições Linux para o UID de ninguém e o GID de nogroup (no arquivo passwd, geralmente é usado o número sem sinal mais alto de 16 bits, 65535).

— David
fonte

Obrigado pela resposta, David. Pela minha postagem, eu no_root_squashativei. Você tem mais informações sobre o arquivo idmapd.conf?

— jberryman

3

Você precisa alterar o arquivo / etc / default / nfs-common (em ambos o servidor e cliente): definir NEED_IDMAPDa yes.

Pelo menos isso me ajudou.

— Veger
fonte

2

Estamos usando as opções do NFS anonuide anongidpara definir os IDs de usuário / grupo que o servidor usará para arquivos criados por anônimos. Se estes não estiverem definidos, "ninguém" e "nogroup" serão usados - o que pode variar dependendo da versão e distribuição do SO. Então um

/websites 10.0.0.0/8 
    (fsid=0,no_subtree_check,rw,no_root_squash,anonuid=1001,anongid=1001)
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^

pode ser o truque (com 1001 sendo um UID / GID válido e utilizável no seu servidor).

— Axel Knauf
fonte