Windows Subsystem for Linux (WSL): what can't I do with the Ubuntu application for Microsoft Windows?

The Ubuntu that runs under Windows 10 Subsystem for Linux is not a full distro. In fact, it's not Linux at all -- it has no Linux kernel. So you can't test or try kernel extensions, including drivers, because you're not running Linux.

If you want to do stuff like that, either install Ubuntu in a VM -- Win10 includes Hyper-V, but personally, I prefer VirtualBox, which is free -- or dual-boot your machine with Ubuntu running on the bare metal. You will almost certainly find the latter faster than running Windows -- I do on all my machines. Partly this is because you need antivirus protection when running Windows, which saps performance, especially disk performance. And because you need it, Win10 includes built-in antivirus.

With Linux, you do not need any, so there is less performance impact.

There are many useful pieces of information on each of the above answers. I am here summarizing the main concepts of each of them.

Update April 2020: Pro and cons in using WSL are here explained. There is clear why having a real Linux kernel is an advantage!! Additionally, here there is a guide to install WSL 2 onto your Windows 10. If you have installed the WSL 1 and you want to pass to WSL 2, here you can find the instruction for doing it.

Update August 2019: The new WSL 2 was released (read here for more information). It seems that you can work with a real Linux kernel and with a Linux file system. Honestly, I haven't tried the new version so far (it is on my TODO list).

Update May 2019: as pointed out in one of the most recent answers, WSL is evolving by using the real Linux Kernel and giving many more options. I have been through this document and, if confirmed, it will be a big step forward. Here you can find a nice article about the topic "real Linux kernel on W10"

Answer July 2018 Summarizing: "Ubuntu on windows is the complete Ubuntu userland on top of a Windows kernel in Linux-Compatibility mode", as point out in one of the comments.

What I can't do:

• Officially, no graphics interface supported so far. This means also that graphics applications cannot be executed. Additionally, the standard GUIs of the classic Ubuntu Linux-based are not supported for this reason of course.
• The kernel of Linux developed by Linus is NOT part of the Windows Subsystem for Linux (WSL). This means that you cannot develop drivers and try it directly.
• Not every command line works.

What I can do:

• Use the command line and the basic Bash shell. It is possible to write and execute scripts.
• Develop applications (compile or cross-compile and execute them) but with no graphics so far.
• Use "apt-get" to install/remove new/old packets.

Additional information:

• other distributions are officially supported (like, for example, Debian and Kali)

• these applications are free, downloadable from the Windows Store and here you can find the instruction to install and use it.

• In this other question of the blog, some suggestion on how to use a GUI for WSL (unofficial, third party)

One of the things you cannot easily do under the Windows Subsystem for Linux (WSL) is run Linux GUI applications.

To do so you have to install an unsupported X11 server such as VcXsrv or Xming.

Enabling WSL is relatively trivial. It seems to be pretty good as a Linux command-line userland.

From How-To Geek:

[It] doesn’t yet support background server software, and it won’t officially work with graphical Linux desktop applications. Not every command-line application works, either, as the feature isn’t perfect.

Update from allquixotic's comment:

As of Windows 10 v1803 background tasks are supported.

As of May 2019, WSL 2 is under development.

Dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker.

...

WSL 2 uses an entirely new architecture that uses a real Linux kernel.

...

Initial builds of WSL 2 will be available through the Windows insider program by the end of June 2019.

(emphasis mine)

When this question was first written, neither WSL2 nor WSLg had been released, so the answer today is certainly different than it was a few years ago. Some of that info has been updated in answers here, but I feel there's a lot missing in other answers here around actual "limitations".

I'm a fairly big WSL fan, but I'll be the first to acknowledge that there are quite a few limitations when it comes to WSL. Fortunately, most of these have workarounds, but they do catch most new users off guard.

To start with, let me just lay out some "differences" between Ubuntu on WSL and a traditional Ubuntu installation on a VM or physical machine. I'll reference some of these in the "limitations" section below:

1. WSL1 runs as a "syscall translation layer" that attempts to translate Linux kernel API's into those of the Windows kernel.

2. Ubuntu running in WSL2 acts more like a container. It is running under a real Linux kernel in a managed virtual machine (that you can't access). Ubuntu is running inside a namespace in that VM. It is not, itself, directly running in a VM.

3. WSL has its own init system. Its main job (other than some "normal" Linux init tasks) is to set up the interoperability between Linux and Windows. For instance, it:

   • makes the Windows network available to Ubuntu
   • adds the Windows path to the environment
   • mounts Windows drives into Ubuntu

4. That init runs as PID1 inside the Ubuntu WSL instance/namespace/container.

5. Starting WSL is not like booting a virtual or physical machine. Many of the tasks that Ubuntu would normally (typically through Systemd) do during boot are either not needed for WSL or are actually harmful to its normal operation.

6. There is no concept of a "login" when starting WSL. WSL detects the default user and automatically starts the shell defined for that user in /etc/passwd. No password is requested or needed.

Limitations of WSL

With that in mind, here are some limitations that I can think of:

• init/Systemd: Ubuntu running in WSL does not use Systemd. Systemd requires that it be running as PID1, but WSL's init runs as PID1. Many docs, blog posts, etc. that you come across for various tasks (e.g. installing Docker) will assume that Systemd is available. There are several workarounds that I mention in this answer.

  Further, software packages that are deeply ingrained with and rely on Systemd just won't function unless you resort to the namespace hack mentioned in that answer. Gnome is one of the more common examples.

  As another personal example, I was trying to run cockpit (for a web-interface to libvirtd) in a non-Systemd distribution a few days ago, and I just could not find any way to work around its reliance on Systemd.

  This is certainly one of the top areas of confusion for new users coming to Ubuntu on WSL.

• Running Systemd on WSL2: Related to the previous items, if you do attempt to use Systemd, the default Systemd boot process on Ubuntu (and pretty much any distribution) makes some assumptions that aren't valid on WSL. For instance:

  • Systemd will erase files in /tmp, but at that point in the startup, WSL has already created a symlink there for the well-known X11 socket under Windows 11. (Update note: A change in a recent WSL Preview release makes this a bind-mount instead of a symlink. That bind-mount can be remounted read-only to prevent systemd-tmpfiles from tampering it (found in the Arch Systemd guide)).

  • Systemd will set up some binfmt_misc handlers, overwriting the WSL handler that allows you to run Windows binaries under WSL.

  • Systemd will redefine the user environment, overwriting the Windows path that was appended to it.

  If you are planning on running Systemd (even with a "helper" script), I strongly encourage you to keep in mind that it could interfere with other Ubuntu operations under WSL and plan to troubleshoot if and when it happens.

• Access to physical hardware: On WSL, you will have limited access to hardware:

  • Serial ports: WSL1 has access to serial ports at some level, but only as far as the syscall implementations go. That said, it's possible to run some software on WSL1 that utilizes the serial ports that is not possible on WSL2.

  • Physical drives: Under Windows 10, you can only mount drives via a network protocol or physical drives that are connected to Windows and formatted NTFS. Raw drives and those using other filesystems cannot be mounted.

    WSL2 under Windows 11 does have the ability to mount additional drive types.

  • Graphics: Under Windows 10, there is no direct access from Ubuntu on WSl to any graphical application or interface. If you want to run a graphical Linux app in Ubuntu on WSL, you must install a third-party X server in Windows and run the X client/application in WSL with the appropriate DISPLAY settings. See this answer and this answer for more details.

    Again, under Windows 11, WSL2 now has the ability to run graphical apps out-of-the-box.

  • GPU: Under recent Windows 10 versions, some GPU Compute tasks are available using a passthrough library and the Windows GPU drivers.

    Under Windows 11, some additional GPU Compute tasks have been added.

  • USB: USB devices are not directly accessible. However, under WSL2 (both in Windows 10 and 11), they can be shared from Windows using USB/IP and then attached in Ubuntu.

    Note, though, that the stock WSL2 kernel does not include most device drivers for USB devices. For instance, even the basic media capture (i.e. camera) drivers are not included. However, you can build your own kernel for WSL2 and include the necessary drivers. However, note that currently, I (and others) have not succeeded in capturing video from a USB camera in WSL. See this question on Stack Overflow for the progress-to-date.

• Ubuntu boot device: The primary boot virtual disk/partition for Ubuntu in WSL must be formatted ext4. Although the WSL2 kernel supports additional filesystems such as btrfs, they can only be used for secondary partitions.

• Tasks that rely on authentication/login: Due to (6) above, certain tasks that rely on authentication will behave differently on WSL. For instance, normally you would edit /etc/security/limits.conf to raise the limits (e.g. number of open files, priority/nice, etc.) for a user. However, this is a file that is handled by PAM (the "pluggable authentication module") during user login. Without an authenticated login, this file is never processed. See workaround in this answer if you come across this.

• Startup services:

  • Windows 10: Without Systemd (or another init) to rely on, there's no easy way to define what services should run by default in a WSL instance. For instance, the cron daemon won't be running (the source of this question). The workaround is to check and see if a service is running in your shell startup (e.g. ~/.bashrc) and start it if not. See this answer for more details.

  • Windows 11: Now at least includes the ability to run tasks at startup. Also see the same answer for details. However, I might recommend that you start a process supervisor as your main task using this method, then use the process supervisor to start and manage other needed tasks. I mention how to do this in this Stack Overflow answer using supervisord, but any process supervisor (that doesn't require that it be PID1, of course) will work.

• Networking: While this might belong under the "hardware" section, it probably deserves its own callout here. WSL2's network currently runs under a virtual switch inside Hyper-V, and that switch is NAT'd from the rest of the network. This means that you cannot easily access network services in WSL2 from other devices (computers, phones, etc.) on the local network without additional effort.

  The easiest workaround is to use WSL1 for this when possible. There are multiple other workarounds as well.

• VPNs: Likewise, when connecting to certain VPN's which disable local traffic, WSL2 will lose networking, since it is "local" (but not localhost) network traffic.

• Pen-testing: Some penetration testing tasks simply won't work under with WSL1 (because of the limited syscall translations) nor WSL2 (because hardware is virtualized). Two areas stand out here:

  • Direct access to the wifi interface is not available (only a virtual ethernet device), so WLAN password cracking techniques will not work. As a workaround, it should be possible to install a secondary USB WiFi dongle, pass it through via USB/IP as discussed above, and use it inside WSL2. Note that you will need to build your own kernel with the appropriate drivers for the network dongle.

  • Because WSL2 is on a separate layer 2 network than your Windows host (and the rest of your network), it won't be possible to do any layer 2 scanning. The above USB/IP workaround should work for this as well.

• Performance: In general, performance under WSL2 is pretty good. However, there are a few caveats:

  • WSL1: WSL1 has slightly reduced performance on its "pseudo-ext4/overlay" filesystem. However, WSL2 achieves near-native performance on ext4 filesystems.

  • WSL2: WSL2 takes a huge performance hit when accessing files on Windows drives, especially multiple, small files. Checking out the WSL2 kernel on an NTFS drive takes over 10 minutes (but ~30 seconds otherwise). It is highly recommended that you keep project files on the ext4 filesystem or use WSL1 when accessing Windows drives.

  I keep a WSL1 instance around primarily for the purpose of working with Windows drives when needed.

I'm sure I'll remember some more (or perhaps someone will point them out in the comments), and I'll add them in if needed.

Again, with the workarounds mentioned, most of these are not serious blockers for most WSL users. However, they are the source of many questions that I've answered across the Stack Exchange sites.