Open xiahualiu opened 5 months ago
PS: this issue was originally met when one of the application (vscode-makefile-tool) tried to create a sock file in the $XDG_RUNTIME_DIR
, however the sock creation step failed because the user has a UID of 1001 and cannot access to the $XDG_RUNTIME_DIR
path set by wslg as shown above.
Please make sure wslg set $XDG_RUNTIME_DIR
correctly, it should be assigned per user instead of using a global value.
Here is a workaround according to this post. Create /etc/systemd/system/user-runtime-dir@.service.d/override.conf
and add:
[Service]
ExecStart = sh -c "ln -fs /mnt/wslg/runtime-dir/* /run/user/"%i
This will link everything in /mnt/wslg/runtime-dir
to /run/user/$UID
. The reason why I don't mount /mnt/wslg/runtime-dir
at /run/user/$UID
like what the original post does is that it will cause user@UID.service
's failure due to /run/user/$UID
's incorrect owner
This bug cause user who's id is not 1000 cannot use wayland.
Badly, fresh installed Ubuntu-24.04 has users: ubuntu(uid=1000) and your_user(uid=1002) .
Luckly, dist-updated Ubuntu-24.04 will keep your_user(uid=1000).
Windows build number:
19045.3930
Your Distribution version:
22.04
Your WSL versions:
WSL version: 2.0.14.0 Kernel version: 5.15.133.1-1 WSLg version: 1.0.59 MSRDC version: 1.2.4677 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.3930
Steps to reproduce:
Install the latest Ubuntu WSL OS.
In
/etc/wsl.conf
, enable systemd.restart WSL then
WSL logs:
No response
WSL dumps:
No response
Expected behavior:
Not expect anything.
Actual behavior:
$XDG_RUNTIME_DIR
should not be set by wslg to/mnt/wslg/runtime-dir
. This folder is owned by 1000:1000, any other user cannot access this path even it is set in their environment.However after enable the
systemd
in WSL the$XDG_RUNTIME_DIR
value is set correctly. I don't know whywslg
tries to set it to this value at first.