Em uma caixa recentemente atualizada do SLES 9.3 para 10.2, estou vendo o seguinte problema:
Antes da atualização, uma montagem NFS (definida via yast, por exemplo, aparecia em /etc/fstab ) funcionava corretamente. Após a atualização, no entanto, está falhando. Um rastreamento de rede mostra que está fazendo a conexão inicial com o servidor NFS sobre TCP (para o portmapper RPC), mas depois passa para UDP para a chamada MOUNT subseqüente; já que o servidor NFS não permite o UDP (por um bom motivo, devido a possíveis problemas com corrupção de dados, como em nfs(5) ), a conexão não passará.
Adicionar a opção TCP (seja no fstab ou na linha de comando, etc.) não tem efeito.
Durante a solução de problemas, descobri que / var / adm / messages está relatando o seguinte como ocorrendo durante a inicialização:
Failed services in runlevel 3: network
(devo observar que, apesar dessa mensagem de erro, aparentemente pelo menos alguns serviços de rede foram iniciados, já que a caixa é acessível via SSH.)
Minhas perguntas, então:
Editando para adicionar algumas informações relacionadas às respostas abaixo.
Acontece que o serviço de rede está falhando na inicialização porque uma das interfaces (há duas nesta caixa) usa o DHCP, e isso ainda não está disponível no momento. Então, eu o desativei por enquanto, parei / reiniciei o serviço de rede e os serviços do cliente NFS, mas ainda obtive os mesmos resultados.
Não há firewall no lado do cliente. Além disso, iptables -L no lado do cliente mostra que tudo é aceito; e não há entradas em /etc/hosts.allow ou /etc/hosts.deny.
No lado do servidor NFS, nada foi alterado. O nfsserver remoto é, de fato, publicidade que permite TCP e UDP para todos os serviços NFS (embora haja uma regra de iptables bloqueando UDP).
A entrada do / etc / fstab é bem básica - o que você gostaria de fazer no yast:
x.x.x.x:/volume /localdir nfs defaults 0 0
rpcinfo -p para a caixa do cliente mostra apenas o portmapper v2 em execução, anunciando tanto o TCP quanto o UDP. Para o servidor, mostra todos os serviços habituais:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 4047 status
100024 1 tcp 4047 status
100011 1 udp 4049 rquotad
100021 1 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100005 1 udp 4046 mountd
100005 1 tcp 4046 mountd
100005 2 udp 4046 mountd
100005 2 tcp 4046 mountd
100005 3 udp 4046 mountd
100005 3 tcp 4046 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
A chamada de montagem, com a entrada / etc / fstab acima, é simplesmente:
mount /localdir
embora eu também tenha tentado com várias opções, como tcp, v3, etc.
Tanto a entrada / etc / fstab (daí a montagem) quanto a chamada rpcinfo -p estão usando o endereço IP, portanto não há problemas de resolução de DNS envolvidos.
Para referência, caso alguém encontre essa pergunta e queira uma resposta:
Eu finalmente abri um ticket com a Novell sobre isso. Acontece que este é um bug conhecido no SLES 10.2 (491140: mount ignores "proto=" for "nfs"), e há um patch para ele (util-linux-2.12r-35.35.2.x86_64.rpm) . Com isso instalado, a montagem funciona conforme o esperado e todas as solicitações são feitas através do TCP. (O suporte da Novell também me informou que isso é mesclado no SLES 10.3.)
Verifique se /etc/hosts.deny não contém uma entrada para mountd e verifique hosts.allow , por motivos semelhantes. Por que vale a pena, eu geralmente limpo hosts.deny e uso iptables para controlar o acesso.
Use rpcinfo -p nfsserver para garantir que mountd esteja realmente anunciando TCP - existe uma opção -n para desabilitar a escuta TCP, que (IIRC no SuSE) provavelmente seria definida em /etc/sysconfig/nfs ou por aí.
Pelo que entendi, você pode fazer o seguinte:
rpcinfo do cliente ao servidor mas você não pode montar um sistema de arquivos do servidor nfs no cliente nfs e você não recebe nenhuma mensagem de erro.
qual é a diferença entre suas chamadas rpcinfo e mount ? você usa ip address em um e fqdn no outro? você poderia por favor postar os dois comandos com saída e returncode?
Algumas coisas. Primeiramente, você declara no início que since the NFS server doesn't allow UDP e, em sua edição, menciona The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services . Isso parece um pouco estranho. Por que o servidor anuncia algo que não permite?
Em segundo lugar, você está tentando usar o NFS versão 2 ou versão 3? A versão 2 suporta apenas o UDP, enquanto você precisa da versão 3 para o TCP. Talvez especificar manualmente a versão 3 nas opções de montagem ajudará? (vers = 3) Se o padrão é 2, então até mesmo especificar TCP não fará nenhum bem a você.
Eu também tive problemas com clientes mais novos tentando usar a versão 4, quando o servidor não suportava muito. Sua atualização do SLES pode ter resultado em uma versão padrão diferente. Mais uma razão para especificá-lo explicitamente.
Por que você não publica a entrada em / etc / fstab também?
service network restart e ver quais mensagens você recebe. Deve haver alguma informação lá. Tente definir as coisas explicitamente e veja onde isso acontece. Por exemplo, em / etc / fstab:
x.x.x.x:/vol /local nfs proto=tcp,port=2049,mountport=4046,nfsvers=3 0 0
Isso deve pelo menos ignorar o portmapper e explicitamente tentar conectar as portas TCP listadas acima e facilitar o tcpdump rastrear cada canal durante a depuração.
Tags networking nfs sles10