Access management and policies MinIO AIStor uses the built-in access management where a user’s attached policies determines the operations and data paths to which they have access. The mc table share commands require the following permissions: admin:DeltaSharingCreateShare admin:DeltaSharingGetShare admin:DeltaSharingListShares admin:DeltaSharingUpdateShare admin:DeltaSharingDeleteShare The user must also have s3:GetObject and s3:ListBucket permissions on all buckets and paths in which they must manage table shares.

AIStor Server publishes cluster and node metrics using the Prometheus Data Model. You can use any scraping tool to pull metrics data from AIStor Server for further analysis and alerting. This page provides guidance on baseline P0 and P1 alerts for use with building alerting rules and infrastructure around the available V2 or V3 metrics. These alerts assume infrastructure similar to or exceeding our reference hardware guidelines. Modify them to reflect your needs or open a SUBNET issue for further guidance.

Overview Starting with RELEASE.2025-12-20T04-58-37Z, MinIO AIStor supports creating inventory reports on objects and related metadata in a bucket. The MinIO AIStor inventory feature provides a fully-integrated solution with equivalent utility to the previously announced MinIO AIStor Catalog while expanding functionality with improved scheduling, filtering, and integration options.

MinIO AIStor supports hot-swapping failed drives with new healthy drives. Healing MinIO AIStor detects and heals those drives without requiring any node or deployment-level restart. MinIO AIStor healing occurs only on the replaced drive(s) and in most cases has minimal or negligible impact on deployment performance.

MinIO AIStor supports publishing an audit log of all operations to a remote receiver. The audit logging feature meets security and compliance requirements around granular tracking of operations within an MinIO AIStor deployment. MinIO AIStor does not by default publish audit logs to any destination. Audit logs can contain private and internal details such as hostnames, IP addresses, and object names. The remote receiver takes responsibility for processing, storing, and securing all incoming audit logs.

This page provides guidance for upgrading MinIO AIStor Helm clusters on Kubernetes infrastructure. Overview MinIO AIStor Helm installations consist of two primary components: Operator Chart - Controls resources like CustomResourceDefinitions and core operator functionality Object Store Chart - Deploys and manages MinIO AIStor instances Upgrades involve updating these charts and deploying new container images. The exact procedure depends on your cluster environment’s network configuration and registry access.

Overview This reference provides complete documentation for inventory job configuration. Inventory jobs use YAML configuration files that define what objects to include, what metadata to report, how often to run, and where to store generated reports. The configuration file contains top-level fields that control job behavior, destination settings for output location and format, optional fields for including additional metadata, and filters for selecting specific objects. All configuration files must specify apiVersion, id, and destination as required fields.

Returns the specified policy in JSON format if it exists on the target MinIO AIStor deployment. Syntax Example The following command returns the policy readonly in JSON format from the deployment at alias myaistor.

The mc admin name command and its subcommands manage the cluster name for an MinIO AIStor deployment. The cluster name identifies the deployment in SUBNET registration and other administrative contexts. If you do not set a cluster name, MinIO AIStor automatically generates one at startup using the format <MythicalCreature><Element> (for example, “GriffinWave”, “UnicornFrost”, “KrakenStone”). The auto-generated name persists across restarts. You can also set the cluster name using the MINIO_SITE_NAME environment variable. When set with the environment variable, the name cannot be changed with mc admin name set.

The mc batch generate command creates a basic YAML-formatted template file for the specified job type. After MinIO AIStor creates the file, open it in your preferred text editor tool to further customize. You can define one job task definition per batch file. See job types for the supported jobs you can generate. Syntax Example The following command creates a basic YAML file for a replicate job on the mybucket bucket of the myaistor alias.