Como corrigir ”mount.nfs: acesso negado…“ ao tentar montar um compartilhamento NFS exportado por uma máquina Proxmox 5?

Question

Estou tentando montar um compartilhamento NFS a partir de um host Proxmox 5 e tendo problemas. Eu tenho as duas máquinas a seguir:

192.168.1.3    proxmox debian box (nfs-host)
192.168.1.31   ubuntu 16.04 (nfs-client)

Permissões de /mnt/storage (cliente NFS):

drwxrwxrwx 11 nobody nogroup 4096 Oct  7 10:28 storage

Conteúdo de /etc/exports (host NFS):

/mnt/storage 192.168.1.31(rw,sync,no_subtree_check)

Saída de showmount -e 192.168.1.3 (cliente NFS):

Export list for 192.168.1.3:
/mnt/storage 192.168.1.31

A tentativa de montar do cliente falha:

me@client:/mnt/storage$ sudo mount 192.168.1.3:/mnt/storage /mnt/storage
mount.nfs: access denied by server while mounting 192.168.1.3:/mnt/storage

Eu corri exportfs -ra e reiniciei o servidor do kernel nfs, mas ainda não tive alegria. Eu também tentei todas as sugestões na pergunta mount.nfs: acesso negado pelo servidor durante a montagem em máquinas Ubuntu? , mas nada funcionou para mim. Havia apenas uma ou duas respostas na parte inferior que tinham a ver com o docker e outra que tinha IPs com erros de digitação, ambos não pertenciam a mim.

Eu posso fazer ping de ambos os hosts e ambos os hosts podem acessar a Internet e ver uns aos outros, então não acho que seja um problema de rede.

Agora estou vendo esses erros dentro de /var/log/messages no host:

Oct  7 10:06:36 pve kernel: [44667.325940] audit: type=1400 audit(1507385196.790:23): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-cgns" name="/mnt/storage/" pid=15053 comm="mount.nfs4" fstype="nfs4" srcname="192.168.1.3:/export/storage"
Oct  7 10:07:05 pve kernel: [44696.096558] audit: type=1400 audit(1507385225.559:24): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-cgns" name="/mnt/storage/" pid=15112 comm="mount.nfs" fstype="nfs" srcname="192.168.1.3:/export/storage"

Conforme solicitado, aqui está o conteúdo de todos os arquivos dentro de /etc/apparmor.d/lxc/ contendo a palavra mount :

root@host:/etc/apparmor.d/lxc# ll
total 24
drwxr-xr-x 2 root root 4096 Oct  6 13:24 .
drwxr-xr-x 9 root root 4096 Oct  6 13:24 ..
-rw-r--r-- 1 root root  479 Jun 30 05:01 lxc-default
-rw-r--r-- 1 root root  528 Jun 30 05:01 lxc-default-cgns
-rw-r--r-- 1 root root  544 Jun 30 05:01 lxc-default-with-mounting
-rw-r--r-- 1 root root  527 Jun 30 05:01 lxc-default-with-nesting

root@host:/etc/apparmor.d/lxc# cat lxc-default
# Do not load this file.  Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>

  # the container may never be allowed to mount devpts.  If it does, it
  # will remount the host's devpts.  We could allow it to do it with
  # the newinstance option (but, right now, we don't).
  deny mount fstype=devpts,
}



root@host:/etc/apparmor.d/lxc# cat lxc-default-cgns
# Do not load this file.  Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default-cgns flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>

  # the container may never be allowed to mount devpts.  If it does, it
  # will remount the host's devpts.  We could allow it to do it with
  # the newinstance option (but, right now, we don't).
  deny mount fstype=devpts,
  mount fstype=cgroup -> /sys/fs/cgroup/**,
}



root@host:/etc/apparmor.d/lxc# cat lxc-default-with-mounting
# Do not load this file.  Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default-with-mounting flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>

# allow standard blockdevtypes.
# The concern here is in-kernel superblock parsers bringing down the
# host with bad data.  However, we continue to disallow proc, sys, securityfs,
# etc to nonstandard locations.
  mount fstype=ext*,
  mount fstype=xfs,
  mount fstype=btrfs,
}



root@host:/etc/apparmor.d/lxc# cat lxc-default-with-nesting
# Do not load this file.  Rather, load /etc/apparmor.d/lxc-containers, which
# will source all profiles under /etc/apparmor.d/lxc

profile lxc-container-default-with-nesting flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/lxc/container-base>
  #include <abstractions/lxc/start-container>

  deny /dev/.lxc/proc/** rw,
  deny /dev/.lxc/sys/** rw,
  mount fstype=proc -> /var/cache/lxc/**,
  mount fstype=sysfs -> /var/cache/lxc/**,
  mount options=(rw,bind),
  mount fstype=cgroup -> /sys/fs/cgroup/**,
}

    

Answer 1

Eu fiz as seguintes alterações na configuração para /etc/apparmor.d/lxc-default-cgns no host proxmox e consegui montar a unidade com sucesso.

/etc/apparmor.d/lxc-default-cgns

  mount fstype=nfs*,
  mount options=(rw, bind, ro),

    

Answer 2

Parece que o AppArmour está entrando em ação no servidor. Veja as mensagens do arquivo de log, que incluem esta frase:

apparmor="DENIED"

Infelizmente, só posso aconselhá-lo a desativá-lo, o que eu não recomendaria. Vou ver se consigo encontrar algumas instruções para mediar isso ...