dotnet nuget push fails with cryptic "the system cannot find the path specified" under the SYSTEM account

[colejohnson66]

NuGet Product Used

dotnet.exe

Product Version

9.0.100 (59db016f11)

Worked before?

Unknown

Impact

I'm unable to use this version

Repro Steps & Context

We have a private Gitea-based NuGet source on a 10.0.0.0/24 IP address. Our NuGet.Config looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="gitea" value="http://10.0.0.31/api/packages/<>/nuget/index.json" allowInsecureConnections="True" />
  </packageSources>
  <packageSourceCredentials>
    <gitea>
        <add key="Username" value="<>" />
        <add key="Password" value="<>" />
      </gitea>
  </packageSourceCredentials>
</configuration>

Once we upgraded from SDK 8.0.403 to 9.0.100, our Jenkins pipeline has been failing consistently with a cryptic error:

error: Unable to load the service index for source http://10.0.0.31/api/packages/<>/nuget/index.json.
error:   The system cannot find the path specified.

What gets even more frustrating is that we can remote in and, using the local account, run the push command with no issues. But if Jenkins (under the SYSTEM account) tries, it fails. Using psexec, we can confirm it's not Jenkins that's the issue, but the usage of a SYSTEM account.

I've managed to track the error down; It's thrown in GetServiceIndexResourceV3, but I can't see why without logs and dotnet nuget xyz doesn't support verbosity level.

https://github.com/dotnet/dotnet/blob/2b952814a3d115fe7f4fa9bebe99c43035436f91/src/nuget-client/src/NuGet.Core/NuGet.Protocol/Providers/ServiceIndexResourceV3Provider.cs#L120-L196

Verbose Logs

Specify --help for a list of available options and commands.
error: Unrecognized option '--verbosity'


Usage: dotnet nuget push [arguments] [options]

Arguments:
  [root]  Specify the path to the package and your API key to push the package to the server.

Options:
  -h|--help                      Show help information
  --force-english-output         Forces the application to run using an invariant, English-based culture.
  -s|--source <source>           Package source (URL, UNC/folder path or package source name) to use. Defaults to DefaultPushSource if specified in NuGet.Config.
  -ss|--symbol-source <source>   Symbol server URL to use.
  -t|--timeout <timeout>         Timeout for pushing to a server in seconds. Defaults to 300 seconds (5 minutes).
  -k|--api-key <apiKey>          The API key for the server.
  -sk|--symbol-api-key <apiKey>  The API key for the symbol server.
  -d|--disable-buffering         Disable buffering when pushing to an HTTP(S) server to decrease memory usage.
  -n|--no-symbols                If a symbols package exists, it will not be pushed to a symbols server.
  --no-service-endpoint          Does not append "api/v2/package" to the source URL.
  --interactive                  Allow the command to block and require manual action for operations like authentication.
  --skip-duplicate               If a package and version already exists, skip it and continue with the next package in the push, if any.

[colejohnson66]

This issue first manifested with 9.0.100. When we upgraded, NuGet refused to push to a bare HTTP URL anymore, so we tried creating a NuGet.config, but the "current user's NuGet.config" is in the inaccessible C:\Windows\System32\config. After placing it in C:\NuGet.config as a test, it gives the above error message. We have downgraded to 8.0.404 and are pushing to the bare URL to get this to work.