First, here is how your s3 configuration usually looks like
The <path>pathPrefix</path> controls which directory under your bucket will artifactory put all your binaries. By default, the value is filestore. This means it should look like this:
/filestore/ad/ad0c52f0389d1daf6ba964e60859707e
However, if you are getting 500 binary providers has no content for Error Message during downloading, while having no issues deploying any binaries, chances are that you have a mismatch in the pathPrefix. You can also find other reasons for the 500 binary providers has no content errors here (https://jfrog.com/help/r/artifactory-what-to-do-when-you-get-a-binary-provider-has-no-content-for-error-message/artifactory-what-to-do-when-you-get-a-binary-provider-has-no-content-for-error-message)
A quick test to find out the mismatch is to deploy a dummy file. Find out the checksum ( sha1) of the dummy files in artifactory UI . Try locate that file in your s3 bucket:
aws s3 ls s3://your-bucket --recursive | grep your-search | cut -c 32-
You might find out that the dummy binaries are put at a different location than the other existing binaries. You can move all existing binaries to the correct path.
One more thing to notice is that tomcat slash encoding could also cause a mismatch on the binary path.
By default, the slash encoding is not turned on. So “/” could have been treated as a path by the bucket.
For example, you would expect the following path with default settings:
/filestore/ad/ad0c52f0389d1daf6ba964e60859707e
Yet, the actual path on the bucket would be under a folder named “/”:
<provider id="s3-storage-v3" type="s3-storage-v3"> <endpoint>s3.amazonaws.com</endpoint> <bucketName>bucketName</bucketName> <path>pathPrefix</path> <region>s3Region</region> <identity>yourIdentity</identity> <credential>yourCredentials</credential> </provider>
The <path>pathPrefix</path> controls which directory under your bucket will artifactory put all your binaries. By default, the value is filestore. This means it should look like this:
/filestore/ad/ad0c52f0389d1daf6ba964e60859707e
However, if you are getting 500 binary providers has no content for Error Message during downloading, while having no issues deploying any binaries, chances are that you have a mismatch in the pathPrefix. You can also find other reasons for the 500 binary providers has no content errors here (https://jfrog.com/help/r/artifactory-what-to-do-when-you-get-a-binary-provider-has-no-content-for-error-message/artifactory-what-to-do-when-you-get-a-binary-provider-has-no-content-for-error-message)
A quick test to find out the mismatch is to deploy a dummy file. Find out the checksum ( sha1) of the dummy files in artifactory UI . Try locate that file in your s3 bucket:
aws s3 ls s3://your-bucket --recursive | grep your-search | cut -c 32-
You might find out that the dummy binaries are put at a different location than the other existing binaries. You can move all existing binaries to the correct path.
One more thing to notice is that tomcat slash encoding could also cause a mismatch on the binary path.
By default, the slash encoding is not turned on. So “/” could have been treated as a path by the bucket.
For example, you would expect the following path with default settings:
/filestore/ad/ad0c52f0389d1daf6ba964e60859707e
Yet, the actual path on the bucket would be under a folder named “/”:
$ ls / $ cd / && ls filestore/ $ cd filestore/ && ls ad/ 0e/ …The solution is to add the following javaOpts in artifactory system.yaml
shared: extraJavaOpts: "-Xms512m -Xmx2g -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH= true "