WSL2终端运行正常但Windows端无法访问其挂载文件如何解决

• WSL2跨系统文件互访依赖的9P协议服务异常。此前WSL进程异常退出、Jupyter内核崩溃时，9P服务的会话状态或缓存出现损坏，即使重启WSL或主机，损坏的状态没有被正常清理，导致Windows侧访问WSL文件系统时请求无响应，陷入无限加载。
• WSL2的ext4虚拟磁盘元数据损坏。如果异常退出时刚好有大量IO操作正在执行，可能导致虚拟磁盘的元数据出现错误，9P服务读取异常元数据时陷入死锁，无法响应Windows侧的访问请求。
• Windows侧WSL客户端组件状态异常。Windows端负责对接WSL文件服务的客户端残留了异常的旧会话连接，新启动的WSL实例无法覆盖旧状态，导致所有访问请求都被路由到已经失效的会话上，无返回结果。

• WSL内部9P服务相关日志：在Ubuntu终端执行 dmesg | grep 9p 可查看内核层面的9P服务运行错误、IO异常记录；执行 journalctl -xe | grep -E '9p|filesystem' 可查看系统服务层面的相关报错。
• Windows侧WSL事件日志：打开Windows事件查看器，依次展开「应用程序和服务日志 > Microsoft > Windows > WSL」，查看故障发生时间点前后的警告、错误事件，重点筛选带9p、Plan9、filesystem关键字的条目。
• 故障关联的Jupyter日志：可到WSL中~/.jupyter/logs/目录下，查找异常退出时间对应的日志文件，确认内核崩溃是否和磁盘IO过载、资源耗尽有关。
• 虚拟磁盘完整性验证：先在Powershell执行 wsl --shutdown 关闭所有WSL实例，再执行 wsl --mount <你的WSL虚拟磁盘vhdx文件路径> --bare 裸挂载磁盘，之后进入WSL执行 sudo fsck /dev/sdb 检测虚拟磁盘是否存在元数据错误。
• 临时绕过方案：可先在WSL中将需要访问的文件复制到Windows挂载路径（如/mnt/c/Users/你的用户名/Desktop/），既可验证文件本身是否损坏，也能暂时绕过9P服务故障正常使用文件。

内容的提问来源于stack exchange，提问作者Whitehot