Azure Artifacts · NuGet · Checked November 6, 2026

Azure DevOps: "Unable to load the service index for source" from an Azure Artifacts feed

Before NuGet downloads anything, it reads the feed's service index, the index.json address in your nuget.config. When Azure Artifacts refuses that request, restore stops here. The status code after it tells you which way: 401 means no credentials were sent, or they were not accepted; 403 means the identity was known but has no role on the feed (a Stack Overflow question on this message has been seen over 140,000 times, and Azure DevOps questions with it over 700,000 times in all).

When restore fails in a pull request's build validation, the pull request waits on it: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the feed lets the build in. Get it on JetBrains Marketplace

What it looks like

• error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/fabrikam/Web/_packaging/shared/nuget/v3/index.json., then Response status code does not indicate success: 401 (Unauthorized). or 403 (Forbidden).
• From the .NET task's restore command, also the warning For internal feeds, make sure the build service identity '...' [...] has access to the feed. and Packages failed to restore. The warning names the identity the job ran as, which is the one to look up in the feed's permissions.
• A 403 whose body says the user lacks permission and needs ReadPackages is the build identity without a role (the accepted answer on a question about it).

In a pipeline: give the build identity a role on the feed

• The job runs as {Project} Build Service ({Organization}) or Project Collection Build Service ({Organization}). In Artifacts, open the feed, then Feed settings, Permissions, Add users/groups, and add that identity (Microsoft's page on feed permissions).
• Feed Reader can download what is already in the feed. Feed and Upstream Reader (Collaborator) can also save a package from an upstream source such as nuget.org, which happens the first time a build asks the feed for a package it has not stored yet. That is the role Microsoft gives the build identities by default, and the one to give for restore. To push packages, give Feed Publisher (Contributor), to both identities.

dotnet build restores again, without the credentials

• The .NET task's restore command (DotNetCoreCLI@2 with command: restore) writes the feed's credentials into a temporary nuget.config, runs dotnet restore with it, and deletes it when it finishes (the task's source). dotnet build, test, publish and pack restore again by default, this time with your repository's nuget.config and no credentials, and that restore is the one that fails.
• Either pass --no-restore in those steps' arguments, or put - task: NuGetAuthenticate@1 before them. That task installs the Azure Artifacts Credential Provider, so every later dotnet, nuget and MSBuild command in the job gets credentials for feeds in your organization (the task's reference; the most voted answer on the most read question). It is also the fix for dotnet tool restore and for dotnet restore in a plain script step.
• It needs dotnet 6 or later. After moving from NuGetAuthenticate@0, a 401 with It was not possible to find any compatible framework version earlier in the log means the agent has no .NET 6; add UseDotNet@2 first, as the reference says.

The restore task's own feed settings

• With feedsToUse: select, vstsFeed takes an organization-scoped feed by its name, and a project-scoped feed as Project/Feed (the task's help).
• With feedsToUse: config and nugetConfigPath, feeds in the same organization get the build's credentials without anything else. Feeds outside it need a NuGet service connection named in externalFeedCredentials.

A feed in another project or organization

• Another project in the same organization: with Limit job authorization scope to current project on, the job runs as {Project} Build Service of the pipeline's project, so that identity, not only Project Collection Build Service, needs a role on the feed (the accepted answer found this setting after adding feed permissions had not helped). Microsoft's feed page also asks for a project-level permission for that identity in the feed's project. The scope setting itself: the checkout page has it in its TF401019 section.
• Another organization: the build's token does not reach it. Create a NuGet service connection with a personal access token from that organization that can read packages, and name it in NuGetAuthenticate@1's nuGetServiceConnections or in the restore task's externalFeedCredentials.
• A pull request from a fork: runs triggered from an external fork do not get the secrets for internal feed authentication. NuGetAuthenticate looks successful and a later step fails; the task's reference shows a 500 with VS800075. Once the pull request is merged, the run that the merge triggers authenticates.

On your own machine

• dotnet: install the Azure Artifacts Credential Provider (dotnet tool install --global Microsoft.Artifacts.CredentialProvider.NuGet.Tool, with a .NET SDK of 9.0.200 or later), then run dotnet restore --interactive once. It signs you in and keeps a token, so later commands work without --interactive until the token expires (Microsoft's dotnet setup page).
• Visual Studio after a password change: it may keep sending the old credential. Remove the entries named like VSCredentials_<domain> under Windows Credentials in Credential Manager, and Visual Studio asks again (an answer).
• A personal access token in packageSourceCredentials of a nuget.config gets 401 once it expires or when it lacks read access to packages. Make a new one, and keep it in your user-level nuget.config rather than the repository's.

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps, Azure Artifacts, Azure Pipelines, NuGet and Visual Studio are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: npm: E401 Unable to authenticate from the same kind of feed · the dotnet task matched no project · checkout stops with Git fetch failed with exit code: 128 · no zip where the deploy task looks · 日本語