Recentemente, decidi me comprometer a usar o NFSv4 apenas por vários motivos, e o mais importante é que minha organização considera o rpcbind um risco de segurança. (Não importa que o upstream esteja enviando arquivos da unidade systemd do nfs-server que dependem do rpcbind, mas isso é um problema separado).
Em um servidor Ubuntu 16.04 eu instalei os pacotes NFS e configurei / etc / exports assim:
/srv/nfs 192.168.1.100(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cemdata 192.168.1.100(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.1.100(rw,sync,no_subtree_check)
Não há absolutamente nenhuma documentação que eu possa encontrar fornecendo instruções sobre como desabilitar o NFSv2 e o NFSv3, mas adivinhei que isso facilitou adicionando a seguinte linha ao / etc / default / nfs-kernel-server:
RPCNFSDARGS="-N 2 -N 3"
No sistema do cliente, a entrada / etc / fstab se parece com isso:
# NFSv4 mounts from kraken:
kraken.xxx.utexas.edu:/local /local nfs4 _netdev,auto 0 0
kraken.xxx.utexas.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
Então, aqui está o meu problema: parece que, por padrão, a segurança nos compartilhamentos NFS ainda está sendo determinada pelo UID. Eu experimentei trocando os UIDs de alguns usuários no servidor NFS e as alterações de propriedade montadas de acordo. Enquanto isso, o idmapd parece estar em execução:
root@kraken:/etc/default# systemctl status nfs-idmapd
● nfs-idmapd.service - NFSv4 ID-name mapping service
Loaded: loaded (/lib/systemd/system/nfs-idmapd.service; static; vendor preset
Active: active (running) since Tue 2017-10-31 14:19:01 CDT; 2 days ago
Process: 1424 ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS (code=exited, stat
Main PID: 1437 (rpc.idmapd)
Tasks: 1
Memory: 716.0K
CPU: 12ms
CGroup: /system.slice/nfs-idmapd.service
└─1437 /usr/sbin/rpc.idmapd
Oct 31 14:19:01 kraken systemd[1]: Starting NFSv4 ID-name mapping service...
Oct 31 1 4:19:01 kraken systemd[1]: Started NFSv4 ID-name mapping service.
Em algumas referências mais antigas, eu noto pessoas sugerindo que você deve definir sec = sys em / etc / exports para obter o antigo comportamento baseado em UID, mas quando você olha a man page de exportação não há nenhuma opção sys listada, indicando que ela deve estar obsoleta.
Alguém pode explicar o que está acontecendo? O sistema é padronizado para o mapeamento de UID porque não tenho nenhum mapeamento estático configurado em /etc/idmapd.conf? O Debian / Ubuntu está compilando o servidor de kernel nfs com a opção sec = sys ativada por padrão? Certamente, seria útil ter uma documentação abrangente para um serviço de sistema tão importante. É por isso que as pessoas continuam usando o NFSv3.