XDG_RUNTIME_DIR mounted with `noexec` option

[W1M0R]

Windows Version

Microsoft Windows [Version 10.0.26100.4061]

WSL Version

2.5.7.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04.5 LTS

Other Software

This issue did not occur while I was on WSL version: 2.4.13.0. Then I ran wsl --update and got WSL version: 2.5.7.0. I did a wsl --shutdown and then opened my Ubuntu 22.04.5 LTS, after which the issue started appearing.

Repro Steps

Run findmnt $XDG_RUNTIME_DIR. The output will indicate that the noexec option is set and that mode is 755. This means that chmod +x has no effect on scripts that are stored within $XDG_RUNTIME_DIR, that is, those scripts can't be executed by just running them.

A temporary solution is to run this command every time that the wsl distro is started:

sudo mount -o remount,exec $XDG_RUNTIME_DIR

This seems to go against the stated purpose of $XDG_RUNTIME_DIR:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and they MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The directory MUST be on a local file system and not shared with any other system. The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems AF_UNIX sockets, symbolic links, hard links, proper permissions, file locking, sparse files, memory mapping, file change notifications, a reliable hard link count must be supported, and no restrictions on the file name character set should be imposed.

Related:

1. https://github.com/casey/just/issues/2702
2. https://specifications.freedesktop.org/basedir-spec/latest/#variables
3. https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html#Runtime%20Data
4. https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#%24XDG_RUNTIME_DIR
5. https://github.com/microsoft/WSL/issues/10896

Expected Behavior

Duplicate mount entries should not appear. The mount point should not have noexec and the mode should be 700.

❯ echo $XDG_RUNTIME_DIR
/run/user/1000/

❯ mount | grep /run/user/1000
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000)
tmpfs on /mnt/wslg/run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000)

❯ findmnt /run/user/1000
TARGET         SOURCE FSTYPE OPTIONS
/run/user/1000 tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000

Actual Behavior

Duplicate mount entries appear, with the options specified in the last mount being active, i.e. noexec and mode=755.

❯ echo $XDG_RUNTIME_DIR
/run/user/1000/

❯ mount | grep /run/user/1000
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000)
tmpfs on /mnt/wslg/run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /mnt/wslg/run/user/1000 type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

❯ findmnt /run/user/1000
TARGET         SOURCE FSTYPE OPTIONS
/run/user/1000 tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=1220116k,nr_inodes=305029,mode=700,uid=1000,gid=1000
/run/user/1000 tmpfs  tmpfs  rw,nosuid,nodev,noexec,relatime,mode=755

Diagnostic Logs

WslLogs-2025-05-28_13-53-59.zip acl.txt appxpackage.txt bcdedit.txt HKCU.txt HKLM.txt optional-components.txt P9NP.txt windows-version.txt Winsock2.txt wpr.txt wslservice.txt wslsupport-impl.txt wslsupport-proxy.txt

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

[github-actions[bot]]

Diagnostic information

Issue was edited and new log file was found: https://github.com/user-attachments/files/20482351/WslLogs-2025-05-28_13-53-59.zip
Detected appx version: 2.5.7.0

[W1M0R]

WslLogs-2025-05-28_13-53-59.zip

[github-actions[bot]]

Diagnostic information

Detected appx version: 2.5.7.0

[OneBlue]

Thank you for reporting this @W1M0R. WSL doesn't set noexec on that mount, so I wonder if this is caused by something else.

Do you see the same issue if you disable systemd in /etc/wsl.conf ?

[microsoft-github-policy-service[bot]]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-file it as a new issue.

Thank you!

[urob]

I can reproduce the exact issue reported in OP with WSL version 2.5.9.0 if and only if WSLg is also installed (v1.0.66). Uninstalling WSLg restores the expected behavior:

$ findmnt /run/user/1000
TARGET         SOURCE FSTYPE OPTIONS
/run/user/1000 tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=1626540k,nr_inodes=406635,mode=700,uid=1000,gid=1000

So it seems that WSLg might be somehow responsible?

[ghost]

Indeed @urob is right, disabling GUI application support resolves the issue.

# append to .wslconfig
guiApplications=false

[ghost]

Never mind on the above, it's not a stable long term workaround. The issue regressed for us after a restart on the next day, even with GUI disabled. I'm not knowledgeable enough so not sure how it temporarily resolved the issue in the first place.

[urob]

Indeed, a related issue re-emerged after restarting for me as well. It seems that even after uninstalling WSLg, it continues to mount /mnt/wsgl/run/user to run/user (overwriting tmpfs originally mounted to /run/user):

$ findmnt -D -M /run/user
SOURCE                       FSTYPE    SIZE  USED  AVAIL USE% TARGET
none                         tmpfs  1006.9G 19.9G 935.7G   2% /run/user
/dev/sdd[/mnt/wslg/run/user] ext4   1006.9G 19.9G 935.7G   2% /run/user

The difference to before is that after uninstalling, /mnt/wslg/run/user/$UID is owned by root without any read access by $USER:

$ ls -l /mnt/wslg/run/user
drwx------ - root 24 Jun 09:45 1000

This results in an access error when trying to access /run/user/$UID as $USER:

$ ls /run/user/$UID
"/run/user/1000": Permission denied (os error 13)

In either case, it seems that the issue is /mnt/wslg/run/user being mounted to run/user (on top of the tmpfs mount).