/tmp/.X11-unix is missing the sticky bit

[Link1J]

Windows build number:

22621.2361

Your Distribution version:

Fedora 39/Ubuntu 22.04.2 LTS/Debain 11

Your WSL versions:

WSL version: 2.0.2.0
Kernel version: 5.15.123.1-1
WSLg version: 1.0.58
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2361

Steps to reproduce:

1. Install GNOME Shell (sudo dnf install gnome-shell on Fedora, sudo apt install gnome-shell on Ubuntu/Debain)
2. Run env GNOME_SHELL_SLOWDOWN_FACTOR=2 MUTTER_DEBUG_DUMMY_MODE_SPECS=1024x768 dbus-run-session -- gnome-shell --nested --wayland

WSL logs:

No response

WSL dumps:

No response

Expected behavior:

GNOME launchs
Note: GNOME still fails to launch on Ubuntu 20.04.2 LTS and Debian 11.

Actual behavior:

GNOME does not launch and reports one of the follow errors
[Fedora 39]

(gnome-shell:316247): libmutter-ERROR **: 10:42:44.263: Failed to start X Wayland: Directory "/tmp/.X11-unix" is missing the sticky bit
== Stack trace for context 0x55bfd11ea3e0 ==
A connection to the bus can't be made

[Debain 11]

(gnome-shell:28220): mutter-WARNING **: 10:57:15.911: Failed to ensure X11 socket directory: Directory "/tmp/.X11-unix" is missing the sticky bit

(gnome-shell:28220): mutter-ERROR **: 10:57:15.911: Failed to start X Wayland

[Ubuntu 20.04.2 LTS]

(gnome-shell:18273): libmutter-ERROR **: 11:00:01.801: Failed to start X Wayland: Directory "/tmp/.X11-unix" is missing the sticky bit
GNOME Shell crashed with signal 5
== Stack trace for context 0x5627590d1190 ==

This is caused by a missing sticky bit on /tmp/.X11-Unix, which cause XWayland to not launch.
This also happens with KDE Plasma, but the errors are a lot less clear.

[elsaco]

@Link1J unless you really need an X server try running gnome-shell as a Wayland compositor without starting XWayland. Add --no-x11 at the end of your command invocation and it will work.

[Link1J]

I know of that flag, which is why there is edit to add a note that GNOME still crashes on Debain 11 and Ubuntu 20.04.2 LTS.
Also, I haven't been able to find an equivalent flag for KDE Plasma, and would also likely affect launch X in other ways. So this is still a problem.

I used GNOME just because KDE Plasma's error messages are really long.

[elsaco]

/tmp/.X11-unix is created by WSL as read-only to prevent systemd-tmpfiles from removing /tmp/.X11-unix during startup. I recall there were bugs filed on this issue.

elsaco@ubuntu:~$ findmnt /tmp/.X11-unix
TARGET         SOURCE           FSTYPE OPTIONS
/tmp/.X11-unix none[/.X11-unix] tmpfs  ro,relatime

This is the command from init:

ExecStart=/bin/mount -o bind,ro,X-mount.mkdir -t none /mnt/wslg/.X11-unix /tmp/.X11-unix

and X-mount.mkdir defaults to 0755. I guess WSL team could change it to 1755 since as end-user the sticky bit can't be set on that directory:

elsaco@ubuntu:~$ sudo chmod u+t /tmp/.X11-unix
chmod: changing permissions of '/tmp/.X11-unix': Read-only file system

[xishian]

/tmp/.X11-unix is created by WSL as read-only to prevent systemd-tmpfiles from removing /tmp/.X11-unix during startup. I recall there were bugs filed on this issue.

elsaco@ubuntu:~$ findmnt /tmp/.X11-unix
TARGET         SOURCE           FSTYPE OPTIONS
/tmp/.X11-unix none[/.X11-unix] tmpfs  ro,relatime

This is the command from init:

ExecStart=/bin/mount -o bind,ro,X-mount.mkdir -t none /mnt/wslg/.X11-unix /tmp/.X11-unix

and X-mount.mkdir defaults to 0755. I guess WSL team could change it to 1755 since as end-user the sticky bit can't be set on that directory:

elsaco@ubuntu:~$ sudo chmod u+t /tmp/.X11-unix
chmod: changing permissions of '/tmp/.X11-unix': Read-only file system

same question

# findmnt /tmp/.X11-unix
TARGET         SOURCE           FSTYPE OPTIONS
/tmp/.X11-unix none[/.X11-unix] tmpfs  ro,relatime

[lvlte]

NB. /tmp/.X11-unix missing the sticky bit causes other related issues (ie. without using gnome shell), like indefinitely growing logs, etc., see WSL#9303 and WSL#11943.

[radbobdad]

Is there a known workaround for this issue?

[threeifbyair]

Just to add to this, I'm sure this was OK in the past, because running a VNC server was my workaround to #973 when I was RDPed from an iPad. But now even my workaround doesn't work because this prevents me from starting a VNC server on WSL2!

[levrik]

This issue is also spamming the syslog, causing a constant CPU usage of ~10% for the VmmemWSL process on my machine which is rather annoying. Disabling WSLg gets rid of this constant CPU usage.