mv falha, mas o cp é bem-sucedido no nfs mount

Question

Estou tentando mover um arquivo de um diretório local para um diretório nfs montado em um servidor CentOS 7. A exportação é fornecida pelo FreeNAS.

Ambos os diretórios são de propriedade do usuário atual com pelo menos 755 (nfs mostra como 777, mas não tenho certeza se acredito nisso).

Meu fstab se parece com isso

host:/path/to/export /mnt/nfs         nfs     defaults        0 0

Não consigo mover o arquivo

mv /local/file /mnt/nfs/file
mv: cannot create regular file 'file': Operation not permitted

No entanto, posso copiá-lo e removê-lo

cp /local/file /mnt/nfs/file
rm /local/file

Saída de mount

host:/path/to/export on /mnt/nfs type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=host,mountvers=3,mountport=908,mountproto=udp,local_lock=none,addr=host)

Permissões de diretório no cliente

ls -ld /local /mnt/nfs
drwxrwxrwx. 15 user user 17 Nov 28 08:32 /mnt/nfs/
drwxrwxrwx. 2  root root 17 Nov 29 12:20 /local

Após uma investigação mais aprofundada, isso parece estar relacionado à alteração de permissões. mv usa as permissões do arquivo, mas cp cria um novo arquivo que herda as permissões do diretório pai. Parece que a montagem nfs não permite que eu chown arquivos, mesmo se eu sou root ou o proprietário dos arquivos. Então, agora, minha pergunta é como permitir a alteração de permissões ou ignorar as permissões dadas no mv .

    

Answer 1

• Seus bancos de dados de senha / grupo estão sincronizados entre o cliente e servidor?
  

• Você vê algum arquivo no diretório nfs montado no cliente nfs como pertencente por

  nobody nobody

• Você pode enviar a saída de nfsidmap -d do servidor e do cliente? Sugestão - quando utilizar saídas NFSV4 deve corresponder.

O mais provável é que você esteja encontrando uma discrepância entre o UID / GID no servidor NFS e no cliente NFS. Vou mostrar como isso funciona com base em um exemplo simples.

Digamos que você esteja compartilhando em seu cliente NFS / nfs_share dessa forma. Observe que nfs_share é gravável por qualquer pessoa (777).

[root@nfsserver nfs_share]# cat /etc/exports
/nfs_share      192.168.0.52(rw,no_root_squash) 

[root@nfsserver nfs_share]# ls -ld /nfs_share
drwxrwxrwx. 2 root root 4096 Nov 30 23:55 /nfs_share

E montagem no seu cliente NFS assim

mount 192.168.0.51:/nfs_share /mnt

Agora você tem um usuário do servidor nfs chamado dmitry

[root@nfsserver nfs_share]# getent passwd|grep dmitry
dmitry:x:500:500::/home/dmitry:/bin/bash
[root@nfsserver nfs_share]# getent group|grep dmitry
dmitry:x:500:

E no seu cliente nfs você tem usuário helen

[root@nfsclient ~]# getent passwd|grep helen
helen:x:500:500::/home/helen:/bin/bash
[root@nfsclient ~]# getent group|grep helen
helen:x:500:

Observe que, apesar de serem usuários diferentes, eles têm o mesmo UID e GID. Então, o que acontece se eu tocar como o arquivo helen do usuário no compartilhamento nfs?

[helen@nfsclient mnt]$ touch helen_client
[helen@nfsclient mnt]$ ls -lrt
[helen@nfsclient mnt]$ ls -lrt
total 0
-rw-rw-r--. 1 nobody nobody 0 Nov 30 23:58 helen_client

No cliente NFS, esse novo arquivo será exibido como de propriedade de nobody nobody . Isso ocorre porque o nfsidmap não pode mapear client_user_name @ domain para server_user_name @domain. E agora momento de trégua. Vamos verificar qual é o dono do arquivo no servidor nfs.

[root@nfsserver nfs_share]# ls -rlt
total 0
-rw-rw-r--. 1 dmitry dmitry 0 Nov 30 23:58 helen_client

Surpreso ainda?
No entanto, não há nada de estranho na verdade. Isso funciona como esperado.
O servidor NFS não pode mapear o usuário helen, mas o que recebeu é UID e GID. Por isso, criou o arquivo (uma vez que a pasta é gravável pelo mundo) com o UID 500 e o GID 500, que é mapeado para dmitry: dmitry no servidor NFS.

Agora, digamos que temos outro usuário que tenha UID / GID e os nomes correspondem entre o servidor e o cliente

[root@nfsserver mnt]# getent passwd|grep angelina
angelina:x:501:501::/home/angelina:/bin/bash
[root@nfsserver mnt]# getent group|grep angelina
angelina:x:501:

[angelina@nfsclient mnt]$ getent passwd|grep angelina
angelina:x:501:501::/home/angelina:/bin/bash
[angelina@nfsclient mnt]$ getent group|grep angelina
angelina:x:501:

E se eu tocar em arquivo no cliente nfs como usuário angelina - verei o nome de usuário / grupo correto no servidor e no cliente

[angelina@nfsclient mnt]$ pwd
/mnt
[angelina@nfsclient mnt]$ touch angelina_1
[angelina@nfsclient mnt]$ ls -l
total 0
-rw-rw-r--. 1 angelina angelina 0 Dec  1  2016 angelina_1
-rw-rw-r--. 1 nobody   nobody   0 Dec  1 00:16 helen_1

[root@nfsserver nfs_share]# pwd
/nfs_share
[root@nfsserver nfs_share]# ls -l
total 0
-rw-rw-r--. 1 angelina angelina 0 Dec  1 00:27 angelina_1
-rw-rw-r--. 1 dmitry   dmitry   0 Dec  1 00:16 helen_1

A linha de fundo é que o NFSV4 funcione corretamente, você precisa ter

• Servidor e senha do cliente / banco de dados do grupo em sincronia. De preferência use ldap.
• cliente e servidor devem concordar com o nome de domínio comum nfsidmap -d