Isso é um bug. Ele trabalhou brevemente em uma atualização de pré-lançamento, mas foi quebrado novamente. Eu enviei um relatório de bug com a Apple.
Somos uma loja Linux com cerca de 30 Macs para suportar. Temos nossos sistemas Leopard e Snow Leopard configurados com autenticação LDAP e diretórios de origem NFSv3 montados automaticamente para que nossa equipe tenha o mesmo login e arquivo, quer eles usem o OS X ou o Ubuntu. O único problema que temos é que, com o NFSv3, não podemos usar o Firefox > = 4. Esse problema ainda existe no Lion.
Agora que o OS X suporta o NFSv4 no Lion, decidi experimentar. Ele falhou rapidamente. Eu não consigo abrir aplicativos. Quando eu efetuo login com o ssh, muitos comandos relacionados a operações de arquivo são interrompidos.
Em clientes Linux NFSv4, você deve configurar um nome de domínio para mapear nomes de usuários entre o cliente e o servidor em /etc/idmpad.conf. Existe algo parecido no Lion? Existe alguma outra configuração que eu precise verificar?
Eu também tentei usar a última versão do Netatalk, mas depois de um tempo, o Microsoft Word começa dizendo que os arquivos são somente de leitura.
Informações atualizadas
We discovered that using async in NFSv3 solved our problem with Firefox. Unfortunately, async does not solve the problem with NFSv4.
Isso acabou sendo um mal-entendido do problema. async não resolve o problema para NFSv3 ou NFSv4.
Método de teste
Temos algumas contas de teste em nosso servidor LDAP com entradas autofs apontando para um servidor NFSv4 no Ubuntu. Eu testo fazendo o login através da janela de login ou por ssh. Na GUI, tento abrir aplicativos e editar arquivos de texto. Via ssh, eu tento editar arquivos de texto com o vim.
Para a sugestão do NFS Manager, usei su para me tornar um desses usuários e tentei editar um arquivo com o vim.
Configurações do servidor
Este é o arquivo / etc / exports do meu servidor nfsv4 de teste. As configurações são as mesmas dos servidores NFSv3 de produção.
/var/lib/nfs/v4root @utm(ro,fsid=0,root_squash,insecure,no_subtree_check,async) @admin(ro,fsid=0,no_root_squash,insecure,no_subtree_check,async)
/var/lib/nfs/v4root/d2/export/fac @utm(fsid=31,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=31,rw,async,no_root_squash,no_subtree_check,insecure)
/var/lib/nfs/v4root/d2/export/grad @utm(fsid=32,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=32,rw,async,no_root_squash,no_subtree_check,insecure)
/var/lib/nfs/v4root/d2/export/staff @utm(fsid=33,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=33,rw,async,no_root_squash,no_subtree_check,insecure)
/d2/export/fac @utm(fsid=41,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=41,rw,async,no_root_squash,no_subtree_check,insecure)
/d2/export/grad @utm(fsid=42,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=42,rw,async,no_root_squash,no_subtree_check,insecure)
/d2/export/staff @utm(fsid=43,rw,async,root_squash,no_subtree_check,insecure) @admin(fsid=43,rw,async,no_root_squash,no_subtree_check,insecure)
Opções de montagem do cliente
Os clientes usam o autofs no LDAP para montar o sistema de arquivos. As opções são as seguintes:
intr,tcp,rw,vers=4,timeo=20
Eu tentei apenas com vers = 4, mas obtive os mesmos resultados.
Rede
Para este teste, o cliente e o servidor estão em sub-redes diferentes. O tráfego passa por switches cisco de 100 Mbps com conexões gigabit ao switch cisco route. Os testes de throughput mostram transferências consistentes de 91 Mbps com picos baixos de 0,3 ms. Esta rede tem sido apropriada para o NFSv3 por muitos anos.
Solução
Espere por 10.7.3. Tenho o prazer de informar que este foi um bug no 10.7.2, e o pré-lançamento do 10.7.3 o corrige.
Você pode tentar usar o Gerenciador NFS para ajudá-lo a configurar suas montagens NFS. É muito mais fácil de usar que o Utilitário de Disco da Apple.