Advanced Search
Search Results
217 total results found
Shares
A share exposes a folder inside a volume over SMB or NFS, so it can be mounted directly by Windows, Linux, or macOS clients as a network file share — no block-level host mapping required. A volume needs a file system assigned to it before you can add a share t...
Host Groups and Pairing
This page covers two related ways of managing multiple hosts together: grouping hosts that should share the same volume mappings (useful for clusters), and pairing a host or host group with its counterpart on a remote system for replication. Host groups A host...
Hosts
A host (also called an initiator) represents a server or client that connects to StorONE block storage — over iSCSI, Fibre Channel, or NVMeOF — so that a volume can be mapped to it. Creating a host registers the identifiers StorONE uses to recognize that serve...
Local Admins
For a NAS server joined to Active Directory, local admins are the Active Directory users or groups granted local administrative rights over the NAS server itself — for example, the ability to manage SMB share permissions from a Windows client using the "Comput...
NAS Servers
A NAS server is the identity and authentication endpoint that SMB and NFS shares authenticate against — it's the "server" your Windows and Linux/macOS clients see when they connect, complete with its own name, floating IP(s), and authentication configuration f...
Object Access Keys
An access key is the S3 credential pair (access key + secret key) that clients use to authenticate against an object store — the S3 equivalent of a username and password. Access keys exist independently of any one object store: you create a key once, then gran...
Object Stores
An object store turns a volume into an S3-compatible endpoint: instead of (or in addition to) mounting the volume as a block device or file share, applications talk to it over HTTP using the S3 API — buckets, objects, and standard S3 tooling all work against i...
Automation
An automation workflow is a saved, named sequence of StorONE CLI commands that you can run as a single unit, as many times as you like, instead of typing (or scripting) each command individually. It's built for repeatable, multi-step procedures — provisioning ...
Scheduled Reports
A scheduled report emails the output of up to six List commands — the same read-only commands you'd otherwise run yourself and read on screen — to a set of recipients on a recurring schedule. Use it to keep stakeholders who don't log into StorONE up to date: ...
Action Policies
An action policy tells StorONE that a particular kind of operation needs the approval of several administrators before it runs. This page covers creating, editing, listing, and deleting policies. For the big picture, see Multi-Admin Approval; for a complete, r...
Pending Actions
When an action policy is in place for an operation, performing that operation doesn't happen immediately — it creates a pending action instead, which sits waiting for review until enough of the policy's authorized reviewers approve it. How approval works Initi...
Monitoring
StorONE's monitoring commands give you both a live view of what the system is doing right now and a historical view of how it got there — health, capacity, performance, utilization, and tiering, at the system, pool, node, application, or volume level. Most mon...
Historical monitoring
Where the live monitoring views show what's happening right now, these views look backward — performance and utilization trends over a date range, which volumes have been busiest, and exactly how much physical space each volume is really reserving. For the two...
Live monitoring
These views show what StorONE is doing right now. In an interactive CLI session they stream continuously — refreshing on the configured interval — until you press a key to stop; the web interface shows the same data as a live-updating chart. When called non-in...
Tiering monitoring
Volumes with an upper (autotiering) tier evacuate the coldest data down to the lower tier once the upper tier's pinned size is exceeded — see the Tiering chapter for how tiers are configured. These three views let you watch that evacuation happen live, review ...
Browsing Notification History
Every StorONE node keeps its own local history of the notifications it has generated, independent of whether you've configured any notification targets to receive them. This is useful for after-the-fact investigation — for example, confirming when a Replicatio...
Notifications
StorONE watches its own health continuously — hardware, replication, capacity, security, and more — and raises notifications when something changes state or needs attention. A notification target tells StorONE where to send those notifications: an email inbox,...
Configurations
Every change you make to a system — creating a volume, editing a schedule, deleting a user, and so on — is tracked as a configuration. This chapter covers viewing that history and, for scripting, waiting on configurations to complete. Configuration history Con...