Nuget.Server configuration problem

Dec 21, 2011 at 3:41 PM

I tried to setup a nuget.server using the Nuget.Server package. But when I try to do a nuget push, nuget.exe exits with a System.FormatException.
I've encountered this problem before, when the application pool identity didn't have sufficient rights to write in the packages directory on the server.

Currently, the application pool uses the Network Service identity, and I gave it full rights to the packages directory. But the error remains and I can't figure out what goes wrong.

The server is hosted on http://myserver/nuget16.
The command I use: nuget -push mypackage.nupkg MyApiKey -src http://myserver/nuget16

Web.Config contains <add key="apiKey" value="MyApiKey" />

Any suggestions how to figure out what is wrong ?

Dec 21, 2011 at 3:52 PM

Are you using the latest nuget.exe (nuget.exe update -self) ? We fixed the issue where you got the FormatException. That might help you see what the response from the server is.

Dec 21, 2011 at 3:58 PM
Edited Dec 21, 2011 at 4:00 PM

when I use the latest nuget.exe command, I get other problems... 
It asks for credentials, and whatever I specify, it fails 
The message I get from the nuget command line :
Please provide credentials for http://myserver/nuget16

the sites authentication is set to anonymous

Dec 21, 2011 at 4:22 PM

I think somebody else posted about this - does specifying the source http://myserver/nuget16/api/v2/ work? Certainly sounds like a bug somewhere, but if this works, it might help narrow down what's wrong.

Dec 21, 2011 at 4:40 PM

When I use http://myserver/nuget16/api/v2/  it returns : Failed to process request : 'Not Found'
The external server has returned an error: (404) not found.. 

Dec 21, 2011 at 4:45 PM

Actually appending /api/v2/package/ works for this. I was having the same problem and found it worked against my local nuget.server running in visual studio. Fiddler showed /api/v2/package/ as being different in the url between the working (localhost) and non working (remote) instances. Adding this to the source in the push command seems to be a workaround.

Dec 21, 2011 at 4:50 PM

Indeed jpree, when I add /package, it seems to work... thx !!

Dec 21, 2011 at 5:02 PM

Ok, definitely figured out what's wrong. We have some funky code in there to not append the /api/v2/package path if we see a path in the source url. (In your case the path's nuget16). Definitely a big miss on my part. I think I could tweak the server to redirect PUT or DELETE requests to the right route.

Jan 13, 2012 at 1:08 PM

I have experienced similar problems, but none of the above suggestions have helped.

When I use

nuget push -source http://localhost/NuGet mypackage.nupkg -ApiKey sometext

I am prompted for credentials.  Upon entering a username and password, "Cannot access a closed Stream." is displayed.

If I try

nuget push -source http://localhost/NuGet/api/v2/ mypackage.nupkg -ApiKey sometext

the following error occurs:

"Failed to process request. 'Not Found'.  The remote server returned an error: (404) Not Found.."

If I try

nuget push -source http://localhost/NuGet/api/v2/package/ mypackage.nupkg -ApiKey sometext

the following error occurs:

"Failed to process request. 'Internal Server Error'.  The remote server returned an error: (500) Internal Server Error.."


The NuGet server builds and runs, I think that I'm doing something wrong however when trying to publish to the server.


Jan 13, 2012 at 4:30 PM

Is your site hosted under a virtual directory named NuGet?

Jan 13, 2012 at 4:54 PM

Yes, I deployed the Nuget server web app to the NuGet VirDir.

Jan 13, 2012 at 5:38 PM

I created a separate site for the NuGet server and ran into the same error messages that I listed above when I executed and of the following:

nuget push mypackage.nupkg -s http://localhost:8086 -ApiKey sometext
nuget push mypackage.nupkg -s http://localhost:8086/api/v2 -ApiKey sometext
nuget push mypackage.nupkg -s http://localhost:8086/api/v2/package -ApiKey sometext
Jan 13, 2012 at 5:52 PM

1) In the first case (nuget push mypackage.nupkg -s http://localhost:8086 -ApiKey sometext), do you continue to get prompted for credentials?

2) Are you using IIS 6? if so, could you check if the workaround listed at works for you?

3) Do you think you could set up fiddler and see what urls the exe is trying to ping? Use this guide - - in case you have trouble getting it to log correctly.


Jan 13, 2012 at 8:41 PM

Fiddler helped me identify my problem.  The App Pool did not have access to the Packages folder.  (I thought that I had previously checked the permissions on the folder, but I must have missed something.)

I'll answer your questions in case it helps others in the future:


#1, No I was not being prompted for credentials, but I was getting a 500 error.

#2, No I'm using II7 on Windows Server 2008 R2.

#3, Fiddler helped identify the root cause of the 500 (could not access the Packages folder).

Feb 8, 2012 at 4:32 PM

I had similar permissions issues.

To debug this I added a <CustomErrors Mode="Off"/> to the nuget server's web.config. Then I used Fiddler2 to get at the failed 500 response.

I had to give write access to both the packages directory and the ASP.Net temp directory. In my case this was C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Mar 13, 2012 at 3:00 PM

I started getting a (404) Not Found error once I updated to version NuGet Version: 1.6.21205.9031.  I've filled an issue at  Perhaps this is also what others are experiencing here.

Apr 18, 2012 at 10:47 AM

I installed Nuget.Server as per the instructions on the

The route setup appears to be broken - clicking the 'here' link on the nuget home page returns 'Not found'.

Deploying via uget push {package file} -s http://host/nuget/ {apikey} prompts for credentials (?) and then fails with 'Cannot access a closed Stream.'

I have tried all the fixes recommended and it still does not work, even on my workstation.

I challenge the Nuget team to create a new repository as per the instructions above using the current release. It simply does not work.

Any ideas, hints or suggestions are welcome.

Apr 18, 2012 at 1:45 PM

SOLVED: If you're forced to develop in VB, ensure that you port Routes.cs to Routes.vb - then your routes are configured, and all is well.

Dec 9, 2012 at 9:10 PM
Edited Dec 9, 2012 at 9:22 PM

I found the issue was by default IIS7 or above blocks requests larger than 30mb, once that was increased nuget push now worked for me, I don't know why it returns 404 when it fails though. Here's the web.config change, the value is in bytes:

      <requestLimits maxAllowedContentLength="300000000" />
Dec 31, 2012 at 4:31 PM

@pranavkm I was curious if there was ever a fix implemented on this?  I am running Server v2.2 and it appears that I am having the same issue that you described above.  I saw the post that you had from Dec 21, 2011 and if I append "api/v2/package/" to my url the push does seem to work.

Oct 15, 2013 at 1:49 AM
For the (500) error, In IIS Manager for the site, r-click on the Packages folder, select the Security Tab, then give write permissions to the user associated with the site (it was site name on my installation).
Mar 9, 2015 at 4:12 AM
I just ran into this today. I was using TeamCity to push a NuGet package to a private NuGet server and ran into the 404 problem. After digging around it turns out that the problem was related to the size of the NuGet package being pushed (it was 38.4 MB). IIS will block PUT requests that are smaller than 30 MB unless you change the setting.

Here is how you can change it:
Open IIS Manager > Server Node > Request Filtering > Rules > Edit Feature Settings... > Maximum allowed content length > change the value to 100 MB (in bytes).

This requires no change to the code for the private NuGet server and does not require any changes to the web.config file for the NuGet server either.
Apr 26, 2015 at 9:03 PM
Thank You rodolfoneuber,
I was pulling my hair with this trying to upload a large nuget package (70Mb) to the nuget.server installation. Strangely it did work using the 1.6 version but after upgrading the nuget.server package to 2.8 the 404 errors started to appear. After double checking the maxRequestLength and maxAllowedContentLength attributes I was at a loss. Didn't really guess that the new version would be affected by a setting in the IIS, but they perhaps changed the push method to use PUT instead of a POST...
Thanks anyway, You made my day :)