WSL2中Windows文件系统默认挂载noexec、nodev选项的原因及debootstrap执行失败相关疑问

嗨，我来帮你把这个问题捋清楚～

首先，咱们先说说为什么WSL2里的Windows文件系统（就是/mnt/c这类路径）默认会挂载noexec和nodev选项：

• Windows的NTFS文件系统和Linux的文件系统底层逻辑差得挺多的，NTFS根本没法原生支持Linux的设备文件（就是/dev目录下那些特殊文件），所以WSL2默认加上nodev选项，禁止在NTFS上创建或访问设备节点——这也是你运行debootstrap时遇到mknod失败的直接原因，因为debootstrap需要创建测试用的/dev/null节点，而NTFS不支持这个操作。
• 至于noexec，是因为Windows和Linux的可执行文件权限规则不一样，直接在NTFS上运行Linux可执行文件容易出现权限混乱或者安全问题，所以WSL2默认禁用了在NTFS分区上执行程序的权限。

然后说说你尝试remount子目录为啥失败：
mount -o remount这个命令只能针对整个已挂载的文件系统操作，而/mnt/c/Users/user/workshop/container_fs只是/mnt/c这个挂载点下的一个子目录，并不是独立的挂载点，所以系统会提示你“mount point not mounted or bad option”，这很正常。

最后说说解决方案：

• 你已经找到的最佳方案：把debootstrap的操作放在WSL自己的文件系统里（比如/home/user/），因为这是原生的Linux文件系统，完全支持Linux所需的设备节点、可执行权限等特性，所以debootstrap能顺利运行。
• 如果一定要在Windows目录下临时测试，你可以尝试重新挂载整个/mnt/c分区，加上exec和dev选项：

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

  不过要注意，这么做可能会带来一些兼容性问题，比如某些Windows文件可能被错误识别为可执行文件，或者设备相关操作出现异常，所以不推荐长期这么用。

简单总结一下：debootstrap这类工具依赖Linux文件系统的核心特性，而Windows挂载目录因为系统差异默认不支持这些特性，所以放在WSL原生目录是最稳妥的选择。

备注：内容来源于stack exchange，提问作者ishuah