Isso acontece porque o volume está usando a private
propagaçã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
( r
para 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