I have been using Azure DevOps for a project for quite some time, but suddenly publishing to my own organisation/collection feed results in a 403.
I created a feed and I can select it on the nuget push build step, but it does not work. I created a new feed to publish the NuGet packages to and this works perfectly again. It seems to me like a token expired, but I never created one or used it to authenticate. I also do not want to change my NuGet feed to the new one, as I want to use older packages as well.
This is the buildpipeline:
And this is the stack trace:
Active code page: 65001 SYSTEMVSSCONNECTION exists true
SYSTEMVSSCONNECTION exists true SYSTEMVSSCONNECTION exists true
[warning]Could not create provenance session: {"statusCode":500,"result":{"$id":"1","innerException":null,"message":"User
'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks permission to complete
this action. You need to have
'ReadPackages'.","typeName":"Microsoft.VisualStudio.Services.Feed.WebApi.FeedNeedsPermissionsException,
Microsoft.VisualStudio.Services.Feed.WebApi","typeKey":"FeedNeedsPermissionsException","errorCode":0,"eventId":3000}}
Saving NuGet.config to a temporary config file. Saving NuGet.config to
a temporary config file. [command]"C:\Program Files\dotnet\dotnet.exe"
nuget push d:\a\1\a\Microwave.0.13.3.2019072215-beta.nupkg --source
https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json
--api-key VSTS error: Unable to load the service index for source https://simonheiss87.pkgs.visualstudio.com/_packaging/5f0802e1-99c5-450f-b02d-6d5f1c946cff/nuget/v3/index.json.
error: Response status code does not indicate success: 403
(Forbidden - User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks
permission to complete this action. You need to have 'ReadPackages'.
(DevOps Activity ID: 2D81C262-96A3-457B-B792-0B73514AAB5E)).
[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
[error]Packages failed to publish
[section]Finishing: dotnet push to own feed
Is there an option I am overlooking where I have to authenticate myself somehow? It is just so weird.
"message":"User 'a831bb9f-aef5-4b63-91cd-4027b16710cf' lacks
permission to complete this action. You need to have 'ReadPackages'.
According to this error message, the error you received caused by the user(a831bb9f-aef5-4b63-91cd-4027b16710cf) does not have the access permission to your feed.
And also, as I checked from backend, a831bb9f-aef5-4b63-91cd-4027b16710cf is the VSID of your Build Service account. So, please try with adding this user(Micxxxave Build Service (sixxxxss87)) into your target feed, and assign this user the role of Contributor or higher permissions on the feed.
In addition, here has the doc you can refer:
There is a new UI in the Feed Permissions:
To further expand on Merlin's solution & related links (specifically this one about scope), if your solution has only ONE project within it, Azure Pipelines seems to automatically restrict the scope of the job agent to the agent itself. As a result, it has no visibility of any services outside of it, including your own private NuGet repos held in Pipelines.
Solutions with multiple projects automatically have their scope unlocked, giving build agents visibility of your private NuGet feeds held in Pipelines.
I've found the easiest way to remove the scope restrictions on single project builds is to:
In the pipelines project, click the "Settings" cog at the bottom left of the screen.
Go to Pipelines > Settings
Uncheck "Limit job authorization scope to current project"
Hey presto, your 403 error during your builds involving private NuGet feeds should now disappear!
I want to add a bit more information just in case somebody ends up having the same kind of problem. All information shared by the other users is correct, there is one more caveat to keep into consideration.
The policies settings are superseded by the organization settings. If you find yourself unable to modify the settings or they are grayed out click on "Azure DevOps" logo at the left top of the screen.
Click on Organization Settings at the bottom left.
Go to Pipeline --> Settings and verify the current configuration.
When I created my organization it was limiting the scope at the organization level. It took me a while to realize it was superseding the project.
Still wondering where that "Limit job authorization scope to current project" setting is, took me a while to find it, its in the project settings, below screenshot should help
It may not be immediately obvious or intuitive, but this error will also occur when the project your pipeline is running under is public, but the feed it is accessing is not. That might be the case, for instance, when accessing an organization-level feed.
In that scenario, there are three possible resolutions:
Make the feed public, in which case authentication isn't required; or
Make the project private, thus forcing the service to authenticate; or
Include the Allow project-scoped builds under your feed permissions.
The instructions for the last option are included in #Merlin Liang - MSFT's excellent answer, but the other options might be preferable depending on your requirements.
At minimum, this hopefully provides additional insight into the types of circumstances that can lead to this error.
Another thing to check, if using a yaml file for the Pipelines, is if the feed name is correct.
I know this might seem like a moot point, but I spent a long time debugging the ..lacks permission to complete this action. You need to have 'AddPackage'. error only to find I had referenced the wrong feed in my azure-pipelines.yaml file.
If you don't want to/cannot change Project-level settings like here
You can set this per feed by clicking 'Allow Project-scoped builds' (for me greyed out as it's already enabled).
That's different from the accepted answer, as you don't have to explicitly add the user and set the permissions.
Adding these two permissions solved my issue.
Project Collection Build Service (PROJECT_NAME)
[PROJECT_NAME]\Project Collection Build Service Accounts
https://learn.microsoft.com/en-us/answers/questions/723164/granting-read-privileges-to-azure-artifact-feed.html
If I clone an existing pipeline that works and modify it for a new project the build works fine.
But if I try to create a new pipeline I get the 403 forbidden error.
This may not be a solution but I have tried everything else suggest here and elsewhere but I still cannot get it to work.
Cloning worked for me.
I am building a Web Application that will be installed many times. The application needs to be able to save certain setting itself upon request.
I have an installer (InnoSetup) but I want to very careful about what permissions I give the Web Application.
I can't use a database.
A default install always leaves the web.config as read-only. (Most secure)
The registry can be problematic. Unless there is a set of keys a DotNet webapp can always write to by default (IIS_IUSR)...
I was considering App_Data, but the default permissions are no longer useful and Inno-Setup can't easily fix it correctly:
https://support.microsoft.com/en-us/kb/2005172
Security and Ease of Setup are both big issues..
I also don't want to make a mess of the machines I install to.
A FAILED solution was to write to the user portion of the registry:
Microsoft.Win32.Registry.CurrentUser.CreateSubKey("Software\\MyCo\\MyApp\\");
var reg = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\\MyCo\\MyApp", true);
reg.SetValue("MyValue", (string)dataString, Microsoft.Win32.RegistryValueKind.String);
But I found out that writing to HKEY_CURRENT_USER is also not allowed by default on Server 2012 and likely others. The server error page is helpful and gives options such as explicitly giving the IUSR_{MachineName} explicit permission but this is a no go for me.
So my final solution is to have the installer create a user configurable folder and then assigning all users Read/Write access to that folder. The administrator can always lock it down more if they want.
If anyone has a better option then let me know.
With InnoSetup I created a new Wizard page to suggest and collect a Data folder from the user. The installer then:
Created that folder and gave All Users Read/Write access,
Added a HKLM registry key telling the Web App where to look for the folder,
Notified the user that they should lock the folder down further to prevent abuse.
Got an ASP.NET site which I wish to perform an SVN info call from.
My understanding is this error message appears when a user hasn't yet done their basic setup to use SVN. Specifically there is a folder a few steps under AppData named Subversion which when not present and properly configured, shows the aforementioned message.
The ASP.NET site is running under the account "NetworkService" whose AppData folder I cannot find. I was planning to copy & paste the Subversion folder, as it's not easy to do an actual log in as NetworkService.
How can I proceed using NetworkService so that the "svn info" can also proceed?
Thanks in advance--
FYI: Using SharpSvn as a wrapper. Doubt that matters, but there you go
add this line before you authenticate and or perform any svn event.
client.LoadConfiguration(Path.Combine(Path.GetTempPath(), "Svn"), true);
I have a production website that, once built in TFS is re-deployed and updated using xcopy. The entire site (excluding the root directory) it deleted then the new site copied in. This works well.
We use a 3rd party charting package that creates images at runtime and then renders a link to them. In order to do this it needs write permissions to a browsable folder.
Unfortunately, every time we update the website the write permissions of IIS_USRS is lost. Is there any way to retain this?
I guess it depends on what operating system the server is running, and whether you are building on the same server as you're deploying to, or a remote one.
The simplest thing to do is to put your xcopy command into a batch file, and include something like the following after the xcopy:
cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C
Or a more up to date option (I've not used this, so my parameters may be off):
icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M
Basically, either of those should give the user account that the site is running under modify (change) rights in the folder specified. This should be in addition to any existing rights on the folder, there are modifiers or switches to replace the existing rights.
If you are deploying to a remote server, you'll need some mechanism to run commands on there, we've found that PSExec works a treat (part of the PS tools from SysInternals).
SO ... here is the scenario ... i have a workflow on a document library that copies a file to a windows directory ... this workflow is set to be started at the time when a new item is added to the document library ... so everything works fine when you are manually uploading files to the doc library ... but the problem occurs when we use emails to populate the doc library instead of the manual uploading of files.
When an email is received ... the workflow starts successfully and runs properly (i have kept workflow history entries to check every section of code is being executed or not) ... the workflow stops when the section where the file is being copied to the windows folder is reached.
I basically think this is a problem with the permissions or access issues. Because when we upload the file manually (i.e. from doc library > upload) everything works fine. But maybe there is some other permission set which is used while an email is received by the doc library ... i have tried by assigning permissions to "Everyone" on the windows folder ... but no luck...
Can someone let me know which windows user account is used when an email is received by a document library? (i think its the IIS default account - but isnt it included in Everyone?? )
One solution which i can devise in my mind is that for the file transfer to the windows folder i should use temporary impersonation for the specific code segment (which writes the doc library file to windows folder) but any suggestions are welcome.
P.S. I dont have access to the server right now so i can only devise approaches in my mind ... cant test them right nw... so it would be good to have all suggestions u have so that once i get the access i can try all stuff :D
This is a well known situation. The system does not know who sent the email so it cannot impersonate a user it has no knowledge about.
Depending on which version of SharePoint you are running, the workflow may not start at all or it may start under the account that published the workflow.
For details see this Microsoft Support Article.