Configuring Blob Stores

What is a Blob Store?

The binary assets you download via proxy repositories, or publish to hosted repositories, are stored in the blob store attached to those repositories. In traditional, single node NXRM deployments, blob stores are typically associated with a local filesystem directory, usually within the sonatype-work directory.

For NXRM HA-C however, the blob store location must be:

  1. outside of the sonatype-work directory
  2. read-write accessible by all nodes
Caution: Sonatype has very specific guidelines on choosing an appropriate filesystem for blob stores in a NXRM HA-C environment.

Choosing a Type for your Blob Stores

NXRM HA-C stores blobs in shared storage, which can be either a shared file system or a cloud object store.  Here are some recommendations to consider when choosing where to store your blobs.  In general, file system blob stores may have better performance, but object store blob stores offer unbounded storage and convenience.  Cloud object stores perform better if you are also running NXRM in the cloud with the same cloud provider.


Do not copy or share the sonatype-work directory used by your Nexus Repository Manager nodes. Each node must be allowed to initialize its own private sonatype-work directory; data generated on first run is unique to each instance.

Your shared file systems, if File based, must exist outside of the sonatype-work directory.

Recommended Shared File Systems

NFS v4 is the recommended file system.  On Amazon Web Services (AWS), Elastic Filesystem (EFS) can be used as an NFS v4 server. Whatever the file system type, the blob store location must be outside of the sonatype-work directory and read/write accessible by all nodes.

NFS v4

The recommended settings for an NFS v4 server in /etc/exports:

/srv/blobstores 10.0.0.0/8(rw,no_subtree_check)

The recommended settings for mounting the NFS filesystem on each node:

defaults,noatime,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,vers=4.1


Versions of NFS older than v4 are not supported.

AWS Elastic Filesystem (EFS)

EFS acts as a limitless NFS v4 server and is an option if NXRM is running in AWS.   Clients should mount the EFS volume with the same settings as NFS v4.  Note that EFS performance will be lower than a dedicated NFS server.

Cloud Object Stores

Cloud object stores store your blobs using AWS S3. No shared file system is required if cloud object stores are used exclusively.

AWS Simple Storage Service (S3)

Blob stores can be configured to use AWS Simple Storage Service.

Blobs are stored in an S3 bucket by using AWS REST APIs over HTTP. Object PUTs use multi-part uploads of approximately 5MB chunks. Since HTTP traffic to S3 blobstores introduces more I/O latency across the network, it is recommended to use S3 only if NXRM is running on EC2 instances within AWS

When setting up a bucket for the S3 blob store:

  • NXRM will automatically apply a lifecycle rule to expire deleted content.
  • The bucket can use server-side encryption with KMS key management transparently.  Other methods of server side encryption are not supported.

The AWS user for accessing the S3 Blobstore bucket needs to be granted permission for these actions:

  • s3:PutObject
  • s3:GetObject
  • s3:DeleteObject
  • s3:ListBucket
  • s3:GetLifecycleConfiguration
  • s3:PutLifecycleConfiguration
  • s3:PutObjectTagging
  • s3:GetObjectTagging
  • s3:DeleteObjectTagging
  • s3:DeleteBucket
  • s3:CreateBucket
  • s3:GetBucketAcl ( used for problem diagnosis ) NEW IN 3.19.0 

Sample minimal policy where <user-arn> is the ARN of the AWS user and <s3-bucket-name> the S3 bucket name:

{
    "Version": "2012-10-17",
    "Id": "NexusS3BlobStorePolicy",
    "Statement": [
        {
            "Sid": "NexusS3BlobStoreAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<user-arn>"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:ListBucket",
                "s3:GetLifecycleConfiguration",
                "s3:PutLifecycleConfiguration",
"s3:PutObjectTagging",
"s3:GetObjectTagging",
"s3:DeleteObjectTagging",
"s3:DeleteBucket",
"s3:CreateBucket",
"s3:GetBucketAcl"
 ], "Resource": [ "arn:aws:s3:::<s3-bucket-name>", "arn:aws:s3:::<s3-bucket-name>/*" ] } ] }

Access Denied Errors

Access denied errors are an indication that the user configured to connect to the bucket has insufficient permissions. AWS does not provide information specific to which permission is required to perform the failed action. For this reason NXRM will generically report access denied errors.

File Systems to avoid

Using the File Blob Store with NXRM HA-C relies on POSIX semantics.  File systems known to be unreliable are:

  1. glusterfs
  2. FUSE based user space filesystems

Determining a Backup Solution

Backing up your blob store file systems is covered in detail in the Designing your Cluster Backup/Restore Process section.


Your next step is to review your network configuration with Configuring Hazelcast.