Skip to content
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

mkdir /run/user/1000/: permission denied after WSL 2.0.0 #10498

Open
1 of 2 tasks
felipecrs opened this issue Sep 19, 2023 · 20 comments
Open
1 of 2 tasks

mkdir /run/user/1000/: permission denied after WSL 2.0.0 #10498

felipecrs opened this issue Sep 19, 2023 · 20 comments

Comments

@felipecrs
Copy link

Windows Version

Microsoft Windows [Version 10.0.22631.2338]

WSL Version

2.0.0.0

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

5.15.123.1-1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

I'm sorry but I'm not sure if this issue happened after upgrading to 2.0.0 or after running wsl --manage Ubuntu --set-sparse true, since I did both at once.

Some programs I have, like chezmoi, is now failing:

$ chezmoi update
chezmoi: mkdir /run/user/1000/: permission denied

Expected Behavior

To work as it did before.

Actual Behavior

$ chezmoi update
chezmoi: mkdir /run/user/1000/: permission denied

Diagnostic Logs

No logs.

The workaround is to:

sudo mkdir /run/user/1000 && sudo chmod 700 /run/user/1000 && sudo chown $(whoami): /run/user/1000

Which I saw somewhere but I don't remember where.

@benhillis
Copy link
Member

Do you have systemd enabled?

@ghost ghost changed the title mkdir /run/user/1000/: permission denied after WSL 2.0.0 and wsl --manage Ubuntu --set-sparse true mkdir /run/user/1000/: permission denied after WSL 2.0.0 Sep 19, 2023
@felipecrs
Copy link
Author

Yes, I forgot to mention that.

@felipecrs
Copy link
Author

Just to mention, this issue happened again out of the blue after booting up my WSL today. I suspect it's perhaps to the automatic disk sparsing.

Previously I tested wsl --shutdown many times and it didn't trigger the issue after fixing the directory permissions manually.

@luis-aranda
Copy link

luis-aranda commented Sep 22, 2023

I have the same issue. The workaround for me is to remove systemd in /etc/wsl.conf

Also setting the permission works with something like "chmod 700 $XDG_RUNTIME_DIR" but this doesn't persist in new sessions after closing the current session

@OneBlue
Copy link
Collaborator

OneBlue commented Sep 22, 2023

@felipecrs: Can you share the output of ls -la /run/user and share boot logs for when you see this issue ?

/logs

@microsoft-github-policy-service
Copy link
Contributor

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://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 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

Thank you!

@felipecrs
Copy link
Author

Will do, as soon as I can reproduce the issue again. As mentioned, it seems to happen randomly after fixing the permissions manually. Rebooting WSL or Windows does not immediately trigger the issue, apparently.

@felipecrs
Copy link
Author

I was really not able to reproduce this issue today. Yesterday it happened multiple times.

@luis-aranda if you are still experiencing this, please share the logs as @OneBlue asked if you don't mind.

@felipecrs
Copy link
Author

After upgrading to 2.0.1 I was able to reproduce this issue again. I'm working to capture the logs.

@felipecrs
Copy link
Author

After wsl --shutdown to enable debugConsole I can no longer see the issue. Odd!

@felipecrs
Copy link
Author

Ok, issue happened again while WSL was even running. A restart isn't required to trigger the issue apparently.

chezmoi cd
chezmoi: mkdir /run/user/1000/: permission deniedls -la /run/user/1000
ls: cannot access '/run/user/1000': No such file or directorysudo ls -la /run/user
total 0
drwxr-xr-x  2 root root  40 Sep 25 20:30 .
drwxr-xr-x 29 root root 780 Sep 25 20:29 ..

WslLogs-2023-09-25_20-35-57.zip

@asampal
Copy link

asampal commented Sep 27, 2023

Also have been getting asimilar error, (org.gnome.Nautilus:1046): dconf-CRITICAL **: 20:13:44.733: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly., since 2.0.0. Noticed it when running nautilus &. Terminal spews this as you move the cursor over the UI.

@felipecrs
Copy link
Author

I gotta say that after unregistering my WSL instance and starting from scratch I'm no longer having this issue.

In the meantime I had also upgraded to 2.0.1, so maybe it also fixed it.

@g2flyer
Copy link

g2flyer commented Oct 5, 2023

FYI: i see also a similar issue: since quite a while, after starting wsl i initially get the "normal" /usr/user/1000 for default user but then fairly quickly something removes the whole directory with all files. A 'ssh localhost' does recreate them and from then on all the files stay as expected (to the extent i have to stay logged in via ssh, as soon as i log out the files get quickly removed). And yes, i also have systemd enabled (and currently run it with wsl 2.0.4.0 ...)

@felipecrs
Copy link
Author

An update on my side: I deleted my whole distro (wsl --unregister) and reinstalled it. I'm no longer facing this issue after doing that. Several days have passed already.

@g2flyer
Copy link

g2flyer commented Oct 10, 2023

FYI: realized only now that this is a duplicate of #10496 and #10552. Disabling systemd-networkd.disable as mentioned there solves the issue. Additionally, as discussed there (and in related issue https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358), this is more a ubuntu/systemd issue than a WSL2 issue, so probably this issue could be closed?

@dan788
Copy link

dan788 commented Oct 20, 2023

add this start up script to your .profile
start_script.txt
sudo -i
chown 1000:1000 /run/user/1000
logout
env | grep DBUS
should show DBUS_STARTER_ADDRESS=unix:path=/run/user/1000/bus
hope this helps

@appselskapet
Copy link

@dan788 this worked for me. Thanks alot. Do you have a brief explanation what it does?

@georgejean
Copy link

@appselskapet See here.

@aruprakshit
Copy link

I have this error too.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble
$ emacs .

(emacs:3234): dconf-CRITICAL **: 13:12:43.450: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.451: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.451: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.452: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.452: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.453: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.454: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

(emacs:3234): dconf-CRITICAL **: 13:12:43.454: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants