NetApp ONTAP Cheat Sheet: Day-to-Day Commands

2026年8月26日 LOG admin

NetApp ONTAP 日常运维总在集群、SVM、LIF、卷与共享之间来回切换。本文整理一份高频 ONTAP 命令速查表：优雅关机/重启节点、查看 SVM 归属节点、创建与管理卷、CIFS 共享（含隐藏共享）、NFS 导出访问模拟与健康检查，全部命令带参数说明，可直接用于生产与实验环境。

Everything below is taken from a working ONTAP 9 cluster and is ordered the way an administrator actually uses it: know where you are, stop or restart things safely, add storage, publish it, then watch it. Every command is written for the cluster admin privilege level and is safe to run read-only unless stated otherwise. The redacted example cluster is cluster01 and the data SVM is svm_data.

Background: How the ONTAP CLI Is Organised

ONTAP's CLI is a hierarchical command tree rather than a flat set of verbs. system covers the physical cluster and its nodes, network covers ports and logical interfaces (LIFs), vserver covers SVMs and services published from them, volume covers the FlexVol and FlexGroup layer, and storage covers aggregates and the disks beneath them. The same object can often be reached through more than one path — a LIF is network interface show at cluster level but network interface show -vserver X scoped to a SVM — and understanding which scope you are in removes most of the "command not found" frustration.

Two conventions matter in daily use:

-fields selects columns, -instance prints every field one per line. When you need a value you cannot remember the name of, -instance is faster than the documentation.
* means "all objects" but only where a node or SVM name is expected — system node halt -node * is a blunt instrument that affects the whole cluster.

Prerequisites Before You Start

A cluster management LIF reachable over SSH or the serial console, and an account with the admin role or an equivalent RBAC role that includes cli access.
Knowledge of which node currently holds the cluster management LIF — if you shut that node down first over SSH, you lose access to the rest of the cluster.
A change window for anything that halts, reboots or deletes. Read-only show commands are safe at any time; volume delete and system node halt are not.
A current system configuration backup or an AutoSupport snapshot taken before major changes, so you can compare state afterwards.

cluster01::> set -privilege advanced    # only when a command says "requires advanced"
cluster01::> set -privilege admin       # return to normal as soon as you are done

Advanced privilege unlocks destructive and diagnostic commands. Leave it as soon as the task finishes; the default admin privilege level prevents most accidental damage.

Cluster and Node Management

优雅关停整个集群（Graceful Cluster Shutdown）

cluster01::> system node halt -node * -inhibit-takeover true -ignore-quorum-warnings true

出现 "Could not migrate LIFs away from node" 时，可加 -skip-lif-migration-before-shutdown 强制关机（会短暂断连）。SSH 关机时先确认谁持有 cluster-mgmt LIF，最后关该节点以免断线。

Two more flags worth knowing in this scenario:

-inhibit-takeover true stops the surviving nodes from absorbing the halted node's LIFs — essential when you are powering down the whole cluster anyway.
-ignore-quorum-warnings true suppresses the complaint that quorum will be lost as nodes go down. Only use it when you genuinely intend to stop every node.

cluster01::> network interface show -role cluster-mgmt   # which node holds cluster management

Halt that node last. Otherwise the SSH session dies mid-sequence and you finish the job on the serial console.

重启节点（Rebooting a Node）

cluster01::> system node reboot -node cluster01-02 -reason "Maintenance reboot"
cluster01::> system node reboot -node cluster01-02 -force -reason "Emergency reboot"

A graceful reboot triggers takeover of the node's data LIFs by its HA partner. Always populate -reason: it lands in the audit log and in the AutoSupport event history, which is what makes a future investigation possible. -force skips the clean shutdown and should be reserved for a node that has stopped responding.

If takeover does not happen, check the HA pair state before retrying:

cluster01::> storage failover show
cluster01::> storage failover show -fields state,possible,node,partner
cluster01::> storage failover giveback -fromnode cluster01-02   # return LIFs after maintenance

After maintenance the node re-integrates and the partner gives back the LIFs it took. Giveback is not optional — leaving a cluster running in takeover state halves your redundancy.

查看节点与集群信息（Node and Cluster Information）

cluster01::> system node show -instance
cluster01::> version
cluster01::> network interface show -role cluster-mgmt
cluster01::> network interface show -vserver svm_data   # SVM 当前运行节点
cluster01::> system node show -node * -fields node,uptime,health

network interface show -vserver svm_data is the fastest way to answer "which node owns this SVM right now", which you need before any node-level operation. Combine it with storage failover show to know whether the SVM is currently on its home node or on the partner.

SVM, Volume and Aggregate Operations

创建 SVM（Creating a Storage VM）

cluster01::> vserver create -vserver svm_data -aggregate aggr_data01 -rootvolume root_vol_svm_data -rootvolume-security-style unix

The root volume's security style decides how the SVM's own root volume handles permissions; the data volumes created later can differ. After creation, the SVM needs at least one data LIF and a protocol service enabled before any client can reach it.

cluster01::> vserver show -vserver svm_data -fields state,type,allowed-protocols,aggregate
cluster01::> vserver services name-service dns show

创建/挂载/删除卷（Volume Lifecycle）

cluster01::> volume create -vserver svm_data -volume vol_data01 -aggregate aggr_data01 -size 500MB
cluster01::> volume mount -vserver svm_data -volume vol_data01 -junction-path /vol_data01
# 删除顺序：unmount → offline → delete
cluster01::> volume unmount -vserver svm_data -volume vol_data05
cluster01::> volume offline -vserver svm_data -volume vol_data05
cluster01::> volume delete -vserver svm_data -volume vol_data05

注意：删除的卷会进入 recovery queue（默认保留 12 小时），可用 volume recovery-queue show 查看，volume recovery-queue purge 立即清除，未 purge 前可一条命令恢复。

cluster01::> volume recovery-queue show -vserver svm_data
cluster01::> volume recovery-queue restore -vserver svm_data -volume vol_data05

The recovery queue is a real safety net: an accidental volume delete is recoverable for twelve hours by default, restored with the same name and junction path. volume recovery-queue purge destroys that safety net immediately — use it only when you are deliberately reclaiming aggregate space after a confirmed decommission.

Useful companion commands while working the volume layer:

cluster01::> volume show -vserver svm_data -fields volume,aggregate,size,available,state,type
cluster01::> volume show-footprint -vserver svm_data -volume vol_data01
cluster01::> volume modify -vserver svm_data -volume vol_data01 -size 2GB
cluster01::> volume show -vserver svm_data -fields volume,junction-path,style

volume show-footprint answers the perennial question "why is a 500 MB volume consuming 1.2 GB of aggregate space" — it breaks down the space used by the volume itself, its snapshots, and the aggregate-level overheads such as Snapshot reserve and WAFL metadata.

Aggregate Checks

cluster01::> storage aggregate show -fields aggregate,size,available,state,raidtype
cluster01::> storage aggregate show-status

An aggregate that is above roughly 90% used cannot accept new writes reliably, and once it passes 95% the spare capacity needed for WAFL overwrites disappears. Check available space before creating any volume.

CIFS Shares and NFS Exports

# 创建隐藏 CIFS 共享（$ 结尾）
cluster01::> vserver cifs share create -vserver svm_data -share-name admin-tools$ -path /cifs-data04
# 模拟 NFS 访问检查
cluster01::> check-access -vserver svm_data -volume vol_data01 -client-ip 10.0.0.89 -authentication-method none -protocol nfs3 -access-type read-write

A share name ending in $ is hidden from browse lists but fully accessible to anyone who knows the name — it is convenience, not security. For real access control use share-level permissions and NTFS ACLs, and for NFS use export policies.

cluster01::> vserver cifs share show -vserver svm_data -fields share-name,path,acls,comment
cluster01::> vserver cifs share access-control show -vserver svm_data -share-name admin-tools$
cluster01::> vserver export-policy rule show -vserver svm_data
cluster01::> vserver export-policy check-access -vserver svm_data -volume vol_data01 -client-ip 10.0.0.89 -protocol nfs3 -access-type read-write

export-policy check-access is the authoritative test: it walks every rule in the order ONTAP evaluates them and reports which rule matched, whether the client was allowed, and what access type resulted. When a client is refused, this command tells you which rule to fix rather than making you guess.

Snapshots and Data Protection Basics

cluster01::> volume snapshot show -vserver svm_data -volume vol_data01
cluster01::> volume snapshot create -vserver svm_data -volume vol_data01 -snapshot manual_before_change
cluster01::> snapshot policy show -vserver svm_data
cluster01::> volume snapshot policy show -vserver svm_data -volume vol_data01

Take a manual snapshot before any change that is hard to reverse. It costs nothing in advance and gives you a named rollback point. Remember that snapshots consume space in the volume, so a volume sitting at 95% full with hourly snapshots can run out of room even if the active file system has not grown.

Verification and Health Checks

cluster01::> system health status show
cluster01::> system health alert show
cluster01::> system node run -node * sysconfig
cluster01::> storage aggregate show-status   # RAID 状态
cluster01::> storage aggregate show-space    # 容量

Run the health pair after every change window. system health status show gives a one-word verdict (ok, degraded, notHealthy), and system health alert show lists the specific alerts behind that verdict with severity, node and corrective action. Treat anything above info severity as work to be scheduled rather than noise.

cluster01::> storage failover show
cluster01::> network port show -fields node,port,link,mtu,speed
cluster01::> vserver show -fields state
cluster01::> volume show -state error
cluster01::> event log show -severity ERROR -time-recent 1h
cluster01::> system health alert show -severity major -node *

The last two commands are the ones to run when a user reports a problem and you have no idea where it came from. Recent EMS events filter out the history and show what changed in the last hour.

Troubleshooting and FAQ

"Could not migrate LIFs away from node" during a halt

One or more data LIFs have nowhere to go — usually because the HA partner is not in a healthy state, or because the LIF's failover target list does not include the partner. Check storage failover show and network interface show -fields failover-policy,status-admin. The forced path is -skip-lif-migration-before-shutdown, which causes a brief client outage and should be a deliberate choice.

A new volume is not visible to clients

Three things must all be true: the volume is mounted with a junction path (volume mount), the parent volume's junction is reachable from the SVM namespace, and the client's protocol access is permitted by the share ACL or export policy. Check them in that order with volume show -fields junction-path, vserver show -fields rootvolume and export-policy check-access.

Deleting a volume fails because clients hold it open

ONTAP refuses to offline a volume with open handles. Confirm with vserver locks show, close the client sessions, then retry the unmount. If the volume must be removed regardless, -force true exists on some operations but should be the last resort.

Where do I find out which node an SVM is on after a failover?

network interface show -vserver svm_data prints the LIF and its current node and port. Add -instance for the full detail including failover policy and the target list.

Is there a way to see the commands I just ran?

Every CLI command is recorded in the audit log when auditing is enabled. Check the relevant audit configuration with vserver audit show and read the resulting files from the audit staging volume.