We’re getting a sudden issue where the sonar-scanner fails due to an authorization error. The SONAR_TOKEN used was set to never expire and was last used 3 days ago and was working then. No details have been changed both within Sonarqube and in the pipeline but it just started failing.
Has there been a recent update to Sonarqube configuration that I am unaware of?
I have even recreated the access token and tried to use scoped organization tokens for analysis but to no avail.
However, when I try to rerun the job it does show that the token has been used despite it failing.
Key info
ALM used: Gitlab
CI system used: Gitlab
Scanner command used when applicable:
Languages of the repository: typescript
Command: sonar-scanner -Dsonar.clearCache=true
Project is private
SONAR_TOKEN is set within the cicd variables
SONAR_HOST_URL is also set within the cicd variables as https://sonarcloud.io
Error
13:07:32.325 INFO Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
13:07:32.327 INFO Project root configuration file: /**********/sonar-project.properties
13:07:32.334 INFO SonarScanner CLI 8.0.1.6346
13:07:32.336 INFO Linux 6.6.87.2-microsoft-standard-WSL2 amd64
13:07:32.813 INFO Communicating with SonarQube Cloud
13:07:32.814 INFO JRE provisioning: os[linux], arch[x86_64]
13:07:41.532 INFO Starting SonarScanner Engine...
13:07:41.532 INFO Java 21.0.9 Eclipse Adoptium (64-bit)
13:07:42.141 INFO Load global settings
13:07:42.536 INFO Load global settings (done) | time=391ms
13:07:42.580 INFO Server id: 1BD809FA-AWHW8ct9-T_TB3XqouNu
13:07:42.689 INFO Loading required plugins
13:07:42.689 INFO Load plugins index
13:07:42.754 INFO Load plugins index (done) | time=64ms
13:07:42.754 INFO Load/download plugins
13:07:45.339 INFO Load/download plugins (done) | time=2584ms
13:07:45.455 INFO Loaded core extensions: sca, architecture, a3s
13:07:45.561 INFO Process project properties
13:07:45.571 INFO Project key: gitmsd_web-msd
13:07:45.571 INFO Base dir: /*******
13:07:45.571 INFO Working dir: /*********
13:07:45.583 INFO Load project settings for component key: 'gitmsd_web-msd'
13:07:45.979 INFO Load project settings for component key: 'gitmsd_web-msd' (done) | time=403ms
13:07:45.985 INFO Found an active CI vendor: 'Gitlab CI'
13:07:46.202 INFO Check ALM binding of project 'gitmsd_web-msd'
13:07:46.396 INFO Detected project binding: BOUND
13:07:46.396 INFO Check ALM binding of project 'gitmsd_web-msd' (done) | time=194ms
13:07:46.398 INFO Load branch configuration
13:07:46.400 INFO Auto-configuring pull request 798
13:07:47.046 ERROR Not authorized or project not found. Please check the 'SONAR_TOKEN' environment variable, the 'sonar.projectKey' and 'sonar.organization' properties, or contact the project administrator to verify the token's permissions.
13:07:47.378 INFO EXECUTION FAILURE
13:07:47.379 INFO Total time: 15.055s
Configuration
below is the configuration of the sonar-project.properties
# This is the name and version displayed in the SonarCloud UI.
#sonar.projectName=web-msd
#sonar.projectVersion=1.0
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8
sonar.sources=services, packages
sonar.projectKey=gitmsd_web-msd
sonar.organization=gitmsd
sonar.exclusions= \
**/node_modules/**, \
**/tests/**, \
**/**.spec.ts, \
**/**.test.ts, \
**/**.json, \
**/dist/**, \
**/**.yml, \
sonar.qualitygate.wait=true
sonar.qualitygate.timeout=300
sonar.tests=tests
Steps to reproduce
Create an access token with a user who is in the owner group of a project
Add that token as a SONAR_TOKEN environment variable
Run sonar-scanner -Dsonar.clearCache=true through the pipeline using the above configuration.
Get above error
Please let me know if you require any further information. Thanks!
I’ve added some debug logs and I will post below just in case they’re of use
14:05:20.608 DEBUG --> GET https://sonarcloud.io/api/alm_integration/show_pullrequest?project=gitmsd_web-msd&pullrequestKey=798
14:05:20.926 DEBUG <-- 401 https://sonarcloud.io/api/alm_integration/show_pullrequest?project=gitmsd_web-msd&pullrequestKey=798 (318ms, unknown-length body)
14:05:20.931 DEBUG Reporting scanner status
14:05:20.972 DEBUG Scanner status payload: {"project":"gitmsd_web-msd","organization":"gitmsd","status":"FAILURE","durationMs":1192,"context":"{\"scanner\":{\"type\":\"ScannerCLI\",\"version\":\"8.0.1.6346\",\"engineVersion\":\"13.2.0.3890\",\"useNewEntryPoint\":true},\"ci\":{\"name\":\"Gitlab CI\"},\"os\":{\"name\":\"Linux\",\"arch\":\"x86_64\"},\"runtime\":{\"javaVersion\":\"21.0.9\",\"javaVendor\":\"Eclipse Adoptium\"},\"memory\":{\"maxHeapBytes\":12591300608,\"peakUsedHeapBytes\":180987176,\"physicalMemoryBytes\":50348503040},\"failure\":{\"stacktrace\":\"org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.scanner.scan.branch.BranchConfiguration]: Factory method \\u0027provide\\u0027 threw exception with message: Not authorized or project not found. Please check the \\u0027SONAR_TOKEN\\u0027 environment variable, the \\u0027sonar.projectKey\\u0027 and \\u0027sonar.organization\\u0027 properties, or contact the project administrator to verify the token\\u0027s permissions.\\n\\tat org.springframework.beans.factory.support.SimpleInstantiationStrategy.lambda$instantiate$0(SimpleInstantiationStrategy.java:183)\\n\\tat org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiateWithFactoryMethod(SimpleInstantiationStrategy.java:72)\\n\\tat org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:152)\\n\\tat org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653)\\n\\tat org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:645)\\n\\tat org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1362)\\n\\tat org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1194)\\n\\tat org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:565)\\n\\tat org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:525)\\n\\tat org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:333)\\n\\t... 132 frames omitted\\nCaused by: Not authorized or project not found. Please check the \\u0027SONAR_TOKEN\\u0027 environment variable, the \\u0027sonar.projectKey\\u0027 and \\u0027sonar.organization\\u0027 properties, or contact the project administrator to verify the token\\u0027s permissions.\\n\"}}"}
14:05:20.973 DEBUG --> POST https://api.sonarcloud.io/analysis/scanner-status (2661-byte body)
14:05:21.127 DEBUG <-- 204 https://api.sonarcloud.io/analysis/scanner-status (153ms, 0-byte body)
14:05:21.128 DEBUG Scanner status reported
14:05:21.148 DEBUG Cleanup org.eclipse.jgit.util.FS$FileStoreAttributes$$Lambda/0x0000796f503b9500@4483d35 during JVM shutdown
14:05:21.153 ERROR Not authorized or project not found. Please check the 'SONAR_TOKEN' environment variable, the 'sonar.projectKey' and 'sonar.organization' properties, or contact the project administrator to verify the token's permissions.
Thanks for including the information from the logs, the debug output actually points somewhere different than the SONAR_TOKEN itself.
Looking at the debug log, the specific call that fails is:
GET /api/alm_integration/show_pullrequest?project=gitmsd_web-msd&pullrequestKey=798 → 401
That’s the ALM/pull-request lookup call, and it’s a distinct endpoint from the analysis calls in the same log. The scanner-status POST right after it succeeded using the same request credentials, which rules out an invalid or expired SONAR_TOKEN. If the token itself were bad, every call would fail the same way, not just this one. That points to an authorization problem specific to the merge request / DevOps platform integration lookup for this project, rather than the token used to run the analysis.
GitLab merge request decoration in SonarQube Cloud is tied to the access token used when your GitLab group was originally connected to SonarQube Cloud, and it’s recommended that token belong to a dedicated technical GitLab account rather than an individual (see GitLab CI). If that connection’s underlying credential expired, was revoked, or the account behind it lost access/role on the relevant GitLab group or project, the MR lookup can start failing with a 401 like this even though your own SONAR_TOKEN is completely valid. This would also explain why recreating your token and trying a Scoped Organization Token had no effect, since those aren’t the credential involved in this specific call. For more on how decoration ties into analysis, see Pull request analysis.
To narrow this down, could you check the following:
Which GitLab account was used to originally connect the gitmsd organization/group to SonarQube Cloud, and is that account still active with unchanged access to the relevant GitLab group/project (not removed, downgraded, or requiring
re-authentication via SSO)?
Does analysis succeed on a regular branch pipeline (e.g., main), rather than a merge-request pipeline? That would confirm the failure is isolated to PR/MR decoration rather than analysis auth in general.
Has anything changed recently around that account’s token, for example, a GitLab personal access token nearing or hitting its expiration date?
Which token type is currently assigned for analysis, a personal access token or a Scoped Organization Token? See Managing Scoped Organization Tokens for how those are scoped and managed if you want to double check permissions there.
If it turns out the GitLab account/token behind the original group connection has expired or lost access, re-establishing that connection with a valid technical account credential should resolve this without needing further changes to your pipeline’s SONAR_TOKEN.