O Docker no WSL não ligará o mount $ HOME

1

Eu perguntei isso originalmente no Stack Overflow, mas achei que o Super User poderia ser mais apropriado.

Eu tenho a situação mais estranha usando o Docker no WSL (Windows Subsystem para Linux, Ubuntu 16.04). Eu estou tentando vincular a montagem /home/username (ou apenas $HOME para conveniência) como um volume em um contêiner e, em vez de encontrar o conteúdo do meu diretório inicial no contêiner, recebo algum outro volume completamente.

O que é mais estranho é que esse "outro volume" persiste de um contêiner para o outro sempre que eu tento vincular a montagem $HOME ou /home/username . Se eu tocar em um novo arquivo, ele aparecerá em todos os outros recipientes em que eu montar $HOME . Todas as outras montagens de ligação para qualquer outro diretório funcionam corretamente.

Por exemplo todos compartilham a mesma pasta de mistério:

docker run -it --rm -v /home/username:/test alpine sh
docker run -it --rm -v $HOME:/test alpine sh
docker run -it --rm -v $HOME:/test -v $HOME:/test2 alpine sh

Quando eu faço um docker volume ls , não há volume chamado /home/username , então isso exclui acidentalmente ter um volume hospedado pelo docker com o mesmo nome.

Qual é esse volume misterioso que estou montando e por que o docker não está montando meu diretório $HOME corretamente?

    
por Martaver 30.07.2018 / 09:52

1 resposta

0

Onde o daemon do Docker está rodando? Eu estou supondo que ele está sendo executado em um servidor em algum lugar ou se você estiver usando o Docker para Windows (com contêineres do Windows / LCOW), ele está sendo executado no host fora do WSL. A montagem de ligação provavelmente está procurando "/ home / username" no host em vez de dentro do ambiente WSL em que o cliente Docker está sendo executado. Com base no seu comentário sobre o / c e / d funcionando, parece que eles estão sendo mapeados de volta para as unidades C: \ e D: \ no host, o que sugere que você está usando o Docker para Windows

De dentro do WSL, parece que os drives são montados dentro do WSL, mas o rootfs reside em um sistema de arquivos virtual, o que explicaria porque o / c e / d estão funcionando

nick@nick-desktop:/mnt$ mount
rootfs on / type lxfs (rw,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noatime)
C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000)
W: on /mnt/w type drvfs (rw,noatime,uid=1000,gid=1000)
X: on /mnt/x type drvfs (rw,noatime,uid=1000,gid=1000)
Z: on /mnt/z type drvfs (rw,noatime,uid=1000,gid=1000)

Aqui está uma documentação que fala sobre como o rootfs do Linux no WSL funciona link

O local em que os rootfs do WSL do Windows residem está listado em KCU: \ Software \ Microsoft \ Windows \ CurrentVersion \ Lxss (consulte link )

Veja algumas informações adicionais sobre a arquitetura do Docker explicando a diferença entre o daemon do Docker e o link

do cliente >     
por 12.09.2018 / 02:30