dotnet workload always installs maui workload as root. This is making it impossible to build a project as a regular user on Manjaro/Arch Linux

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @v1k7-992.

---

From @v1k7-992 on Sunday, May 5, 2024 9:18:14 PM

Hi, recently I installed am trying to build a Maui app, and it seems all my projects when I either use VSCode, Rider or even dotnet build as a regular user, fail with this error:

/usr/share/dotnet/sdk/8.0.204/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.targets(38,5): error NETSDK1147: To build this project, the following workloads must be installed: maui-android

Running dotnet workload list, gives me this output:

dotnet workload list

Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------

Use `dotnet workload list` to find additional workloads to install.

But running the same command as sudo I can see that I have all the workloads installed:

Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------
maui-tizen                 8.0.7/8.0.100         SDK 8.0.200        
wasi-experimental          8.0.4/8.0.100         SDK 8.0.200        
android                    34.0.95/8.0.100       SDK 8.0.200        
maui-android               8.0.7/8.0.100         SDK 8.0.200        
wasm-tools                 8.0.4/8.0.100         SDK 8.0.200       

What could be causing this? Could it be some odd permission problem I might have stumbled on?

More info:
I am using Manjaro Linux using dotnet version 8.0.204. The SDK, runtime and targeting tools are from the AUR.

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @Forgind.

---

From @Forgind on Thursday, May 9, 2024 9:13:33 PM

Interesting...I tried this out with 8.0.100 on ubuntu, and it didn't seem to repro even when I switched to a new user after installing a workload. I'm curious what the differences are between ubuntu and monjaro or if we have a regression between 100 and 204

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @v1k7-992.

---

From @v1k7-992 on Friday, May 10, 2024 1:37:35 PM

What I am using, in case of manjaro, is the AUR package for dotnet sdk. This package to be specific: https://aur.archlinux.org/packages/dotnet-sdk-bin. Could it be possible that the PKGBUILD is to blame?

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @Forgind.

---

From @Forgind on Friday, May 10, 2024 11:11:54 PM

I downloaded the 8.0.204 package for x64 from that link, extracted the contents, and copied them into my dotnet folder. I ran dotnet workload list (empty as expected), then install maui-android (failed: need admin rights), then sudo dotnet workload install maui-android (succeeded).

Then I ran dotnet workload list again (without sudo), and it showed maui-android as installed.

It's possible there's something special with the manjaro file system where it fakes a path at some point or prevents non-admin processes from accessing things in protected directories?

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @v1k7-992.

---

From @v1k7-992 on Sunday, May 12, 2024 2:16:32 PM

@Forgind thank you for investigating into this.

I managed to find the reason why it is not working. It seems that manjaro (and arch linux does this as well), have given incorrect permissions to the folders /usr/share/dotnet/packs and /usr/share/dotnet/sdk-manifests. What is missing is the execution permission. Without that, dotnet build cannot use the Maui workload pkgs, and that is why I couldn't build. It gave an error saying that the packages were not downloaded and installed in my original comment, but it's valid, although confusing abit. Setting the folders using sudo chmod go+x sdk-manifests packs have solved the problem.

The solution for the future might lie in contacting the person maintaining the AUR package, that the PKGBUILD should create those two directories, and assign execution privileges for the folder. This is a little dangerous, so there probably exists a much better solution to this. Probably using groups, idk for now.

Should we close the issue here?

[Forgind]

---

Issue moved from dotnet/sdk#40692

• Please respond to @Forgind.

---

From @Forgind on Monday, May 13, 2024 4:49:44 PM

Thanks for your help with the investigation! I asked my PM where we should go from here, and he suggested transferring this issue to another dotnet repo that is a more central location for issues related to building dotnet from source, as in this case. They should be able to help us find the optimal solution here.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

@alucryd - This looks to be a possible packaging issue.

[MichaelSimons]

[Triage] Looking at the packages at https://aur.archlinux.org/packages/dotnet-sdk-bin, the source is the Microsoft produced tarballs

https://download.visualstudio.microsoft.com/download/pr/0a1b3cbd-b4af-4d0d-9ed7-0054f0e200b4/4bcc533c66379caaa91770236667aacb/dotnet-sdk-8.0.204-linux-x64.tar.gz
https://download.visualstudio.microsoft.com/download/pr/1e449990-2934-47ee-97fb-b78f0e587c98/1c92c33593932f7a86efa5aff18960ed/dotnet-sdk-8.0.204-linux-arm64.tar.gz
https://download.visualstudio.microsoft.com/download/pr/ac99d114-0422-475c-b75b-8279ff9f9a68/19efacb0358aaf945f0a8ad62a8ca718/dotnet-sdk-8.0.204-linux-arm.tar.gz

This should be investigated on the SDK side.

[MichaelSimons]

[Triage] Because the AUR packages are based on the Microsoft tarballs, this is not a source-build issue. Reopened dotnet/sdk#40692 to track this.