Файлы wsl ubuntu в windows

Windows 10 версии 1903 содержит ряд интересных изменений и улучшений, внесенных в функцию WSL. К ним относятся дополнительные дистрибутивы в Магазине, возможность просматривать файлы WSL в Проводнике и многое другое.

Возможность запуска Linux в Windows 10 обеспечивается функцией WSL. WSL это — Windows Subsystem for Linux, которая изначально была ограничена только Ubuntu. Современные версии WSL позволяют устанавливать и запускать несколько дистрибутивов Linux из Microsoft Store.

После включения WSL вы можете устанавливать различные версии Linux из Магазина, используя следующие ссылки:

Ссылки на дистрибутивы в магазине microsoft:

  Ubuntu  | openSUSE Leap  | SUSE Linux Enterprise Server | Debain GNU / Linux | Kali Linux

В Windows 10 версии 1903 вы можете легко получить доступ ко всем файлам в ваших дистрибутивах Linux с помощью проводника Windows. На момент написания статьи эта функция реализована в сборке Windows 10 18836. Она находится на пути к ветви 19h1, поэтому мы увидим ее в следующей сборке. Вот как это можно сделать.

Чтобы получить доступ к файлам WSL Linux из проводника Windows 10 , выполните следующие действия.

Шаг 1: Включить функцию WSL (Подситема Windows для Linux)

Шаг 2: Установите какой-нибудь дистрибутив, например Ubuntu, и запустите его.

Подробнее в нашей статье: Руководство по установке и запуску — Ubuntu Bash в Windows 10.

Шаг 3: Находясь в каталоге Linux FS, введите^

explorer.exe .

Откроется окно проводника, расположенное внутри вашего дистрибутива Linux.

Теперь вы можете получить доступ к любым файлам Linux, так же, как и к любому другому файлу через проводник. Это включает в себя такие операции, как: перетаскивание файлов в другие места, копирование и вставка и даже использование пользовательских записей контекстного меню, добавленных Notepad ++, VSCode или другим программным обеспечением.

Проводник показывает файлы дистрибутива как виртуальный сетевой ресурс по пути \\ wsl $ \ <running_distro_name> \.

Команда WSL активно исследует способы улучшения обнаруживаемости файлов Linux внутри Проводника. Ход их работы уже можно увидеть в Windows 10 Build 18836, которая показывает файловую систему WSL / Linux в File Explorer.

Доступ к файлам Linux в командной строке

В дополнение к Проводнику вы можете использовать классическую командную строку и инструменты PowerShell для доступа к файлам Linux. Точно так же вам нужно перейти к \\wsl$\{имя дистрибутива}\, где {имя дистрибутива} — это имя работающего дистрибутива.

Известные вопросы

Это новая функция, и некоторые ее части могут не работать идеально. Вот некоторые известные проблемы, о которых мы хотим сообщить вам при использовании этой функции:

На данный момент файлы дистрибутивов будут доступны только из Windows, когда дистрибутив работает. Разработчик собирается добавить поддержку не работающих дистрибутивов в будущем обновлении.

Поскольку файловый сервер 9P работает внутри каждого дистрибутива, он доступен только тогда, когда этот дистрибутив работает. Команда ищет способы решить эту проблему.

Доступ к файлам Linux рассматривается так же, как и доступ к сетевому ресурсу, и все правила доступа к сетевым ресурсам будут по-прежнему применяться,

• Например: при использовании CMD cd \\wsl$\Ubuntu\home не будет работать (поскольку CMD не поддерживает пути UNC, так как текущие каталоги), однако будет работать copy \\wsl$\Ubuntu\home\somefile.txt C:\dev\
• Старые правила по-прежнему применяются, вы не должны получать доступ к файлам Linux внутри папки AppData!
• Если вы пытаетесь получить доступ к своим файлам Linux через папку AppData, вы используете обход сервера 9P, что означает, что у вас не будет доступа к файлам Linux, и вы можете повредить ваш дистрибутив Linux.

Примечание: Сервер 9P — это сервер, который содержит протоколы, поддерживающие метаданные Linux, включая разрешения. Демон инициализации WSL теперь включает сервер 9P. Существует служба Windows и драйвер, который действует как клиент и взаимодействует с сервером 9P (который работает внутри экземпляра WSL). Клиент и сервер обмениваются данными через сокеты AF_UNIX, поскольку WSL позволяет взаимодействовать между приложением Windows и приложением Linux, используя AF_UNIX.

For Ubuntu installed from the Windows store:

Each distribution you install through the store is installed to that
application’s appdata directory. For example:
C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState — benhillis

For WSL2 you can access to home directory from windows (Windows 10 build 18342) like this :

\\wsl$

In earlier iterations of Windows Subsystem for Linux, the Ubuntu file system was at %localappdata%\Lxss (e.g., C:\Users\Username\AppData\Local\Lxss — replace the Username with your Username on Windows). See the WSL blog post on File System Support:

The primary file system used by WSL is VolFs. It is used to store the
Linux system files, as well as the content of your Linux home
directory. As such, VolFs supports most features the Linux VFS
provides, including Linux permissions, symbolic links, FIFOs, sockets,
and device files.

VolFs is used to mount the VFS root directory, using
%LocalAppData%\lxss\rootfs as the backing storage. In addition, a
few additional VolFs mount points exist, most notably /root and
/home which are mounted using %LocalAppData%\lxss\root and
%LocalAppData%\lxss\home respectively. The reason for these separate
mounts is that when you uninstall WSL, the home directories are not
removed by default, so any personal files stored there will be
preserved.

CAUTION

Creating/modifying any files within the Linux subsystem using Windows apps & tools can cause Data corruption and data loss in Ubuntu subsystem! (Thanks to Rich Turner for suggesting these words of caution!) This is absolutely not supported. From the same blog post:

Interoperability with Windows

While VolFs files are stored in regular files on Windows in the
directories mentioned above, interoperability with Windows is not
supported. If a new file is added to one of these directories from
Windows, it lacks the EAs needed by VolFs, so VolFs doesn’t know what
to do with the file and simply ignores it. Many editors will also
strip the EAs when saving an existing file, again making the file
unusable in WSL.

Your Windows file system is located at /mnt/c in the Bash shell environment.

Source: Dustin Kirkland’s blog, howtogeek

I’ve been getting a few questions from Windows users about accessing WSL files in Windows and vice versa. I was originally going to wait with this for the next labs, but since this might actually make things a little clearer for some, I’ll just post the information here instead. If anything’s unclear, just wait for the second lab and I’ll probably be able to explain things better in person.

The WSL distributables (i.e. Ubuntu) are kind of like another machine running within your computer. It just features a Unix command-line interface (that’s the terminal, i.e. the bash shell), so the development tools and experiences are pretty limited. You can run vim, nano, or even emacs (might need to be installed) in the terminal to edit your files, but if you want to use a full-fledged IDE you’ll normally have to edit the files on the Windows side and then transfer them over to the Linux environment in WSL.

When we start working with Python, R and jflap, you can probably just solve the exercises on Windows, since you don’t need Linux to write Python or R code. Of course, you can always install python3 in Ubuntu, but you won’t have access to an IDE (unless you follow the guide in the last part of this post).

Accessing your WSL files in Windows

If you are using WSL 1, this should probably work fine most of the time. However, if you are using WSL2, it probably won’t. WSL2 doesn’t like it when we edit files in both Linux WSL and in Windows. WSL1 doesn’t like it either, but it’s possible to do, and I’ve tried so myself many times now without issues.

To access your Linux files in Windows, open the Ubuntu terminal and type explorer.exe . (include the punctuation mark). This will open the linux directory in Windows Explorer, with the WSL prefix “\wsl$\Ubuntu-18.04\home\your-username”.

Now, you’ll notice that Windows treats your Linux environment as a second network. This is because, as I’ve stated earlier, the Linux environment is completely separate from the Windows environment and transferring files between these environments is very similar to transferring files between computer networks. I always recommend that you copy the file you want over to a Windows folder before editing it, so that you won’t mess up the original if the file gets corrupted.

PS: To copy the file, run cp [filename] [destination], like this: console cp file.txt /backup/new_file.txt

Accessing your Windows files in the WSL terminal

Similarly, you can also open your Windows files in the Linux environment. Just use the cd command to navigate to your WSL root folder, then navigate into the mnt folder to access your C: drive. See the example below for more details. As you can see, I managed to access my Documents folder. Make sure to enter your own username when you try this yourself.

I recommend you to use the cp command to copy the files you need from Windows to your Linux environment, so that if anything should get corrupted you’re not going to mess up the original file.

Working in WSL with VScode

VScode is a full-fledged IDE from Microsoft, which has very recently released support for editing Linux files remotely. This means that you can open VScode from the Ubuntu terminal, run it in Windows, but edit the files in Linux while also being able to access the Linux terminal and viewing pathnames and home directory correctly. I’ve tried it out today, and… it just works!

So if you insist on using an IDE to edit your Linux files directly, even though you won’t really need to in this course, you can do it by installing the Remote — WSL extension for VScode. See the documentation and guides here.

VScode editor with WSL-remote enabled

\wsl$ mount point did not work for me so well, it has multiple issues, and many Windows applications fail because they see it as a network drive. For my usecase, it is Rclone what helped to solve the problem to properly mount Linux filesystem so it behaves without any issues, practically the same way as a local disk.

It is free and open source. It works with sftp remote filesystems (like sshfs), so it can mount network drives both on Linux and Windows (running sshd service).

Example command how to run it, assuming remote point «server» is already configured and rclone.exe is in PATH environment variable:

rclone mount server:/ Z: --file-perms=0777 --track-renames --track-renames-strategy=modtime,leaf --metadata --vfs-cache-mode=full --sftp-disable-hashcheck --volname drive_name

For the first time, you need to configure new remote point by running:

rclone config

To find out location of the config file you have just created, run:

rclone config file

Also, you may need to install WinFsp first, if not already intalled. The best thing about it, everything just works the same way like with local disk (assuming if you provide --vfs-cache-mode=writes or --vfs-cache-mode=full option, since without it, many applications will fail to work correctly, please read the documentation to understand why). Option --file-perms=0777 is necessary to allow running .exe files. Even though --vfs-cache-mode=writes may be enough for most applications, but —vfs-cache-mode=full is important for good performance with large files. For the same reason --track-renames-strategy is limited to only modtime and leaf strategies, because if other strategy is used, it will be obviously slow with large files, and --sftp-disable-hashcheck is necessary to prevent rclone from running md5sum, otherwise it will run it even when trying to read a file.

To register Rclone as a system service, edit and run the following command (do not run as is, please see below how you need to edit it first):

New-Service -Name Rclone -BinaryPathName 'C:\Program Files\Rclone\rclone.exe mount server:/ Z: --vfs-cache-mode=full --track-renames --track-renames-strategy=modtime,leaf --metadata --volname drive_name --config="C:\Program Files\Rclone\rclone.conf" --log-file="C:\Program Files\Rclone\rclone.txt" --file-perms=0777 --sftp-disable-hashcheck --no-console'

Obviously, you need to replace «server:/» with your actual remote point name and path, also replace drive_name with any name you like, and of cource you may need to edit paths to rclone.conf, rclone.log and rclone.exe, if you installed it in a different location.

Note: in my case running as a system service caused some permission issues (for example, when trying to save Excel files), and I did not figured out why yet, so I ended up creating startup .bat file to run Rclone as a user, since it works perfectly this way. I will update this answer if and when I figure out how to make running as a service to work as good as running as a user.

Even Windows software which does not like network drives, just works with RClone drives. All is needed, is to setup sshd in the remote system (which in this case is not really a remote syset, but in WSL distribution installed on the same PC). This how to setup sshd in WSL distribution: https://www.hanselman.com/blog/how-to-ssh-into-wsl2-on-windows-10-from-an-external-machine. And here is how to make WSL IP address static: https://github.com/ocroz/wsl2-boot, so you can have sshd running always at the same IP address.