I am trying to upload Snapshot.jar file to nexus and I am getting this error.
Return code is: 400, ReasonPhrase: Detected content type [application/x-sh], but expected [application/java-archive]:
When I change the file to tar extension successfully uploaded. Do you have any idea about this error?
Thank you,
The uploaded jar is being detected as a shell script. Is this a spring boot jar by any chance? If so, this is a known issue. Disable file content validation in the hosted repository in order to work around it.
Thank you so much for your support. Mentioned solution works.
@rseddon why not make it configuarable, whitelist some mime types etc.
I’ve seen in DefaultMimeSupport that you derive the content-type using Apache Tika based on the file’s content and filename.
For an executable jar, Tika indeed returns application/x-sh. But IHMO this is wrong, at least in the context of Nexus Repository. Yes, an executable jar starts with a shell script, but it’s just a wrapper to facilitate execution but doesn’t change the primary nature of the file as a Java archive. The file is primarily a JAR file and should be treated as such (application/java-archive).
Can you reference the “known issue” here? Is there a ticket open for this?
Any chance there will be another solution for this, instead of disabling content type validation completly ?
I’ve stumbled on similar issue. One of our Maven builds generated maven-metadata.xml.sha1 file with a content of 070701ed16f9c4417945c76928598ba49c0b03cc . This naturally produced this error message on artifact upload:
[2026-07-15T06:33:20.716Z] [WARNING] Failed to upload checksum to com/company/clients/0.7.25-SNAPSHOT/maven-metadata.xml.sha1
[2026-07-15T06:33:20.716Z] org.apache.http.client.HttpResponseException: status code: 400, reason phrase: Detected content type [application/x-cpio], but expected [text/plain]: com/company/clients/0.7.25-SNAPSHOT/maven-metadata.xml.sha1 (400)
I.e. it uploaded refreshed maven-metadata.xml but failed to deliver refreshed maven-metadata.xml.sha1. After this, every other Maven build for this artifact failed with the following message:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.1.4:deploy (default-deploy) on project clients: Failed to retrieve remote metadata com.company:clients:0.7.25-SNAPSHOT/maven-metadata.xml: Could not transfer metadata com.company:clients:0.7.25-SNAPSHOT/maven-metadata.xml from/to our.nexus.repo (https://our.nexus.repo/repository/maven-snapshots/): Checksum validation failed, expected '3887cae7e4188486e1e512d03bc523a640abef3d' (REMOTE_EXTERNAL) but is actually '070701ed16f9c4417945c76928598ba49c0b03cc' -> [Help 1]
Note, that 070701 (and 070702) is magic MIME string for CPIO package manager, so a file was identified correctly, however, I don’t think Nexus Manager should perform MIME sniffing at all. Or at least not for Maven metadata files. They should be accepted and served as plain text files in all cases. Else this is not only prone to errors but could potentially be security issue.
P.S. There are other files in MIME magic file which can be detected as non-plain text.