After updating Wonderware update 2 to update 3 ,i am facing following error.
Error: Failed to deploy <Platform_Name>: Access Denied, Invalid Credentials
Issue is fix by enabling "everyone permissions" for anonymous users. To enable these permissions, go to: Local Security Policy > Local Policies > Security Options > Network Access: Let everyone permissions apply to anonymous.
Related
We are using the Sonarcloud plugin in Azure DevOps. Suddenly, we get the following error in our build pipeline:
##[error]ERROR: Error during SonarScanner execution ERROR: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization'
properties, the 'SONAR_TOKEN' environment variable, or contact the
project administrator ERROR: ERROR: Error during SonarScanner
execution ERROR: Project not found. Please check the
'sonar.projectKey' and 'sonar.organization' properties, the
'SONAR_TOKEN' environment variable, or contact the project
administrator ERROR:
##[error]The SonarScanner did not complete successfully The SonarScanner did not complete successfully
##[error]09:51:19.094 Post-processing failed. Exit code: 1 09:51:19.094 Post-processing failed. Exit code: 1
##[error]The process '/usr/bin/dotnet' failed with exit code 1
Authentication is done with ServiceConnections and the token verification is still valid. I also tried to use a new SonarCloud Authentication token for the ServiceConnection. We haven't changed anything in the infrastructure or on the SonarCloud platform, and it was working fine 5 days ago.
I tried to set Administration / Permission / Execute Analysis to "Anyone" (also checked all users) without success.
Any ideas?
The PAT (Personal Access Token) has expired.
Create one in Azure DevOps and add it Administration / Organization settings / Azure DevOps connectivity management / New Personal Access Token
Note: I had to abandon my Pull-Request and create a new one after using the new PAT.
I would like to see this more clearly indicated on the platform (e.g. by an info bar at the top of the platform)
I am using company intranet to login to GitHub within VS Code but it fails with following message:
Sign in failed: FetchError: request to https://vscode-auth.github.com/token?code=******&state=*****-*****-***** failed, reason: unable to get local issuer certificate
If I remove the company proxy setting, it will show me another failure message:
Failure to connect with proxy <my company proxy>.
This likely means that although I had removed the proxy from Windows proxy settings, I could still not bypass it because somewhere else it still requires it.
What am I doing wrong?
VS Code has a builtin extension GitHub Authentication that manages creation of a GitHub Personal Access Token and automatic logins.
However, if you are using more then one GitHub account, the extension might try generating a PAT for the wrong account, resulting in an access denied.
Logon failed, use ctrl+c to cancel basic credential prompt.
remote: Permission to MyAccount/repo.git denied to OtherAccount.
fatal: unable to access 'https://github.com/MyAccount/repo.git/': Failure when receiving data from the peer
The remedy is to abort the web session started by GitHub Authentication, and then in the message bar of VSCode, click on GitHub Authentication to trigger the manual failback PAT handling.
First make sure you have a current PAT created for repo access for MyAccount on GitHub. Then copy the PAT and enter it VSCode when prompted.
Anyone successfully using gcsfuse?
I've tried to remove all default permission to the bucket,
and setup a service account:
gcloud auth activate-service-account to activate serviceaccname
And then running:
gcsfuse --debug_gcs --foreground cloudbuckethere /backup
gcs: Req 0x0: -> ListObjects() (307.880239ms): googleapi: Error 403: xxxxxx-compute#developer.gserviceaccount.com does not have storage.objects.list access
It's weird that it's complaining that the user xxxxx-compute which is not my activated service account:
gcloud auth list
Does show my current service account is active...
I've also granted admin owner, admin object owner, write object, read object to the bucket to my serviceaccname.
If I grant xxxxx-compute to my bucket with all the permission, including legacy permissions, listing seems to work. but writing any file to the directory failed with:
googleapi: Error 403: Insufficient Permission, insufficientPermissions
Anyone have any luck?
I found a solution, not sure if this is a good solution, but it works.
Setup a service account and download the JSON file.
Grant access to the bucket as bucket admin with the above service account name.
Then run add into environment variable, pointing to the path to the service JSON file.
GOOGLE_APPLICATION_CREDENTIALS=/path-to-json/gcloud.json gcsfuse --debug_gcs --foreground bucketname /path-to-mount
Also take note that it may uses large amount of space in the tmp directory by default. Adding flag:
... --temp-dir=/someotherpath
Will really helps if you have limited space in /tmp.
Crystalreportviewer.processreponse locks mxsqlserver database account with error SSPI handshake exception,
Message
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure.
Message
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Message
Error: 17806, Severity: 20, State: 14.
I've had a similar issue trying to deploy a Web Portal for Crystal Reports and the user that was connecting to the Web Portal via the browser did not have security permissions on the SQL database. For me it was as simple as adding the user to the security tab in the SQL Server management console. You might want to check that out first. If not, please check the steps outlined in this link. The troubleshooting steps in the article may help you resolve your issue.The ultimate solution for this user was to check his local security policies to see if any essential rights had been denied. He tried to connect to a share on the server. The connection to a share failed, and he realized the account did not have "access this computer from the network" rights or was missing other domain or network level permissions.
Hope that helps,
Chris