nfs monta um compartilhamento rex nexenta para todos os usuários no cliente linux - falhando

Question

Situação:

Estamos usando um dispositivo Nexenta para serviço de arquivos NFS (nfs v3). Estamos compartilhando um caminho para acesso anônimo de leitura / gravação.

Temos um host Linux que gostaríamos de montar esse compartilhamento de leitura / gravação exportado e também permitir acesso anônimo de leitura / gravação para esse compartilhamento montado nessa máquina cliente. Infelizmente, o que acaba acontecendo é que o root pode gravar no compartilhamento, mas usuários não privilegiados não podem.

Usando os seguintes métodos para montar o compartilhamento:

# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw

Temos um usuário específico que pretendemos usar para o uso anônimo no compartilhamento. Então, tentei montar o volume como esse usuário:

# su - shared_user
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw
mount.nfs: an incorrect mount option was specified

Foi e fez algumas leituras: link .

Decidiu fazer o seguinte uma tentativa que fornece os erros ao tentar montar:

# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path 
mount.nfs: an incorrect mount option was specified
# mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path  # for grins and giggles.
mount.nfs: an incorrect mount option was specified
$ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash
mount.nfs: an incorrect mount option was specified

Eu sou apenas SOL ou há algo que eu esteja sentindo falta aqui? Isso é um santo graal que estou tentando encontrar? Eu nunca usei muito o NFS, então estou com uma perda aqui, agora. TIA!

    

Answer 1

OK. Descobri isso. Primeiro, a versão do Nexenta que estou usando é 3.1.3.5. O Nexenta é um dispositivo baseado no OpenSolaris que vende armazenamento em block via CIFS, NFS, Rsync, WebDAV e FTP. No nosso caso, estamos usando apenas para o NFS (v3 é o padrão. A v4 não está disponível para esta versão).

Então, tl; dr; no lado Nexenta:

Faça o login no Nexenta como root:

$ ssh [email protected]
Password:
Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx
nmc@nex01:/$ option expert_mode = 1

nmc@nex01:/$ !bash
You are about to enter the Unix ("raw") shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute?  Yes

root@nex01:/volumes#
root@nex01:/volumes# grep nfs /etc/passwd
nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh

Observe os números após o primeiro x:#####:##### - estes são o uid e o gid respectivamente.

no lado do cliente: crie usuário:

# groupadd nfs -g 60001 && useradd nfs -g 60001  ## untested. I did it the long way through natural process of elimination, so be careful here.

Tudo bem agora.

Monte o volume e verifique se o usuário nfs recém-criado pode gravar no volume NFS.

Versão longa:

Eu tive o lado do NFS configurado corretamente, até onde eu sei. A documentação foi útil, mas de certa forma foi apenas dividir breadcrumbs.

"Permitir acesso anônimo a esse compartilhamento. O diretório de nível superior compartilhado receberá acesso de leitura / gravação para o usuário anônimo 'nfs'. Se o modo de compartilhamento recursivo for definido como true, essa propriedade será propagada para subpastas existentes. que o acesso anônimo de leitura / gravação não é herdável - o acesso anônimo a sub-pastas futuras não será permitido até que seja explicitamente solicitado. O nome de usuário anônimo é 'nfs'. "

Meu shared_user acabou se tornando "nfs", que ainda estava com falha (veja OP). Eu decidi, porque eu pensei que era um tiro longo, fazer o meu UID no lado do cliente coincidir com o do UID para 'nfs' no aparelho. Eu tive que fazer o login no dispositivo, iniciar um shell bash e, em seguida, executar o comando id para obter o UID, que no meu caso foi 60001.

No cliente, alterei o usuário nfs para corresponder ao UID no dispositivo. Aparentemente, o appliance exige que o UID / GID corresponda ao seu para que isso funcione. Eu imaginei que o servidor NFS ignoraria isso. Este foi o aparentemente o cerne da questão.

Agora, o appliance usa nfs: nobody para user: group. nobody no lado do cliente (Linux) é um UID diferente, e mudar o UID para ninguém seria um pouco mais complicado e eu não sei o que eu poderia inadvertidamente afetar mudando esse groupid, então eu não toquei isto. O usuário nfs na máquina do cliente era inexistente antes de começar a mexer, então não havia risco de quebrar nada. Existe um nfsnobody no lado do cliente. Eu não testei usando e tenho certeza que não teria funcionado, já que a documentação é específica sobre o ID do usuário.

Também devo declarar aqui que o appliance foi definido especificamente para usar o sysauth para autenticação. Usar auth = none não era uma opção, pois o NFSv3 não parece gostar disso. :)

é tudo.