SonarScanner has started failing with AccessDeniedException

[phil-davis]

Template for a good new topic, formatted with Markdown:

• ALM used - GitHub

• CI system used - drone

• Scanner command used when applicable
  Using docker sonarsource/sonar-scanner-cli

• Languages of the repository - PHP

• Only if the SonarCloud project is public, the URL
  docs: remove PHPdoc of non-existent parameter by phil-davis · Pull Request #41256 · owncloud/core · GitHub
  Drone CI

• Error observed

Status: Downloaded newer image for sonarsource/sonar-scanner-cli:latest
INFO: Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO: Project root configuration file: /drone/src/sonar-project.properties
INFO: SonarScanner 5.0.1.3006
INFO: Java 17.0.11 Alpine (64-bit)
INFO: Linux 5.15.0-107-generic amd64
INFO: SONAR_SCANNER_OPTS=-Xdebug
INFO: User cache: /opt/sonar-scanner/.sonar/cache
INFO: Analyzing on SonarCloud
...
ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Failed to preprocess files

Caused by: java.nio.file.AccessDeniedException: /drone/src/data

• Steps to reproduce
  Run the CI again!

• Potential workaround

I tried adding data/** to sonar.exclusions but still get the same error.

This problem started “recently”. But I am not aware of any changes to CI settings or SonarCloud versions. For example, this is a good CI run from May 16:
https://drone.owncloud.com/owncloud/core/39935/29/9

So I am struggling to understand what changed to cause this problem.

[Colin]

Hey @phil-davis

I’m suspicious this has to do with a change to the sonar-scanner-cli docker image no longer running as root

SonarScanner CLI Docker Image v10.0.1.1390_5.0.1: clear your runner caches

Dear Community, We just released the SonarScanner CLI Docker Image v10.0.1.1390_5.0.1 This version includes a significant change that may impact some users: SCANDOCKER-2 Create a scanner-cli user and remove ROOT access If you encounter errors in your pipeline, we recommend clearing the runner caches. Due to the user change, the new scanner-cli user cannot access cached data previously created with the ROOT user. We apologize for any inconvenience this may cause. Please do not hesitate to r…

(I’m not suggesting here that clearing caches will fix this issue, just to provide more context).

Could you try using sonarsource/sonar-scanner-cli:5 instead of sonarsource/sonar-scanner-cli:latest to see if this is what’s causing it?

[phil-davis]

That worked:

chore: use sonarsource/sonar-scanner-cli:5 in CI

https://drone.owncloud.com/owncloud/core/39948/29/9

Note: I excluded the data dir but that was not enough to fix the problem

chore: exclude data dir from sonar-cloud CI processing

[phil-davis]

Is there a way to completely prevent the scanner from even trying to read/traverse a directory?

Just putting data/** into sonar.exclusions does not work. I suppose that the scanner still tries to traverse the whole directory tree, and as it finds each item, it checks if the item is excluded.

But I need it to completely ignore the fact that it can’t even open the data directory to read it.

[Colin]

@phil-davis

/drone/src/data

Can you help me understand what this directory is? Is it a part of your source code? Does your “real” source code sit in another directory in /drone/?

[phil-davis]

ownCloud stores its data (uploaded files) in that data directory, it is not source code, it is not files from the repo. During running of tests in CI there will end up being some test user data in there. The CI uses a real Apache server, and that data directory and its contents will be owned by the Apache server “user” (something like www-data), whereas the the code in drone/src/lib etc. will be owned by whatever user is cloning the GitHub branch into the drone docker environment.

I guess it is a bit unfortunate that the data directory “pollutes” the drone/src structure. But if there is xsome way to tell SonarCloud to really ignore it, then that would be great.

[nathalylopez (Nathaly López)]

Thanks Colin.
I was facing a similar issue and it worked after changing to sonarsource/sonar-scanner-cli:5

This was the error I got, for reference:

INFO: ------------------------------------------------------------------------
INFO: Total time: 15.997s
INFO: Final Memory: 7M/34M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.ProjectLock
	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:66)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:678)
	at org.sonar.core.platform.ComponentContainer.getComponentByType(ComponentContainer.java:282)
	at org.sonar.scanner.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:156)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:150)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:126)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:81)
	at org.sonarsource.scanner.cli.Main.main(Main.java:62)
Caused by: java.lang.IllegalStateException: Failed to create work directory
	at org.sonar.scanner.scan.ProjectLock.<init>(ProjectLock.java:39)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:145)
	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:342)
	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)
	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)
	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)
	at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
	at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
	at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699)
	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647)
	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:64)
	... 22 more
Caused by: java.nio.file.AccessDeniedException: /workspace/.scannerwork
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:397)
	at java.base/java.nio.file.Files.createDirectory(Files.java:700)
	at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:807)
	at java.base/java.nio.file.Files.createDirectories(Files.java:793)
	at org.sonar.scanner.scan.ProjectLock.<init>(ProjectLock.java:36)
	... 37 more

[pierreiexec (Pierre Jeanjacquot)]

I use sonarsource/sonar-scanner-cli (docker) in my CI, things worked well until the latest release when I started to have an error.

I rolled back to sonarsource/sonar-scanner-cli:5 to avoid the issue until.

Here is the error message I get with current sonarsource/sonar-scanner-cli:latest (image digest: sha256:866f32d840223c8178778ed7a28556fbe3cac00dd74aac8290d7af93debcfcb2)

INFO: Working dir: /drone/src/.scannerwork

INFO: ------------------------------------------------------------------------

INFO: EXECUTION FAILURE

INFO: ------------------------------------------------------------------------

INFO: Total time: 3.437s

INFO: Final Memory: 13M/68M

INFO: ------------------------------------------------------------------------

ERROR: Error during SonarScanner execution

java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.ProjectLock

	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:52)

	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:678)

	at org.sonar.core.platform.ComponentContainer.getComponentByType(ComponentContainer.java:277)

	at org.sonar.scanner.bootstrap.ScannerContainer.doBeforeStart(ScannerContainer.java:175)

	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:121)

	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)

	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:131)

	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)

	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)

	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:60)

	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:54)

	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)

	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)

	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

	at java.base/java.lang.reflect.Method.invoke(Method.java:568)

	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)

	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)

	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)

	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)

	at org.sonarsource.scanner.cli.Main.execute(Main.java:126)

	at org.sonarsource.scanner.cli.Main.execute(Main.java:81)

	at org.sonarsource.scanner.cli.Main.main(Main.java:62)

Caused by: java.lang.IllegalStateException: Failed to create work directory

	at org.sonar.scanner.scan.ProjectLock.<init>(ProjectLock.java:25)

	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)

	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)

	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)

	at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:145)

	at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:342)

	at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)

	at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)

	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)

	at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)

	at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)

	at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699)

	at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647)

	at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:50)

	... 22 more

Caused by: java.nio.file.AccessDeniedException: /drone/src/.scannerwork

	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)

	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)

	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)

	at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:397)

	at java.base/java.nio.file.Files.createDirectory(Files.java:700)

	at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:807)

	at java.base/java.nio.file.Files.createDirectories(Files.java:793)

	at org.sonar.scanner.scan.ProjectLock.<init>(ProjectLock.java:22)

	... 37 more

[Colin]

Thanks @pierreiexec. It’s interesting that you’re using Drone as well. I’m flagging this for some expert attention.

[benjamin.raymond]

Hi @phil-davis ,

We could reproduce your error by removing access rights on a subfolder owned by an user different than 1000 inside the source directory,

In your CI, you have to give read and write access to the mounted directory to user 1000. Please refer to our documentation to run the SonarScanner CLI in docker for more information.

But if there is xsome way to tell SonarCloud to really ignore it, then that would be great.

As of today, there is unfortunately no way to completely ignore a directory. We will discuss internally whether it makes sense to fail the analysis when a folder can’t be accessed

Hope this helps,
Benjamin

[phil-davis]

We will discuss internally whether it makes sense to fail the analysis when a folder can’t be accessed.

If the folder is excluded from analysis, and it can’t be accessed, then it seems sensible to me that the analysis should not fail.

[benjamin.raymond]

Hello @phil-davis ,

I’ve requalified the corresponding tickets from improvement to bug. SonarQube and SonarCloud will be updated with a fix to prevent the scanner from failing to read a completely excluded folder.

You can track the SonarQube ticket to follow updates (not the SonarCloud one as this one is private).