Could not write lines to file "/tmp/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs". Access to the path "/tmp/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs" is denied.

[AlseinX]

Steps to reproduce

• Install WSL2 Debian 10 on Windows 10 version 2004.
• Install .NET Core 3.1 SDK.
• Install Visual Studio Code on Windows 10 natively and connect with Remote - WSL.
• Install C# language support extension.
• Open a project simply generated from dotnet new console and wait for OmniSharp loading.

Expected behavior

Everything works fine.

Actual behavior

A warning is reported in omnisharp log:

[warn]: OmniSharp.MSBuild.ProjectLoader
        Could not write lines to file "/tmp/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs". Access to the path "/tmp/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs" is denied.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.200
 Commit:    c5123d973b

Runtime Environment:
 OS Name:     debian
 OS Version:  10
 OS Platform: Linux
 RID:         debian.10-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.200/

Host (useful for support):
  Version: 3.1.2
  Commit:  916b5cba26

.NET Core SDKs installed:
  3.1.200 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

OS info: Windows 10 build 19041.153 updated from Windows Insiders Slow Ring

Remarks

I don't know in which repository this issue should be. Maybe in wsl, omnisharp, msbuild, dotnet sdk, or mono runtime, but I found #2188 a similar issue even though this one is probably different in the new WSL2 environment.

[rainersigwald]

This is the right repo. This should be fixed by #5101 for MSBuild 16.6, which will ship with SDK version 3.1.300.

Are you seeing the error consistently, or only intermittently? The known issues with the old approach to this file were race conditions between multiple projects, but they should go away fairly quickly in a VS Code/OmniSharp environment.

[AlseinX]

This is the right repo. This should be fixed by #5101 for MSBuild 16.6, which will ship with SDK version 3.1.300.

Are you seeing the error consistently, or only intermittently? The known issues with the old approach to this file were race conditions between multiple projects, but they should go away fairly quickly in a VS Code/OmniSharp environment.

Consistently, even after cleaning up all those /tmp files and ensuring that there is no linux file permission problems associated to the project files.

[rainersigwald]

The consistency is very interesting; it must be a different problem from the known race condition.

Can you run your build under strace with the file-I/O operations traced and see what the filesystem thinks is happening when writing that file?

[jjxtra]

Same issue on a 10 project solution Ubuntu 20.04. C# extension is unusable. I am doing build and run from command line for the moment. Wish I could use the debugger :)

.NET Core SDK (reflecting any global.json):
 Version:   3.1.301
 Commit:    7feb845744

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.301/

Host (useful for support):
  Version: 3.1.5
  Commit:  65cd789777

.NET Core SDKs installed:
  3.1.301 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[jjxtra]

chmod 666 /tmp appears to have fixed the issue, at least for now. If you are running vscode as root then you need to run the command after you run sudo -i

[xiangzhai]

:mips-interest

[dotnet-policy-service[bot]]

This issue is marked as stale because feedback has been requested for 30 days with no response. Please respond within 14 days or this issue will be closed due to inactivity.

[dotnet-policy-service[bot]]

This issue was closed due to inactivity. If you can still reproduce this bug, please comment with the requested information, detailed steps to reproduce the problem, or any other notes that might help in the investigation.