Bash on Ubuntu on Windows: What Works and What Doesn't

I installed Bash on Ubuntu on Windows to see whether it could replace a dual-boot setup. It couldn’t. The command-line tools worked, but file watching broke and editing the wrong files from Windows made them disappear from the Linux side.

Microsoft announced the feature at Build 2016 and shipped it with the Windows 10 Anniversary Update. The name was awkward, but the promise was huge: native Linux tools on Windows without setting up a virtual machine.

What this isn’t

It’s not a desktop environment. Don’t expect Ubuntu’s GUI. This is Bash and command-line tools only. Graphical Linux apps still need a VM.

It doesn’t integrate with Windows tools. Git for Windows and Bash on Ubuntu use separate credential stores. Your Windows SSH keys won’t work in Bash. Each environment is isolated.

You can’t run Linux binaries from Windows directly. Linux executables only work inside the Bash shell.

The file system mystery

The Linux environment lives at:

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

For example, /etc maps to:

C:\Users\KahWee\AppData\Local\lxss\rootfs\etc

Keep Windows out of the Linux filesystem I edited config files with Windows Notepad, and they disappeared from the Linux side. Keep shared projects on the Windows side and access them through /mnt.

The file system translation layer doesn’t handle concurrent access from both sides, which breaks a key workflow. You can’t edit code in Visual Studio Code (Windows) and run it in Bash (Linux) reliably when the files live in the Linux file system.

Accessing Windows drives

Windows drives mount under /mnt:

• C: becomes /mnt/c
• D: becomes /mnt/d

This works well:

cd /mnt/c/Users/KahWee/projects
ls -la

Editing files from Windows while running Linux tools works better when files live on the Windows side. But performance is noticeably slower than native Linux file I/O.

File synchronization issues

I wanted Bash for command-line work while editing code in Windows editors. Put projects on C: (Windows), access via /mnt/c (Linux), edit in Windows, run commands in Bash.

File watching broke completely. Tools like Webpack and Gulp watch for file changes. When I edited files in Windows, the Linux side didn’t detect changes. Build tools that rely on inotify (Linux’s file change notification) don’t work with /mnt paths.

No terminal tabs

The Bash window is a single instance. There are no tabs, so multiple terminals means separate windows managed with Alt+Tab.

This gets messy fast with 10 terminal windows open. tmux helps, but it’s not as ergonomic as native terminal tabs.

Can you install zsh and other shells?

Yes:

sudo apt install zsh

It worked but occasionally glitched, with prompts rendering incorrectly and some plugins refusing to load. The environment was not stable enough to trust.

The data loss scare

Files disappeared when I edited from Windows. I don’t know if the file was deleted or just invisible to Bash, but losing work isn’t acceptable.

Microsoft warned that the Linux file system is fragile and shouldn’t be modified from Windows. That warning is justified.

Performance

Command-line operations felt slower than native Linux. npm install and git operations took noticeably longer than the same commands on a Linux VM or dual-boot setup.

Every I/O operation went through Windows, then translated to Linux system calls, then back.

What worked well

Package management: apt worked perfectly. I installed Node.js, Python, Ruby, and other tools without issues.

Shell scripts: Running existing Bash scripts mostly worked. If your scripts don’t rely on file watching or heavy I/O, they’ll run fine.

Learning Linux: For developers learning Linux commands, this beats setting up dual-boot or VMs.

What didn’t work

File system reliability: Editing from Windows while using Bash is risky.

Performance: Noticeably slower than native Linux.

Integration: No shared credentials, SSH keys, or environment variables between Windows and Linux sides.

File watching: Build systems and test runners that watch for changes don’t work on /mnt paths.

Where I landed in 2016

Bash on Ubuntu on Windows was an impressive technical achievement, but not ready for serious work. File system issues and performance problems made it unreliable for daily development.

For light scripting or learning Linux commands, it worked. For professional web development, I stuck with dual-boot or VMs.

How this evolved

By 2019, Microsoft released WSL2. WSL2 runs a real Linux kernel in a lightweight VM, giving proper performance and file system reliability. It became a legitimate replacement for dual-boot setups.

The 2016 version proved the concept, but it still felt like a beta. If you’re reading this now, use WSL2. It’s what I wanted Bash on Ubuntu on Windows to be in the first place.