ARTIFACTORY: What to Do When You Get a Binary provider has no content for Error Message

Introduction 
If downloads from Artifactory fail with 500 status code, and we observe an error like this:

artifactory-service.log:
2025-12-14T09:12:29.370Z [jfrt ] [ERROR] [28c602a6aa83c29b] [.r.ArtifactoryResponseBase:195] [ttp-nio-8081-exec-10] - Sending HTTP error code 500: Binary provider has no content for '821bfb949d11f9fb7bdd9223ebcce89ca6dd6826'

artifactory-request.log:
2025-12-14T09:12:29.373Z|28c602a6aa83c29b|x.x.x.x|admin|GET|/example-repo-local/Archive.zip|500|-1|478863|10|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

This error means Artifactory has the record of a file in its database, but Artifactory can’t locate the actual physical binary file in the filestore.
Note:
 
The binary file is named after the SHA-1 value.


Steps To Resolve

Search for the file: Look in the filestore for the SHA-1 listed in the error - in our case 821bfb949d11f9fb7bdd9223ebcce89ca6dd6826. If we’re using multiple shards - check in all shards, and ensure they are all available.
If the file is missing:
1. Local Repo: Restore the file from a backup or delete and rebuild it
2. Remote-Cache Repo: delete the artifact from Artifactory (via UI or REST API) and pull it again from remote
If the file exists - continue troubleshooting:
1. Check Permissions: Verify that the artifactory user has full ownership and read/write permissions for the entire filestore and for the missing binary specifically.
2. Check binarystore.xml to confirm there are no misconfigurations:
  - For NFS:
    Verify that the NFS is correctly mounted on all nodes and that they see the same content.
  - For Object Storage - S3 / GCS / Azure blob, etc:
    Verify correct configurations pointing to the correct bucket.
  - For Object Storage using Eventual in an HA cluster
    The Eventual mechanism uses the local file system of the node to store the binary temporarily before uploading it to the main Object Storage bucket. Until uploaded to the bucket, binaries in the eventual directory can be served upon download requests.
    In an HA cluster, the binarystore.xml needs to be configured with the respective cluster template, which includes a “sharding-cluster” binary provider to ensure the eventual directory on each node can be accessed by other nodes in the cluster.

Note: 

JFrog officially recommends using the Direct approach with Object Storage - meaning the binaries are uploaded directly to the bucket. With this configuration, there is no need for the “sharding-cluster” in the cluster template, as all binaries are served directly from the shared bucket.


The Last Resort: If the binary is completely gone and cannot be restored, delete the artifact (via UI or API) to avoid referencing it in the database.

To sum it up, the data in the database needs to match the data in the filestore - either by restoring the missing binary, or by deleting the artifact metadata from the database.

For any further assistance, please contact JFrog Support.

Additional Read:
Integrity Checks - https://jfrog.com/help/r/how-to-check-integrity-of-binaries-in-artifactory-database-against-filestore/how-to-check-integrity-of-binaries-in-artifactory-database-against-filestore
Artifactory Backups - https://jfrog.com/whitepaper/best-practices-for-artifactory-backups-and-disaster-recovery/