SonarQube Server Enterprise 2025.1 LTA (sonarqube-2025.1.2.108896)
Deployment by zip
SonarScanner 5.0.1.3006
Oracle Corporation (64-bit)
Linux 5.4.0-186-generic amd64
build-wrapper, version 6.62.2 (linux-x86_64)
CPP cfamily plugin used
There is an issue with symbolic links from a “src” folder of an external source code library to the “source” folder that we typically use in our sonar.sources property. For example, we see this warning in sonar scanner output on Jenkins job.
WARN: File ‘/VS/ICCP/V/mmslite/psi/mmslite/asn1/source/are_int.c’ is ignored. It is a symbolic link targeting a file that does not exist.
When we analyze the symbolic link on cmd line, then we see the target of the symlink is existing and accessible:
build-ubuntu:/VS -> ls -l /VS/ICCP/V/mmslite/psi/mmslite/asn1/source/are_int.c
lrwxrwxrwx 1 hudson psi 33 Jun 6 19:54 /VS/ICCP/V/mmslite/psi/mmslite/asn1/source/are_int.c -> ../../../../mmslite/src/are_int.c
build-ubuntu:/VS -> ls -l /VS/ICCP/V/mmslite/mmslite/src/are_int.c
-rw-rw-r-- 1 hudson psi 13484 Jun 6 19:54 /VS/ICCP/V/mmslite/mmslite/src/are_int.c
We guess the warning/problem for the scanner comes from the relative symbolic link “../../../../mmslite/src/are_int.c”; probably the scanner tries to look for target from root directory ($WORKSPACE in Jenkins) instead of using a “realpath” for the symbolic link which would give the real path name of the symlink target.
Could you please analyze it? It would really help us if this would work properly.
Thank you.
We are seeing the same problem (or error message at least) after upgrading from sonar-scanner-5.0.1.3006-linux to sonar-scanner-7.1.0.4889-linux-x64, e.g.:
23:50:32.164 WARN File '/actual/path/to/a/valid/symlink' is ignored. It is a symbolic link targeting a file that does not exist.
In this case, the symlink points several levels up (../../../../../../theActualFile) however it is a valid symlink (per ls -L). We are running on RHEL 8.10.
This error should have been resolved with SONAR-24784, which was included in the sqs-2025.3version.
Unfortunately, it has not been fixed in the current LTA.
Well, 2025.4.2 is newer than 2025.3 so it should contain the fix. If you have more deatils to share (specific log messages, etc.) it would be great to see them.
sure, here ist the output from the sonarqube analysis in gitlab
11:35:29.665 INFO Auto-configuring with CI ‘Gitlab CI’ 11:35:29.672 INFO Load active rules 11:35:29.997 INFO Load active rules (done) | time=324ms 11:35:30.000 INFO Load analysis cache 11:35:30.483 INFO Load analysis cache | time=483ms 11:35:30.623 INFO Branch name: feature/sonar-analysis 11:35:30.639 INFO Preprocessing files… 11:35:31.832 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/animations’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.833 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/cdk’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.834 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/common’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.836 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/compiler’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.836 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/core’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.837 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/elements’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.837 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/forms’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.838 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/platform-browser’ is ignored. It is a symbolic link targeting a file that does not exist. 11:35:31.838 WARN File ‘/builds/blabla/customers/blubblub/node_modules/@angular/platform-browser-dynamic’ is ignored. It is a symbolic link targeting a file that does not exist.
After looking into it, it is expected that this error message:
Still gets raised. The ticket in this thread (Jira) stops raising the warning when the symlink is using a relative path, and is not located in the project basedir. I’m not sure this is the case for you.
I assume this is a symlink. Does the linked file exist?
To confirm if the targeted file exists and whether a symlink is broken in Linux, use the following command:
ls -l /builds/blabla/customers/blubblub/node_modules/@angular/animations
If you want to follow the symlink and check if the actual target exists, use: