WSL上のDockerはマウント$ HOMEをバインドしません

私はもともとStack Overflowでこれを尋ねましたが、スーパーユーザーの方が適切だと思いました。

WSL（Linux用のWindowsサブシステム、Ubuntu 16.04）でDockerを使用している最も奇妙な状況があります。私はマウントをコンテナ内のボリュームとして/home/username（または単に$HOME便宜上）バインドしようとしていますが、コンテナ内のホームディレクトリのコンテンツを見つける代わりに、他のボリュームを完全に取得します。

奇妙なのは、mount $HOMEまたはをバインドしようとするたびに、この「他のボリューム」が1つのコンテナーから別のコンテナーに保持されること/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、という名前のボリュームがないので、同じ名前のdocker-hostedボリュームが誤って存在することはありません。

私がマウントしているこの不思議なボリュームとは何$HOMEですか？また、ドッカーがディレクトリを正しくマウントしないのはなぜですか？

Dockerデーモンはどこで実行されていますか？どこかのサーバーで実行されているか、Docker for Windows（Windowsコンテナー/ LCOWを使用）を使用している場合、WSLの外部のホストで実行されていると思います。バインドマウントは、Dockerクライアントが実行されているWSL環境内ではなく、ホスト上で「/ home / username」を探している可能性があります。/ cおよび/ dの動作に関するコメントに基づいて、これらはホスト上のC：\およびD：\ドライブにマップされているように聞こえます。これは、Docker for 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)

WSLのLinux rootfsがどのように機能するかについて説明しているドキュメントを次に示しますhttps://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

Windows WSL rootfs内の場所は、KCU：\ Software \ Microsoft \ Windows \ CurrentVersion \ Lxssにリストされています（https://github.com/Microsoft/WSL/issues/2578を参照）

Dockerデーモンとクライアントhttps://docs.docker.com/engine/docker-overview/の違いを説明するDockerアーキテクチャに関する追加情報を次に示します。

MobyLinuxVM内のdockerデーモンにはWSLの知識がなく、その逆も同様であるため、これを行う良い方法はありません。

WSLファイルを含むAppDataフォルダーをボリュームとしてマウントしようとすると、適切なLinuxファイルシステムメタデータを作成せずにファイルを作成しているため、問題が発生します。

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

おそらく、C：ドライブの別の場所にフォルダーを作成することをお勧めします。このフォルダーには、WSLからアクセスでき、を/mnt/c使用してdockerからマウントできます-v "C:\foldername":/test。便宜上、WSL内でマウント/mnt/cをバインドして、を/c使用して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、Dockerボリュームとしてマウントできます。ただし、ホームフォルダーはのdrvfs代わりにファイルシステムとしてマウントされるため、WSL内での作業で問題が発生する可能性がありlxfsます。

私は同じ問題を抱えていましたが、Dockerホストがマウントするファイルシステム（私の場合はHyper-Vで実行されているMobyLinuxVM）がWSLによって管理されているファイルシステム（その場所はC：ドライブのユーザーアプリデータに埋もれています）。

これを解決するために、最初にDockerホストが使用するファイルシステムにアクセスできるシェルを取得しました

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

次に、WSKホームディレクトリを（Windowsパスを使用して）Dockerホストが使用するファイルシステム上のホームディレクトリにリンクしました。

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ディレクトリへの読み取り専用アクセスに対してのみ行うべきです。前述のバグでは、この方法は引き続きSambaを介してWindowsファイルシステムにアクセスするため、ファイルを作成/編集すると、https：//blogs.msdn.microsoft.com/commandline/2016で問題が発生する可能性があることが通知されました。 / 11/17 / do-not-change-linux-files-using-windows-apps-and-tools /