-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSLg's runtime-dir has always owner 1000 resulting in inaccessable runtime dir for default user #9689
Comments
If this issue should actually be filed against microsoft/wslg, happy to create it there again. |
This and related runtime dir issues have, unfortunately, been something of a long-running issue (see #8918 and #9025, primarily). I think the best (most functionality-preserving) current solution is the one I espouse here, in which overlayfs is used to give every user/uid access to their own user runtime directory as in native Linux, but in which the WSLg sockets are effectively made to appear in all of them. |
Same here ..really annoying |
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
Versions
Windows Version
10.0.19045.2604
WSL Version
Kernel Version
5.15.90.1
Distro Version
Ubuntu 22.04 (with systemd enabled)
Other Software
WSL version: 1.1.3.0
Kernel version: 5.15.90.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2604
Repro Steps
/etc/wsl.conf
2wsl.exe --shutdown
or at least the distro in question (wsl.exe --terminate Ubuntu
)wsl.exe
without parameters (as it's the default user of the default distro) and check that you have read access to your runtime dir:ls -la "$XDG_RUNTIME_DIR"
Expected Behavior
The user's run directory (
"$XDG_RUNTIME_DIR"
, i.e./run/user/$UID
) is read-writable and has the required sockets set up, e.g.:It can be either
/mnt/wslg/runtime-dir
(if, and only if the owner of that dir corresponds with the current user), usually shown asnone /run/user/$UID type tmpfs (rw,relatime)
inmount
's outputtmpfs
mount with the optionsrw,nosuid,nodev,relatime,size=6565592k,nr_inodes=1641398,mode=700,uid=$UID,gid=$UID
It can easily be tested with the following command, which should only return 1 entry:
Actual Behavior
The directory
/mnt/wslg/runtime-dir
is always owned UID 1000, whether or not this UID is assigned to a user in/etc/passwd
.The runtime directory is not accessible:
In fact, runtime directory (
"$XDG_RUNTIME_DIR"
,/run/user/$UID
seems to be mounted twice4, at least when logging in as a user with an UID other than 1000:The first would be the regular mount for that user. However, it's "shadowed" by the bind mount to
/mnt/wslg/runtime-dir
, despite the later being owned by another user. As such, the current user's run directory becomes inaccessible:If, however, the later mount is removed with
sudo umount "$XDG_RUNTIME_DIR"
, then the "real" directory becomes "visible" and accessible and apps that require access to e.g. d-bus other sockets can now succeed:Further observations/remarks
runtime-dir
is not accessible graphical apps don't work, or not fully./mnt/wslg/runtime-dir
should be owned by the default user (as set in/etc/wsl.conf
).Workaround
I've been able do make things work by adding the following snippet to the login script:
Diagnostic Logs
WslLogs-2023-02-24_16-35-04.zip
Footnotes
Login as root:
↩wsl.exe -u root
and then run:Still as
↩root
, runeditor /etc/wsl.conf
and add or adjust the following section, making sure that thedefault
property underuser
section is set tonew_user
:In the same
↩root
session, run the following command:I had one occasion, where there was actually only the bind mount, but not the tempfs mount. However, I was not able to reproduce that case. Might be related to the following issue: UAC elevated / basic level of wslhost.exe cause different mount "namespaces" #9690. ↩
The text was updated successfully, but these errors were encountered: