Cheat Sheet NetApp ONTAP – Commands used in day-to-day operations

Working with NetApp ONTAP often means jumping between clusters, SVMs, LIFs, and shares while keeping an eye on performance and troubleshooting access.

Over time, certain commands become part of the daily routine, whether you’re checking CIFS configurations, verifying volume security, or confirming network failover groups.

To save time and avoid digging through documentation, I’ve pulled together a compact cheat sheet of ONTAP commands I use most frequently in day-to-day operations.

I will update this post on a regular basis.

ONTAP Cluster

The graceful shutdown of a ONTAP cluster shown below usually and hopefully is not a day-to-day operation, but in my case for my vSphere lab environment (running on three notebooks, my ESXi hosts) where I will run ONTAP as simulator, this is indeed a day-to-day operation because of shutting down the notebooks (ESXi hosts) when not needed to test.

More about setting up your own NetApp ONTAP 9 lab, you can also read my following post.

And more about how to install the ESXi image on notebooks they will just provide USB NICs as usual these days, you can read my following post.

Graceful Shutdown Procedure for NetApp ONTAP Cluster

Must be done from the Cluster Admin CLI (SSH or console)

!! Note !!
Just shutdown or powering off the simulator virtual machines by using the vSphere client can crash them, so first perform a graceful shutdown by using the Cluster Admin CLI like shown below.

Use this command for each node:

When using SSH first check which node owns the Cluster Management LIF (shown below) and then first shutdown the node which not owns it, otherwise you will get disconnected from the SSH console before you are able to shutdown the second node.

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

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

If you’re shutting down a 2-node ONTAP simulator, you still must halt both nodes via CLI before powering off the VM in vSphere or your hypervisor.

We can now finally powering off the VM.

To reboot instead of shut down:

system node reboot -node * -inhibit-takeover true -ignore-quorum-warnings true

Determine which Node owns the Cluster Management LIF (IP Address)

Show Cluster Management LIF and Owner Node.

cluster01::> network interface show -role cluster-mgmt

To verify the node management LIFs.

cluster01::> network interface show -role node-mgmt

Storage Virtual Machines (SVMs)

Display the CIFS/SMB Server configuration for a specific SVM

The following command shows the CIFS/SMB server configuration for the SVM named svm_data.

cluster01::> vserver cifs show -vserver svm_data

The CIFS server was joined to my AD and the default Computers container during enabling CIFS on the SVM by running the following command. More about in Part 4 under publishing CIFS/SMB shares.

cluster01::> vserver cifs create -vserver svm_data -cifs-server cifs-data02 -domain matrixpost-lab.net

For the CIFS/SMB share (NetBIOS/hostname) I was creating a DNS record in my lab environment which points to the IP address of the SVM we enabled CIFS on.

List all LIFs in the Cluster and show to which SVM they belong

This command will list all LIFs in the cluster but only display two pieces of information for each:

• Which SVM they belong to
• Their IP address

cluster01::> net int show -fields vserver, address

CIFS Shares

List all CIFS Server (SVMs enabled for CIFS) and their NetBIOS Name

This command gives you a quick list of all CIFS server names in your cluster, showing the SVM they belong to and their configured CIFS/NetBIOS identity.

cluster01::> vserver cifs server show -fields cifs-server

List all CIFS Shares for a specific SVM

We can run the following command to show the currently existing CIFS shares on a specific SVM.

cluster01::> vserver cifs share show -vserver <svm>
cluster01::> vserver cifs share show -vserver svm_data

c$ and ipc$ shares here are default administrative shares, very similar to those found on a Windows server.

They are pointing to the root of the SVM namespace, which is the root_vol_svm_data.

Determine Owner and Permissions for a given CIFS Share (ONTAP share-level access)

This command tells you how ONTAP controls who can even open the share in the first place, regardless of the underlying NTFS/UNIX permissions.

So users get either denied or allowed to access the share even before checking the native underlying NTFS/UNIX permissions set directly on the file system.

!! Note !!
Finally a user or group must be granted access on the ONTAP share-level (ONTAP config) and also directly on the NTFS ACLs/Unix permissions (metadata stored on the volume/disk shown in the section below) in order to access the cifs share successfully.

It shows the ONTAP share-level ACLs (the permissions applied to the SMB share object itself, ONTAP’s own configuration regardless of the native NTFS/UNIX permissions).

cluster01::> vserver cifs share access-control show -vserver svm_data -share share-01

By default, the share-level ACL gives full control to the standard group named Everyone.
Full control in the ACL means that all users in the domain and all trusted domains have full access to the share.

Below for example, I already have changed this default share-level ACL to grant only to my enterprise admin and the matrix-cifs-share01 AD security group full control permissions on share-level access.

Determine Owner and Permissions for a given CIFS Share (File/Folder-level NTFS Permissions on the Volume itself set by the OS e.g. Windows Explorer or icacls)

This command tells you how ONTAP checks the NTFS/UNIX ACLs for the CIFS share mounted on the SVM by using the junction-path /cifs-data.

Reflects the file/folder-level NTFS (or UNIX) permissions on the volume itself. Those are the same permissions you’d see or set in Windows Explorer → Security tab or via icacls.

Below e.g. I was first listing all CIFS shares provided by the SVM named svm_data and then checking the owner and permissions for the CIFS share named share-01 by using its junction-path “/cifs-data”.

cluster01::> vserver security file-directory show -vserver svm_data -path "/cifs-data"

Below we will see our CIFS share mounted on a Windows host. The IP address in the UNC path with \\10.0.0.226 (IP address of the SVM named svm_data) will return the CIFS share they are mounted on the SVM.

In ONTAP, each SVM (Storage Virtual Machine) has its own namespace, which is essentially a virtual file system tree made up of Mounted volumes (like mount points) and Junction paths (like folders or subdirectories).

This allows ONTAP to present multiple volumes as a unified file system to clients.

Displays the Security Style configured for a specific Volume (UNIX, NTFS or Mixed)

The following command displays the security style configured for a specific volume (vol_data03 on SVM svm_data).

The security style determines how ONTAP applies file and directory permissions within that volume:

• NTFS → Uses Windows NTFS ACLs
• UNIX → Uses UNIX mode bits and NFS semantics
• Mixed → Accepts both NTFS and UNIX permissions, applies the most recent change
• Unified (for FlexGroup) → Newer style combining NTFS/UNIX semantics

cluster01::> volume show -vserver svm_data -volume vol_data03 -fields security-style

Creating a new Volume and CIFS Share

Below I will create a new volume and CIFS share by running the following commands.

The CIFS share I will by the way create as hidden share by using the $ character at the end of the share name.

Share names ending with the $ character are hidden shares.

For ONTAP 9.7 and earlier, the admin$, ipc$, and c$ administrative shares are automatically created on every CIFS server and are reserved share names. Beginning with ONTAP 9.8, the admin$ share is no longer automatically created.

Source: https://docs.netapp.com/us-en/ontap/smb-admin/share-naming-requirements-concept.html

# I will first create a 500MB data volume named vol_data04 on aggr_data02
cluster01::> volume create -vserver svm_data -volume vol_data04 -aggregate aggr_data02 -size 500MB

# Next I will need to mount this volume in the namespace of NetApp ONTAP (SVM)
cluster01::> volume mount -vserver svm_data -volume vol_data04 -junction-path /cifs-data04

# I can now create a new CIFS/SMB share by using the new volume and its junction-path
# !! Note !! By using the $ character at the end of the shares name like admin-tools$, this will make the share hidden from normal browse lists (e.g., it won’t show up in \\cifs-server\ when users browse shares).
cluster01::> vserver cifs share create -vserver svm_data -share-name admin-tools$ -path /cifs-data04

# Finally I will check the creation of the new CIFS share
cluster01::> vserver cifs share show -vserver svm_data

Below to show the difference behavior when using hidden shares, I was creating a further volume and CIFS share with the same name as previously but this time without the suffix $ at the end of the share name, so just admin-tools.

cluster01::> vserver cifs share create -vserver svm_data -share-name admin-tools -path /cifs-data05

When browsing to \\cifs-server\, just my last created CIFS share (the one not marked as hidden) but also named admin-tools will be shown up for the root path of the SVM.

Users still can connect to hidden CIFS shares directly by using the full UNC path (e.g. \\cifs-data02\admin-tools$), provided they have the right share + file system permissions.

To brows to the hidden share also named admin-tools (but with the $ character as suffix) we need to provide its full path like shown below, provided we have the right share + file system permissions as mentioned.

\\10.0.0.226\admin-tools$

Links

Storage virtualization overview
https://docs.netapp.com/us-en/ontap/concepts/storage-virtualization-concept.html

Manage CIFS shares
https://docs.netapp.com/us-en/ontap-restapi/ontap/protocols_cifs_shares_endpoint_overview.html