NetApp

ONTAP FabricPool Attach to StorageGRID Runbook

Published May 25, 2026 | 11 min read

Scope

This runbook covers attaching a StorageGRID object store to an ONTAP aggregate to create a FabricPool. NetApp documents storage aggregate object-store attach as the command that attaches an object store to an aggregate and notes that once an object store is attached to an aggregate, it cannot be detached: storage aggregate object-store attach.

That warning drives the whole change design: validate aggressively before attachment.

Prechecks

system health status show
storage aggregate show
storage aggregate object-store config show
network interface show -role intercluster
network ping -lif <intercluster_lif> -destination <storagegrid_fqdn_or_ip>

Confirm:

Area	Best Practice
Object store	Bucket, credentials, certificate, and endpoint are approved
Network	Intercluster LIFs can reach StorageGRID from the aggregate owner and HA partner
Workload	Tiering policy impact is understood, especially for SAN workloads
Aggregate	Supported aggregate type and enough local capacity remain
Change risk	Attachment is treated as one-way for planning purposes

NetApp's FabricPool requirements documentation lists supported object stores, including StorageGRID, and notes protocol and connectivity considerations: Requirements for using ONTAP FabricPool.

CLI Process

Create or confirm the object store configuration:

storage aggregate object-store config show
storage aggregate object-store config show -object-store-name sg_fabricpool01

Attach the object store:

storage aggregate object-store attach \
  -aggregate aggr_data_01 \
  -object-store-name sg_fabricpool01

Verify the aggregate:

storage aggregate object-store show -aggregate aggr_data_01
storage aggregate show -aggregate aggr_data_01

Set tiering policy on selected volumes only after the aggregate attachment is validated:

volume modify -vserver svm_nfs01 -volume archive_data01 -tiering-policy snapshot-only
volume show -vserver svm_nfs01 -volume archive_data01 -fields tiering-policy

REST API Process

Use REST for discovery and validation:

curl -k -u admin:'<password>' \
  "https://cluster.example.com/api/storage/aggregates?name=aggr_data_01&fields=uuid,name,space,cloud_storage"

curl -k -u admin:'<password>' \
  "https://cluster.example.com/api/network/ip/interfaces?services=data_core&fields=name,ip.address,location,state"

If your ONTAP release exposes native object-store attach endpoints, use the native storage aggregate cloud tier endpoint from that release's REST documentation. If not, do not build an untested workaround for production. Use CLI for the attach and REST for evidence capture.

Modify volume tiering policy through REST after attachment:

curl -k -u admin:'<password>' \
  -X PATCH \
  "https://cluster.example.com/api/storage/volumes/<volume_uuid>" \
  -H "Content-Type: application/json" \
  -d '{ "tiering": { "policy": "snapshot_only" } }'

Validate:

curl -k -u admin:'<password>' \
  "https://cluster.example.com/api/storage/volumes/<volume_uuid>?fields=name,tiering,aggregates.name,space"

Backout Reality

FabricPool attachment is not a casual reversible change. The safest backout is usually to avoid tiering data in the first place until the attachment is proven. If a volume policy was changed incorrectly, set it back:

volume modify -vserver svm_nfs01 -volume archive_data01 -tiering-policy none

Post-Change Evidence

storage aggregate object-store show -aggregate aggr_data_01
volume show -vserver svm_nfs01 -fields volume,tiering-policy
system health status show

Document StorageGRID endpoint, bucket, object-store config name, attached aggregate, and every volume tiering policy changed.