Mapeamento de ID do usuário com NFS no Synology NAS

Eu tenho uma caixa Synology NAS (executando o DSM 5.1) e exportei um diretório via NFS. Estou tentando montá-lo na minha caixa do Ubuntu.

Geralmente funciona bem, mas estou tendo problemas com os mapeamentos de usuários e grupos. Na caixa do Ubuntu, eu sou uid 1000 (roger), gid 1000 (roger). Na Synology, eu uid 1026 (Roger), grupo 100 (usuários).

Se eu uso o NFSv3, ele usa valores numéricos de uid / gid, o que significa que a propriedade está desarrumada na Synology.

Se eu acessar apenas a montagem NFS da mesma caixa do Ubuntu, usando o mesmo usuário, tudo bem, mas também acessarei o diretório a partir de uma caixa do Windows, usando CIFS (SMB), o que significa que as permissões são errado.

Se eu usar o NFSv4 ( mount -o nfsvers=4), com as configurações padrão do Synology, os arquivos pertencentes roger.usersao Synology aparecerão pertencentes a roger.usersquando visualizados na caixa Ubuntu. Isso é bom.

No entanto, quando eu touchum arquivo:

roger@ubuntu$ touch /mounts/diskstation/music/foo

Ele acaba sendo de propriedade 1000.1000da Synology e mostrado como de propriedade nobody.4294967294quando visualizado na caixa do Ubuntu.

Tudo o que posso encontrar sobre o tópico nos fóruns da Synology é datado de 2011, quando o NFSv4 não era suportado, ou consiste em pessoas fazendo a mesma pergunta e desistindo.

Para completar, /etc/exportspossui:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... e eu estou montando na caixa Ubuntu com:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Encontrei algumas dicas de que isso sec=syspode ser um problema: Por que o mapeamento uid / gid do NFSv4 não funciona com AUTH_UNIX (AUTH_SYS) , mas isso não tem solução.

Existe uma maneira simples de contornar esse problema? Existe uma (mais complexo tosse Kerberos tosse ) maneira de resolver isso?

Sério, se Kerberos é a resposta, eu levo esse golpe, mas eu gostaria de saber antes de perder muito tempo com isso.

Atualização : enquanto a documentação da Synology fala sobre várias opções do Kerberos, não consigo encontrá-las na interface do usuário. As notas de versão afirmam "Se o sabor de segurança Kerberos for implementado ...". Encontrei (mas não consigo encontrar novamente) uma página que implica que ela pode não estar em certos modelos. Eu tenho um DS211, de acordo com a página Informações do sistema. Talvez eu esteja sem sorte?

Para o mapeamento de ID do NFSv4 funcionar corretamente, o cliente e o servidor devem estar executando o idmapddaemon do Mapeador de ID e ter o mesmo Domainconfigurado /etc/idmapd.conf.

Dessa forma, seu cliente NFS envia suas credenciais de ID como roger@example.comnos comandos NFS na conexão e o idmapper do servidor NFS mapeia isso para um usuário chamado rogerno servidor NFS. O UID e o GID não importam, eles são mapeados em cada sistema pelo idmapper.

No entanto, eu não me incomodo com isso na minha Synology. Minha pasta compartilhada tem as seguintes permissões:

• Permissões
  • Usuários locais
    • Admin = leitura / gravação
• Permissões NFS
  • Abóbora
    • Mapear todos os usuários para o administrador

Isso resulta em anonuid=1024,anongid=100(o adminusuário e o usersgrupo) sendo adicionados à exportação no /etc/exportsNAS.

Meu cliente NFS (que não possui o ID Mapper em execução) envia meus comandos NFS como meu usuário ( 1000:1000) e, como esse UID e GID não existem no NAS, ele converte meu UID e GID para 1024:100que eu seja tratado como o Usuário administrador com permissão total.

Esse é um uso extremamente inseguro e não profissional do NFS para um ambiente de negócios, mas apenas para acessar meus arquivos em casa, é um abuso do comportamento do NFS que é aceitável para mim.

Outra opção é fazer rogeré UID e GID o mesmo no cliente NFS e NAS, então você pode usar NFSv4 sem ID Mapping, ou você poderia usar NFSv3 que se baseia apenas em UID e GID.

Eu tenho realmente lutado com exatamente o mesmo problema. Passei pela enorme dificuldade de configurar um servidor Kerberos com o Docker no Synology, configurei o mapeamento de ID e ainda não gostei do comportamento. O Kerberos é excessivamente projetado e difícil de continuar trabalhando nas reinicializações e na montagem automática. Além disso, a umask padrão dos arquivos recém-criados era 0000, e cada novo arquivo era criado no modo 777, independentemente do meu umask local.

Minha solução foi semelhante à do suprjami, mas levei um pouco mais longe:

• Crie um novo usuário com a interface do usuário da web da Synology, nomeie-o como algo roger.remote. Faça o mesmo para um grupo de usuários e atribua o mesmo nome que o nome de usuário.
• Na Synology como raiz, edite o arquivo / etc / passwd e altere roger.remoteo UID para 1000 e o GID para 1000
• edite o / etc / group e mude o grupo roger.remotepara 1000 também
• Na interface do usuário da web da Synology, defina squash como "todos os usuários para administrar" e salve
• Como root novamente, edite / etc / exportações e altere o UID / GID para anonuid=1000,anongid=1000
• Reinicie o NFS com /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Isso também é um pouco hacky - mas chmod 777 /volume1. Eu tive muitos problemas estranhos com o meu diretório pessoal montado. O KDE não seria iniciado porque a access()função glibc retornaria o acesso negado no diretório NFS montado. (Mas qualquer subdiretório funcionaria) O Firefox também teve um problema semelhante, onde se recusou a salvar arquivos no diretório montado por causa da verificação de acesso. Mesmo que as permissões estivessem corretas e eu pudesse tocar / criar / gravar arquivos no diretório montado. Alterar o diretório pai / volume1 para o mundo gravável corrigiu esse problema idiota e enganou os aplicativos clientes para escrever nele.
• Remova todas as ACLs do sistema de arquivos do compartilhamento. Por meio de muitas experiências aleatórias, descobri que essas ACLs causam problemas com a máscara de modo dos arquivos criados. Eu não sou um mestre da ACL, então talvez haja uma solução mais elegante. Como root na Synology, faça synoacltool -del /volume1/myshare. Você deve ver o +símbolo removido da saída ls -l.
• Altere a propriedade do compartilhamento para seu novo usuário: chown roger.remote:roger.remote /volume1/myshare
• Mude o modo para 755: chmod 755 /volume1/myshare
• Monte o volume no cliente, teste as permissões, ele deve funcionar! Certifique-se de tocar em um arquivo também e verifique se o umask do bash foi aplicado corretamente.

$ umask 
0002
$ cd / mnt / myshare
$ teste de toque
Teste $ ls -l
-rw-rw-r-- 1 roger roger 0 de outubro 21 18:15 teste

Na Synology, você deve ver:

# ls -l / volume1 / myshare / teste
-rw-rw-r-- 1 roger.remote roger.remote 0 de outubro 21 18:15 teste

Desfrutar!