Докер в WSL не будет связывать mount $ HOME

Question

Первоначально я спрашивал об этом при переполнении стека, но я подумал, что Super User может быть более подходящим.

У меня самая странная ситуация с использованием Docker на WSL (Подсистема Windows для Linux, Ubuntu 16.04). Я пытаюсь связать mount /home/username (или просто $HOME для удобства) как том в контейнере, и вместо того, чтобы находить содержимое моего домашнего каталога в контейнере, я полностью получаю другой том.

Что странно, так это то, что этот «другой том» сохраняется из одного контейнера в другой всякий раз, когда я пытаюсь связать mount $HOME или /home/username . Если я коснусь нового файла, он появится во всех других контейнерах, в которые я монтирую $HOME . Все остальные привязки к любому другому каталогу работают корректно.

Например, все они находятся в одной папке:

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

Когда я делаю docker volume ls там нет тома /home/username , так что исключается случайное наличие тома, размещенного в докере с тем же именем.

Что это за загадочный том, который я монтирую, и почему докер неправильно монтирует мой каталог $HOME ?

Answer 1

Где работает демон Docker? Я предполагаю, что он работает где-то на сервере или, если вы используете Docker для Windows (с контейнерами Windows /LCOW), он работает на хосте вне WSL. Вероятно, при подключении монтируется «/home /username» на хосте, а не в среде WSL, где работает клиент Docker. Исходя из вашего комментария о работе /c и /d, кажется, что они возвращаются на диски C:\ и D:\ на хосте, что предполагает использование Docker для Windows

Изнутри WSL похоже, что диски смонтированы внутри WSL, но rootfs живет в виртуальной файловой системе, что объясняет, почему работают /c и /d

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)

Вот некоторая документация, рассказывающая о том, как rootfs Linux в WSL работает https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

Расположение в rootfs Windows WSL, в котором он находится, указано в KCU:\Software\Microsoft\Windows\CurrentVersion\Lxss (см. Https://github.com/Microsoft/WSL/issues/2578).

Вот некоторая дополнительная информация об архитектуре Docker, объясняющая разницу между демоном Docker и клиентом https://docs.docker.com/engine/docker-overview/

Answer 2

У меня была та же проблема, и я согласен с Nijave, что проблема в том, что файловая система, с которой монтируется Docker Host (в моем случае MobyLinuxVM работает в Hyper-V), отличается от файловой системы, управляемой WSL (расположение которой похоронены в вашем пользовательском приложении данные на диске C:) .

Чтобы решить эту проблему, я сначала получил оболочку с доступом к файловой системе, используемой Docker Host

docker run --privileged -it -v /var/run/docker.sock:/var/run/docker.sock jongallant/ubuntu-docker-client
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh
chroot /host

Затем я связал свой домашний каталог WSL (используя путь Windows) с домашним каталогом в файловой системе, которую использует Docker Host:

ln -s /C/Users/WINDOWS_USERNAME/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/LINUX_USERNAME/ /home/

После этого я смог сделать такие вещи, как:

docker run -it --rm -v ~/.ssh:/root/.ssh alpine some-ssh-command

Примечание. В Docker Core содержится сообщение об ошибке: https://github.com/docker/for-win/issues/2151.

ВНИМАНИЕ: вы, вероятно, должны делать это только для доступа только для чтения к вашему каталогу $ HOME. В вышеупомянутой ошибке мне сообщили, что этот метод все еще обращается к файловой системе Windows через Samba, и поэтому при создании / редактировании файлов вы можете столкнуться с проблемами здесь: https://blogs.msdn.microsoft.com/commandline/2016 / 11/17 / делать-не-изменение-Linux-файлы, используя-окна-приложения-и-инструменты /

Answer 3

Нет хорошего способа сделать это, так как демон docker в MobyLinuxVM не знает WSL, и наоборот.

Если вы попытаетесь смонтировать папку AppData, содержащую файлы WSL как том, вы столкнетесь с проблемами, поскольку пишете файлы без создания соответствующих метаданных файловой системы linux:

https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

Вероятно, лучше всего создать папку в другом месте на диске C:, к которой вы можете получить доступ из WSL в /mnt/c , и которую можно смонтировать из докера с помощью -v "C:\foldername":/test . Для удобства вы можете связать mount /mnt/c с /c в WSL, чтобы вы могли написать команду docker, используя -v /c/foldername:/test .

sudo mkdir /c sudo mount --bind /mnt/c /c

Смотрите https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

Если вам действительно нужно смонтировать $ HOME как том докера, вы можете попробовать настроить домашнюю папку WSL как папку на C: например, C:\home , как описано здесь:

https://brianketelsen.com/going-overboard-with-wsl-metadata/

Затем вы можете смонтировать C:\home как том докера. Однако вы можете столкнуться с проблемами при работе в WSL, поскольку ваша домашняя папка теперь будет монтироваться как файловая система drvfs вместо lxfs .