Why can't .exes see files in /tmp in Windows Subsystem for Linux when the current working directory is a subdirectory of /mnt/c?

Viewed 741

When I run a .exe file from within WSL when the current working directory is /mnt/c or a subdirectory thereof, it seems to be unable to see files in /tmp. For example, cd /mnt/c; notepad.exe $(mktemp) throws "The system cannot find the file specified", even though non-exe executables work fine, such as cat $(mktemp). Note that mktemp itself works fine, giving the correct output and actually creating the file.

Interestingly, I've noticed that this does not happen when the current working directory is /, among others. There, notepad.exe $(mktemp) works fine. However, when the current working directory is /mnt/c or a subdirectory of it, this strange behavior occurs.

Why can exes in WSL see /tmp when the current working directory is outside /mnt/c, but not from inside it? What causes this to happen?

If it matters, I'm on WSL1 Ubuntu 18.04 LTS.

The output of ps awx with notepad.exe $(mktemp) running is

    1 ?        Ssl    0:58 /init
    5 tty1     Ss     0:00 /init
    6 tty1     S      0:09 -bash
 3227 tty1     S      0:00 /init /mnt/c/Windows/system32/notepad.exe /tmp/tmp.KQwVgByK8u
 3228 tty2     Ss     0:00 /init
 3229 tty2     S      0:00 -bash
 3255 tty2     R      0:00 ps awx

Process 3227's mount info is

=== /proc/3227/mountinfo ===
2 2 0:2 / / rw,noatime - lxfs rootfs rw
3 2 0:3 / /dev rw,noatime - tmpfs none rw,mode=755
4 2 0:4 / /sys rw,nosuid,nodev,noexec,noatime - sysfs sysfs rw
5 2 0:5 / /proc rw,nosuid,nodev,noexec,noatime - proc proc rw
6 3 0:6 / /dev/pts rw,nosuid,noexec,noatime - devpts devpts rw,gid=5,mode=620
7 2 0:7 / /run rw,nosuid,noexec,noatime - tmpfs none rw,mode=755
8 7 0:8 / /run/lock rw,nosuid,nodev,noexec,noatime - tmpfs none rw
9 7 0:9 / /run/shm rw,nosuid,nodev,noatime - tmpfs none rw
10 7 0:10 / /run/user rw,nosuid,nodev,noexec,noatime - tmpfs none rw,mode=755
11 5 0:11 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc binfmt_misc rw
12 4 0:12 / /sys/fs/cgroup rw,relatime - tmpfs cgroup rw,mode=755
13 12 0:13 / /sys/fs/cgroup/devices rw,relatime - cgroup cgroup rw,devices
14 2 0:14 / /mnt/c rw,noatime - drvfs C:\134 rw,uid=1000,gid=1000,case=off```
1 Answers

Old question, but I had the same problem just now. Found the solution to this on superuser: https://superuser.com/a/1728907/144431

You need to update wsl utilities to the latest (apparently this years-old bug was finally fixed). On Ubuntu, it's just a matter of doing:

sudo add-apt-repository ppa:wslutilities/wslu
sudo apt update
sudo apt upgrade
Related