为什么 Windows 文件系统使用 noexec 和 nodev 选项挂载在 WSL 上？

Question

我问这个问题是因为我很好奇并且想更好地了解 WSL。

我的环境是 Windows 11，使用运行 Ubuntu 的 WSL 2。我正在学习容器基础知识，并且在运行debootstrap时遇到了一个有趣的错误。

当我在已安装的 Windows 文件系统 ( ) 中运行它时/mnt/c/：

user@laptop:/mnt/c/Users/user/workshop$ sudo debootstrap --arch amd64 jammy container_fs http://archive.ubuntu.com/ubuntu

我收到以下错误：

mknod: /mnt/c/Users/user/workshop/container_fs/test-dev-null: Operation not supported
E: Cannot install into target '/mnt/c/Users/user/workshop/container_fs' mounted with noexec or nodev

我尝试/mnt/c/Users/user/workshop/container_fs使用exec和dev选项重新安装。

user@laptop:/mnt/c/Users/user/workshop$ sudo mount -o remount,exec,dev /mnt/c/Users/user/workshop/container_fs

输出：

mount: /mnt/c/Users/user/workshop/container_fs: mount point not mounted or bad option.

正是在这一点上，我尝试运行 debootstrap /home/user/，它工作正常，没有任何问题。

Answer 1

为什么 Windows 文件系统使用 noexec 和 nodev 选项挂载在 WSL 上？

您收到的错误消息有点误导。它实际上没有使用这些选项中的任何一个来安装，您可以通过以下方式确认：

mount | grep '/mnt/c'

drvfs on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)

我尝试/mnt/c/Users/user/workshop/container_fs使用exec和dev选项重新安装。

...

mount: /mnt/c/Users/user/workshop/container_fs: mount point not mounted or bad option.

该错误是因为/mnt/c/Users/user/workshop/container_fs不是安装点。挂载点是/mnt/c. 以下将成功完成：

sudo mount -o remount,exec,dev /mnt/c

但是，它并不能解决你的问题。

请记住，错误显示为noexec 或 nodev。

因此，让我们将其分为两部分：

noexec

如上所述，文件系统实际上是使用特权挂载的exec，您可以从该驱动器运行可执行文件。这就是为什么您可以从 Windows 驱动器运行 Windows 可执行文件，例如notepad.exe、powershell.exe、 和。code您可以使用以下方法测试反例：

sudo mount -o remount,noexec,dev /mnt/c/
notepad.exe

您将收到 ，Permission denied直到您使用 重新安装exec。

nodev

为此，重要的是查看错误的第一部分debootstrap：

mknod: /mnt/c/Users/user/workshop/container_fs/test-dev-null: Operation not supported

这可能是因为 WSL2 下的 Windows 文件系统及其共享不完全兼容 POSIX。

WSL2 通过 Plan 9 (9P) 网络文件系统提供对 Windows 驱动器的访问。据我所知，9P不支持mknod. 根据我发现的这个评论，即使是Linux版本的9P也不支持（或者至少3-4年前不支持）mknod。

然而，用于 WSL2 发行版本身的虚拟 SDD 上的 ext4 文件系统完全兼容 POSIX，这就是其debootstrap工作的原因。