Dotnet restore uses global temporary directory

[Inumedia]

This is a forwarded issue from the Dotnet CLI repository, I was informed that this issue stems from the NuGet side of things.

The original issue can be seen here: https://github.com/dotnet/cli/issues/2806

Steps to reproduce

• Setup Ubuntu 14.04 instance to test on
• Install latest dotnet runtime
• Create new project as root
• Execute dotnet restore
• Login as another user
• Create new project as other user
• Attempt to execute dotnet restore
• You will see a permission error, attempting to access /tmp/NuGetScratch/lock

Expected behavior

dotnet restore should work as expected and my project's dependencies should be restored.

Actual behavior

dotnet restore attempts to re-use the /tmp/NuGetScratch/lock causing a permissions error and failing out.

Environment data

dotnet --info output:

(Attempting to run dotnet --info yields no helpful information, I ran dotnet --version)

dotnet --version :
.NET Command Line Tools (1.0.0-beta-001598)

Product Information:
Version: 1.0.0-beta-001598
Commit Sha: N/A

Runtime Environment:
OS Name: ubuntu
OS Version: 14.04
OS Platform: Linux
Runtime Id: ubuntu.14.04-x64

[rrelyea]

Not sure what is best temp to use on Linux: http://stackoverflow.com/questions/31068/how-do-i-find-the-temp-directory-in-linux

[Inumedia]

@rrelyea Not sure, but on Ubuntu 14.04 only mktemp out of those commands are available built in.

[IntelOrca]

As a work around, you can either set your environment variable TMPDIR beforehand to something the user will have permissions to... or you can set the permissions of /tmp/NuGetScratch/ and /tmp/NuGetScratch/lock to o+rwx.

[dcby]

Same issue on centos. I believe all *nix systems are affected. Did not check on windows yet. Any reason to not use user specific directory (i.e. inside ~/.nuget)?

[jjqq2013]

+1 i ran into same problem in an non-root docker container. @IntelOrca thank you.
It seems the first one who create ${TMPDIR}/NuGetScratch/lock should set correct permission because this lock directory will be used all other users, and the same for ${TMPDIR}/NuGetScratch.

I think this is a bug.

[naamunds]

Another possible workaround is to simply delete /tmp/NuGetScratch. That worked for me in the limited testing I've done.

[jjqq2013]

Yes remove the /tmp/NuGetScratch will work fine. Besides, I have created a docker image to resolve some problem about this and other anti-root tools like yeomon . https://hub.docker.com/r/osexp2000/dnetcore_docker_image/

[IntelOrca]

Deleting the folder will not solve the issue of two users doing a package restore at the same time.

[tmds]

On linux, Path.GetTempPath returns "/tmp" while on Windows it returns a user specific folder "C:\Users\tmds\AppData\Local\Temp".

From the corefx code it seems like the value returned by Path.GetTempPath can be controlled by setting the TMPDIR environment variable. Setting this variable to a user specific folder can serve as a workaround.

According to the documentation Path.GetTempPath should return the current user's temporary folder.

I'll create a matching issue in the corefx repo to see of Path.GetTempPath needs to be updated so it returns a user specific folder or whether the NuGet.Client needs to take into account it may not be the sole owner of the directory returned by Path.GetTempPath.

[IntelOrca]

Would it be possible to enhance NuGet to work with any number of concurrent package restores even for the same user?

[tmds]

@IntelOrca NuGet allows concurrent restores for the same and different users. "lock" is a folder and in it are files which represent a lock on a file in the filesystem.

[joelverhagen]

Fixed with NuGet/NuGet.Client#1035. Thanks @tmds!

[Inumedia]

Woohoo! Thanks 😄

[Perksey]

Deleting %AppData%\..\Local\Temp\NuGetScratch and %UserProfile%\.nuget seems to fix this issue on windows environments.

[meidianto]

Fixed the issue by deleting %UserProfile%\.nuget