Eu tive isso depois de uma atualização recente. Desativei o NFS4 no Qnap e o habilitei no Qnap e depois funcionou para o cliente.
Eu tenho um QNAP TS-251 NAS com um par de 4 Unidades GB configuradas como RAID 1, sendo executadas como um servidor, principalmente para backups. Tem o sistema operacional padrão, QTS 4.2.0 (2016/01/19), que eu acho que é atual. É um sabor personalizado do Linux com uma interface gráfica que eu corro do meu desktop do Windows. Tem o número de IP 169.254.100.101 em sua porta Ethernet nº 1 e 169.254.100.102 em sua porta Ethernet nº 2.
Como cliente, tenho um velho laptop Dell (Core 2 Duo T8100) rodando o Ubuntu 14.04 LTS. Ele está conectado à porta Ethernet nº 2 da QNAP e seu número IP é 169.254.100.99.
Observação: A partir daqui, incluirei detalhes do histórico que provavelmente podem ser ignorados (mas responda "Por que você faria isso?", perguntas que eu antecipo) em [colchetes].
Há também uma área de trabalho do Windows conectada à porta Ethernet # 1 da QNAP, que está envolvida com isso apenas para executar a GUI da QNAP. Eu também posso usar o PuTTY dele para o QNAP se eu precisar de uma linha de comando
[O QNAP vem com várias pastas compartilhadas padrão: Download, Multimídia, Público, Gravações, Web, residências.]
Eu criei uma pasta compartilhada chamada CrashPlan no servidor QNAP, e um ponto de montagem no cliente Ubuntu chamado / mnt / QNAP-CrashPlan. Eu instalei pacotes do cliente NFS no cliente com sudo apt-get install portmap nfs-client [e instalei o autofs com sudo apt-get install autofs em uma tentativa malsucedida de diagnosticar problemas].
Seguindo os conselhos em esta questão , dei direitos de acesso ao NFS , host / IP / rede 169.254. *, permissão de leitura / gravação e opção de squash NO_ROOT_SQUASH. As caixas anônimas permaneceram acinzentadas.
Então, no momento da verdade, do cliente, eu tentei sudo mount 169.254.100.102:/CrashPlan /mnt/QNAP-CrashPlan e sudo mount -t nfs 169.254.100.102:/CrashPlan /mnt/QNAP-CrashPlan e recebi mount.nfs: Connection timed out nos dois casos.
Em uma tentativa de diagnosticar o problema, tentei showmount -e 169.254.100.102 , mas ele respondeu clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) .
Eu pesquisei muito e tentei muito, mas não encontrei nenhum outro caminho para diagnosticar o problema. Alguma idéia?
Vou editar mais detalhes conforme necessário. Além disso, isso pode merecer uma tag "qnap", mas não tenho permissão para criar tags.
[<> Detalhes do problema XY : razão que eu nomeei a pasta compartilhada que eu criei CrashPlan é que eu tentei executar o QNAP como um servidor CrashPlan. Não consegui fazer isso funcionar, exceto montando a pasta CrashPlan como uma unidade do Windows, usando net use para montá-la e executando uma instância de cliente em modo de usuário separada do CrashPlan no Windows, porque o Windows não permite serviços acesso a net use drives. A execução do servidor CrashPlan no meu antigo laptop Ubuntu com o QNAP montado através do NFS foi descrito como uma configuração que evitou esse problema.]
Eu tive isso depois de uma atualização recente. Desativei o NFS4 no Qnap e o habilitei no Qnap e depois funcionou para o cliente.
Endereços IP iniciados por 169. * são um erro, você precisa corrigi-lo primeiro, talvez ele possa ser corrigido configurando um servidor DHCP no NAS.
O resto deve ficar bem depois disso.