SonarQubeAnalyze: ERROR: save config file 'FileBasedConfig[Z:\.config\jgit\config]' after upgrade to SonarQube 8.5

After we updated our SonarQube Server from version 8.2 to 8.5, the SonarQubeAnalyze Pipeline Task on our on-premise Azure DevOps 2020 server prints the following error logs:

##[error]ERROR: Cannot save config file 'FileBasedConfig[Z:\.config\jgit\config]'
java.io.IOException: Creating directories for Z:\.config\jgit failed
	at org.eclipse.jgit.util.FileUtils.mkdirs(FileUtils.java:411)
ERROR: Cannot save config file 'FileBasedConfig[Z:\.config\jgit\config]'
java.io.IOException: Creating directories for Z:\.config\jgit failed
	at org.eclipse.jgit.util.FileUtils.mkdirs(FileUtils.java:411)
##[error]at org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:130)
	at org.eclipse.jgit.storage.file.FileBasedConfig.save(FileBasedConfig.java:219)
	at org.eclipse.jgit.util.FS$FileStoreAttributes.saveToConfig(FS.java:735)
	at org.eclipse.jgit.util.FS$FileStoreAttributes.lambda$4(FS.java:424)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
	at org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:130)
	at org.eclipse.jgit.storage.file.FileBasedConfig.save(FileBasedConfig.java:219)
	at org.eclipse.jgit.util.FS$FileStoreAttributes.saveToConfig(FS.java:735)
	at org.eclipse.jgit.util.FS$FileStoreAttributes.lambda$4(FS.java:424)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

We use SonarQubeAnalyze 4.17.0.

Thanks in advance.

I get the same error using the zipped trial version and running the Gradle sonarqube task. For me, it’s pointing to an old drive that is no longer connected, but I don’t know where SonarQube is reading the drive setting.

I fixed my issue by updating my %HOMEDRIVE% Windows variable to a valid drive. It was pointing to a non-existent drive after my company’s IT group migrated our home drive locations and didn’t update our AD profiles.