如何从Windows 10 WSL访问linux / Ubuntu文件?


71

这个问题回答了如何从Ubuntu Bash访问Windows文件,但是我该如何做呢?

具体来说,我需要从/home/mark/.ssh/id_rsaBash下的Windows访问我的SSH密钥。



(我建议按相反的时间顺序将phuclv的链接问题关闭为dupe,因为该问题不仅更通用,而且具有更好的答案和最新的答案。)
Bob

Answers:


26

适用于Windows命令行的PM:

2019年10月更新:更新以下响应以反映通过Win10 1903(及更高版本)中新集成的P9服务器直接访问发行版Linux文件的新增功能

重要信息:已经并且将继续不支持通过Windows文件系统访问Linux文件,强烈反对!要了解原因,请阅读这篇文章

那么如何使用Windows工具(例如记事本,VS / VScode等)访问Linux文件?以前,您不能,但是从Windows 10 1903开始,我们(最终!)通过P9文件服务器将发行版的文件系统公开到Windows。我们还发布了深入的视频,讨论其工作原理!您也可以在此博客文章中阅读此新功能的摘要。

在此处输入图片说明

期待听到您如何使用此功能。如果发现任何问题,请在以下位置的WSL GitHub存储库上提交问题:https : //github.com/Microsoft/wsl


先生,对于普通用户,此9P文件服务器功能是否稳定?如果不是这样,最好添加有关使用不稳定的内部人员构建的警告。许多用户可能不熟悉它。一个有趣的事实是,您的答案包含2016年和2019年的博客,〜3年;)
Biswapriyo

哦,那真是令人兴奋的消息!感谢你的分享!
mpen

@ biswaprio.it在手动步骤中非常清楚,您必须完成一些步骤才能加入Insider程序,这些发行版实际上是正在构建的下一版本Windows的每周发布。是的,9P服务器将在其内部提供的主流OS版本中对一般用户稳定。是的,在这里我们花了很长时间建立并开始提供一个体面的解决方案这一事实应该使您对我们的小型团队确定优先级和进行工程设计有多难的想法有所了解。
理查德·特纳

1
自从我第一次听说该命令发布以来,我一直在Ubuntu的每次系统更新中试用该命令。我的资源管理器始终转到我的“文档”文件夹。而且我还没有找到“启用”此功能的任何步骤
Axeman

3
与Axeman类似的情况,在运行时explorer.exe .会打开System32文件夹。@RichardTurner手动步骤在哪里?
克里斯

57

该位置实际上已在最新版本中移至:

C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\

请参阅Microsoft / WSL#2578中的 GitHub问题

正如上面的问题和下面的注释中所提到的,请不要与Windows操作系统中的这些文件混淆。

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


1
谢谢!以为我会按照旧的说明发疯,我什至没有lxss文件夹。
Alex S

1
这些信息仍然正确吗?我找不到在我的Windows 10这样的文件夹
布鲁诺指

6
我们强烈建议您不要从WINDOWS进入发行版根文件夹。如果这样做,数据丢失和/或腐败是极有可能:请阅读这篇文章了解详情:blogs.msdn.microsoft.com/commandline/2016/11/17/...
理查德·特纳

1
“我怀疑有人会试图以这种方式操作或更改文件”。您为什么认为我大喊上述建议?我们每周从人们那里听到很多很酷的消息,他们忽略或没有阅读此建议,最终破坏了其根文件夹中的文件。哎呀,有些工具也可以替换导致您的Beta变形文件。
理查德·特纳

1
我浏览到了我在Explorer中通过Ubuntu WSL创建的文件夹,结果该文件夹不可逆地破坏了权限...所以是的,我不建议这样做!
SamAndrew81

9

通过搜索我的整个C盘找到了它。文件在这里:

C:\Users\<username>\AppData\Local\lxss

例如,我的SSH密钥在这里:

C:\Users\Mark\AppData\Local\lxss\home\mark\.ssh\id_rsa

2
自官方FCU更新以来,路径似乎已改变。
Briefkasten

1
@Briefkasten我刚刚更新到FCU,但我的文件仍然在那里。只是为了确保在Bash下创建了一个新文件。您升级了WSL还是什么?
mpen

2
@John D WSL位于将安装应用程序的程序包文件夹中。对我来说是:C:/用户/ {用户名} /AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/续。到github.com/Microsoft/WSL/issues/402#issuecomment-321853125
Briefkasten

9

是的,但是不建议从Windows资源管理器中操作该文件夹。如果要复制,移动,编辑或擦除lxss文件夹中的文件,则需要使用命令行工具在ba​​sh内进行操作。只有/ mnt / *上的文件才能从Windows资源管理器中真正操作。


1
甚至是简单的文本文件?有什么陷阱?
mpen

3
驻留在Volfs文件夹(例如/ home)上的每个文件都有扩展属性,用于存储该文件的Linux权限。如果您在Windows编辑器上编辑该文件,则这些属性将丢失,文件将从bash中消失。您可以在此处了解更多信息:blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support
onoma

4
听起来应该是个错误。Windows要么不应该授予我们访问这些文件的权限,要么不授予我们只读访问权限,否则它们应该拦截对linux文件的写调用,而只是不修改属性。谢谢你的提示。我只想读取文件,所以希望这不是问题。
mpen

5

在中powershell,使用

cd ${env:appdata}\..\local\packages\canonical*\localstate\rootfs

然后

ls

返回与文件夹相同的文件夹列表

ls / 

在WSL上重击。


4

正如上面提到的,WSL目录中的[onoma]文件具有一些属性,如果使用Windows系统下运行的资源管理器或文本编辑器对其进行操作,这些属性将消失。解决方案可能是在WSL中启动ssh-server(可能需要重新安装),在localhost上侦听,然后使用例如win-sshfs将WSL文件系统安装为驱动器,或者您可以仅使用Bitvise SSH客户端通过ssh连接并通过sftp窗口操作文件。该主题已在此处进行部分讨论:如何通过SSH进入“ Windows 10上的Ubuntu上的Bash”?


3

subst L: $env:LOCALAPPDATA\lxss (用于powershell)

subst L: %LocalAppData%\lxss(来自cmd

这会将Linux子系统文件系统根/放在L:驱动器上。

您也可以仅映射主目录,也可以仅%LocalAppData%\lxss在资源管理器窗口中映射。只是不要尝试浏览L:\ mnt \ c,否则您的大脑可能会爆炸。


3
不错的解决方案!对于当前的Windows 10,它的值是L:$ env:LOCALAPPDATA \ Packages \ CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc \ LocalState \ rootfs
Andreas M. Oberheim

3

我终于找到了一种从WSL内部使用实际正确的文件夹上下文打开资源管理器(和vscode)的方法:https : //github.com/andymule/wslwin

例如,在安装此文件后,只需在linux(WSL)中cd /home/mark/.ssh/键入explorer,然后它将在该位置打开Windows资源管理器,无论它是什么。

编辑:WSL现在正式支持此功能,您不再应该使用我的脚本


2

我在Windows 10 Creators Update上。我使用SFTP NetDrive将WSL文件系统作为网络驱动器安装到Windows中。

有一些Window sshFS端口可以实现相同的目的。

您需要通过“ sudo service ssh start”启动ssh守护进程。


与直接转到文件相比,这样做有什么好处?
mpen

这些文件具有附加的元数据,当使用不了解元数据的应用程序直接访问元数据时,元数据可能会丢失。
mlk

0
\\wsl$\Ubuntu\home\user\whatever 

在资源管理器或“运行”窗口小部件(Cmd + R)中。就像普通的网络共享一样工作,可以安全地操作文件。

您还可以将其映射到驱动器或文件夹,就像其他任何网络共享一样。

注意:这是Windows 10内部版本18342中实现的新功能

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.