Isso acontece porque o volume está usando a privatepropagação de montagem. Isso significa que quando a montagem acontecer, quaisquer alterações que ocorram no lado de origem (por exemplo, o lado "host" no caso do Docker) não serão visíveis embaixo da montagem.
Existem algumas maneiras de lidar com isso:
Primeiro, monte o NFS e inicie o contêiner. A montagem será propagada para o contêiner, no entanto, como antes, qualquer alteração na montagem não será vista pelo contêiner (incluindo desmontagens).
Use propagação "escrava". Isso significa que, uma vez criada a montagem, quaisquer alterações no lado de origem (host do docker) poderão ser vistas no destino (no contêiner). Se você estiver montando aninhados, convém usar rslave( rpara recursivo).
Também há propagação "compartilhada". Esse modo faria com que as mudanças no ponto de montagem de dentro do contêiner se propagassem para o host, e vice-versa. Como seu usuário nem teria privilégios para fazer essas alterações (a menos que você adicione CAP_SYS_ADMIN), provavelmente não é isso que você deseja.
Você pode definir o modo de propagação ao criar a montagem da seguinte maneira:
$ docker run -v /foo:/bar:private
A outra alternativa seria usar um volume em vez de uma montagem de host. Você pode fazer o seguinte:
$ docker volume create \
--name mynfs \
--opt type=nfs \
--opt device=:<nfs export path> \
--opt o=addr=<nfs host> \
mynfs
$ docker run -it -v mynfs:/foo alpine sh
Isso garantirá sempre a montagem no contêiner para você, não dependerá de ter o host configurado de alguma maneira específica ou de lidar com a propagação da montagem.
nota : :na parte da frente do caminho do dispositivo é necessário, apenas algo estranho no módulo do nfs kernel.
note : No momento, o Docker não resolve a <nfs host>partir de um nome DNS (será em 1.13), portanto, você precisará fornecer o endereço IP aqui.
Mais detalhes sobre montagens de "subárvore compartilhada": https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt