Ons Doc Sag 2200 g1 - 3100sag2007 09

ONStor Bobcat™ 2200 Series
NAS Gateway
System Administrator’s Guide
Customer Order Number: ONS-DOC-SAG-2200, Rev G1

Text Part Number: 690-0015-0001G1
ONStor, Inc.
254 East Hacienda Ave.
Campbell, CA 95008
(408) 963-2400
Copyright © 2005-2007 ONStor, Incorporated. All rights reserved.
ONStor, EverON, AutoGrow, ONStor Bobcat, ONStor Cheetah, ONStor Pantera, and STORE-FS are
trademarks of ONStor, Inc.
This document exists for use with the products of ONStor, Inc. and is intended for use by employees,
representatives, assigns, and clientele of ONStor, Inc. This document cannot be copied, reproduced,
transmitted, or stored electronically, in part or in whole, without first obtaining the express consent and
agreement of ONStor, Inc.
This document can contain the names of products and services of other companies. Such products and
services are the property of their owners, and ONStor, Inc. makes no implications or claims, express or
implicit, to the ownership of such products and services. ONStor, Inc. has, in good faith, made efforts to
represent trademarked and copyrighted products and services as the property of their respective owners.
Contents
Foreword ......................................................................................................... i
Audience................................................................................................................................ 1-ii
Scope .................................................................................................................................... 1-iii
Document Organization ....................................................................................................... 1-iv
Related Documentation ........................................................................................................ 1-vi
Revision Trail...................................................................................................................... 1-vii
Syntax Usage...................................................................................................................... 1-viii
Chapter 1: NAS Gateway Overview and Access .....................................1-1

Introducing the ONStor NAS Gateway ................................................................................ 1-2
Hardware Overview ............................................................................................................. 1-4
System Switch and Controller ........................................................................................ 1-4
File Processor.................................................................................................................. 1-4
Storage Processor............................................................................................................ 1-5
NAS Gateway Chassis.................................................................................................... 1-5
Fans................................................................................................................................. 1-6
AC Power Supplies......................................................................................................... 1-6
Chassis Front Panel......................................................................................................... 1-7
Example Topology .............................................................................................................. 1-11
Software Overview.............................................................................................................. 1-12
EverON Operating System ........................................................................................... 1-12
System Control ............................................................................................................. 1-12
File Processing.............................................................................................................. 1-12
Network Connectivity................................................................................................... 1-13
Storage Processing........................................................................................................ 1-13
Volume Manager.................................................................................................... 1-13
Understanding the Active Configuration ............................................................................ 1-15
Accessing the NAS Gateway CLI....................................................................................... 1-16
690-0015-0001G1 ONStor Bobcat 2200 Series NAS Gateway System Administrator’s Guide
Chapter 2: Managing Privileges................................................................2-1
Understanding Privileges....................................................................................................... 2-2
Enforcing Privileges........................................................................................................ 2-2
Understanding Exec Privileges ....................................................................................... 2-2
Creating Exec Privileges ....................................................................................................... 2-4
Managing Local User Accounts .......................................................................................... 2-10
Chapter 3: Working with Virtual Servers..................................................3-1

Understanding Virtual Servers .............................................................................................. 3-2
Supported Features.......................................................................................................... 3-2
Virtual Server States ....................................................................................................... 3-3
Understanding the Management Virtual Server .................................................................... 3-4
Virtual Server Context and NAS Gateway Context ....................................................... 3-5
Adding a Virtual Server and a NAS Gateway to an LDAP Domain ..................... 3-15
Displaying DNS Name Resolution for a Virtual Server ........................................ 3-45
Configuring DNS Name Resolution for a Virtual Server ...................................... 3-45
Load Balancing Virtual Servers.................................................................................... 3-55
Chapter 4: Managing Storage and Fibre Channel ...................................4-1

Disk LUNs ...................................................................................................................... 4-1
Free LUNs ................................................................................................................ 4-2
Foreign LUNs........................................................................................................... 4-2
Out of Cluster ........................................................................................................... 4-2
Storage Ports and LUNs.................................................................................................. 4-2
Initial Boot ...................................................................................................................... 4-3
Addition of Physical Storage.................................................................................... 4-3
Physical Storage Going Offline................................................................................ 4-4
Network Power Cycle ..................................................................................................... 4-5
Managing Storage Ports ........................................................................................................ 4-6
Managing LUNs .................................................................................................................... 4-9
Displaying the LUN Topology ..................................................................................... 4-12
Managing the SCSI Layer ................................................................................................... 4-16
Chapter 5: Working with Network Interfaces...........................................5-1

Working with Network Protocols.......................................................................................... 5-2
ONStor Bobcat 2200 Series NAS Gateway System Administrator’s Guide 690-0015-0001G1
Working with Management Interfaces.................................................................................. 5-4
Creating Interfaces.......................................................................................................... 5-5
Working with Logical Ports ................................................................................................ 5-12
Understanding Logical Port Operation Modes ............................................................. 5-12
Load Balancing on IP Interfaces with Logical Ports .................................................... 5-18
Cisco Systems Switch Connectivity Example ....................................................... 5-18
Extreme Networks Switch Connectivity Example................................................. 5-20
Understanding Stackable Logical Ports........................................................................ 5-22
Chapter 6: Managing Volumes and File Systems ...................................6-1

Introduction to Volumes........................................................................................................ 6-2
Volumes and Virtual Servers.......................................................................................... 6-2
Understanding the Management Volume ....................................................................... 6-2
Managing Volumes ............................................................................................................... 6-5
Considerations for Importing Volumes.................................................................. 6-20
File System Statistics .......................................................................................................... 6-24
Chapter 7: Managing Shares.....................................................................7-1

NFS Environment.................................................................................................................. 7-2
NFS Share Considerations.............................................................................................. 7-2
Sharing Nested Directories ...................................................................................... 7-3
Share Permissions .................................................................................................... 7-3
Sharing with Root Access ........................................................................................ 7-3
Share’s Client List.................................................................................................... 7-4
Exclusions to the Share’s Client List ....................................................................... 7-4
CIFS Environment................................................................................................................. 7-6
Global Namespace (GNS)..................................................................................................... 7-8
GNS Root Management ...................................................................................................... 7-10
Junction Management ......................................................................................................... 7-16
Virtual Directory Management ........................................................................................... 7-19
Shares Management ............................................................................................................ 7-24
Multiprotocol Environment................................................................................................. 7-30
Understanding ID Mapping .......................................................................................... 7-31
ID Map Scanning Logic ......................................................................................... 7-32
ID Map Components .............................................................................................. 7-33
Naming Conventions.............................................................................................. 7-33
CIFS and NFS Shares and Services..................................................................................... 7-35
Preconfiguration Considerations................................................................................... 7-35
Configuration Steps ...................................................................................................... 7-36
Managing NFS Shares......................................................................................................... 7-48
Modifying NFS Shares ................................................................................................. 7-49
Managing CIFS Shares........................................................................................................ 7-52
Enabling or Disabling CIFS.......................................................................................... 7-53
Deleting a CIFS Share .................................................................................................. 7-54
Managing CIFS Servers ...................................................................................................... 7-56
Managing CIFS Wide Links................................................................................................ 7-58
Examples of Wide Link Behavior................................................................................. 7-58
CIFS Behavior Considerations with Wide Links.......................................................... 7-59
Exporting and Importing Shares.......................................................................................... 7-64
Managing ID Mappings....................................................................................................... 7-68
Multiprotocol File Access Without Using NIS ................................................................... 7-73
Working With Symbolic Links ........................................................................................... 7-77
Symbolic Links and the Directory Tree........................................................................ 7-77
Deletions and Symbolic Links ...................................................................................... 7-78
Deletion of All Objects in a Path .................................................................................. 7-78
Support for Absolute and Relative Symbolic Links ..................................................... 7-79
Displaying a Symbolic Link Mapping Rule ................................................................. 7-81
Removing a Symbolic Link Mapping Rule .................................................................. 7-82
Chapter 8: Managing File Auditing ...........................................................8-1

Understanding File Auditing ................................................................................................. 8-2
Audit Events.................................................................................................................... 8-3
Managing File Auditing ........................................................................................................ 8-9
Configuring File Auditing ................................................................................................... 8-19
Chapter 9: Managing Snapshots ..............................................................9-1

Snapshots Overview .............................................................................................................. 9-2
Scheduled Snapshots ................................................................................................ 9-2
File System Quotas and Snapshots ................................................................................. 9-3
Snapshot Location on the NAS Gateway........................................................................ 9-3
Managing Snapshots on the NAS Gateway........................................................................... 9-4
Chapter 10: Managing File System Quotas ..........................................10-1
Quotas Overview................................................................................................................. 10-2
File System Quotas and Volume-Level Quotas............................................................ 10-2
Quota Types.................................................................................................................. 10-2
Quota Interaction with Other NAS Gateway Features ................................................. 10-3
File System Quotas and Backup and Restore Operations ............................................ 10-3
Setting ONSTOR_SUPERSEDE_QUOTAS......................................................... 10-4
Setting ONStor Ignore User or Group Quotas ....................................................... 10-6
Setting ONStor Ignore Tree Quotas....................................................................... 10-7
File System Quotas and Mirrors ................................................................................... 10-8
File System Quotas and Snapshots ............................................................................... 10-9
Specific Tree Quotas ............................................................................................ 10-12
Specific Tree Quotas Removal............................................................................. 10-13
Specific User and Group Quotas.......................................................................... 10-13
Working With the Quota Log............................................................................................ 10-23
Chapter 11: Monitoring the NAS Gateway .............................................11-1

Monitoring with the NAS Gateway .................................................................................... 11-2
Supported RFCs and MIBs........................................................................................... 11-3
Managing SNMP................................................................................................................. 11-4
Chapter 12: Autosupport and Event Monitoring ..................................12-1

Understanding Autosupport ................................................................................................ 12-2
Understanding Autosupport and Event Logs................................................................ 12-2
Understanding Autosupport Message Types ................................................................ 12-3
Configuring Autosupport .................................................................................................... 12-4
Event Monitoring and Reporting Services ........................................................................ 12-10
EMRS Upload Methods.............................................................................................. 12-11
Configuring and Managing EMRS............................................................................. 12-11
Prerequisites for EMRS........................................................................................ 12-12
Chapter 13: Working with ONStor Data Mirror ......................................13-1

Managing ONStor Data Mirror ........................................................................................... 13-2
Data Mirroring Over IP ................................................................................................ 13-2
Features and Functionality Supported by Data Mirror over IP.............................. 13-3
Data Mirror over IP Prerequisites .......................................................................... 13-4
Local Data Mirror ......................................................................................................... 13-4
Data Mirroring Methods ............................................................................................... 13-4
Asynchronous and Synchronous Mirroring ........................................................... 13-5
Volumes and Automatic Growth .................................................................................. 13-5
Tracking File System Quotas on Target Volumes........................................................ 13-6
Configuring Data Mirrors.................................................................................................... 13-7
Backing Up Mirror Volumes ...................................................................................... 13-15
Chapter 14: Managing Backup and Restore ..........................................14-1

Introducing Backup and Restore ......................................................................................... 14-2
Backing Up and Restoring Data Using NDMP ............................................................ 14-2
Backing Up and Restoring Data Using CIFS or NFS................................................... 14-3
Supported Backup and Restore Configurations............................................................ 14-4
Supported Backup and Restore Types .......................................................................... 14-4
Supported Data Management Applications .................................................................. 14-5
Supporting the NDMP Snapshot Management Extension............................................ 14-5
Performing NDMP Services Through the NAS Gateway ............................................ 14-6
Performing Backup and Restore Through the NAS Gateway ...................................... 14-6
Understanding Backup and Snapshots.......................................................................... 14-9
Understanding Restore and File System Quotas........................................................... 14-9
Understanding Management Volumes and NDMP Sessions...................................... 14-12
Understanding NDMP Environment Variables .......................................................... 14-13
Managing NDMP Sessions................................................................................................ 14-28
Configuring the NAS Gateway for NDMP Services......................................................... 14-39
Typical Task Sequence in Configuring the NAS Gateway for NDMP ...................... 14-39
Preconfiguration Considerations................................................................................. 14-39
Mapping a Device Path to a Physical Device by Querying a SCSI Bridge....14-42
Mapping a Device Path to a Physical Device by Querying a Tape Library ...14-43
Chapter 15: Managing Virus Scanning...................................................15-1

Introducing Virus Scanning................................................................................................. 15-2
Supporting Third-Party Virus Scanning Solutions ....................................................... 15-2
Installing the VirusScan Applet........................................................................................... 15-4
Installation Prerequisites............................................................................................... 15-4
Configuring the VirusScan Applet .................................................................................... 15-18
Configuring the VirusScan Applet for the Symantec AntiVirus Scan Engine........... 15-19
Configuring the VirusScan Applet for the McAfee AntiVirus Engine API............... 15-21
Updating McAfee .DAT files ..................................................................................... 15-22
Configuring the CIFS Domain .......................................................................................... 15-23
Receiving Virus Notification on CIFS Clients ........................................................... 15-26
Prerequisites and System Recommendations.................................................................... 15-27
Virus-Scan Server Recommendations for the Symantec AntiVirus Scan Engine...... 15-27
Virus-Scan Server Recommendations for the McAfee VirusScan Enterprise 8.0i Software
15-27
Virus-Scan Server Recommendations for the VirusScan Applet ............................... 15-27
Configuring the Symantec AntiVirus Scan Engine........................................................... 15-29
Configuring the McAfee VirusScan Enterprise 8.0i Software.......................................... 15-30
Managing Virus Scanning From the CLI.......................................................................... 15-31
Chapter 16: Managing NAS Gateway System Settings ........................16-1

Introducing NAS Gateway System Management ............................................................... 16-2
Working with System Time.......................................................................................... 16-5
Change in Daylight Saving Time (DST) ...................................................................... 16-6
Working With an Event Log (elog) ............................................................................ 16-10
Displaying IP Statistics ..................................................................................................... 16-17
Displaying File Processing Port Load Statistics ............................................................... 16-18
Managing NAS Gateway System Health .......................................................................... 16-19
Getting the NAS Gateway Statistics........................................................................... 16-26
Working with the Read Ahead Cache ............................................................................... 16-32
Working with Core Dumps ............................................................................................... 16-34
Displaying Core Dump Files ...................................................................................... 16-37
Preface
This preface contains the front matter for the System Administrator’s Guide for the
ONStor Bobcat™ 2200 Series NAS Gateway family of products. It contains the
following sections:
• “Audience”
• “Scope”
• “Document Organization”
• “Related Documentation”
• “Revision Trail”
• “Syntax Usage”
1-ii
Audience
This System Administrator’s Guide is for IT professionals that administer the ONStor
family of products and their company’s storage area network (SAN). This guide serves
IT professionals and storage administrators of varying levels of experience.
1-iii
Scope
This System Administrator’s Guide helps you understand and configure the ONStor
NAS Gateway software. This guide accompanies a separate set of installation
instructions, the ONStor Bobcat 2200 NAS Gateway Installation Guide. Use this
System Administrator’s Guide only after you have successfully installed the NAS
Gateway and connected it to the facility’s power source.
This document is predominantly a reference manual. It contains some reference text
and some task-oriented text. Although some overview material is contained in this
manual, this manual is not intended to be an in-depth reference document about the
public domain protocols with which the NAS Gateway interfaces. For additional
material about the NAS Gateway, refer to the additional NAS Gateway product
documentation listed in “Related Documentation”.
1-iv
Document Organization
Table 1 lists the chapters in this document and briefly describes each chapter.
Table 1 : Document Organization
Chapter... Purpose...
1 - “NAS Gateway Overview Provides an overview of the software, hardware, and

and Access” product features and shows how to access the command-
line interface (CLI).
2 - “Managing Privileges” Explains the administrative privileges supported on the

NAS Gateway for administrative uses, and specify file
system privileges for end users.
3 - “Working with Virtual Explains the concept of virtual servers and provides
Servers” commands for configuring and managing virtual servers.
4 - “Managing Storage and Explains the NAS Gateway’s role in discovering and
Fibre Channel” using storage and Fibre Channel (FC) compliant devices.
5 - “Working with Network Explains how network interfaces are used on the NAS
Interfaces” Gateway, and how to provision IP functionality.
6 - “Managing Volumes and Explains what volumes are and how the NAS Gateway
File Systems” manages volumes.
7 - “Managing Shares” Explains the EverON™ software, how it operates with

NFS, and how to use NFS share functions.
8 - “Managing File Auditing” Explains the support for auditing and logging file and
directory access and usage attempts.
9 - “Managing Snapshots” Explains what snapshots are, what types are available,
and how to configure them.
10 - “Managing File System Explains what quotas are, what types are available, and
Quotas” how to configure them.
11 - “Monitoring the NAS Explains what SNMP functionality the NAS Gateway
Gateway” supports.
12 - “Autosupport and Event Explains what the autosupport feature is and how it
Monitoring” works.
1-v
Table 1 : Document Organization (Continued)
Chapter... Purpose...
13 - “Working with ONStor Explains the NAS Gateway’s mirroring capabilities

Data Mirror” through the Data Mirror feature.
14 - “Managing Backup and Explains the type of backup and restore operations
Restore” supported, how to manage NDMP sessions and tape
devices, and how to configure the NAS Gateway for
NDMP sessions.
15 - “Managing Virus Explains how to install and configure the virus scanning
Scanning” applet, what types of third-party virus scanning packages
are supported, and how to manage virus scanning from
the command-line interface (CLI).
16 - “Managing NAS Gateway Explains the system-wide features that control the NAS
System Settings” Gateway’s operation, and how to configure them.
1-vi
Related Documentation
This document is part of a set of product documentation for the NAS Gateway. Table 2
lists the related documentation.
Table 2 : ONStor Product Documentation
Document Name Part Number Revision Level
ONStor Bobcat NAS Gateway ONS-DOC-CCG-2200 D1

Installation and Cluster
Configuration Guide
ONStor Bobcat 2200 Series NAS ONS-DOC-CR-2200 E1

Gateway Command Reference
ONStor Bobcat 2200 Series NAS ONS-DOC-CMA B1

Cluster Manager Administrator’s
and User’s Guide
If you are managing the NAS Gateway through the ONStor NAS Cluster Manager,
you can also use the NAS Cluster Manager context-sensitive online help.
Release notes are available with every release of software. The release notes contain
additional information about bugs and fixes in the product, documentation errata or
omissions, and new features or enhancements.
1-vii
Revision Trail
This document is regularly reviewed and revised. Table 3 lists the revision history of
this document. We recommend that you obtain the latest information whenever
possible.
Table 3 : Product Documentation Revision History
Revision Revision
Document Name Part Number
Level Date
ONStor Bobcat 2200 Series ONS-DOC-SAG- A1 01/18/05

System Administrator’s Guide 2200
ONStor Bobcat 2200 Series ONS-DOC-SAG- B1 03/16/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- C2 05/08/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- D1 08/15/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- E1 01/23/07

ONStor Bobcat 2200 Series ONS-DOC-SAG- F1 05/18/07

ONStor NAS Gateway System ONS-DOC-SAG- G1 09/30/07

Administrator’s Guide 2200
1-viii
Syntax Usage
The NAS Gateway command-line interpreter uses different syntax markers to indicate
specific conditions of usage in the command line. Table 4 lists the different syntax
markers used in the command-line interpreter and explains what each marker means.
Table 4 : Syntax Markers
Syntax Marker Means... Example
- (dash) You are specifying an option. -a
blank space You are delimiting words, arguments, arp show

or options in a command.
bold text Command syntax. list
bold italic text A mandatory variable. You need to ipaddr

enter some input for italicized
arguments.
[ ] (squared Input is optional. The command [-c CONTROLLER]
brackets) will complete with or without the
optional argument.
| (pipe) A logical or operation. Select one disk|tape
of the choices for the command to
complete.
{ } (braces) A choice is contained within the {left|center|right}
braces. The open brace ({)
indicates the beginning of the
choice list, and the closed brace (})
indicates the end of the choice list.
Choice lists use pipes (described
above) to delimit each element in
the choice list. Enter one of the
elements in the choice list exactly
as it occurs in the list.
Chapter 1: NAS Gateway Overview
and Access
This chapter provides an overview of the main software and hardware elements that
enable the ONStor™ NAS Gateway to provide file system services to a storage
environment.
This chapter contains the following sections:
• “Introducing the ONStor NAS Gateway” on page 1-2
• “Hardware Overview” on page 1-4
• “Example Topology” on page 1-11
• “Software Overview” on page 1-12
• “Understanding the Active Configuration” on page 1-15
• “Accessing the NAS Gateway CLI” on page 1-16
1-2
Introducing the ONStor NAS Gateway

The ONStor NAS Gateway consists of reliable and scalable hardware and software
that provides file-level services in your storage environment. The NAS Gateway
supports file services features, such as:
• Automatic storage area network (SAN) discovery
• Virtualization of storage resources to simplify administration of the SAN
• Consolidation of network-attached storage (NAS) and direct-attached storage
(DAS) into a single platform
• Elimination of NAS and DAS storage islands
• Dynamic volume growth
• Mirroring
• Snapshots
• Clustering
• File system quotas
• Virus scanning
• Multiprotocol client support through Common Internet File System (CIFS) only,
NFS only, and a mixed CIFS and NFS environment
The NAS Gateway operates in enterprise and storage service provider (SSP)
applications and environments, such as:
• Network-accessible file systems, for example, for collaborative development
efforts
• E-mail message archiving and retrieval
• Data and software applications storage
• Storage of e-commerce transactions - online transaction processing (OLTP)
• Content distribution and Internet publishing
• Customer resource management and enterprise resource management applications
(CRM and ERM, respectively)
1-3
The NAS Gateway carries out the following functions in a NAS or SAN storage
environment:
• Support large numbers of users, files, and file systems.
• Support a high number of file system operations per second.
• Provide virtualized storage, which makes a SAN appear as a unified storage pool
over the local area network (LAN). Because IT administrators are more familiar
with an IP LAN, the NAS Gateway facilitates SAN administration, which reduces
costs and required personnel time.
• Provide high scalability and high reliability. The NAS Gateway offers efficient,
high-performance service to the data center and enables the data center to grow.
• Provide graphical policy-based management. Policies can be set for file system
volumes for such features as snapshot frequency, mirror frequency, and automatic
growth of logical unit number (LUN) space for volumes.
• Automate storage tasks. The NAS Gateway facilitates management of storage.
Advanced storage capacity management through the NAS Gateway’s automated
storage growth policies facilitates controlling storage regardless of the number of
users, growth rates, or the amount of storage you need to manage.
• Automatically discover SAN storage devices when the NAS Gateway is connected
to a SAN. The NAS Gateway enables configuration of devices into a single
managed storage pool.
• Reducing element-level management tasks through automating processes enabling
you to focus on more productive activities.
1-4
Hardware Overview
The NAS Gateway is a one-rack unit. Hardware elements inside the chassis are
responsible for communicating user data and file meta data, distributing power, and
transporting control packets. The NAS Gateway contains the following hardware
elements:
• System switch and controller (SSC)
• Gigabit Ethernet (GE) file processor (FP)
• Fibre Channel (FC) storage processor (SP)
System Switch and Controller

The SSC contains the following elements:
• Boot and runtime images
• Central address resolution protocol (ARP)
• Interface and route tables
• Fault tolerance software
• Logs and system elements
The SSC provides the command-line interface. You can connect to it through a secure
shell (SSH) session over any of the NAS Gateway’s 10/100 Ethernet ports, or through
the Console port on the front of the chassis.
File Processor
The FP contains processing for IP connectivity. The FP supports IP protocol
processing, network file protocols, volume management, and GE interfaces into the IP
network. The FP supports connections to the IP network through four optical GE
(1000BaseSX) ports that support the IP interface connecting the NAS Gateway to the
IP network. Each port supports an optical link at a throughput rate of 1 Gbps. You can
also use SFP (small form pluggable) copper transceivers.
Note - Optical and copper transceivers cannot be mixed on the same FP.
1-5
Storage Processor
The SP contains processing for storage functions. The SP supports FC and serial small
computer system interface (SCSI) protocols that run on top of FC. The SP provides
connection to the storage network through two physical FC ports that connect the NAS
Gateway to the SAN. The SP supports fiber optic cabling on each of the two FC ports.
Each FC port supports full duplex traffic at 1 or 2 Gbps in each direction. The link
speed is autonegotiated.
NAS Gateway Chassis

The NAS Gateway is installed in a standard 19-inch open frame equipment rack, and
the mounting brackets for the chassis can be front-mounted or center-mounted
depending on your requirements. The NAS Gateway has the following physical
dimensions:
• Height: 1.675 inches
• Chassis weight: 22 pounds
• Total shipping weight: 31 pounds
• Width: 19 inches with mounting brackets installed, 17.3” without mounting
brackets
• Depth: 23.45 inches
The NAS Gateway operates effectively in the following physical environment
conditions:
• Operating temperature: 0 degrees Celsius to 40 degrees Celsius (from 0 to 3000
feet in altitude), and 0 degrees Celsius to 35 degrees Celsius (from 3000 to 7000
feet in altitude)
• Humidity: 10% to 80%, noncondensing
The NAS Gateway operates effectively with AC power at a current draw of 100 to 240
V AC. At 100 V AC, the NAS Gateway draws a peak 2.2 amps and a constant 1.5
amps.
The NAS Gateway ships with a console cable and a cross-over cable.
The NAS Gateway complies with the following agency approvals and certifications:
1-6
• FCC Class A, Part 15

• CA ICES-003, Issue 3, Class A
• EN60950
• NOM-018
Fans
The NAS Gateway provides a chassis cooling system that draws air in from the front,
across the elements in the chassis to cool them, then exhausts the heated air out of the
chassis to the rear into the surrounding data closet. The NAS Gateway chassis contains
five individual fans.
The fan system contains a grill work that allows ambient air from the surrounding
room to enter the chassis and cool the chassis. Then, the NAS Gateway’s exhaust fans
push the heated air out of the back of the chassis where the air can diffuse into the
surrounding room and cool again. The fans are located toward the back of the chassis.
AC Power Supplies
The NAS Gateway chassis contains two AC power supply units (PSUs). The power
supplies plug into the facility’s AC power outlets, digest the input AC power, and
distribute the power across the NAS Gateway’s chassis elements.
One power supply provides enough power to support the NAS Gateway. However,
two power supplies are provided for power supply redundancy. When the NAS
Gateway is operating, the two power supplies loadshare to decrease the load on each
PSU. If a power supply fails, the active power supply assumes the full load.
1-7
Chassis Front Panel

The front panel of the NAS Gateway features status LEDs, ports, and slots for the
CompactFlash cards. See Table 1-1.
ONStor NAS Gateway Console Port
Compact Flash
Status LED Slots and LEDs
10/100 Ethernet GE FC Port

Ports and LEDs Port LEDs LEDs
Compact Flash
GE
Ejector
Ports
FC Ports
Power Supply
and Fan Status LED
Figure 1-1 ONStor NAS Gateway Front Panel
Table 1-1: Chassis Front Panel Elements
Panel Element Description
NAS Gateway status LEDs Indicator of whether the NAS Gateway is

operating properly or has encountered a failure.
A green LED means that the NAS Gateway is
OK. A red LED means the NAS Gateway has
encountered a failure.
1-8
Table 1-1: Chassis Front Panel Elements (Continued)
Power supply and fan status LEDs Indicator of the status of the fans (the FAN LED)
and the power supplies (the PS LED):
• A green FAN LED means the NAS
Gateway’s fans and chassis cooling system
are operating properly.
• A red FAN LED means the NAS Gateway’s
fans and cooling system have encountered
a failure.
• A green PS LED means the NAS
Gateway’s power supplies are operating
properly.
• A red PS LED means the NAS Gateway’s
power supplies have encountered a failure.
10/100 Ethernet ports, 2 Two ports for an Ethernet or Fast Ethernet

segment. The ports automatically negotiate for
the higher of the two bandwidths.
10/100 Ethernet port LEDs, 2 Indicator of whether the NAS Gateway

recognizes a valid 10/100 Ethernet connection
at the physical layer. One LED corresponds to
each of the management ports, and if the LED
is lit, a physical link has been established.
CompactFlash ejectors Ejects the CompactFlash cards. Each

CompactFlash slot has one ejector button.
1-9
CompactFlash memory card slots, 2 Two slots that accept one CompactFlash
memory card each. One CompactFlash
memory card is considered the active card
because it contains the runtime images, and
one CompactFlash memory card is considered
the standby card because it is not in runtime
mode. The active card is indicated by an amber
LED, the standby card is indicated by a green
LED.
Do not remove the active (amber LED) card.

You can remove the standby card (green LED).
CompactFlash LEDs, 2 Indicator for the CompactFlash cards. A green

LED indicates either that no CompactFlash card
is in the slot or the card that is in that slot is the
standby card. An amber light indicates that a
active CompactFlash card is in the slot.
Do not remove the active CompactFlash card.
GE ports, 4 GE ports of the NAS Gateway. Each port

supports an individual GE collision domain. The
four ports on the chassis correspond to the four
Link Status LEDs. The NAS Gateway also
supports copper transceivers.
GE port LEDs, 4 Indicator of whether the NAS Gateway’s

transceiver recognizes a valid GE LAN
connection at the physical layer. One LED
corresponds to each of the GE ports. If the LED
is lit, a physical link has been established.
FC ports, 2 FC ports for the NAS Gateway. Each port

supports an individual FC link. The two ports on
the chassis correspond to the two Link Status
LEDs.
1-10
FC port LEDs, 2 Indicator of whether the NAS Gateway

transceiver recognizes a valid FC connection at
the physical layer. One LED corresponds to
each of the FC ports. If the LED is lit, a physical
link has been established.
Console Port Enables you to directly connect to the chassis

and attach a management console to the NAS
Gateway.
1-11
Example Topology
The NAS Gateway sits between the IP network and the SAN. The NAS Gateway
provides a front end for file processing transactions between the clients in the IP
network and the stored data resources in the SAN. Figure 1-2 shows an example
configuration containing the NAS Gateway.
ONStor NAS Gateway

NIS
IBM Compatible
Server
GE FC
W orkstation
NFS
Client
IP SAN
IBM Compatible
hub/router Primary Windows

W orkstation
Domain Controller
NFS
Client
IBM Compatible
Secondary Windows Disk ar ray Disk ar ray
Windows
W orkstation Workstation Workstation
Windows Windows Domain Controller Consolidated NAS

NT Client XP Client 2000 Client and SAN Storage
Figure 1-2 Example Topology Containing an ONStor NAS Gateway
1-12
Software Overview
The NAS Gateway contains several software components that control the file services
and storage network operations it performs.
EverON Operating System

The proprietary ONStor EverON™ operating system software overlays the format of
file system blocks onto resources in the SAN. The EverON operating system software
supports NFS and CIFS network file system protocols for UNIX and Windows client
accessibility to data.
System Control
The system control software governs the NAS Gateway. The system control software
runs across multiple processors and resides on the SSC element. The system control
software performs such tasks as monitoring and maintaining the NAS Gateway during
runtime and boot time. The system control software also enables you to halt, restart, or
upgrade the NAS Gateway, set time and date information, and track uptime.
For more information about the NAS Gateway System Control software, see
“Managing NAS Gateway System Settings” on page 16-1.
File Processing
File processing enables clients in the IP network to successfully read and write files
and other data to disks and tapes. File processing resides on the GE FP element. File
processing features include:
• Network connectivity
• The ONStor STOR-FS™ file system
The NAS Gateway supports file services, such as:
• Scheduled and on-demand snapshots
• Mirrors
• Clustering
1-13
For more information about the StorFS file system, see “Managing Shares” on page 7-
1.
Network Connectivity
The NAS Gateway’s network connectivity is used to transmit and receive NFS packets
through User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). The
NAS Gateway supports both UDP and TCP. The determination of whether to use TCP
or UDP depends on which protocol is in use on the client machine.
Storage Processing
The NAS Gateway’s storage processing software enables the NAS Gateway to support
SCSI and FC services over multiple physical media, and it resides on the SP element.
The storage processing software enables the following features:
• Automatic SAN discovery
• Rapid convergence on SAN topology changes
• High throughput of file system input and output processes between the NAS
Gateway and the storage resources
SP software also governs volumes through the NAS Gateway’s volume manager
(VM). For more information about the SP software, see the “Managing Storage and
Fibre Channel” on page 4-1.
Volume Manager
The Volume Manager (VM) summarizes and manages LUN-level information for the
SAN. The VM gathers information about physical storage, virtualizes that
information, and presents it to the file system so that file systems can be created on top
of the virtualized disk blocks. The VM is also responsible for dynamically adding
LUNs to a volume’s free space based on a configured ONStor AutoGrow™ policy. For
more information about the VM, see the “Managing Volumes and File Systems” on
page 6-1.
You can access and configure the NAS Gateway through one of the following
methods:
• Command-line interface (CLI) through secure shell (SSH) access
1-14
• CLI through direct connect Console port access

• NAS Cluster Manager Web user interface (web UI)
1-15
Understanding the Active Configuration

Each NAS Gateway contains its active configuration in the cluster database. The
cluster database is the repository of all configuration information for all NAS
Gateways in the cluster. Each NAS Gateway in the cluster contains its own copy of the
cluster database. When a parameter has been configured, that parameter is written to
the NAS Gateway’s cluster database. If any state change or configuration change
occurs, the cluster databases are synchronized between all NAS Gateways in the
cluster so that they all contain the same information.
1-16
Accessing the NAS Gateway CLI

The NAS Gateway’s command line interface (CLI) is the prompt at which you type
commands. Figure 1-3 shows the NAS Gateway’s CLI at the admin mode.
Login:admin
Password:*****
ssc>
Figure 1-3 Sample ONStor NAS Gateway Command Prompt at Admin Mode
The default command prompt displays that the management session is logged in to the
system switch and controller (SSC) element.
Note - The NAS Gateway’s command line is case sensitive. Ensure that you
run all commands in lower case. Capitalization of letters can be used when
entering the names of objects, for example, a volume or virtual server.
If you access the user interface through a secure shell or telnet session, you can enter
the NAS Gateway through either of the following methods:
• A management interface, one of the two 10/100 SSC interfaces on the SSC
• A Gigabit Ethernet interface, a configured IP interface on the GE file processor
If you access the user interface through a direct console connection, you can enter the
NAS Gateway through the Console port on the front of the chassis.
Note - If you are accessing the NAS Gateway for the first time, direct console
connection is the only connection method supported until IP addresses are
configured. After IP addresses have been configured, secure shell access is
available.
Chapter 2: Managing Privileges
• “Understanding Privileges” on page 2-2
• “Creating Exec Privileges” on page 2-4
• “Managing Local User Accounts” on page 2-10
2-2
Understanding Privileges
Privileges provide a secure mechanism to assign task responsibility on a system-wide
basis. Each privilege has a well-defined role assigned by the system administrator to a
user or group.
The NAS Gateway supports file system execution (exec) privileges that apply to end
users on Windows, Network Information Service (NIS), or Lightweight Directory
Access Protocol (LDAP) clients. For more information, see “Understanding Exec
Privileges” on page 2-2.
A privilege consists of the admin, user, or group name, a privilege, and a scope:
• Privileges are the rights that you have to perform an action on the NAS Gateway.
• Scope defines to which objects the privilege applies. Two types of scope exist:
cluster and virtual server.
When you create a privilege, you specify an allow or deny action as a privilege rule
that determines the privilege and scope of the privilege. The allow or deny logic is
similar to the Windows Access Control List (ACL) logic.
Enforcing Privileges
Privileges are checked against the scope and the deny rule. The software checks for
privileges at the virtual server scope first, then at the cluster scope. The software also
checks for deny rules first and stops at the first match of an admin, user, or group name
with a deny privilege.
Understanding Exec Privileges

File system execution (exec) privileges are applied to users or groups for manipulating
files and directories in the file system. CIFS domains require these file system
execution privileges, and they closely resemble the Windows privilege model. Exec
privileges are applied to the user or group name during file access check.
2-3
Table 2-2 lists the exec privileges that the NAS Gateway supports and displays the
amount of control that they have.
Table 2-2: Exec Privileges for File Operations
Exec Privilege Scope Allowed Operations
SECURITY Cluster, virtual server Enabling or disabling file-

level audit management,
manipulating SACL.
BACKUP Cluster, virtual server Read any file or directory.

This privilege is used for
backup operations only.
RESTORE Cluster, virtual server Read, write, or delete any

file or directory. This
privilege is used for restore
operations only.
TAKEOWNERSHIP Cluster, virtual server Change owner of any file or

directory.
TRAVERSE Cluster, virtual server Traverse directory, request

change notification.
2-4
Creating Exec Privileges

When you create exec privileges for NIS, LDAP, or Windows users or groups for a
given domain, at least one virtual server that is part of that domain must be enabled in
the cluster.
Creating an Allow Rule

You can create allow privileges by running the priv add allow command. This
command sets the parameters for allowed operations at a specific level of control.
Note - Exec privileges can override file-level privileges. For example, if user
exec1 does not have read permissions on a file, but is configured with
“backup” exec privileges, user exec1 can read the file for the purposes of
backing up the file.
You can specify only one level of scope for each admin user, but specifying
higher-scope levels includes the lower-scope levels. Enter the scope in
lowercase.
To Add an Allow Privilege

• Run the following command:
priv add allow {user|group} IDENTITY PRIVILEGES
cluster|vsvr [VIRTUALSERVER]
Options and
Description
Arguments
user|group This argument interacts with the IDENTITY argument to specify

the name of the user or group. Use an alphanumeric character
string. If you specify group, the IDENTITY argument names the
group, and if you specify user, the IDENTITY argument names
the user.
2-5
IDENTITY Specifies the name of the user or group for which you are adding
a privilege definition. The maximum identity string size must be
congruent with the string size supported through the domain,
such as 15 characters for a NetBIOS name, 64 for a Windows
domain. If an identity has blank spaces, enclose it in double
quotation marks.
This argument works in combination with the user|group
argument to specify the name of a user or group. Enter the
identity as one of the following:
• WindowsDomainName\UserName, for a Windows user or
group
• UserOrGroupName@DomainName for a NIS or LDAP user
or group from an NIS or LDAP domain
• A local user account
PRIVILEGES Specifies the privilege that you are configuring for the NAS
Gateway admin in IDENTITY. This argument accepts any of the
privileges listed in Table 2-2 on page 2-3 for exec privileges.
Enter the privilege in uppercase.
cluster|vsvr Specifying cluster applies privileges to all virtual servers

[VIRTUALSERVER] within that cluster.
Specifying vsvr applies privileges to the current virtual server.
Specifying vsvr [VIRTUALSERVER] applies privileges to a
specified virtual server.
Configuring a Deny Rule

Deny privileges are added to the NAS Gateway to enforce a limit on what a NAS
Gateway administrator or user can do. You can configure a deny rule for a NAS
Gateway administrator by running the priv add deny command.
Note - The NAS Gateway administrator’s privilege is cluster and scope is

cluster, so by creating a deny list for a NAS Gateway administrator, you
disallow that admin from running any commands on the NAS Gateway.
2-6
To Create a Deny Privilege

priv add deny {user|group} IDENTITY PRIVILEGES
Options and
Description
Arguments

the name of the user or group. If you specify group, the
IDENTITY argument names the group, and if you specify user,
the IDENTITY argument names the user.
IDENTITY Specifies the name of the user or group for which you are adding
a privilege definition. Use an alphanumeric character string. The
maximum identity string size must be congruent with the string
size supported through the domain, such as 15 characters for a
NetBIOS name, 64 for a Windows domain. If an identity has
blank spaces, enclose it in double quotation marks.
group
PRIVILEGES Specifies the privilege that you are configuring for the NAS
Gateway admin in IDENTITY. This argument accepts any of the
admin privileges listed in Table 2-2 on page 2-3 for exec
privileges. Enter the privilege in uppercase.
cluster Specifying cluster applies privileges to all virtual servers within

that cluster.
vsvr Specifying vsvr applies privileges to the current virtual server.

[VIRTUALSERVER] Specifying vsvr [VIRTUALSERVER] applies privileges to a
2-7
Displaying the Configured Privileges

The privileges table contains a list of configured privileges and information about each
privilege’s scope. You can display the contents of the privileges table by running the
priv show command.
To Display Configured Privileges

priv show cluster|vsvr [VIRTUALSERVER]
[-P PAGENUMBER] [-S PAGESIZE]
Options and
Description
Arguments
cluster Shows privileges of all virtual servers within that cluster.
vsvr Shows privileges of the current virtual server.
VIRTUALSERVER Specifies the virtual server that you want to show privileges for.
-P PAGENUMBER Shows privileges by page number.
-S PAGESIZE Show privileges by page size in number of records.
Deleting an Allow Rule

You can delete an allow rule at any time by running the priv delete allow
command. This command allows you to delete privileges of a specified user or group.
To Delete an Allow Rule
priv delete allow {user|group} IDENTITY PRIVILEGES
Options and
Description
Arguments
2-8

the name of the user or group. If you specify group, the IDENTITY
argument names the group, and if you specify user, the
IDENTITY argument names the user.
IDENTITY Specifies the name of the user or group for which you are deleting
an allow rule. Use an alphanumeric character string.
This argument works in combination with the user|group argument
to specify the name of a user or group. Enter the identity as one of
the following:
group
• UserOrGroupName@DomainName for a NIS or LDAP user or
group from an NIS or LDAP domain
PRIVILEGES Specifies the privilege for which you are deleting the allow rule in
IDENTITY. This argument accepts any of the privileges listed in
Table 2-2 on page 2-3 for exec privileges. Enter the privilege in
uppercase.
cluster Specifying cluster deletes an allow rule on all virtual servers within
that cluster.
vsvr Specifying vsvr deletes an allow rule on the current virtual server.
[VIRTUALSERVER] Specifying vsvr [VIRTUALSERVER] deletes an allow rule on a
Deleting a Deny Rule

You can delete a deny rule at any time by running the priv delete deny command.
This command allows you to delete privileges from a specified user or group.
2-9
To Delete a Deny Rule

priv delete deny {user|group} IDENTITY PRIVILEGES
Options and
Description
Arguments
user|group This argument interacts with the IDENTITY argument to

specify the name of the user or group. If you specify group, the
IDENTITY argument names the group, and if you specify user,
the IDENTITY argument names the user.
IDENTITY Specifies the name of the user or group for which you are
deleting a deny rule. Use an alphanumeric character string.
group
PRIVILEGES Specifies the privilege for which you are deleting the deny rule
in IDENTITY. This argument accepts any of the privileges listed
in Table 2-2 on page 2-3 for exec privileges. Enter the privilege
in uppercase.
cluster|vsvr Specifying cluster deletes a deny rule on all virtual servers

within that cluster.
[VIRTUALSERVER] Specifying vsvr deletes a deny rule on the current virtual

server. Specifying vsvr [VIRTUALSERVER] deletes a deny
rule on a specified virtual server.
2-10
Managing Local User Accounts

A local user account gives you a user identity for accessing NAS Gateways. You can
assign privileges to a local user account and use it for specific system functions and
applications. For example, a local user account is necessary to run Network Data
Management Protocol (NDMP).
Unlike NIS or Windows user accounts that reside on the domain controller or NIS
server, the NAS Gateway local user account has no effect outside of the NAS
Gateway. Because the local user account is configured on the NAS Gateway, the
account name cannot contain a domain name and does not need to be authenticated
through a domain controller.
Each local user account is a cluster-wide entity, so you can use the same local user
account on any NAS Gateway in a cluster. However, each local user account must be
unique within a cluster.
Note - If you want to launch the ONStor VirusScan applet from any user
account, you need to configure that user account with BACKUP and
RESTORE privileges because the VirusScan applet needs to access files in
read/write mode in the virtual server. The scope of the privilege can be either
VIRTUAL SERVER or CLUSTER.
You need to configure a local user account with LOGIN privilege to allow the
owner of the local user account to login to the NAS Gateway. With LOGIN
privilege, the owner of the local user account can also run any of the show
commands - for example, arp show - but cannot configure or change any
parameters.
You can configure a local user account to support SSH keys for access to the NAS
Gateway without a password.
Adding a Local User Account

This procedure creates a new user account on the NAS Gateway. As part of the
account creation, you are required to specify a password for the user account you are
2-11
configuring. When you enter the user name, the NAS Gateway prompts you for the
user account's password. Enter the password for the account. For security purposes,
the password is not displayed when you configure it with this command.
To Add a Local User Account
Step 1: Run the following command:
useraccount add USERNAME [-k PUBKEY]
Options and
Description
Arguments
USERNAME Specifies the user account name by using an alphanumeric

character string from 3 to 63 characters.
-k PUBKEY Specifies the SSH key for a local user account. This argument
must be the SSH key that the client generated. If the key is not
supplied or is not an exact match with the client’s SSH key, the
user account cannot automatically log in. Therefore, you need
to enter a password every time the user account accesses the
NAS Gateway.
The first time you create a local user account, you need to
specify the password, even if you use the -k PUBKEY
argument.
Step 2: When prompted, do either of the following:

• Enter the password for the user account you just created.
• Enter the SSH key that the client generated for the local user
account.
Step 3: Set the privileges for the user account you just created by running
the priv add allow command.
Changing a Local User Account Password or SSH Key

You can modify the password or SSH key for the local user account at any time by
running the useraccount modify command.
2-12
When you run the useraccount modify command, the NAS Gateway either prompts
you to enter the new password for a specified user account or a new SSH key.
• When you enter the new password, it becomes active immediately.
• When you enter a new SSH key, it overwrites any existing SSH key for the local
user account, and becomes active immediately.
To Change the Password or SSH Key Associated With a Local User
Account
useraccount modify USERNAME [-k PUBKEY]
Options and
Description
Arguments
USERNAME Specifies the user account name by using an alphanumeric

-k PUBKEY Specifies the SSH key for a local user account. This argument
must be the SSH key that the client generated. If the key is not
supplied or is not an exact match with the client’s SSH key, the
user account cannot automatically log in. Therefore, you need
to enter a password every time the user account accesses the
NAS Gateway.
The first time you create a local user account, you need to
specify the password, even if you use the -k PUBKEY
argument.
Step 2: When prompted, enter the password for the user account you just
created.
Displaying a Local User Account

When a local user account is created, it is added to the local user account list, which
contains all defined local user accounts for NDMP in the current virtual server. You
can display the configured local user accounts by running the useraccount show
command.
2-13
To Display All Local User Accounts

useraccount show
Deleting a Local User Account

You can remove a local user account at any time by running the useraccount delete
command. The deletion is effective immediately.
To Delete a Local User Account
Step 1: To locate the local user account you want to delete, run the
following command:
useraccount show
Note the user account name for use in the next step.
useraccount delete USERNAME
USERNAME specifies the user account by using an alphanumeric
2-14
Chapter 3: Working with Virtual
Servers
• “Understanding Virtual Servers” on page 3-2
• “Understanding the Management Virtual Server” on page 3-4
• “Creating a Virtual Server and Performing Basic Setup” on page 3-7
3-2
Understanding Virtual Servers

A virtual server is a software entity that enables the logical association of elements
required for file services.
Note - When a node is added to a cluster, you need to ensure that all virtual
servers reside on the Primary cluster.
Two types of virtual servers exist within a NAS Gateway:

• Management virtual server, which is automatically created when the NAS
Gateway is started for the first time. The management virtual server is used to
support the core volume and management volume. For more information about the
core volume and management volume, see “Understanding the Management
Volume” on page 6-2.
• Virtual servers, which you create and configure to provide file services.
Supported Features
Virtual servers support the following two features:
• Failover - When a virtual server is set to protected mode, it supports failover.
When it is set to unprotected mode, it does not support failover.
• Manual load balancing - You can manually assign a virtual server to different NAS
Gateways to facilitate load Balancing.
You need to create at least one virtual server to enable client input/output (I/O) on the
NAS Gateway. When you create a virtual server, you configure it with all the pertinent
components for supporting failover and load balancing. The following components are
required for creating and configuring a virtual server:
• A unique name so that each virtual server can be addressed individually
• At least one IP interface for connectivity to the client’s IP network
For the virtual server to provide file services, you need to configure the following
components:
3-3
• Volumes
• Lightweight Directory Access Protocol (LDAP), Network File System (NFS) or
Common Internet File System (CIFS) shares
• Routes, which are associated with an IP interface
You can set the route table, interface table, and address resolution protocol (ARP)
table for each virtual server individually.
Multiple virtual servers can exist on a NAS Gateway, but NAS Gateways cannot share
the same virtual server. Each cluster can support up to 32 virtual servers. The
automatically created management virtual servers (one per NAS Gateway in the
cluster) do not count against the maximum number of virtual servers.
Virtual Server States

Virtual servers can be in one of two states:
• Enabled: The state when the virtual server has been created and enabled in a
cluster.
• Disabled: The state when the virtual server is not online and clients cannot
connect to the virtual server. This state is the default state when you create the
virtual server. When you have configured the virtual server, you need to enable it.
Note - When you disable a configured virtual server, you interrupt the file
services and IP connectivity provided to the clients.
3-4
Understanding the Management Virtual Server

Each NAS Gateway has one management virtual server that is automatically created
when the NAS Gateway is started for the first time. The management virtual server
provides:
• Continuous availability of core dump functionality
• Continuous availability of a management volume
The management virtual server requires no network-related configuration because that
configuration is done on the individual virtual servers. However, if you are using any
of the following features, some configuration is required:
• A temporary directory for NDMP backup and restore operations. To use this
feature you need to create and configure a management volume from the
management virtual server context.
• Core dump space for failure information. To use this feature you need to create and
configure a core volume from the management virtual server context.
• Autosupport mechanism. The management virtual server is preconfigured for the
autosupport mechanism.
Note - For autosupport to function, the management virtual server must have
the DNS resolver configured, which you can configure through the system
dnsconfigure resolver command. For more information, see “Configuring
DNS Name Resolution for a Virtual Server” on page 3-46.
Because the management virtual server is unprotected, it does not failover to another
NAS Gateway if the NAS Gateway is configured in a clustered environment. The
management virtual server cannot be moved within a cluster.
The management virtual server always contains the name string “VS_MGMT” and a
numerical ID. The ID is generated when the management virtual server name is
created, and is an identifier only. It has no relation to the number of virtual servers
configured.
3-5
Virtual Server Context and NAS Gateway Context

When the NAS Gateway is initially booted, by default all resources belong to the NAS
Gateway, and not to a specific virtual server. After you have created at least one virtual
server, two types of context exist from which you can perform tasks, such as running
commands for creating and configuring virtual servers:
• NAS Gateway context
• Virtual server context
The context from which you are running commands determines the scope of the
commands’ effects. Some features, such as the interfaces, route table, and ARP table,
display different information depending on whether you are viewing them from the
NAS Gateway context or a specific virtual server context.
Note - You need to make the configurations for any virtual server within the
context of that virtual server.
You can determine whether you are in virtual server or NAS Gateway context by
looking at the command-line prompt, as shown in the following examples:
eng33> Shows the default prompt, which is the NAS
Gateway’s unique node name. This command
prompt indicates that you are in NAS Gateway
context.
eng33 PUBSTEST> Shows the virtual server named PUBSTEST.
The value eng33 is the NAS Gateway’s unique
node name. This prompt indicates that you are
in the virtual server context.
Table 3-3 lists the virtual server commands, the contexts in which they are available,
and the virtual server state necessary to run the command. If a virtual server state is
3-6
listed as N/A, the command does not depend on the virtual server state, so you can run
the command regardless of the virtual server state.
Table 3-3: Command Availability
NAS Virtual
Virtual
Command Gateway Server
Server State
Context Context
system dnsconfigure show Yes Yes N/A
system dnsconfigure hosts Yes Yes N/A
system dnsconfigure resolver Yes Yes N/A
vsvr create Yes No N/A. By

default, virtual
servers are
created
“disabled”.
vsvr clear No Yes N/A
vsvr clear autocreate No Yes Disabled
vsvr clear domain No Yes Disabled
vsvr set unprotected No Yes N/A
vsvr clear wins No Yes Disabled
vsvr delete Yes, if you Yes, but with N/A

specify the or without the
virtual server virtual server
name name
vsvr disable No Yes Enabled
vsvr enable No Yes Disabled
vsvr move No Yes N/A
vsvr set NAME Yes Yes N/A
vsvr set name netbios NAME No Yes Disabled
3-7
Table 3-3: Command Availability (Continued)
NAS Virtual
Virtual
Command Gateway Server
Server State
Context Context
vsvr set name generic NAME No Yes Disabled
vsvr set autocreate No Yes Disabled
vsvr set domain No Yes Disabled
vsvr set protected No Yes N/A
vsvr set wins No Yes Disabled
vsvr show Yes Yes N/A
Creating a Virtual Server and Performing Basic Setup

You can create virtual servers only from the context of the NAS Gateway by running
the vsvr create command. The NAS Gateway does not support nested virtual
servers. When the vsvr create command completes, you are automatically put into
the virtual server context. If you are in a virtual server context and you want to
configure a new virtual server, return to the NAS Gateway context with the vsvr
clear command.
To Create a Virtual Server and Perform Basic Setup

3-8
vsvr create VIRTUALSERVER [-n NODE] [-u]
Options and
Description
Arguments
VIRTUALSERVER Specifies the name of the virtual server you are creating. Use an
alphanumeric character string from 1 to 15 characters. Do not
use special characters in the virtual server name, such as *, ?,
and /.
• Virtual server names need to start with an alphabetic or
numeric character.
• Each virtual server name must be unique within a cluster.
Even though virtual server names are displayed in
uppercase, they are case insensitive with all vsvr
commands. Therefore, you can use upper or lowercase
when specifying a virtual server name.
• Virtual servers cannot be named with VS_MGMT because
that string is reserved for the management virtual server.
• The keyword All is reserved and cannot be used as a virtual
server name.
-n NODE An optional argument that configures the virtual server on any

NAS Gateway in a cluster.
• If you specify the -n option and enter a NAS Gateway
name, the virtual server is created on that NAS Gateway.
• If you do not specify the -n option, the virtual server is
created on the current NAS Gateway.
-u An optional argument that sets the virtual server to unprotected

mode. By default, virtual servers are created in protected mode.
• If you specify the -u option, the virtual server will not be
switched to another NAS Gateway if the NAS Gateway is
forced to reset.
• If you do not specify the -u option, the virtual server is
created in protected mode (the default). This mode makes
the virtual server transportable to a different NAS Gateway
on failover.
3-9
Note - The virtual server name you create is also the NetBIOS name by
default.
Step 2: Assign an IP interface to the virtual server by running the

interface create command:
interface create INTERFACE -l LPORT
[-s (enable|disable)] [-t VLANTAG]
[-a IPADDR/MASKLEN] [,IPADDR/MASKLEN] ...]
[-p [cifs=(enable | disable)],
[nfs=(enable|disable)]] [-w PRIMARYIPADDR
[,SECONDARYIPADDR]]
The interface create command is run from within the context of the current virtual
server so you do not need to specify the virtual server name. You can configure a
virtual server with no interfaces, but for client connectivity, each virtual server must
have at least one IP interface.
Options and
Description
Arguments
INTERFACE Specifies the name you want to give the interface.
-l LPORT Specifies the name of the logical port that the interface uses.
For more information about logical ports, see “Working with
Logical Ports” on page 5-12.
-s enable|disable Specifies the interface’s state, either enabled or disabled. The

interface state takes precedence over other parameters’ states.
For example, if you create the interface in disabled state, but set
CIFS and NFS to enabled, then CIFS and NFS access is also
disabled on the interface because the interface is not online.
3-10
Options and
Description
Arguments
-t VLANTAG Specifies a VLAN tag enabling the NAS Gateway to process

802.1q packets. The value for VLAN tags can be any number
between 0 and 4095. A value of 0 indicates that VLAN tagging
is disabled for that interface. You can assign one VLAN tag per
interface.
Note - The VLANTAG option of this command is only available

if you are running the command from the virtual server context.
For the virtual server, the IP address of each interface has to be

unique. The virtual server does not support overlapping subnets
across VLANs. Do not use the same VLAN number for different
interfaces on the same virtual server.
-a IPADDR/MASKLEN Specifies the IP address and mask length in bits that you are
adding. Each virtual server can support up to 32 IP interfaces.
,IPADDR/MASKLEN An optional comma-separated list of IP addresses and masks

that you can add to the interface.
3-11
Options and
Description
Arguments
-p The argument that supports controlling the file access protocol

state for either CIFS or NFS when the interface is created:
• -p cifs=enable|disable allows you to create the
interface with CIFS either enabled or disabled. After the
interface is created, you can change the state of CIFS on
the interface by running the interface modify
command.
• -p nfs=enable|disable allows you to create the
interface with NFS either enabled or disabled. After the
interface is created, you can change the state of NFS on the
interface by running the interface modify command.
• For a multiprotocol environment, you can run the arguments
in the same command if you separate them with a comma.
For example:
-p cifs=enable,nfs=enable would create an interface
with both CIFS and NFS enabled on the same interface.
By default, all protocols are enabled when the interface is
created.
-w PRIMARYIPADDR Specifies the primary WINS server address for interfaces

supporting CIFS that need WINS.
,SECONDARYIPADDR Specifies the secondary WINS server address, if needed. If you

are specifying the secondary WINS server address, make sure
you separate the primary and secondary IP addresses with a
comma.
Note - The same physical and logical port can be used by

different virtual servers, but the same IP address cannot be
used on multiple virtual servers.
Step 3: Create a default route for the virtual server by running the route
add command:
route add default -g IPADDR
-g IPADDR is the IP address of the gateway.
3-12
Example:
route add default -g 10.2.0.1
Modifying Virtual Server Interfaces

Any time after you’ve created a virtual server, you can make changes to its interfaces
by running the interface modify command. Through this command you can
modify interfaces in any of the following ways:
• Change the logical port associated with the interface.
• Change the state of the interface to either disabled or enabled.
• Add or delete IP addresses on the interface.
• Enable or disable CIFS or NFS on the interface.
• Change the WINS server address, or add a backup WINS server.
• Enable or disable protocols associated with the interface.
• Change or disable VLAN tagging.
To Modify a Virtual Server Interface
interface modify INTERFACE [-l LPORT]
[-s (enable|disable)] [-t VLANTAG]
[-a IPADDR/MASKLEN] [,IPADDR/MASKLEN] ...]
[-d IPADDR][-p [cifs=(enable | disable)],
[nfs=(enable|disable)]]
[-w PRIMARYIPADDR [,SECONDARYIPADDR]]
Options and
Description
Arguments
INTERFACE Specifies the location of the NAS Gateway and port where you
want to modify the IP interface.
-l LPORT An optional argument that specifies name of the logical port

that the interface uses.
3-13
Options and
Description
Arguments
-s enable|disable Enables or disables the entire interface. If you use this

argument to change the state of the interface, all the
interface’s parameters are affected. For example, if you
disable an interface that supports a multiprotocol share, CIFS
and NFS access is also disabled on the interface even though
you have not explicitly disabled the individual protocols on the
interface.
-t VLANTAG Specifies a VLAN tag that enables the NAS Gateway to

process 802.1q packet. The value for VLAN tags can be any
number between 0 and 4095. A value of 0 indicates that VLAN
tagging is disabled for that interface. You can assign one
VLAN tag per interface.
Note - The VLANTAG option of this command is only

available if you are running the command from the virtual
server context.
For the virtual server, the IP address of each interface has to

be unique. The virtual server does not support overlapping
subnets across VLANs. Do not use the same VLAN number
for different interfaces on the same virtual server.
-a IPADDR/MASKLEN Specifies the IP address and mask length in bits for the
interface that you are adding. Each virtual server can support
up to 32 IP interfaces.
,IPADDR/MASKLEN An optional comma-separated list of IP addresses and mask

lengths that you can add to the interface.
3-14
Options and
Description
Arguments
-p The argument that controls the state of CIFS or NFS:

• -p cifs=enable|disable allows you to enable or disable
CIFS on the interface.
• -p nfs=enable|disable allows you to enable or disable
NFS on the interface.
• For a multiprotocol environment, you can run the
arguments in the same command if you separate them
with a comma. For example:
-p cifs=disable,nfs=disable would disable both CIFS
and NFS on the same interface.
By default, all protocols are enabled when the interface is
created.
-w PRIMARYIPADDR Specifies the primary WINS server address for interfaces

supporting CIFS that need WINS.
,SECONDARYIPADDR Specifies the secondary WINS server address, if needed. If

you are specifying the secondary WINS server address, make
sure you separate the primary and secondary IP addresses
with a comma.
Joining Virtual Servers to a Domain

For virtual servers and NAS Gateways to be visible to clients, you need to add the
NAS Gateway to the domain that clients use. The NAS Gateway supports any of the
following client domain environments:
• LDAP (Lightweight Directory Access Protocol) for NFS and CIFS clients. For
CIFS clients using LDAP, the LDAP domain environment is set as a Windows
domain.
• Network information services (NIS) domain for NFS clients.
• Windows domain for CIFS clients.
Adding a virtual server to a domain occurs in two steps:
1. Add a domain to the NAS Gateway using the domain add
command.
3-15
2. Add the virtual servers associated with the NAS Gateway to a

domain using the vsvr set domain command.
Note - Disable virtual servers before joining them to domains.
When the virtual servers are added to the domains, the remaining configuration and
management of the NAS Gateway is done through the virtual servers. For more
information about configuring virtual servers, see “Working with Virtual Servers” on
page 3-1.
LDAP or NIS authentication is not mandatory for supporting NFS shares. It is only
required if the virtual server contains volumes with data that is accessed by both CIFS
and NFS clients.
In a Windows domain, CIFS authentication enables the addition of a virtual server to
the domain so that clients can access the virtual server’s resources.
After you have added LDAP, NIS, or Windows domain to the NAS Gateway cluster,
you can add virtual servers to the domain with the vsvr set domain command.
The following sections document the commands necessary to add and manage the
virtual server in an LDAP, NIS, or Windows domain. For more information about
joining the virtual server to an LDAP, NIS, or Windows domain, see:
• “Adding a Virtual Server and a NAS Gateway to an LDAP Domain” on page 3-15
• “Adding a Virtual Server and a NAS Gateway to a NIS Domain” on page 3-19
• “Adding a Virtual Server and a NAS Gateway to a Windows Domain” on page 3-
21
Adding a Virtual Server and a NAS Gateway to an LDAP Domain
You can add an LDAP domain to the NAS Gateway’s configuration by running the
domain add ldap command. This command also specifies the primary LDAP server
and optionally, a backup LDAP server with which the NAS Gateway will register to
become a part of the domain.
To Configure the NAS Gateway for an LDAP Domain
Step 1: From the NAS Gateway context, run the following command:
3-16
domain add ldap DOMAINNAME SERVER_URIS

DEFAULT_BASE_SCOPE [-u LOGIN_DN]
[-p PASSWORD_BASE_SCOPE] [-g GROUP_BASE_SCOPE]
[-h HOST_BASE_SCOPE] [-n NETGROUP_BASE_SCOPE]
Options and Arguments Description
DOMAINNAME Specifies the name of the LDAP domain that is used for
authentication. Use an alphanumeric character string of
up to 63 characters. Do not use restricted characters
such as *,~,?, and !.
SERVER_URIS Specifies the LDAP server host name or IP address and

port. You can specify up to 32 servers by including them
in quotation marks (“) and separating the list with
commas and spaces (, ). For example, a string
specifying the LDAP server ldap://192.168.3.1 can use
any of the following formats:
• ldap://server.example.com:345
• ldap://192.168.2.1:678
• 192.168.3.1
• server.example.com
3-17
DEFAULT_BASE_SCOPE Specifies the default base distinguished name (DN) and

scope to be used for LDAP searches. Examples:
“ou=eng, o=company, c= us: SUB”,
“ou=qa, o=company, c= us: BASE”,
“ou=finance, o=company, c= us: ONE”
• BASE specifies a search at the root layer of the
directory.
• ONE specifies a search at one layer of the
directory.
• SUB specifies a search through all subdirectories of
the tree.
Note - When enclosing values in quotation marks, a

space between the values after the comma is valid. A
space before the values BASE, SUB, and ONE is
required.
If the scope is not specified or is not BASE, ONE, or

SUB, the default scope is SUB.
The following arguments are optional.
-u LOGIN_DN Specifies the login DN to be used for administrative

queries. Example: “cn=admin, dc=example,
dc=com”.
If you enter this argument, you are prompted for that
account’s password.
-p PASSWORD_BASE_SCOPE Specifies the base DN and scope to be used for user

account-related LDAP searches. Example:
“ou=People, o=company, c=us: SUB”.
-g GROUP_BASE_SCOPE Specifies the base DN and scope to be used for user

group-related LDAP searches. Example:
“ou=Groups, o=company, c=us: BASE”.
-h HOST_BASE_SCOPE Specifies the base DN and scope to be used for LDAP

searches related to the host name and address.
Example: “dc=example,dc=com: ONE”.
3-18
-n A character string that specifies the base DN and scope

NETGROUP_BASE_SCOPE for LDAP searches related to NIS netgroups. Example:
“cd=example,dc=com: SUB”.
Note - Because all optional arguments are character strings, verify any values
you enter with your LDAP system administrator to ensure that they are valid.
Invalid values cause LDAP search errors and might produce unexpected
results.
Step 2: From the virtual server context, run the following command to
disable the virtual server:
vsvr disable
Step 3: From the virtual server context, run the following command to add
the virtual server to the domain:
vsvr set domain ldap DOMAINNAME
DOMAINNAME specifies the domain name for the virtual server.
DOMAINNAME is the domain name you previously specified in
the NAS Gateway using the domain add ldap command.
enable the virtual server:
vsvr enable
verify the LDAP domain configuration and to connect to the LDAP
server:
domain verify ldap DOMAINNAME
DOMAINNAME specifies the LDAP domain name for the virtual
server. DOMAINNAME is the domain name you previously
specified in the NAS Gateway using the domain add ldap
command.
3-19
Adding a Virtual Server and a NAS Gateway to a NIS Domain

You can add a NIS domain to the NAS Gateway’s configuration by running the
domain add nis command, which specifies the NIS domain controller with which
the NAS Gateway will register to become a part of the domain.
Note - The domain that you are adding needs to exist before running this
command because the NAS Gateway attempts to register with the domain
controller when this command completes.
After you have added the NAS Gateway to a NIS domain, you can add virtual servers
associated with the NAS Gateway to the NIS domain with the vsvr set domain
command.
To Add the NAS Gateway to a NIS Domain
domain add nis DOMAINNAME IPADDR
Options and
Description
Arguments
DOMAINNAME Specifies the name of the LDAP domain that is used for
authentication. Enter an alphanumeric character string of up to
63 characters. Do not use restricted characters such as *,~,?,
and !.
Note - If you need to log in to the NAS Gateway through this

domain, use the NIS identity format, for example,
userA@domainY.
IPADDR Specifies the IP address of the NIS server.
vsvr disable
3-20
vsvr set domain nis DOMAINNAME
DOMAINNAME specifies the domain name for the virtual server.
DOMAINNAME is the domain name you previously specified in
the NAS Gateway using the domain add nis command.
vsvr enable
Note - When a NIS domain is configured for a virtual server, client host name
resolution occurs through a NIS server, not through the DNS resolver. With
local NIS maps, no NIS server exists for the virtual server, so client host name
resolution does not occur for the virtual server. Therefore, configure DNS on
each virtual server that is using local NIS maps.
verify the NIS domain configuration:
domain verify nis DOMAINNAME IPADDR [IPADDR]
Options and
Description
Arguments
DOMAINNAME Specifies the domain name by using an alphanumeric character

string.
IPADDR Specifies the IP address of the NIS server or domain controller

from which to retrieve the configuration information.
[IPADDR] An optional argument that specifies up to four additional IP

addresses of NIS servers serving the same domain.
3-21
Adding a Virtual Server and a NAS Gateway to a Windows

Domain
Add a Windows domain to the NAS Gateway’s configuration by running the domain
add windows command. This command also specifies the primary domain controller
(PDC) and optionally, a backup domain controller (BDC) with which the NAS
Gateway will register to become a part of the domain.
Note - The domain that you are adding needs to exist before running this
command because the NAS Gateway attempts to register with the domain
controller when this command completes.
To Configure the NAS Gateway in a Windows Domain

domain add windows DOMAINNAME LOGINUSER HOSTNAME
[HOSTNAME] [-NONETBIOS] [-k KRBDOMAINNAME]
[-t CLOCKSKEW]
DOMAINNAME Specifies the domain name by using an alphanumeric

character string. For Windows domains, this should
currently be the NetBIOS Windows domain name.
LOGINUSER Specifies a user name that will be used to contact the

domain controllers. Use an alphanumeric character string.
This argument is applicable only to Windows domains.
LOGINUSER can be a regular domain user account with
"domain user" group.
HOSTNAME Specifies the IP (A.B.C.D) or hostname of the domain

controller that should be contacted for retrieving the
domain information. In case [-NONETBIOS] is set, the
HOSTNAME needs to be the hostname, not the IP
address.
For a Windows NT domain, this is the IP or hostname of
the Primary Domain Controller (PDC).
3-22
[HOSTNAME] An optional argument that specifies the hostname or IP

address of up to three additional primary domain
controllers for a Windows domain. If the -NONETBIOS
option is set, HOSTNAME needs to be the DNS host
name.
[-NONETBIOS] This option should be set when the Domain Controller

server can only be contacted by using either DNS or
LDAP name resolution (when NetBIOS name resolution is
not configured on the Domain Controller). When this
option is used, the Domain Server name should be used
instead of the Domain Controller server IP in the
HOSTNAME field.
When using the domain show command, this domain is
displayed with an asterisk (*) next to it.
[-k KRBDOMAINNAME] This option needs to be set for adding a Kerberos domain
only.
[-t CLOCKSKEW] Max. clock skew value in minutes. This option can be
specified only with -k option. Clock skew ranges from 1 to
9999 minutes.
Default value is 5 minutes. All clocks must be
synchronized.
vsvr disable
3-23
vsvr set domain windows DOMAINNAME ADMINUSER

[-o ORGUNIT]
Options and
Description
Arguments
DOMAINNAME Specifies the name of the Windows domain that you are setting
for the virtual server.
ADMINUSER Specifies the name of the Windows domain administrator to use

when the virtual server joins the domain. ADMINUSER should
be a domain user account with full privilege.
[-o ORGUNIT] Specifies the organizational unit in which the computer object
for the virtual server should be created. This option can be set
only for a Kerberos domain.
Note - If any portion of ORGUNIT contains spaces, it should

be enclosed in quotes.
vsvr enable
Displaying the Domains Associated with a NAS Gateway

The NAS Gateway tracks all the domains it has joined in the domain list. This list is
available on each cluster. You can display the NAS Gateway’s domain list by running
the domain show command. By adding keywords to the domain show command,
you can filter the display by the following categories:
• All domains regardless of domain type
• All LDAP domains
• All NIS domains
• All Windows domains
3-24
To Display the Domains in Which the NAS Gateway is Participating

domain show {all|ldap|nis|windows}
Choose from all|ldap|nis|windows to specify the type of
domain that you are displaying.
• all displays a list of all LDAP, NIS, and Windows domains
configured on the NAS Gateway.
• ldap displays a list of all LDAP domains configured on the
NAS Gateway.
• nis displays a list of all NIS domains configured on the NAS
Gateway.
• windows displays a list of all Windows domains configured
on the NAS Gateway.
Displaying LDAP Domain Schemas

You can display the contents of the LDAP domain schema with the domain show
ldap schema command. The display contains the following schema information:
• User (object class, attribute name for the user name, attribute name for the user ID,
and attribute name for the user password)
• Group (object class, attribute name for the group name, attribute name for the
group ID, and attribute name for the group member)
• Netgroup (object class, attribute name for the netgroup name, attribute name for
the netgroup triple (user, host, and domain), and attribute name for the netgroup
member)
• Host (object class, attribute name for the host’s canonical name, attribute name for
the hosts’s alias names, attribute name for the host’s IP address)
To Display the Schema of a Configured LDAP Domain
domain show ldap schema DOMAINNAME
3-25
DOMAINNAME is the LDAP domain name.
Modifying the LDAP Domain Information for a NAS Gateway

You can modify parameters of an existing domain by running the domain modify
command.
Note - Except for the -s SERVER_URIS and the -d DEFAULT_BASE_SCOPE

options, you can enter an empty string to clear an option.
If the scope is not specified or is not BASE, ONE, or SUB, the default scope is
SUB.
To Modify the LDAP Domain Information in the NAS Gateway

Step 1: From the NAS Gateway context, run the following command to
locate the domain information that you want to modify:
domain modify ldap DOMAINNAME [-s SERVER_URIS]
[-d DEFAULT_BASE_SCOPE] [-u LOGIN_DN]
[-p PASSWORD_BASE_SCOPE] [-g GROUP_BASE_SCOPE]
[-h HOST_BASE_SCOPE] [-n NETGROUP_BASE_SCOPE]
DOMAINNAME Specifies the name of the LDAP domain membership

that you are modifying. Use an alphanumeric
character string of up to 63 characters. Do not use
restricted characters such as *,~,?, and !.
3-26
SERVER_URIS Specifies the LDAP server host name or IP address

and port. You can specify up to 32 servers by
including them in quotation marks (“) and separating
the list with commas and spaces (, ). For example, a
string specifying the LDAP server ldap://
192.168.3.1 can be either of the following formats:
• ldap://server.example.com:345
• ldap://192.168.2.1:678
• 192.168.3.1
• server.example.com
DEFAULT_BASE_SCOPE Specifies the default base distinguished name (DN)

and scope to be used for LDAP searches. Examples:
“ou=eng, o=company, c= us: SUB”,
“ou=qa, o=company, c= us:BASE”,
“ou=finance, o=company, c= us: ONE”
• BASE specifies a search at the root layer of the
directory.
• ONE specifies a search at one layer of the
directory.
• SUB specifies a search through all subdirectories
of the tree.
Note - If the scope is not specified or is not BASE,

ONE, or SUB, the default scope is SUB.
When enclosing values in quotation marks, a space

between the values after the comma is valid. A space
before the values BASE, SUB, and ONE is required.
The following arguments are optional.
3-27
-u LOGIN_DN Specifies the login DN to be used for administrative

queries. Example: “cn=admin, dc=example,
dc=com”.
Note - If you enter this argument, you are prompted

for that account’s password.
-p PASSWORD_BASE_SCOPE Specifies the base DN and scope to be used for user

account-related LDAP searches. Example:
“ou=People, o=company, c=us: SUB”.
-g GROUP_BASE_SCOPE Specifies the base DN and scope to be used for user

group-relates LDAP searches. Example:
“ou=Groups, o=company, c=us: BASE”.
-h HOST_BASE_SCOPE Specifies the base DN and scope to be used for

LDAP searches related to the host name and
address. Example: “dc=example, dc=com:
ONE”.
-n NETGROUP_BASE_SCOPE Specifies the base DN and scope for LDAP searches

related to NIS netgroups. Example:
“cd=example,dc=com: SUB”.
Note - Because all optional arguments are character

strings, verify any values you enter with your LDAP
system administrator to ensure that they are valid.
Invalid values cause LDAP search errors and might
produce unexpected results.
Step 3: Run the following command to verify the LDAP domain

configuration:
DOMAINNAME is the name of the LDAP domain.
3-28
Modifying Schemas of LDAP Domain Configurations

You can modify the schema of a configured LDAP domain by running the domain
modify ldap schema command. With this command you can modify the following
schemas:
• User
• Group
• Netgroup
• Host
To Modify the Schema of an LDAP Domain
domain modify ldap schema (user | group | netgroup |
host) DOMAINNAME [OPTIONS ...]
Options and
Description
Arguments
user The user schema. In the user schema you can modify the user
object class, the user name, the user ID number, and the user
password.
group The group schema. In the group schema you can modify the
object class, the group name, the group ID number, and the
group member ID.
netgroup The netgroup schema. In the netgroup schema you can modify
the object class, the netgroup name, the netgroup triple (user,
host, domain), and the netgroup member ID.
host The host schema. In the host schema you can modify the object
class, the host name, and the host’s IP address.
DOMAINNAME Specifies the LDAP domain name by using an alphanumeric

character string.
OPTIONS A set of optional arguments through which you can specify

object class names and attribute names.
3-29
Options and
Description
Arguments
For the group portion of the LDAP schema, the following

options are available:
• -o OBJECTCLASS — the object class name for the group.
The RFC2307 value is posixGroup. The default Windows
ADS value is group.
• -n GROUPNAME — the attribute name for the group
name. The RFC2307 value is cn. The default Windows ADS
value is msSFU30Name.
• -i GID — the attribute name for the group ID. The
RFC2307 value is gidNumber. The default Windows ADS
value is msSFU30GidNumber.
• -m MEMBERNAME — the attribute name for the group
member. The RFC2307 value is memberUid. The default
Windows ADS value is msSFU30MemberUid.
For the host portion of the LDAP schema, the following

• -o OBJECTCLASS — the object class name for a host, for
example, the IP device. The RFC2307 value is ipHost. The
default Windows ADS value is computer.
• -n HOSTNAME — the attribute name for a host’s
canonical name. The RFC2307 value is cn. The default
Windows ADS value is msSFU30Name.
• -l HOSTALIASES — the attribute name for a host’s alias
names.The RFC2307 value is cn. The default Windows
ADS value is msSFU30Aliases.
• -a HOSTADDR — the attribute name for a host’s IP
address. The RFC2307 value is ipHostNumber. The default
Windows ADS value is msSFU30IpHostNumber.
3-30
Options and
Description
Arguments
For the netgroup portion of the LDAP schema, the following

• -o OBJECTCLASS — the object class name for the NIS
netgroup. The RFC2307 value is nisNetGroup. The default
Windows ADS value is msSFU30NisNetgroup.
• -n NETGROUPNAME — the attribute name for the
netgroup name. The RFC2307 value is cn. The default
Windows ADS value is msSFU30Name.
• -t NETGROUPTRIPLE — the attribute name for the
netgroup triple. The RFC2307 value is nisNetgroupTriple.
The default Windows ADS value is
msSFU30NetgroupDetail.
• -m NETGROUPMEMBER — the attribute name for the
netgroup member. The RFC2307 value is
memberNisNetgroup. The default Windows ADS value is
msSFU30NetgroupDetail.
For the user portion of the LDAP schema, the following

• -o OBJECTCLASS — the object class name for the user
account. The RFC2307 value is posixAccount. The default
Windows ADS value is user.
• -n USERNAME — The attribute name for the user name.
The RFC2307 value is uid. The default Windows ADS value
is msSFU30Name.
• -i UID — the attribute name for the user ID. The
RFC2307 value is uidNumber. The default Windows ADS
value is msSFU30UidNumber.
• -p PASSWORD — the attribute name for the user
password. The RFC2307 value is userPassword. The
default Windows ADS value is msSFU30Password.
Step 2: Run the following command to verify the LDAP domain

configuration:
3-31
DOMAINNAME is the name of the LDAP domain.
Modifying the NIS Domain Information for a NAS Gateway

You can modify parameters of an existing domain by running the domain modify nis
command.
To Modify the NIS Domain Information In the NAS Gateway
domain modify nis DOMAINNAME IPADDR
Options and
Description
Arguments
DOMAINNAME Specifies the name of the domain that you are modifying. Enter
an alphanumeric character string of up to 63 characters. Do not
use restricted characters such as *,~,?, and !.
IPADDR Specifies the IP address of the NIS server.
Modifying the Windows Domain Information for a NAS

Gateway
You can modify parameters of an existing domain by running the domain modify
windows command.
To Modify the Windows Domain Information In the NAS Gateway

3-32
domain modify windows DOMAINNAME LOGINUSER

HOSTNAME [HOSTNAME]
[-t CLOCKSKEW]
Options and
Description
Arguments
DOMAINNAME Specifies the domain name by using an alphanumeric character

string. For Windows domains, this should currently be the
NETBIOS Windows domain name.
LOGINUSER Specifies a user name that will be used to contact the domain
controllers by using an alphanumeric character string. This
argument is applicable only to Windows domains.
HOSTNAME Specifies the IP (A.B.C.D) or hostname of domain controller that

should be contacted for retrieving the domain information.
[HOSTNAME] An optional argument that specifies the IP address of any

additional backup domain controllers for a Windows domain.
Enter the IP address of the backup domain controller.
[-t CLOCKSKEW] Specifies the maximum clock skew value in minutes. This
option can be specified only if the domain was created with -k
option. Clock skew ranges from 1 to 9999 minutes. Default
value is 5 minutes.
Removing Virtual Servers and NAS Gateways from a Domain

You can remove virtual servers and NAS Gateways from a domain at any time.
Removing a NAS Gateway from a domain occurs in two steps:
1. Remove the virtual servers associated with the NAS Gateway from the domain
using the vsvr clear domain command.
Note - Disable virtual servers before removing them from a domain.
2. Remove domain from the NAS Gateway by using the domain delete command.
3-33
Note - If you want to change the domain definition on the NAS Gateway, you
can delete the domain and reconfigure it. However, a more efficient way to
change a domain definition is through the domain modify command.
To Remove the Virtual Server From a Domain

locate the domain information that you want to delete:
vsvr disable
remove the virtual server from the domain:
vsvr clear domain ldap|nis|windows [DOMAINNAME]
Note - You need to repeat steps 2 and 3 for every virtual server in the cluster
that were joined to the domain before you can delete the domain at the NAS
Gateway context.
Options and
Description
Arguments
ldap|nis|windows A list from which you specify one domain type at a time.
DOMAINNAME Specifies the name of the domain that you are deleting.
vsvr enable
3-34
Step 5: Run the following command to remove the domain information

from the NAS Gateway:
domain delete {ldap|nis|windows} DOMAINNAME }
Note - A domain cannot be removed from the NAS Gateway unless there are
no virtual servers associated with the domain.
Options and
Description
Arguments
ldap|nis|windows A list from which you specify one domain type at a time.
DOMAINNAME Specifies the name of the domain that you are deleting. Enter an
alphanumeric character string of up to 63 characters. Do not
use restricted characters such as *,~,?, and !. For Windows
domains, this is the NetBIOS Windows domain name.
Setting the Virtual Server to Protected Mode

A virtual server can be in one of two modes: protected or unprotected. Protected mode
enables the virtual server to failover, unprotected mode does not permit failover.
By default, a virtual server is configured in protected mode when you create it through
the vsvr create command. However, you can specify the -u option in the vsvr
create command to change the state from protected mode to unprotected mode.
Note - The management virtual server is always in unprotected mode and the
vsvr set protected command does not affect the management virtual
server.
To Set a Virtual Server to Protected Mode

Step 1: From the virtual server’s context, run the following command:
vsvr set protected
3-35
Step 2: (Optional) You can check the virtual server’s mode by running the
vsvr show command with the virtual server’s name. The ID field
shows the mode as protected. If the ID field shows only the
numerical ID, the virtual server is in unprotected mode.
Setting a Virtual Server to Unprotected Mode

A virtual server can be in one of two modes: protected or unprotected. Protected mode
enables the virtual server to failover, unprotected mode does not permit failover.
To Set a Virtual Server to Unprotected Mode
Step 1: From the virtual server’s context, run the following command:
vsvr set unprotected
Step 2: (Optional) You can check the virtual server’s mode by running the
vsvr show command with the virtual server’s name. The ID field
shows only the virtual server’s numerical ID, which means it is in
unprotected mode. If the ID field shows protected, the virtual
server is in protected mode.
Setting the WINS Server Address for a Virtual Server

The Windows Internet Name Service (WINS) name servers allows resolution of
windows work station names to IP addresses. The NAS Gateway uses WINS name
servers to locate domain controllers. The NAS Gateway also registers the name of
each virtual server with the WINS server so that Windows clients can resolve the
names to IP addresses.
Note - Configuring the WINS server address for a virtual server is optional.
With the vsvr set wins command, you can specify the IP address of the WINS server
that a virtual server should use. You can specify the WINS server addresses for a
virtual server only if the virtual server is in the disabled state. You can put the virtual
server into disabled state by running the vsvr disable command. For details, see
“Enabling and Disabling a Virtual Server” on page 3-45.
3-36
To Specify the IP Address of the WINS Server

vsvr set wins PRIMARYIPADDR [SECONDARYIPADDR]
Options and
Description
Arguments
PRIMARYIPADDR Specifies the IP address of the primary WINS server. Because

the WINS server can reside in a standalone server or on the
domain controller, specify either the IP address of the
standalone WINS server, or the IP address of the domain
controller, whichever is pertinent to your network
configuration.
[SECONDARYIPADDR] An optional argument that specifies the IP address of the

secondary WINS server. Because the WINS server can reside
in a standalone server or on the domain controller, specify
either the IP address of the standalone WINS server, or the IP
address of the domain controller, whichever is pertinent to
your network configuration.
Deleting the WINS Server Address from a Virtual Server

Delete the WINS server address from a domain at any time by running the vsvr
clear wins command. This command enables you to delete the IP address of the
primary and secondary WINS server. When you delete the WINS server, the name-to-
IP-address resolution does not occur for the virtual server.
You can delete the WINS server IP addresses from a virtual server only if the virtual
server is in the disabled state. You can put the virtual server into disabled state by
running the vsvr disable command. For details, see “Enabling and Disabling a
Virtual Server” on page 3-45.
To Delete the WINS Server
vsvr clear wins
3-37
Setting a CIFS NetBIOS Name of a Virtual Server

You can set the CIFS NetBIOS name of the virtual server by running the following command
from the virtual server context:
vsvr set name netbios NAME
NAME specifies the CIFS NetBIOS name. By default, the
NetBIOS name is the same as the virtual server name. This
command overrides that rule. The virtual server must be disabled
before you can run this command.
Note - You can add additional NetBIOS names to the virtual server with the
cifs server add command. See the ONStor 2200 Series NAS Gateway
Command Reference for details on how to use this command.
Configuring a Virtual Server with the Autocreated Shares

Utility
The autocreated shares utility enables the creation of a share for the volume and path
to users’ home directories. Each virtual server can contain a volume where home
directories are supported for users. The autocreated shares utility supports CIFS clients
only.
You can configure the autocreated shares utility for a virtual server through the vsvr
set autocreate command. This command enables the NAS Gateway to
automatically create a user’s home directory share in a virtual server by concatenating
three pieces of information:
• The volume that will contain the user home directories.
• The path to the home directories. The path must already be configured on the
volume that will contain the user home directories.
• The user’s name, which is discovered as the user logs in to the network.
When the virtual server is enabled, the volume and path are exported along with any
specific shares configured in the virtual server. When a user logs in to a Windows
domain, the NAS Gateway matches the user name portion of the logon and appends it
to a concatenation of the volume and file path.
3-38
Part of the vsvr set autocreate command is a file path. For a share with the user’s
name to appear in the Shares List, a directory with the same name must exist in the
path.
The autocreated shares feature has the following considerations:
• You can run the vsvr set autocreate command only when the virtual server is in
the disabled state.
• The volume you specify must be read-writable.
• The volume containing home directories must already be created.
• The path to the home directories must already be configured in the file system on
the home directory’s volume.
• You need to have a home directory for each user.
• The user’s home directory name must be the same as the user’s Windows login.
• If a user logs in with a different name, the user can directly connect to the home
directories of other users. For example, user “paulw” can connect to the home
directory of “johndoe” even though this share is not listed by default for “paulw.”
After a user has connected to another user’s home directory share, this share is
listed in the connected user’s Shares List as long as the user remains connected to
that share. For example, “paulw” will see a share called “johndoe” while listing the
shares in the same virtual server, but only for as long as “paulw” is connected to
the “johndoe” share.
Before configuring a virtual server with the autocreated shares utility, ensure that a
volume with user home directories exists. For more information about creating
volumes, see “Managing Volumes and File Systems” on page 6-1.
Before configuring a virtual server with the autocreated shares utility, gather the name
of the volume where the home directories exist, and the path to the users’ home
directories.
Note - The user home directory structure must match the file path you enter
when configuring the virtual server’s autocreated shares utility.
3-39
To Configure the Autocreated Shares Utility on a Virtual Server

Step 1: From the virtual server context, disable the virtual server if it is
currently enabled by running the vsvr disable command.
Step 2: Configure the autocreated shares utility and specify the file path so
autocreated shares can export a user’s home directory by running
the following command:
vsvr set autocreate VOLNAME PATHNAME
Options and
Description
Arguments
VOLNAME Specifies the volume in which the home directory is configured.

Use an alphanumeric character string from 1 to 127 characters.
Volume names can begin with an alphanumeric character, an
underscore ( _ ), or a hyphen ( - ). The volume must already
exist before you run this command.
PATHNAME Specifies the absolute path to the directory in which the user
home directories are configured, for example:
\users\local\homes. Use an alphanumeric character string
from 1 to 15 characters. You do not need to specify the user
name as part of the path. The NAS Gateway discovers the user
name from the user’s login and uses the name to determine
which home directory is shared with which user.
Example:
vsvr set autocreate testvol \user\local\homes
This argument takes the file path to the directory where user
home directories are configured. The NAS Gateway prefixes
the volume to the file path. When the user logs into the domain,
the user name from the login is automatically appended to the
end of the volume and file path, resulting in the creation of the
entire share to each user’s home directory.
Note - You do not need to specify the user name in the file
path.
3-40
Deleting the Autocreated Shares Utility

At any time, you can delete the autocreated shares utility from a virtual server by
running the vsvr clear autocreate command. After deleting the autocreated shares
utility, if users want to access their home directories, they need to browse the file
system to their home directories through the virtual server.
Note - You can delete the autocreated shares utility at any time. However, if
you delete the autocreated shares utility while the virtual server is enabled, the
change does not take effect until you have disabled, and then re-enabled the
virtual server.
To Delete the Autocreated Shares Utility

Step 1: Disable the virtual server by running the following command:
vsvr disable
Step 2: Delete the autocreated shares utility by running the following
command:
vsvr clear autocreate
Step 3: Re-enable the virtual server by running the following command:
vsvr enable
Configuring a Virtual Server for a File System Protocol

Virtual servers use standard file system protocols to access and share files. Virtual
servers support the following file system protocols:
• CIFS
• NFS
• A multiprotocol environment with both NFS and CIFS
3-41
Before you begin configuring a virtual server for any of these environments, you need
prerequisite information. Table 3-4: lists the prerequisite information you need for
each environment before you start configuring a virtual server for it.
Table 3-4: File System Protocol Configuration Prerequisites
Prerequisite Information Required For
Decide whether you want the virtual server CIFS, NFS, and mixed CIFS-NFS
configured in protected mode for failover to
a different NAS Gateway. See “Creating a
Virtual Server and Performing Basic Setup”
on page 3-7.
Decide what the virtual server’s name will CIFS, NFS, and mixed CIFS-NFS
be. By default, the virtual server’s name
and the NetBIOS name are the same, but
you can change the virtual server’s name or
the NetBIOS name later.
Gather the IP addresses you want assigned CIFS, NFS, and mixed CIFS-NFS
to the virtual server. Each virtual server can
be configured with a maximum of 32 IP
addresses. These IP addresses are
assigned to the virtual server itself.
Gather the Windows domain and user CIFS and mixed CIFS-NFS
names. The virtual server uses the
Windows domain.name.
Gather the name of the LDAP domain the NFS and mixed CIFS-NFS
virtual server will join.
Gather the name of the NIS domain the NFS and mixed CIFS-NFS
virtual server will join.
Gather the IP address of the primary WINS CIFS and NFS

server and any secondary WINS server.
The WINS server might be configured on
the domain controller, in which case, you’ll
need the domain controller’s IP address.
3-42
Table 3-4: File System Protocol Configuration Prerequisites (Continued)
Prerequisite Information Required For
Decide if the virtual server will support CIFS and mixed CIFS-NFS
home directories. See “Configuring a Virtual
Server with the Autocreated Shares Utility”
on page 3-37.
To configure and activate a virtual server for a NFS, CIFS, or multiprotocol file
system protocol, follow the steps outlined in the following procedure. Steps for CIFS
only or NFS only file system protocols are specifically noted as such. All other steps
apply to either CIFS, NFS, or multiprotocol file system environment setup. Follow the
steps as required, depending on the type of file system protocol you want to set up.
To Configure and Activate a Virtual Server for an NFS, CIFS, or
Multiprotocol File System Protocol
Step 1: If you are configuring a virtual server for the CIFS file system
protocol, specify any WINS servers that the virtual server should
use by running the vsvr set wins command. For example, to
specify that the virtual server use the primary WINS server at
33.44.55.5, and the secondary WINS server at 33.44.55.66, enter
the command as shown:
vsvr set wins 33.44.55.5 33.44.55.66
Note - This step is optional.
If your multiprotocol environment supports home directories

through the autocreated shares utility, go to “Configuring a
Virtual Server with the Autocreated Shares Utility” on page 3-37
before continuing with this procedure.
Step 2: If you are setting up a CIFS file system protocol, specify the
Windows domain that the NAS Gateway will join as part of
configuring another virtual server, by running the domain add
windows command.
3-43
For example, to have the NAS Gateway join the Windows

domain “effigy” whose domain controller is at 10.2.128.141 and
use the admin login name “onstor,” run the following command:
domain add windows effigy onstor 10.2.128.141
If you are setting up an NFS file system protocol, specify the NIS
domain that the NAS Gateway will join as part of configuring
another virtual server, by running the domain add nis
command.
For example, to have the NAS Gateway join the NIS domain
“tiamat” whose domain controller is at 10.5.129.1, enter the
command as shown:
domain add nis tiamat 10.5.129.1
Note - The NIS or Windows domain name can be a maximum of 63 characters.
Step 3: If you are configuring a virtual server for a CIFS file system
protocol, specify the Windows domain in which the virtual server
will register by running the vsvr set domain command.
For example, to set the Windows domain “effigy” with the login
administrator name “onstor”, run the command as shown:
vsvr set domain windows effigy onstor
You also need to specify the password for the administrator
“onstor”.
Note - DNS is supported through the vsvr set domain windows command.
Step 4: If you are configuring a virtual server for an NFS file system
protocol, specify the NIS domain in which the virtual server will
register by running the vsvr set domain command.
For example, to set the NIS domain “tiamat”, run the following
3-44
command:
vsvr set domain nis tiamat
Step 5: Add an interface that supports IP connectivity and a route to the
domain controller by running the interface create command.
For example, to create an interface on fp.0 and logical port lp.0 to
the domain controller 10.2.128.141 with mask length of 24, run
interface create fp.0 -l lp.0 -a 10.2.128.141/24
Step 6: Run the vsvr show command to verify the virtual server’s
configuration, and check that you have assigned the resources to
the correct virtual server.
For example, to check the virtual server configuration of
“pubstest,” run the following command:
vsvr show pubstest
• If the virtual server configuration is not correct, you can rerun
commands to delete and reconfigure, or modify, the parts of
the virtual server that need correcting. Configure virtual
server setup parameters while the virtual server is disabled. At
this point, the virtual server is still disabled.
• If the virtual server configuration is correct, proceed to the
next step.
Step 7: Enable the virtual server in runtime, by running the vsvr enable
command from the virtual server context:
vsvr enable
Enabling and Disabling a Virtual Server

When you have created a virtual server with the vsvr create command, it is in the
disabled state by default. Configure the virtual server’s setup parameters while it is in
the disabled state. Configure the virtual server’s runtime parameters while it is in the
enabled state. For more information about which parameters and commands are
available in which state, see Table 3-3 on page 3-6.
3-45
Enabling a virtual server, does not require the virtual server to have any resources
configured, such as IP interfaces, volumes, or shares.
To Enable the Virtual Server Configuration
• Run the following command from the virtual server context:
vsvr enable
New or changed virtual server parameters become active when you run this command.
You can disable individual virtual servers by running the vsvr disable command.
Disabling a virtual server is important for the following functions:
• Changing the setup configuration of a virtual server.
• Adding the virtual server to a domain with the vsvr set domain command.
To Disable a Virtual Server
vsvr disable
Displaying DNS Name Resolution for a Virtual Server
You can display details of DNS configuration by running the system dnsconfigure
show command from the context of the virtual server. This command show hosts and
resolver configuration details of the virtual server.
Configuring DNS Name Resolution for a Virtual Server
The NAS Gateway supports DNS name resolution for virtual servers through a hosts
database specific to each virtual server. The NAS Gateway also supports a specific
DNS resolver configuration for each virtual server.
DNS is configured on a per-virtual server basis. This includes the management virtual
server. For example, for autosupport to work, you need to configure DNS for the
management virtual server.
Editing the DNS Hosts Database

You can configure a mapping of IP addresses to symbolic device names by running the
system dnsconfigure hosts command from the context of the virtual server. This
command starts a text editor and allows you to enter one or more mappings for IP
3-46
addresses. When the text editor is closed, the mapping you created is saved and name
resolution can begin for the devices you added to the DNS hosts database.
To Configure a DNS Entry in the Hosts Database
system dnsconfigure hosts
This command starts the vi editor for the hosts database.
Step 2: When the editor is opened, you can enter the following information
separated by spaces or tab characters:
• Host IP address in dotted decimal notation
• An official host name
• An alias for the host name
Example:
192.168.10.101 rutile Server10
Note - When an NIS domain is configured for a virtual server, client host name
resolution happens through an NIS server, not through DNS resolver. With
local NIS maps, no NIS server exists for the virtual server, so client host name
resolution does not occur for the virtual server. Therefore, configure DNS on
each virtual server that is using local NIS maps.
Editing the DNS Resolver Configuration File

The NAS Gateway supports a DNS resolver configuration file that allows you to
configure different types of DNS-supported information. You can edit the resolver
configuration file for the DNS-supported information with the system dnsconfigure
resolver command from within the context of the virtual server.
The resolver configuration file contains a list of keyword/value pairs that provides
various types of resolver information. Valid keywords for editing the resolver
configuration file are:
3-47
• nameserver — Specifies the IP address of a name server for the resolver to query.
When the name server is found, the IP address of that name server is displayed.
You can specify up to three name servers, one per keyword. The resolver queries
them in the order listed. If a query times out, the query algorithm continues to
query each subsequent name server until the list of specified name servers is
completed. The query algorithm then repeats the query of the name servers on the
list for a maximum number of times.
• domain — Specifies the local domain name. Most queries for names within the
domain accept short names relative to the local domain.
• lookup — Specifies which database to search and in which order to search. Valid
keywords are: bind and file.
- If you specify bind only, the resolver search uses the domain server to
search IP address-to-DNS name bindings.
- If you specify file only, the resolver searches the hosts database.
Note - When you are resolving a host name within a virtual server context, the
NAS Gateway always checks the NIS domain for that virtual server first. This
is done automatically; you do not have to explicitly specify this in your query.
As an alternative, you can specify the lookup keyword with no related

keyword. If no keyword is specified, the resolver searches both databases, first
the bind database, then the hosts database.
• search — Specifies a search list for host-name search. The search list contains a
domain search path following the search keyword with spaces or tabs separating
the names. The search list function supports a maximum of six domains and a total
of 1024 characters. Most resolver queries search each component of the search
path in turn until a match is found.
3-48
Note - The search process can take a while if the servers for the listed domains
are not local. Queries will time out if no server is available for one of the
domains.
To Edit the DNS Resolver Configuration File

system dnsconfigure resolver
This command starts the vi editor for the appropriate file or
database.
Step 2: When the editor is opened, you can enter one of the following
keyword and string patterns:
• The nameserver keyword and an IP address.
• The domain keyword and an official host name.
• The lookup keyword and “bind”, “file”, “bind file” or “file
bind”. For example: lookup bind to search only the bind
database, or lookup file bind to search the hosts database
first, then the bind database.
• The search keyword and one or more domain search paths.
You can use the system ping command with a host name to check whether you
configured the resolver correctly. When given a host name, the ping utility attempts to
resolve the name and prints the IP address of the host in dotted decimal notation if the
resolution is successful.
Displaying Virtual Servers

You can view the state of a virtual server by running the vsvr show command. This
command displays all virtual servers arranged by their virtual server ID and displays
the runtime state of each virtual server.
3-49
Note - Even though virtual server names are displayed in uppercase, they are
case insensitive when entered at the command prompt. Therefore, you can
specify a virtual server name in uppercase or lowercase when you run any of
the vsvr commands.
To Display Virtual Server Information

vsvr show ([VIRTUALSERVER]
[-v]|all ([-n NODE]|[-v])))
Options and
Description
Arguments
VIRTUALSERVER An optional alphanumeric character string, 1 to 15 characters

long, that specifies a particular virtual server that you want to
display. The following information about the virtual server is
displayed:
• The server’s ID number. Virtual server numbers can range
from 1 to 33 because 32 virtual servers are supported per
cluster and there is also the management virtual server.
• The Windows or NIS domain in which the server is
registered.
• The server’s mode. Valid modes are “unprotected” or
“protected”.
• The server’s state. Valid state’s are “enabled” or “disabled”.
• The IP interface the server owns.
• The autocreate volume name that is exported through the
CIFS share autocreation. For more information, see
“Configuring a Virtual Server with the Autocreated Shares
Utility” on page 3-37.
• The autocreate path for supporting CIFS share
autocreation. The path is created as part of the virtual
server autocreate volume.
• The volumes owned by the virtual server.
• The volumes mounted in the current virtual server’s context.
3-50
Options and
Description
Arguments
all An optional keyword that enables you to list all virtual servers
configured in a cluster. When you specify the all keyword, the
runtime state of each virtual server is also listed in the output.
-n NODE An optional keyword that enables you to list brief information on

all virtual servers of a particular NAS Gateway.
-v Displays additional information about the virtual server, such as

the failover state, the number of volumes owned by the virtual
server, and the name of the NAS Gateway to which the virtual
server is assigned.
If you enter none of the optional arguments, all virtual servers configured on the
current NAS Gateway are displayed.
Note - If a failover occurs, you can locate virtual servers by running the vsvr
show command. This command executes on the local NAS Gateway by
default.
• If you run the vsvr show command, and the virtual server is
displayed, it resides on the local NAS Gateway.
• If you run the vsvr show command, and the virtual server is
not displayed, it is not currently on the local NAS Gateway.
Run the vsvr show all command to ensure that the virtual
server is still in the cluster. You can also run the vsvr show -
n NODE command against each NAS Gateway in the cluster,
where NODE is the node name of an NAS Gateway.
Changing to a Different Virtual Server Context

Each NAS Gateway can contain more than one virtual server. By running the vsvr set
command, you can switch the context of a virtual server. From within that context, you
can configure the virtual server’s resources.
3-51
Note - This command is cluster aware, so when you run the command, you can
change context to any virtual server in the cluster regardless of the NAS
Gateway on which the virtual server resides.
You can verify that the vsvr set command has completed by looking at the command
prompt after you run the command:
• If the command completes against an existing virtual server, the command prompt
contains the name of the new virtual server, and you are in the context of the new
virtual server.
• If the command does not complete, the command prompt displays the name of the
virtual server from which you ran the command, and you are still in the context of
that virtual server or you are still in the cluster context (where the command could
also have been run from).
To Change From One Virtual Server to Another Virtual Server
vsvr set VIRTUALSERVER
VIRTUALSERVER is an alphanumeric character string from 1 to 15
characters.
Clearing a Virtual Server Context

You can exit a specific virtual server’s context by clearing the context.
To Clear the Virtual Server Context
vsvr clear
Note - You do not have to run the vsvr clear command before changing
virtual server contexts.
3-52
This command does not delete a virtual server or release any resources configured
within a virtual server. Instead, when you run this command, you return to the NAS
Gateway context.
Changing a Virtual Server’s Name

You can change the virtual server’s name by using the vsvr set name generic
command. This command enables you to change the virtual server name of an existing
virtual server, but the NetBIOS name of the virtual server is not changed. The virtual
server ID does not change when you change the virtual server name. The virtual
server set name generic command has the following considerations:
• The command works only in the context of the virtual server whose name you
want to change.
• The virtual server must be disabled to change the name. You can use the vsvr
disable and vsvr enable commands to disable, then re-enable, the virtual server.
• The management virtual server cannot be renamed.

• The new name for the virtual server has the same restrictions as the original name
you used when you created the virtual server with vsvr create:
- The new virtual server name needs to start with an alphanumeric
character, with a dash ( - ) or an underscore ( _ ).
- The new virtual server name can have a maximum of 15 characters.
- The new virtual server name cannot use a name starting with
“VS_MGMT”.
- The new virtual server name cannot be the reserved word all.
Note - Virtual server names are case insensitive, so the name vs1 is the same as
the name VS1.
To Change a Virtual Server’s Name

Step 1: From the context of the virtual server that you want to rename,
disable the virtual server by running the following command:
3-53
vsvr disable
Step 2: Change the name of the virtual server by running the following
command:
vsvr set name generic NAME
NAME is the new name that you are setting on the virtual server.
Step 3: Re-enable the virtual server by running the following command:
vsvr enable
Note - The NetBIOS name of the virtual server won't change when you rename
the virtual server. To modify the NetBIOS name, see the vsvr set name
netbios command.
Moving a Virtual Server

You can move a virtual server to a different single NAS Gateway or to a NAS
Gateway group. Moving a virtual server to a different NAS Gateway can be useful, for
example, if a hot-swap procedure is required on the NAS Gateway or for load
balancing across NAS Gateways in a cluster.
Consider the following before moving a virtual server configuration:
• Know the name of the NAS Gateway that currently owns the virtual server. This
NAS Gateway is called the source NAS Gateway in the following procedure.
• Display the NAS Gateway’s name by running either the cluster show group or
vsvr show all command.
• Know the name of the NAS Gateway that will own the virtual server after the
move. This NAS Gateway is called the destination NAS Gateway in the following
procedure. You can display the NAS Gateway’s name by running either the
cluster show group or vsvr show all command.
• Ensure that the IP subnets for the virtual servers you are moving are accessible
from the destination NAS Gateway.
3-54
• Ensure that the destination NAS Gateway has one or more logical ports with the
same name as the logical ports used by the virtual server’s interfaces. The admin
and operational state of the logical ports must be UP.
• Ensure that the destination NAS Gateway has access to each volume owned by the
virtual server.
• You cannot move virtual servers to a NAS Gateway in another cluster.
You can move a virtual server by running the vsvr move command. When the vsvr
move command completes, the virtual server configuration, the IP interfaces, volumes,
and shares configured on the virtual server are retained, but relocated to the destination
NAS Gateway. After the move completes, the virtual server is in the enabled state.
To Move a Virtual Server Between NAS Gateways
Step 1: Verify the virtual server’s name and state by running the
following command:
vsvr show all
Step 2: Specify and set the virtual server you want to move:
vsvr set VIRTUALSERVER
Step 3: To move the virtual server, run the following command:
vsvr move -f DSTNASGATEWAY | -g DSTGROUP
Options and
Description
Arguments
-f DSTNASGATEWAY Specifies the destination NAS Gateway that you want to move
the virtual server to.
-g DSTGROUP Specifies the destination NAS Gateway group that you want to
move the virtual server to.
Step 4: Verify that the virtual server has been moved to the correct NAS
Gateway:
vsvr show all
3-55
Load Balancing Virtual Servers

Virtual servers provide continuous file services through manual load balancing.
Note - Virtual servers do not have to be in protected mode for manual load
balancing
Manual load balancing involves the following basic tasks:

1. Gather performance and operation reports from NAS
Gateways and their associated virtual servers to determine
capacity and load issues. See “Displaying Virtual Server
Performance Statistics” on page 3-56.
2. Display performance statistics at regular intervals by using
the vsvr stats command to help you make load balancing
decisions. See “Displaying Virtual Server Performance
Statistics” on page 3-56.
3. Move any virtual servers from one NAS Gateway to another
to balance the load. See “Moving a Virtual Server” on page 3-
54.
Displaying Virtual Server Performance Statistics

Use the vsvr stats command to display virtual server statistics. You can configure
this command to show a scrolling display of performance statistics at regular intervals
for either all virtual servers on an NAS Gateway or for a particular virtual server. To
stop scrolling of the display, type Ctrl+Z. The vsvr stats command provides
statistics on two types of operations: speed and throughput. Speed is measured in the
number of operations per second, and throughput is measured in bytes (B), kilobytes
(KB), or megabytes (MB) per second.
Speed operations on which the vsvr stats command provides statistics include:
• NFS request operations received from clients
• NFS responses successfully sent to clients
3-56
• CIFS requests received from clients

• CIFS responses successfully sent to clients
Throughput operations on which the vsvr stats command provides statistics
include:
• Number of NFS B, KB, or MB per second received from clients
• Number of NFS B, KB, or MB per second sent to clients
• Number of CIFS B, KB, or MB per second received from clients
• Number of CIFS B, KB, or MB per second sent to clients
To Determine Which Virtual Servers Need to Be Moved to Create a
Balanced Load
vsvr stats [all|agg] [-i SECONDS][-c COUNT]
Options and
Description
Arguments
all An optional keyword that enables the display of statistics

associated with all the enabled virtual servers on a particular
NAS Gateway. If you don’t specify this keyword and you are in
virtual server context, the command displays statistics only for
that virtual server.
agg An optional keyword that enables the display of the cumulative

or aggregate statistics of all the enabled virtual servers on a
particular NAS Gateway. If you don’t specify this keyword and
you are in virtual server context, the command displays
statistics only for that virtual server.
-i SECONDS Enables you to set a refresh interval for gathering statistics. The
default refresh interval is 10 seconds.
-c COUNT Specifies the number of reports to display.
3-57
Note - You can execute the vsvr stats command without the keywords all
and agg only from within the context of the virtual server. If you are running
the vsvr stats command with the keywords all and agg, you need to be in the
virtual server context.
Deleting a Virtual Server and Its Resources

You can delete a virtual server by running the vsvr delete command. This command
removes the virtual server and all its configurations from the database.
Before deleting the virtual server, you need to delete the volumes from the virtual
server by running the volume delete command from within the virtual server’s
context; otherwise, the vsvr delete command will not complete.
After you delete a virtual server, you automatically revert to the NAS Gateway
context, and the resources that were associated with the deleted virtual server are now
available to be assigned to another virtual server.
Note - The vsvr delete command is available from the NAS Gateway
context as well as a virtual server context. The context you are in when you run
this command affects whether you need to specify an argument.
• If you run the vsvr delete command from the NAS

Gateway context, you need to specify the virtual server to be
deleted.
• If you run the vsvr delete command from the context of a
specific virtual server, you do not need to specify the virtual
server name. The virtual server that has the current context is
deleted.
• You cannot delete a virtual server from the context of another
virtual server.
To Delete a Virtual Server and Its Resources
Step 1: As an option, delete all shares assigned to the virtual server’s
3-58
volumes by running one of the following commands:

• nfs share delete
• cifs share delete
Step 2: Delete all volumes assigned to the virtual server, by running the
volume delete command against all volumes on the virtual server.
Note - If you have not yet deleted the shares, you can run the volume delete
command, and it will delete the shares as part of the volume deletion process.
Step 3: As an option, you can delete all interfaces assigned to the virtual
server, by running the interface delete command.
Note - If IP addresses are associated with the interface, remove them before
deleting the interface. You can use the interface modify command with the
-d IPADDR option to delete the IP address.
Step 4: Delete the virtual server by running the following command:

vsvr delete [VIRTUALSERVER]
Step 5: When you run the vsvr delete command, the NAS Gateway
prompts you for confirmation as follows:
Are you sure? [y|n]:
Type y to confirm the deletion, or type n to cancel the deletion of
the virtual server.
Note - The NAS Gateway requires at least one virtual server for processing
client I/O. Be sure not to delete the only virtual server in a cluster. If you do,
you will isolate clients from SAN resources.
Chapter 4: Managing Storage and
Fibre Channel
• “Managing Storage Ports” on page 4-6
• “Managing LUNs” on page 4-9
• “Managing the SCSI Layer” on page 4-16
Disk LUNs
Logical unit numbers (LUNs) are unique identifiers in the SAN that represent granular
units of storage that the NAS Gateway can control. LUNs represent the disks that the
NAS Gateway needs to access for reading or writing. You cannot divide a LUN into
smaller parts.
LUNs are discovered through SCSI and FC topology discovery routines. After the
LUNs are discovered, the volume manager (VM) groups LUNs with specific
characteristics into storage pools. LUNs are grouped in the storage pool by
characteristics such as:
• Make
• Model
• RAID controller name
The VM can then create volumes out of the LUNs in the storage pools or leave LUNs
in the storage pools. The volume manager (VM) does not control tape drives. As
volumes are created, the NAS Gateway manages the assignment of resources out of
the pool automatically. During runtime operation of the volume, the NAS Gateway
tracks volume space usage and can automatically add new LUNs through the ONStor
AutoGrow™ feature if more space is required in the volume. The AutoGrow feature
selects only the allocatable LUNs that have the correct parameters. For example, you
would get only LUNs that have the same RAID level, make, model, or that were from
the same controller. You can configure LUN parameters for the AutoGrow feature.
4-2
Free LUNs
Free LUNs are available to the NAS Gateway, but they have not been used for volume
space. The NAS Gateway recognizes free LUNs by a label that you can instruct the
NAS Gateway to put on each LUN. Free LUNs reside in the storage pool and are
available for creating new volumes or for assignment to volume space if the NAS
Gateway’s automatic resizing feature determines that a volume needs to grow.
Foreign LUNs
Foreign LUNs are not available to the NAS Gateway. The NAS Gateway typically
considers LUNs foreign for two reasons:
• The LUN is new and you have not yet made the LUN available to the NAS
Gateway.
• The LUN is in use by another vendor’s storage equipment.
However, you can convert foreign LUNs to free LUNs by making them explicitly
available. Foreign LUNs reside in the foreign LUN pool until you label them.
Out of Cluster
Out of cluster LUNs are recognized by one NAS Gateway as being claimed by another
NAS Gateway that is not in the same cluster. LUNs are only available to a NAS
Gateway if they are in the same cluster as the NAS Gateway.
Storage Ports and LUNs

During initial boot the NAS Gateway automatically detects LUNs through a storage
port. The storage port is the FC, or FC-compliant, transceiver, that connects an
individual FC slice to the FC topology. The NAS Gateway supports two storage ports
on each Fibre Channel (FC) storage processor (SP) element.
Storage ports interact with physical storage devices to discover LUNs. When physical
devices are connected to the NAS Gateway through a storage port, SCSI discovery
routines discover the device and its characteristics. The discovered device is
virtualized and its LUNs are recorded. After a device has been virtualized, the NAS
Gateway’s volume management software can use it in the EverON file system.
4-3
Initial Boot
At initial boot, the FC protocol discovers the storage devices attached to the NAS
Gateway, the connection types they are in, and how they can be accessed. The NAS
Gateway discovers characteristics about each physical device, such as its World Wide
Name (WWN), LUN ID, and relevant number of data blocks for each LUN
discovered. After the initial discovery is complete, any LUN that is added or deleted
from an array requires an operator intervention before the changes become known to
the NAS Gateway. Once a LUN has been added to the NAS Gateway for use by the
file system, care must be taken not to alter the device’s number of blocks. Never
increase or decrease the number of blocks a LUN exports for use after the discovery
completes. This information is passed to other software entities that process the
physical device information for use by volumes or file systems.
Note - The NAS Gateway’s storage software does not discover whether blocks
are used.
Addition of Physical Storage

When physical storage is added to the SAN, that creates a SAN topology change, the
NAS Gateway automatically detects the attachment point change. The detection
routines are part of the FC protocol and depend on the type of topology involved:
• In arbitrated loops, the FC-AL protocol governs the arbitration of adding new
devices. Through a series of notification messages passed between neighbors, the
new device is added and every device reregisters. If a device is added to the
arbitrated loop, the loop resets. During the reset, data transfer is momentarily
interrupted. Instead of controlling the loop arbitration or reset, the NAS Gateway
detects all announcing devices and puts them in a list.
• In a switch-fabric topology, the FC switch arbitrates the addition of the new device
through a request-and-response sequence that forces the new device to log in to the
FC switch. During the addition or deletion of storage, all devices are forced to
reregister with the FC switch. The NAS Gateway participates in the registration
process in the switch fabric by receiving notifications from the FC switch about
new device or target. A target will normally export one or more LUN devices that
can be used by the NAS Gateway and the file system. Before the NAS Gateway
4-4
can detect the available LUN devices, a SAN topology event must take place. This
event will start the LUN discovery in motion for the topology change. When
adding or deleting LUN devices from a target device, operator intervention will be
required before the NAS Gateway will register the changes.
- In the case of Target/LUN discovery, there is one exception to the rule.
If a target does not export a LUN zero, the NAS Gateway will
periodically probe the target device for any changes in the number of
LUN devices exported for use. This probe will only detect newly
exported LUN devices, and add them to the NAS gateway. This will
not detect deleted LUN devices or LUN devices that have changed in
size. For that to take place, operator intervention is required. See
“Managing the SCSI Layer” on page 4-16.
• After the target and LUN devices are discovered and registered, you need to label
them to make them available to the NAS Gateway. After you label the LUN, the
VM adds the LUN to its database of LUNs. The NAS Gateway does not
automatically add this new resource to any part of available file system space. The
LUN remains empty of file system space until you use it to either resize an existing
volume space or create a new file system volume. Automatic resizing is initiated
by the VM. If the new LUN is intended to be part of a file system, perform
additional configuration as documented in “Managing Volumes” on page 6-5.
Note - Never resize an individual LUN after it is in use by the file system.
Physical Storage Going Offline

System or network events can cause physical storage to go offline. If a device is
deleted from an arbitrated loop, the loop resets, and data transfer is momentarily
interrupted.
The NAS Gateway error detection features enable it to detect an error condition and
alert you to the problem. While the error condition exists, the physical storage is
offline, and the NAS Gateway notes the deletion of those resources and converges on
the location of the errored LUN. The NAS Gateway rediscovers the remaining storage
resource locations, characteristics, and accessibility to represent an accurate picture of
the SAN and its components.
4-5
Network Power Cycle

When the NAS Gateway is power cycled, it will rediscover the storage information. To
ensure correct storage information, the NAS Gateway always reregisters with the SAN
switches and composes a new list of LUNs when the FC restarts.
4-6
Managing Storage Ports

Storage port functionality enables you to view some of the operation and performance
statistics of the NAS Gateway’s FC ports. You can also enable, disable, and reset
storage ports.
Displaying Storage Port Statistics

As storage ports become active, the NAS Gateway tracks the performance and
operation statistics for read and write data on each FC port on the NAS Gateway’s SP
element. Each port’s statistics are entered into the port statistics table, where you can
view them. The port statistics table contains general statistics about the port and traffic
on it. You can view FC ports individually.
To View the Port Statistics Table
port show stats PORT
PORT is one of the NAS Gateway’s storage ports. For example,
sp.2.
Displaying Detailed Information About a Storage Port

You can view detailed information about port attributes for any FC port on the NAS
Gateway. Detailed storage port information includes information about:
• The FC adapter type and version levels
• Interface and link state information
• SCSI tag information and FC node name and frame size information
To View the FC Ports Individually
port show detail PORT
sp.2.
4-7
Displaying All Information About Storage Ports

The NAS Gateway supports a table of general information about all storage ports on
an NAS Gateway. The storage port information table displays the following
information about all FC ports on the SP element:
• The adapter name
• The firmware revision
• The hardware revision
• The interface type
• The link state
• The link speed
• The maximum number of SCSI tags allowed per device
• The Fibrechannel node name
• The Maximum Fibrechannel frame size allowed
• Whether SRAM parity is available
To Display the Storage Port Information
port show all
Enabling and Disabling a Storage Port

When you enable the storage port, you are not automatically setting it into a state of
activity. Instead, you are causing the port to transition from disabled state to enabled
state. When the port is in the enabled state, it can be in either the UP or the DOWN
state:
• If the port is UP, the FC port detects a physical link and communication on the
port.
• If the port is DOWN, the FC port detects no neighbor device on the link or no
physical connection.
4-8
When you disable the storage port, you are not automatically setting it into a state of
inactivity. The storage port is only disabled, not in DOWN mode. When the port is
disabled, it is unable to support a physical layer link.
To Enable a Storage Port
port enable PORT
sp.2 would enable storage port 2 on the SP element. You can also
specify the keyword all to enable all ports.
To Disable a Storage Port
port disable PORT
sp.2 would enable storage port 2 on the SP element. You can also
specify the keyword all to enable all ports.
Resetting a Storage Port

When the storage port is reset, a restart of the target port occurs. The port is put in the
DOWN state, then transitions to the UP state.
When you reset a storage port, the NAS Gateway rediscovers the SAN. While the port
is resetting, it cannot support traffic until it has reached the UP state.
This command can be helpful if there are changes in the SAN. For example, if you
change a RAID in the SAN, you can reset the port to cause the NAS Gateway to
discover the device.
To Reset a Storage Port
port reset PORT
sp.2 would reset storage port 2 on the SP element. You can also
4-9
specify the keyword all to reset all ports.
4-10
Managing LUNs
The NAS Gateway discovers and manages LUNs automatically through the FC and
SCSI protocols. This section details the LUN management functions available on the
NAS Gateway.
Note - Zoning is a common practice in SANs. The NAS Gateway cannot

discover or display devices that have been zoned away from it.
Displaying LUN Information

You can display LUN information in any of the following ways:
• LUN storage availability report
• All LUNs
• LUNs associated with a specific physical device
• LUNs configured on tape devices
• LUNs configured on a specific storage port
• LUNs configured on disk devices
To Display the LUN Storage Availability Report
lun show
The storage availability report organizes all devices by controller, device type, and
RAID level. The report shows size and usage information of LUNs as follows:
• Size, in megabytes, of used LUN space in each device
• Size, in megabytes, of free LUN space in each device
• Size, in megabytes, of the out-of-cluster LUN in each device
• Size, in megabytes, of the foreign LUN space in each device
4-11
To Display All LUNs That the NAS Gateway Has Discovered

lun show all
This command displays a list of LUNs and their configuration parameters.
To Display the LUNs Associated With a Specific Physical Device
lun show device DEVICE_NAME [-n NODE]
Options and
Description
Arguments
DEVICE_NAME Specifies the name of the controller for the LUN. For example,
IBM_KPZ0B663_0 indicates the RAID controller for which you
want to display all the associated LUNs.
-n NODE An optional argument that allows you to sort the output of the
lun show device command by NAS Gateway node name.
This option is only applicable to a clustered environment.
• If you enter a node name, the lun show device
command is run for all LUNs associated with a device on
the specified NAS Gateway.
• If you do not enter a node name, the lun show device
command is run for LUNs associated with a device on the
local NAS Gateway, which is the NAS Gateway on which
you run the command. By default, the lun show device
command executes on the local NAS Gateway.
4-12
To Display the LUNs Configured on Tape Devices

lun show tape [-c CONTROLLER] [-n NODE]
[-P PAGENUMBER] [-S PAGESIZE]
Options and
Description
Arguments
-c CONTROLLER An optional argument that specifies the controller of the LUNs

that you want to view. If you do not specify this argument, all
LUNs assigned to tape devices will be displayed.
-n NODE An optional argument that specifies the NAS Gateway

associated with the LUNs that you want to view. If you do not
specify this argument, all LUNs assigned to tape devices will
be displayed.
-P PAGENUMBER An optional argument that specifies the number of pages to

display.
-S PAGESIZE An optional argument that specifies the page size in number of

records to display.
To Display LUNs Configured on a Specific Storage Port

lun show port PORT [-n NODE] [-P PAGENUMBER]
[-S PAGESIZE]
Options and
Description
Arguments
PORT Specifies the storage port on which you are displaying the configured
LUNs. Use an alphanumeric character string.
-n NODE An optional argument that specifies the node. Only devices that are
accessible on the specified node are displayed.
-P PAGENUMBER An optional argument that specifies the number of pages to display.
4-13
Options and
Description
Arguments
-S PAGESIZE An optional argument that specifies the page size in number of

records to display.
To Display LUNs Configured on Disk Devices

lun show disk [-c CONTROLLER] [-r RAID_LEVEL]
[-t STATE] [-n NODE]
Options and
Description
Arguments
-c CONTROLLER An optional argument that specifies the controller ID of the LUNs

that you want to view.
-r RAID_LEVEL An optional argument that enables you to filter the output of the
lun show disk command by RAID level.
-t STATE An optional argument that enables you to filter the output of the
lun show disk command by LUN state: free, foreign, used, or
outCluster.
-n NODE An optional argument for filtering the LUN list by node name. Only
devices that are accessible on the specified node are displayed.
The default value is local.
Displaying the LUN Topology

You can view the LUN topology by running the lun topology command. This
command provides basic information about the discovered storage devices. With this
command you can display the storage topology report, which lists the following:
• All controllers that are accessible in a cluster
• The physical device each controller governs, tape, or disk
• The nodes in the cluster
4-14
To Display the Storage Topology Report

lun topology
Labeling and Unlabeling a LUN

LUNs that contain a label have been recognized by the NAS Gateway. The label is
required for enabling automatic claims through such actions as file system automatic
growth. You need to explicitly apply the label for the NAS Gateway to consider a
LUN as eligible for use. You can label the following types of LUNs:
• Foreign LUNs, which are discovered but not yet labeled for use by a NAS
Gateway. Foreign LUNs do not contain a label, so they could be used by another
storage device.
• Out-of-cluster LUNs are available to the NAS Gateway. By labeling an out-of-
cluster LUN, you can assume ownership of the LUN from a NAS Gateway in a
different cluster.
Note - Use caution when assuming ownership of out-of-cluster LUNs because

you might loose data or destroy a volume.
To Label a LUN for the NAS Gateway’s Use
Note - A LUN must have the ONStor label for the NAS Gateway to be able to
virtualize and use the LUN.
Step 1: Run the following command to locate a particular LUN:

lun show disk
Step 2: Run the following command to claim the LUN:
4-15
lun label DEVICE_NAME -f [-r RAID_LEVEL]

[-c CLUSTERNAME]
Options and
Description
Arguments
DEVICE_NAME Specifies the device name of the LUN that you want to label.
-f Enables you to force a label onto a LUN.
Note - This is intrusive and immediate. It can write a label on a LUN that
is owned by other NAS Gateways or other clusters. When a label is forced
onto a device, it can destroy volumes or data.
-r RAID_LEVEL An optional argument that enables you to configure LUNs with

RAID level. If you enter the value Plain, no RAID level is configured
to the LUN, and the RAID level is considered None. Enter any of
the following values:
• Raid-0
• Raid-1
• Raid-01
• Raid-3
• Raid-5
• Plain (which indicates no RAID level)
Note - You can view the device’s RAID level by running the lun show
command. If the value in the Raid Level field is None, then the LUN can
be labeled and simultaneously assigned a RAID level.
Depending on the setup of your storage network, specifying a RAID level

might be a required parameter.
-c CLUSTERNAME An optional argument that enables you to selectively label the LUN
as part of a different cluster.
4-16
To Unlabel a LUN
Note - You can unlabel free LUNs only. When a free LUN is unlabeled, it
becomes a foreign LUN. Foreign LUNs are not available to the NAS Gateway
and cannot be used for automatic volume space growth.
Step 1: Run the following command and note the device name of the
LUN that you want to unlabel:
lun show all
Step 2: Run the following command to remove the label from the LUN:
lun unlabel DEVICE_NAME
DEVICE_NAME is the identifier of the LUN that you want to
unlabel. The DEVICE_NAME argument is the controller’s device
name plus the LUN ID of the LUN.
4-17
Managing the SCSI Layer

The NAS Gateway supports SCSI drivers and SCSI-layer discovery and management.
Initiating SCSI Discovery Storage Port and LUNs

Each storage port on the NAS Gateway’s SP element is its own FC slice. Therefore,
each port recognizes the SAN from a unique perspective. The SCSI layer functionality
is started automatically when the SP element is booted. However, you can manually
start storage port discovery with the scsi discover device command, or you can
start LUN discovery with the scsi discover lun command. The storage ports
remain active while the SCSI drivers are restarted and the rediscovery of the SAN
devices connected on the port or LUNs completes. The neighbor devices on the NAS
Gateway’s port, and any devices attached to the NAS Gateway’s neighbor’s port are
discovered when discovery completes and the SAN resources are reported to the NAS
Gateway by its neighbor, typically an FC switch.
To Start SCSI Discovery for New Target Devices on a Specific Port
scsi discover device {all|sp.0|sp.1|sp.2|sp.3}
This command might be needed if a target device was present on the SAN at boot
time. However, if no LUN devices were exported for use by the NAS Gateway at
startup, the target device itself is ignored by the NAS Gateway. This command will
retry the base target discovery on all targets connected to a storage port, or the SAN
that the storage port is attached to.
Options and
Description
Arguments
all Initiates SCSI device discovery on all ports on the NAS

Gateway’s SP element.
sp.0|sp.1|sp.2|sp.3 Selects the storage port on which you want to perform SCSI
device discovery. You can specify only one port at a time.
4-18
To Start SCSI Discovery for One or All LUNs

scsi discover lun {all|WWN}
This command might be needed when LUN devices on a target device have changed.
A change may be an alteration of the exported LUN ID, or a change in the number of
blocks a LUN shows as usable.
Warning - Never change the number of blocks exported by a LUN device after
the LUN device is in use by the NAS Gateway file system.
Options and
Description
Arguments
all Initiates SCSI device discovery on all LUNs in the SAN.
WWN Specifies the WWN of a specific LUN to discover.
Displaying SCSI Configuration and Device Information

You can display the following SCSI configuration and device information:
• SCSI configuration with the scsi show config command
• Disk or tape SCSI devices or all devices with the scsi show {all|DISK|TAPE}
[-P PAGENUMBER [-S PAGESIZE]] command
• SCSI statistics by device with the scsi show stats DEVNAME command
• SCSI details by device with the scsi show detail DEVNAME command
• Worldwide names of SCSI devices’ ports’ with the scsi show arraywwn
command
To Display the SCSI Configuration
scsi show config
4-19
This command displays the following information about the current SCSI parameters
and the device counts for each of the NAS Gateway’s FC ports:
• The SCSI Configuration and Status Information section displays the state of the
Device-Path Failback feature. For more information about the SCSI failback
feature, see “Enabling or Disabling the Device-Path Failback Feature” on page 4-
22 and “Managing Device Path Failback” on page 4-22.
• The Device Counts section shows the devices opened on the enumerated ports and
the total number of devices discovered.
When the devices are first discovered, they are kept in the storage devices list. This list
contains all devices and displays configuration and state information about each
device, such as:
• Each device’s WWN
• Each device’s type and model number
• The storage port that each device is available through
• Each device’s state and RAID level supported
To Display the SCSI Devices Discovered by the NAS Gateway
scsi show (all | DISK | TAPE) [-P PAGENUMBER
[-S PAGESIZE]]
Options and
Description
Arguments
all Displays all discovered devices. This option displays the entire
storage devices list, including disk and tape devices.
DISK Displays only the discovered disk devices.
TAPE Displays only the discovered tape devices.
-P PAGENUMBER Specifies the number of the page to display.
-S PAGESIZE Specifies the page size in number of records to display.
4-20
The NAS Gateway tracks the SCSI statistics for each identified SCSI device. The
statistics are counted in the SCSI statistics summary.
To Display the SCSI Statistics Summary
scsi show stats DEVNAME
DEVNAME is the alphanumeric character string that specifies the
disk or tape device that you want to display.
To Display Details About a SCSI Device
scsi show detail DEVNAME
DEVNAME is the name of the storage device for which you want
to display detailed information. Enter the device name of a disk or
tape device. You can find the device name by running the scsi
show all command.
The detailed display shows product information about the device

that you are managing, physical device information, and logical
device information.
To Display the Worldwide Names of the SCSI Devices’ Ports
scsi show arraywwn [-P PAGENUMBER[-S PAGESIZE]]
-P PAGENUMBER specifies the page to display.
-S PAGESIZE specifies the page size in number of records to
display.
Releasing a Reserved Tape Device

The NAS Gateway and other storage devices can reserve a tape device. When a
reservation occurs, the tape device becomes unavailable until you clear the
reservation. Although reservations and releases can occur automatically, the NAS
4-21
Gateway supports manual release operations. You can use the manual release
whenever a tape drive cannot be opened or used.
To Invoke a SCSI Release of a Tape Device
scsi release WWN LUN
Options and
Description
Arguments
WWN Specifies the world wide name of the storage device that you want to
release.
LUN Specifies the LUN of the storage device that you want to release.
Note - You can obtain a device’s WWN and LUN ID by running the scsi
show detail command against a device name. For example, scsi show
detail IBM_ECV3HM0B_0. At the bottom of the resulting output, you will see
the WWN and LUN ID field.
Moving SCSI Devices to a Specific Storage Port

The NAS Gateway supports moving devices to an FC port on the SP element. By
enabling you to move SAN devices, the NAS Gateway supports the following:
• Path failback for situations such as a link failure and recovery, or an array
controller failure and recovery. For example, if the NAS Gateway has redundant
connections to a RAID through FC ports sp.0 and sp.1. If the link on sp.1 fails, all
I/O would be supported on sp.0 until the error is cleared. When the error is cleared,
you can use the scsi move command to balance the I/O among storage ports by
assigning some devices back to sp.1.
• Manual load balancing of device I/O across multiple ports.
4-22
Note - The port setting you assign through the scsi move command is not
persistent, so the port usage that you set is affected by a reboot.
To Assign Devices to a NAS Gateway Storage Port

Step 1: Run the volume show VOLNAME command against a specific
volume name. In the resulting display, locate the Device Name
field and note the name of the device that the volume is on.
Step 2: Run the scsi show detail NAME command and find the
following information:
• The STATE field. The device must be in the OPEN state.
• The PORT field in the PATH LIST. Note the port where the
device containing the LUN is located. If numerous devices
are using the same port, you can move some of them to a
different port.
Step 3: Run the scsi move command to rebalance the I/O by assigning
devices to another FC port:
scsi move DEVNAME (sp.0|sp.1)
Options and
Description
Arguments
DEVNAME Specifies the device name of the SAN device that you want to move.
sp.0|sp.1 Specifies the storage port to which to move the device. You can only
specify one port at a time.
Step 4: Run the scsi show all command and check the DEVNAME and
PORT fields of the resulting list to verify that the appropriate
devices have been moved to the appropriate ports.
4-23
Enabling or Disabling the Device-Path Failback Feature

The NAS Gateway selects a primary path to a storage device. If the primary path for a
device fails, the device-path failback feature enables the NAS Gateway to revert back
to using that preferred device path when it is restored. When a device is opened for
use, the NAS Gateway selects a preferred path from the list of paths created during the
device-discovery process. If this path fails, the NAS Gateway automatically selects an
alternate path and directs device I/Os to that path.
To Enable or Disable the Device-Path Failback Feature
• Run the following command with the appropriate option.
scsi failback [enable|disable]
Options and
Description
Arguments
enable Sets the device path used when service restores after a failure to be
the preferred path that had been originally set. This command affects
all devices on a single NAS Gateway. enable is the default setting.
disable Sets the device path used when service restores after a failure to be
whatever the NAS Gateway finds upon restart during the discovery
process. This command affects all devices on a single NAS Gateway.
In this case, if the storage administrator wants to use the original path,
the original path must be configured at the command prompt by
running the scsi move command.
Managing Device Path Failback

The NAS Gateway supports device path failback. You can set up any storage device, a
disk volume, or a tape with multiple paths to the NAS Gateway to enable device path
failback. This feature is useful when a path failure occurs. It also helps to maintain
load balancing across the storage ports managed by the NAS Gateway.
When a device is opened for use, the Storage Device Manager (SDM) selects a
primary path from a list of paths created during the device discovery process. The
SDM automatically saves the primary path to the device’s database record. The
primary path is selected based on port load balancing and array preferences that have
been configured by the array manufacturer.
4-24
Note - You can manually override the automatic primary path selected with the
scsi move command. For details on how to use this command, see “Moving
SCSI Devices to a Specific Storage Port” on page 4-20.
If the primary path fails, the SDM automatically selects a new path from a list of
alternate paths and directs device I/O to that path. When the SDM moves the device
I/O to the new path, it attempts to maintain load balancing across the available NAS
Gateway ports.
When the primary path is available again, the SDM automatically detects the restored
primary path and reverts the device back to it. You also can move the device back to
the primary path manually by running the scsi move command.
Note - Primary and alternate path configurations are lost during a device
reboot.
You can enable or disable the device path failback feature with the scsi failback
enable|disable command. This command enables or disables the device path
failback feature for all devices connected to a single NAS Gateway.
By default, the device path failback feature is enabled in the NAS Gateway.
To Disable Device Path Failback
scsi failback disable
You can check the device failback status of all devices connected to a single NAS
Gateway along with additional device configuration information by running the scsi
show config command.
You can check the device failback status and other configuration details of an
individual device by running the scsi show detail DEVNAME command. For details
see “Releasing a Reserved Tape Device” on page 4-19.
Chapter 5: Working with Network
Interfaces
• “Working with Network Protocols” on page 5-2
• “Working with Management Interfaces” on page 5-4
• “Working with Logical Ports” on page 5-12
5-2
Working with Network Protocols

The NAS Gateway supports the following network protocols:
• Internet protocol (IP), version 4, as defined in RFC 791
• User datagram protocol (UDP) as defined in RFC 768
• Transmission control protocol (TCP) as defined in RFC 793
• Internet control message protocol (ICMP) as defined in RFC 792
• Address resolution protocol (ARP)
The NAS Gateway uses IP and higher-layer IP-based protocols for communicating
with clients in the IP network and to serve users who initiate file service requests
through NFS or other file access protocols.
Note - Though the NAS Gateway supports IP and IP-based protocols, it does
not perform any routing of network traffic from other IP devices. The NAS
Gateway supports limited static routing for packets originating from the NAS
Gateway.
The NAS Gateway’s IP protocol stack operates mainly on the file processing (FP)
Gigabit Ethernet ports and allows the physical and logical connection to IP-connected
clients.
The NAS Gateway’s routing functionality is used to transmit and receive packets
using UDP or TCP. The NAS Gateway supports Internet Control Message Protocol
(ICMP) for tracking the connectability of hosts and the communication status of
datagrams. Address Resolution Protocol in the NAS Gateway.
The NAS Gateway supports keep alive, traceroute, and ping packets to verify that
nodes are online, and connections are available to carry data and metadata. The NAS
Gateway can initiate ping and traceroute packets and receive them from a host.
For more information about sending pings, see “Pinging Another Device from the
NAS Gateway” on page 16-5. For more information about performing traceroutes, see
“Performing Traceroute to an IP Address” on page 16-5.
5-3
For more information about adding static entries to the NAS Gateway’s ARP table, see
“Adding Entries to the ARP Table” on page 5-10.
5-4
Working with Management Interfaces

Management interfaces are automatically created on top of the system switch and
controller (SSC) ports on the NAS Gateway. These ports operate at 10 or 100 Mbps
depending on what bandwidth is negotiated with the peer at the other end of the
management interface’s physical layer. They most commonly are assigned an IP
address from a different network and used for purposes other than network traffic. For
example, management interfaces can be used for configuration and management of the
NAS Gateway through secure shell (SSH) connections, and are essential for high-
availability configuration. Each management interface must have a unique IP address.
Note - The NAS Gateway uses the 192.168.192.0/24 network internally.

Therefore, you cannot use any network address in 192.168.192.0/24 for
interfaces that carry network traffic. If you attempt to assign addresses from
that network space, the NAS Gateway will operate unpredictably.
Displaying Interface Information

The interfaces table lists information about all interfaces either from the NAS
Gateway or the virtual server context. One interfaces table exists for the NAS Gateway
and all its virtual servers.
To Display the Interfaces Table
interface show interface [-a SPEC] [-n NODE]
Options and
Description
Arguments
-a SPEC An optional argument that specifies the Gigabit Ethernet interface for
which to display information. If you do not specify a port, the entire
interfaces table is displayed for the NAS Gateway.
-n NODE An optional alphanumeric character string that specifies the NAS

Gateway for which to display interface information.
5-5
Creating Interfaces
The NAS Gateway interfaces sc1 and sc2 are created automatically. As part of a
virtual server setup you can create interfaces for the virtual server using the
interface create command. For more information, see “Creating a Virtual Server
and Performing Basic Setup” on page 3-7.
Modifying Interfaces and Their IP Addresses

You can use the interface modify command to add, enable, disable, or delete NAS
Gateway interfaces sc1 and sc2 and their IP addresses. You can use this command in
the virtual server context to modify interfaces for the virtual server. See “Modifying
Virtual Server Interfaces” on page 3-12, for details on how to modify virtual server
interfaces.
To modify a NAS Gateway interface, use any of the following commands from the
NAS Gateway context, where INTERFACE specifies the name of the interface:
To modify a NAS Gateway interface, use any of the following commands from the
NAS Gateway context, where INTERFACE specifies the name of the interface:
To Enable an Interface
interface modify INTERFACE -s enable
To Disable an Interface
interface modify INTERFACE -s disable
To Add One or More IP Address to the Interface
interface modify INTERFACE -a IPADDR/MASKLEN
[,IPADDR/MASKLEN]...
To Delete One or More IP Address From the Interface
interface modify INTERFACE -d IPADDR [,IPADDR] ...
5-6
Displaying the IP Table

The IP table lists information about all the NAS Gateway’s configured IP addresses
from either the NAS Gateway context or the virtual server context. One IP table exists
for the NAS Gateway and each of its virtual servers.
To Display the IP Table
interface show ip [-a SPEC] [-n NODE]:
Options and
Description
Arguments
-a SPEC An optional argument that specifies the IP address for which to

display information. If you do not specify an IP address, all IP
addresses for the NAS Gateway are displayed.
-n NODE An optional alphanumeric character string that specifies the NAS

Gateway for which to display the IP table.
Configuring Frame Size

The NAS Gateway supports maximum transmission unit (MTU) sizes on each port.
The default MTU size for the NAS Gateway’s file processing ports is 1500 bytes. You
can set the MTU on a file processing port by running the port modify command. This
command configures the largest unfragmented packet size for packets transmitted on
the port. Packets that are larger than the MTU size are fragmented and sent in multiple
packets and then reassembled at their destination.
Note - Configuring the MTU size to a value that is not supported by the switch
and network can cause unexpected behavior or loss of service.
5-7
To Configure the MTU Size

port modify PORT [-m MTU]
Options and
Description
Arguments
MTU Specifies a numerical value, in bytes, that sets the MTU size for
unfragmented packets on the port. Specify an MTU size between 1500
and 16384 bytes. The default MTU size is 1500 bytes. You can set
different MTU sizes on different ports.
PORT Specifies the port on which you are setting the MTU size.
Adding a Route
You can configure routes at the NAS Gateway level or at the virtual server level. When
you add a route, the route is added to the appropriate route table. Routes remain in
either the NAS Gateway’s route table or a virtual server’s route table until you remove
them.
5-8
To Add a Route to the NAS Gateway’s Route Table

route add {net|default} -g IPADDR
[-a IPADDR/MASKLEN] [-n NODE]
Options and
Description
Arguments
net|default Specifies the type of route that you are adding:

• net indicates a specific network route. Network routes
enable communication with a separate subnet when no
routing exists between the two subnets.
• default indicates a default route to a gateway. Default
routes enable communication with a destination that does
not exist as a network route in the NAS Gateway’s route
table. A default route always points to a network gateway
so the NAS Gateway can forward packets to a next hop,
where the gateway will assume further routing
responsibilities.
-g IPADDR Specifies the address of the gateway router for the route. For
example, 192.168.0.1.
-a IPADDR/MASKLEN Specifies the route and the mask length in bits that you’re
adding. For example, 10.20.30.0/16.
-n NODE An optional command that specifies the name of the NAS

Gateway on which the route is configured. This option is valid
only for displaying the NAS Gateway route table.
Displaying the Route Table

The route table shows all routes, including default routes and network routes, that are
currently configured for the current context. If a default route is present, it will appear
as an all-zeroes broadcast address (0.0.0.0) in the route table.
5-9
To Display the Route Table

route show [-a IPADDR/MASKLEN] [-n NODE]
Options and
Description
Arguments
-a IPADDR/MASKLEN Specifies the IP address and mask length, for the route table
you want to display. For example, 10.20.30.0/24.
-n NODE Specifies the name of the NAS Gateway on which to display

the route table. This option is valid only for displaying route
information in the NAS Gateway route table.
Removing a Route
You can remove a static or default route from the route table at any time. You can
remove routes from either the virtual server’s route table or the NAS Gateway’s route
table.
To Remove a Route From the Route Table
• Run the following command.
route delete {net|default} -g IPADDR
[-a IPADDR/MASKLEN] [-n NODE]
Options and
Description
Arguments
net|default Specifies whether to delete a network or default route.
-g IPADDR Specifies the address of the gateway router for the static route.
-a IPADDR/MASKLEN Specifies the static route and mask length in bits that you are
deleting, for example, 10.20.30.0/24.
-n NODE An optional alphanumeric string that specifies the NAS Gateway

on which you are deleting the route. This option is valid only for
removing a route from the NAS Gateway route table.
5-10
Adding Entries to the ARP Table

The NAS Gateway supports ARP and maintains ARP tables at the NAS Gateway level
and at the virtual server level. Because virtual server boundaries are enforced, you
cannot see another virtual server’s ARP table from the context of a different virtual
server.
You can manually add an ARP entry into the NAS Gateway’s or virtual server’s route
table. When you add an ARP entry to the ARP table, you specify the six-bit MAC
address of the far-end device. This MAC address enables the NAS Gateway to resolve
a MAC address to an IP address.
To Manually Add an ARP Entry Into the ARP Table
arp add IPADDR -a MACADDR [-n NODE]
Options and
Description
Arguments
IPADDR Specifies the IP address of the ARP entry you are adding.
-a MACADDR Specifies the MAC address of the device at the far-end of a

physical link.
-n NODE An optional alphanumeric string that specifies the NAS Gateway

where the ARP entry is added. This option is valid only for
adding an ARP entry to the NAS Gateway ARP table.
Displaying the ARP Table
cluster1-4> arp add 10.1.1.89 -a 00:01:d2:c3:a4:21 -n cluster1-3

cluster1-4>
The ARP table contains all the resolved ARP transactions for all interfaces in the NAS
Gateway or a virtual server. When you view the ARP table, you see manually added
entries as well as dynamically added entries. You can view the ARP table for the NAS
Gateway or for a virtual server depending on what context you are in.
5-11
To View the ARP Table for the NAS Gateway or a Virtual Server
arp show [-a IPADDR] [-n NODE]
Options and
Description
Arguments
-a IPADDR An optional argument that specifies the IP address of an

interface for which you want to view the ARP information. If you
do not use the optional IPADDR argument, the entire ARP table
is displayed.
-n NODE An optional argument that specifies the NAS Gateway on which

you want to display the ARP table. This option is valid only for
displaying an entry in the NAS Gateway ARP table.
Removing Entries from the ARP Table

Deletes an ARP entry from any node within the cluster.
To Remove an Entry from the ARP Table
arp delete IPADDR [-n NODE]
Options and
Description
Arguments
IPADDR Specifies the IP address associated with the ARP entry that you
want to remove.
-n NODE An optional alphanumeric character string that indicates the

NAS Gateway from which you want to delete the ARP entry.
This option is valid only for deleting an entry in the NAS
Gateway ARP table.
5-12
Working with Logical Ports

The NAS Gateway supports logical ports. Logical ports are logical constructions that
enable you to group physical links so that they appear as one single port. By doing so,
you gain redundancy through configuration, because the NAS Gateway can recover
from port or link failure.
Interfaces use logical ports. Multiple interfaces can use the same logical port, but one
interface can use only one logical port.
Logical ports exist in the network stack and enable link-layer configuration and
flexibility in network wiring.
The NAS Gateway supports two types of logical ports:
• Standard logical ports are created out of one or more child physical ports. For
more information, see “Understanding Logical Port Operation Modes” on
page 5-12.
• Stackable logical ports are created out of one or more logical ports. For more
information, see “Understanding Stackable Logical Ports” on page 5-22.
Understanding Logical Port Operation Modes

The NAS Gateway’s logical port feature operates in one of three modes: failover,
aggregation, or single.
• In failover mode, only one active physical port of the logical ports carries traffic.
Other physical links on the logical ports are available to carry traffic, but only if
the active link becomes unavailable. When the active link state changes to DOWN,
the live backup link can assume operation as the new active physical link, and
continue carrying traffic after a switch over. During switch over, packet
retransmission occurs through TCP or UDP.
Note - After setting the port preference, the preferred port becomes the active
port for the logical port as long as the preferred port is UP. For more
information about setting the link preference, see “Setting Path Preference for
a Logical Port” on page 5-24.
5-13
• In aggregation mode, all physical links in the logical port are considered active and
carry traffic simultaneously. In link-aggregated configuration, the traffic is load
balanced across all physical links that are associated with the logical port. Link
aggregated mode provides redundancy by load balancing traffic across remaining
active links if one link goes into the DOWN state.
Note - To support aggregation mode, EtherChannel or another trunking

method needs to be configured on the switch to which the physical ports are
connected.
• In single mode, only one physical port exists. It can be used as a way to rename the
default logical port.
NAS Gateway
Virtual Server “Eng” Virtual Server Virtual Server
CIFS/NFS CIFS/NFS CIFS/NFS
UDP TCP UDP TCP UDP TCP

IP IP IP
Route Table Route Table Route Table

ARP Table ARP Table ARP Table
Interfaces
Logical Ports
Link Layer
Physical Ports
Figure 5-1 NAS Gateway Network Stack Showing Logical Port Layer
5-14
As shown in Figure 5-1, logical ports exist at the NAS Gateway level and are
associated with virtual servers. Because the interface is associated with the virtual
server, it fails over to a new NAS Gateway whenever the virtual server fails over.
However, the logical ports themselves belong to the NAS Gateway and do not fail
over. Therefore, for a virtual server to successfully fail over from one NAS Gateway to
another, the new NAS Gateway should have all logical ports required by all the
interfaces in the virtual server. During a virtual server failover, the NAS Gateway
checks for the following:
• The existence of a logical port with required names
• The link state of the logical port
The NAS Gateway does not check the logical port’s mode (single, failover, or
aggregation).
Table 5-5 and Table 5-6 are examples of two NAS Gateways (A and B) in which the
logical port configuration is not viable for virtual server failover.
Table 5-5: Logical Port Configuration on NAS Gateway A
Logical Port Logical Port

Virtual Servers Physical Ports
Name Mode
vs-0 lp0 aggregate fp.0, fp.1
vs-0, vs-1 lp1 single fp.2
vs-2 lp2 single fp.3
Table 5-6: Logical Port Configuration on NAS Gateway B

Virtual Servers Physical Ports
Name Mode
5-15
In the previous configuration, vs-2 can run on NAS Gateway A. It cannot be failed
over to NAS Gateway B because logical port lp2 does not exist on NAS Gateway B.
For successful virtual server failover, make sure that all NAS Gateways have logical
ports with the same name. There is no restriction on the type of logical port and the
physical port contained in the logical port, which relaxes wiring/cabling requirements.
Consider the following example of two NAS Gateways, A and B. Table 5-7 and
Table 5-8 list the logical port configuration of each NAS Gateway.
Table 5-7: Logical Port Configuration on NAS Gateway A

Physical Ports Physical Network
Name Mode
lp0 aggregate fp1.0, fp1.1 network 1
lp1 fail-over fp1.2, fp1.3 network 2
Table 5-8: Logical Port Configuration on NAS Gateway B

Physical Ports Physical Network
Name Mode
On NAS Gateway A, ports fp.0 and fp.1 are connected to network1 whereas on NAS
Gateway B fp.0 and fp.1 are connected to network2.
On NAS Gateway A, lp1 is in failover mode whereas on NAS Gateway B lp1 is of
type aggregate.
Creating a Logical Port

When creating a logical port, consider the following:
5-16
• A default logical port or user-defined logical port that is already in use by an

interface cannot participate in a logical port.
• A default logical port cannot participate in multiple logical ports. For example,
default logical port fp.0 cannot be configured in both logical port1 and logical
port2.
You can create a standard or stackable logical port by running the lport create
command. The difference is in the type of port you use to complete the -a PORTS
argument:
• If you use a default logical port for the -a PORTS argument, you will create a
standard logical port. See “Understanding Logical Port Operation Modes” on
page 5-12.
• If you use a user-defined logical port for the -a PORTS argument, you will create a
stackable logical port. See “Understanding Stackable Logical Ports” on page 5-22.
Note - If a port on the NAS Gateway changes to the DOWN state, it does not
transition to the UP state unless the state of autonegotiation on the NAS
Gateway matches the state of autonegotiation on the peer device on the link.
For example, if a port goes offline, and the port’s autonegotiation state is set to
OFF when the peer device on the other end of the link has autonegotiation set
to ON, the NAS Gateway’s port does not come back online because of this
mismatch.
Ensure that the port and peer device are both set to the same autonegotiation
state. To set the autonegotiation state of a port, run the port autoneg
command.
The lport create command must have at least one default port. The command
cannot have more than:
• Four default logical ports for a standard logical port.
• Four logical ports for a stackable logical port.
5-17
To Create a Standard Logical Port

lport create LPORTNAME
-m {single|failover|aggregation}
-a PORTS
-s {enable|disable}
Options and
Description
Arguments
LPORTNAME Specifies the logical port you are adding by using an

alphanumeric character string.
-m Indicates the mode in which the logical port should operate.

single|failover| • single configures the logical port with a standard single port.
aggregation • failover causes the logical port to operate in failover mode.
By default, the NAS Gateway assigns the first default logical
port configured as the preferred logical port. However, you
can change the preferred logical port by running the lport
prefer command.
• aggregation causes the logical port to operate in link
aggregation mode.
Note - To support aggregation mode, EtherChannel or another

trunking method has to be configured on the switch to which the
physical ports are connected.
-a PORTS Specifies the default logical ports that are being created. You
can specify multiple default logical ports by separating them
with commas, for example, fp.0,fp.1. The -a PORTS argument
must have at least one default logical port specified, but no
more than four.
-s enable|disable Specifies whether the logical port is enabled or disabled

regardless of what mode of logical port you are creating. You
can modify the state of the logical port by running the lport
modify command.
5-18
Load Balancing on IP Interfaces with Logical Ports

Load balancing on the NAS Gateway Gigabit Ethernet IP interfaces is supported
through logical ports. Load balancing support on a logical port requires the following
prerequisites:
• Create the logical port in aggregation mode.
• The NAS Gateway must have two or more Gigabit Ethernet ports that connect to
Gigabit Ethernet ports on a switch, and must be in the same subnet.
• Connect the logical port to a switch that supports EtherChannel.
• Configure the EtherChannel switch needs. The switch is doing the load balancing.
Note - Logical ports have been tested for interoperability with Cisco Systems
3500, 4000, and Extreme Networks 5i and 7i series switches only.
Cisco Systems Switch Connectivity Example

For illustration purposes, assume the following:
• The switch to which you are connecting is a Cisco Systems 3508.
• The 4440 model NAS Gateway’s two file processing (FP) ports are ports fp1.0 and
fp1.1 and the ONStor Bobcat 2200 series NAS Gateway’s two FP ports are ports
fp.0 and fp.1.
• These ports connect to the Cisco 3508 Gigabit Ethernet ports 1 and 6.
To Support Load Balancing on a Cicso 3508 Switch
Step 1: Configure the Cisco 3508 switch, for example:
cisco3508r30#config term
Enter configuration commands, one per line. End with
CNTL/Z.
cisco3508r30(config)#interface gigabitEthernet 0/1
cisco3508r30(config-if)#port group 1
cisco3508r30(config-if)#exit
cisco3508r30(config)#interface gigabitEthernet 0/6
5-19
cisco3508r30(config-if)#port group 1 distr source

cisco3508r30(config-if)#end
cisco3508r30#show running-config
interface GigabitEthernet0/1
port group 1
!
!
!
!
!
port group 1
!
!
!
The switch’s port 1 and port 6 have been configured as part of a
port group. Therefore, the switch distributes the traffic on these
two output links based on the source media access control (MAC)
address of the clients.
Step 2: On the NAS Gateway, create the logical ports in aggregation mode
by running the lport create command. For example, to create a
logical port named “lp1.0” on the NAS Gateway and associate
physical ports to the logical port, you would enter:
5-20
lport create lp1.0 -m aggregation -a fp1.0,fp1.1

lp1.0 is the name of the logical port that you are creating.
-m aggregation is the mode that you are configuring for the
logical port.
-a fp1.0,fp1.1 is the comma-separated list of physical ports that
you are associating with the logical port.
Step 3: On the NAS Gateway, configure the IP address that the logical
port’s physical ports will share, by running the interface create
command. For example, to configure 11.111.22.11 as the IP
interface to be shared on “lp1.0”, run:
interface create intname -l lp1.0 -a 11.111.22.11/16
intname is the name of the virtual interface to which you are
adding an IP address.
-l lp1.0 is the name of the logical port to which you are adding an
IP address.
-a 11.111.22.11 is the IP address and /16 is the subnet mask.
Extreme Networks Switch Connectivity Example
For illustration purposes, assume the following:
• The switch to which you are connecting is an Extreme Networks 5i.
• The 4400 model NAS Gateway’s two FP ports are ports fp1.0 and fp1.1 and the
ONStor Bobcat 2200 series NAS Gateway’s two FP ports are ports fp.0 and fp.1.
• These ports connect to the Extreme Networks 5i Gigabit Ethernet ports 1 and 6.
To Support Load Balancing on an Extreme Networks 5i
Step 1: For configuration on the Extreme Networks 5i, use the following
syntax:
enable sharing MASTER PORT NUMBER grouping RANGE OR
LIST OF NUMBERS algorithm round-robin
On the Extreme Networks 5i switch, this command appears as
shown in the following example:
5-21
enable sharing 1 grouping 1,6 algorithm round-robin

To show the Extreme Networks 5i switch configuration, run the
following command:
show ports configuration
To disable the Extreme Networks 5i switch, run the following
command:
disable sharing 1
Step 2: On the NAS Gateway, create the logical ports in aggregation mode
by running the lport create command. For example, to create a
logical port named “lp1.0” and associate physical ports to the
logical port, you would enter:
lport create lp1.0 -m aggregation -a fp1.0,fp1.1
-l lp1.0 is the name of the logical port that you are creating.
-m aggregation is the mode that you are configuring for the
logical port.
-a fp1.0,fp1.1 is the comma-separated list of physical ports that
you are associating with the logical port.
Step 3: On the NAS Gateway, configure the IP address that the logical
port’s physical ports will share, by running the interface create
command. For example, to configure 11.111.22.11 as the IP
interface to be shared on “lp1.0”, run:
interface create intname -l lp1.0 -a 11.111.22.11/16
intname is the name of the virtual interface to which you are
adding an IP address.
-l lp1.0 is the name of the logical port to which you are adding an
IP address.
-a 11.111.22.11 is the IP address and /16 is the subnet mask.
5-22
Understanding Stackable Logical Ports

The NAS Gateway supports stackable logical ports, which you can use to create a
parent logical port out of child logical ports. Stackable logical ports operate similar to
standard logical ports. See “Understanding Logical Port Operation Modes” on
page 5-12.
Before you can create stackable logical ports you need to create single or aggregation
logical ports.
Consider the following illustration of configuring a failover parent logical port out of
two child logical ports configured to use two physical Gigabit Ethernet ports in link
aggregation mode. See Figure 5-2 on page 5-22. No single point of failure exists.
Note - Both switches must be in the same subnet.
Gigabit Ethernet Switch Gigabit Ethernet Switch
Connect to 2 switches
for failover
NAS Gateway A fp1.0 fp1.1 fp1.2 fp1.3 Gigabit Ethernet ports
Logical Port A Logical Port B Logical ports with link

aggregation
Logical port with failover
Logical Port AB across logical ports A and B
Figure 5-2 Configuring a Failover Logical Port out of Child Logical Ports
5-23
Note - Not all combinations of logical ports are permitted. Currently the
following restrictions apply to forming a logical port using other logical ports:
• To form a single logical port, use only the ports fp1.0 through fp1.3.
• To form an aggregate logical port, use single ports only.
• Do not use failover ports to form a failover logical port
• Parent logical ports can only be in failover mode. Children
ports can only be in single or aggregation mode.
Creating Stackable Logical Ports

Creates a logical port of specified mode and ports or lports.
To Create a Stackable Logical Port
lport create LPORTNAME
-m {single|failover|aggregation}
-a PORTS -s {enable|disable}
Options and
Description
Arguments
LPORTNAME Specifies the name of the logical port you are adding by using
an alphanumeric character string.
5-24
Options and
Description
Arguments
-m Indicates the mode in which the logical port should operate.

single|failover| • single configures the logical port with a standard single port.
aggregation • failover causes the logical port to operate in failover mode.
By default, the NAS Gateway assigns the first logical port
configured as the preferred logical port. However, you can
change the preferred logical port by running the lport
prefer command.
aggregation mode.
Note - To support aggregation mode, EtherChannel or another

trunking method has to be configured on the switch to which the
physical ports are connected.
-a PORTS Specifies the logical ports to be used as children. You can

specify only two logical ports separated by a comma, for
example, lport1, lport2.
-s enable/disable Specifies whether the logical port is enabled or disabled

regardless of what mode of logical port you are creating. You
can modify the state of the logical port by running the lport
modify command.
Setting Path Preference for a Logical Port

The NAS Gateway supports a preferred path for failover logical ports only. The
preference value you assign determines which one is the preferred path to carry traffic.
5-25
To Set a Logical Port Preference

lport prefer LPORTNAME -a PORT
Options and
Description
arguments
LPORTNAME Specifies the failover logical port on which you are setting the
preferred link by using an alphanumeric character string.
-a PORT Specifies the preferred path for carrying traffic on a failover

logical port. You can specify the name of the default or user-
defined logical port to be the preferred port. You can specify
only one logical port link with this argument.
Modifying a Logical Port

You can modify an existing logical port by running the lport modify command.
When you modify a logical port, you can:
• Change the mode of the logical port.
• Add up to four ports to the logical port. When adding one or more ports to the
logical port, the ports you are adding cannot belong to another logical port.
• Delete ports from the logical port.
• Change the administrative state of the logical port.
The lport modify command does not complete unless you specify at least one of the
arguments.
5-26
To Modify a Logical Port

lport modify LPORTNAME
[-m {single|failover|aggregation}] [-a PORTS]
[-s {enable|disable}]
Options and
Description
Arguments
LPORTNAME Specifies the logical port you are modifying by using an

alphanumeric character string.
-m Determines the mode that you are setting on the logical port.
single|failover| • single configures the logical port with a standard single
aggregation port.
• failover causes the logical port to operate in failover mode.
By default, the NAS Gateway assigns the first logical port
configured as the preferred logical port. However, you can
change the preferred logical port by running the lport
prefer command.
aggregation mode.
-a PORTS Specifies which ports are being added to or deleted from the
logical port. Ports can be default logical ports or user-defined
logical ports. If you specify multiple logical ports, separate them
with commas.
-s enable|disable Changes the state of the logical port to either enabled or

disabled. If a logical port’s state is changed, the state change is
applied to all interfaces of all virtual servers using the logical
port.
Displaying Logical Port Information

The NAS Gateway keeps a list of all the logical ports and their associated physical
links in the logical ports table. The logical ports table contains each logical port and
provides information about how the logical port is configured and operating.
5-27
To Display the Logical Ports Table

lport show [LPORTNAME][-n NODE]
Options and
Description
Arguments
LPORTNAME An optional alphanumeric character string that names the

logical port you are displaying.
• If you do not specify a logical port, all logical ports are
displayed.
• If you specify a logical port, then detailed information about
the logical port is displayed, such as the administrative
state, the operational state, the list of ports, preferred port (if
the mode is failover), and the list of interfaces using this
logical port.
-n NODE Displays all logical ports of a NAS Gateway.
Deleting a Logical Port

The NAS Gateway supports deleting a logical port. When you delete a logical port, no
IP interface can be associated with the logical port.
Note - If you need to first delete the interfaces associated with the logical port,
you do so by running the interface delete command.
To Delete a Logical Port

lport delete LPORTNAME
LPORTNAME is an alphanumeric character string that specifies
the logical port you are deleting.
5-28
Chapter 6: Managing Volumes and
File Systems
• “Introduction to Volumes” on page 6-2
• “Managing Volumes” on page 6-5
• “File System Statistics” on page 6-24
6-2
Introduction to Volumes
The NAS Gateway builds its file system from volumes that are created by LUNs. The
following types of volumes can exist on the NAS Gateway, depending on their use:
• File system volumes, also called standard volumes. This type of volume contains a
file system and provides the user a way to make their file system data accessible.
• Mirror volumes are used by the NAS Gateway’s Data Mirror mirroring
application. You can mount a mirror volume only as a read-only volume. For more
information, see “Working with ONStor Data Mirror” on page 13-1.
• Core volumes are used to receive and temporarily hold NAS Gateway core dumps
if the NAS Gateway crashes. The core volume is not mountable. Any core data is
copied from the core volume to the management volume from where you can
retrieve it. One core volume exists on each NAS Gateway. For more information,
see “Working with Core Dumps” on page 16-34.
• Management volumes exist within management virtual servers. This volume
provides a repository for temporary files (for example, during NDMP backup and
restore sessions), and for administrative tasks, such as receiving core dump files
when they are copied from the core volume. One management volume exists on
each NAS Gateway.
Volumes and Virtual Servers

Volumes are associated with virtual servers and, therefore, you need to configure them
from within the context of a virtual server. For more information about virtual servers,
see “Working with Virtual Servers” on page 3-1.
Understanding the Management Volume

The management volume operates like any other volume. It contains management
data, but it can also contain user data. You need to explicitly create the management
volume by running the system create mgmtvolume command.
The management volume has the following considerations:
• It exists within the management virtual server and, therefore, you need to
configure it within the context of the management virtual server. For more
6-3
information about the management virtual server, see “Understanding the

Management Virtual Server” on page 3-4.
• It always has the name string vol_mgmt_XXXX. Where XXXX is the same numerical
identifier as the management virtual server in which it is configured.
• You need to configure it on an array.
• You can configure it with volume AutoGrow parameters.
• You can modify it and its AutoGrow parameters through the volume modify
command.
Creating a Management Volume

The management volume is created within the management virtual server. The
management volume operates like a standard volume in regards to volume features
such as AutoGrow.
To Create a Management Volume
Step 1: Run the following command to display the management virtual
server:
vsvr show all
The management virtual server contains the name string
“VS_MGMT_”. Note the full name of the management server
including its number. You will use the management virtual server
name in the next step.
Step 2: Switch to the management virtual server by running the following
command:
vsvr set VS_MGMT_4353
Step 3: Configure an IP address for the management virtual server by
running the following command:
interface create fp1.0 -l lp.0 -a 10.123.48.101
Step 4: Run the following command from within the context of the
management virtual server to create the management volume.
Specify the array on which the management volume will be
6-4
created. For example, to create the management volume on the

array “IBM_ECV5TUHB” within the management virtual server
vs_mgmt_4353, you would run the following command:
system create mgmtvolume IBM_ECV5TUHB
This creates the management volume name string. The
management volume name string is always vol_mgmt_XXXX
where X is the same number string as the management virtual
server.
Note - This step creates the management volume with default usage and
AutoGrow parameters, but you can configure custom parameters. For more
information about the volume usage and AutoGrow parameters, see “Creating
a Volume” on page 6-5.
6-5
Managing Volumes
Although volumes and their associated physical storage and file systems are managed
automatically in runtime, you need to configure the volume space policy that the NAS
Gateway uses.
Creating a Volume
When creating and managing volumes, consider the following:
• Smaller volumes facilitate and expedite maintenance.
• Smaller volumes are more flexible and efficient for snapshots, mirrors, and other
file system services.
• Smaller and more focused volumes are more easily managed because the amount
of data contained in more focused volumes is less than in one larger volume.
Note - When you create a volume, assign it an alphanumeric name string of no

more than 127 characters.
Volumes are created within the context of a virtual server. To configure a volume, the
minimum required parameters are the volume name and the array or device name on
which it is configured. Additional parameters you can configure are disk usage
conditions for triggering the volume AutoGrow feature, and LUN characteristics for
creating or AutoGrow the volume with compatible LUNs.
Before creating a volume, ensure that the following conditions exist:
• One or more LUNs must be labeled. See “Labeling and Unlabeling a LUN” on
page 4-14 for details.
• A virtual server must exist because you create a volume within a virtual server. See
“Configuring a Virtual Server for a File System Protocol” on page 3-41 for details.
6-6
To Create and Configure a Volume

volume create VOLNAME ARRAY [-A ATIMEUPDATES]
[-c CHARSUBST] [-e SHAREDREAD] [-g MINAUTOGROW]
[-h HIGHWATERMARK] [-l MINLUNSIZE] [-L LANGUAGE]
[-m] [-o OPLOCKS] [-q HARDQUOTA][-r RAIDLEVEL]
[-s SOFTQUOTA] [-t CHARSUBSTTABLE]
[-u MAXLUNSIZE] [-j SECURITYTYPE]
Options and
Description
Arguments
VOLNAME Specifies the name of the volume you are creating. Volume
names can be any alphanumeric character string of up to 127
characters.
ARRAY Specifies the name of an array or device from which the

volume obtains LUNs, or a specific device name.
• An array name is a string that consists of a
make_serial#. For example, IBM_60432. You can
also use part of the array name, for example, I to select all
IBM arrays, IBM_6 to select all IBM arrays with a serial
number that starts with 6, or IBM_60432_ to select any
LUN in the specific array IBM_60432_. If you use this
method and multiple arrays fit the criteria, a LUN is used
from the first array in the list.
• A device name is a string that consists of
make_serial#_LUN. For example,
IBM_60432_255.
-A ATIMEUPDATES An optional argument that disables or enables the automatic
last access time updates option. When enabled, the file
system automatically updates the last access time on files and
directories when they are read. When disabled, the last access
time is only updated when an NFS or CIFS client explicitly sets
the time stamp. Enabling this option increases the file system
update load, but enables clients to see which files are being
used. The default is enabled.
6-7
Options and
Description
Arguments
-c CHARSUBST An optional argument that sets the CIFS illegal character

substitution option to enabled or disabled. When enabled, if
NFS creates a filename with the illegal characters, which are
"*:<>?\|, then the NAS Gateway automatically substitutes
a list defined by CHARSUBSTTABLE. The value for
CHARSUBST can be “enabled” or “disabled”. By default, the
CHARSUBST is “disabled”. You cannot set this to enabled
without also providing a value for CHARSUBSTTABLE.
-e SHAREDREAD An optional argument that specifies the state of the CIFS “no
shared read” open flag for the volume. This flag is read by NFS
requests, and the state you set affects whether NFS clients
can access files on the volume. You can set this variable to
allow or disallow. By default, the shared read is allowed.
Specify the shared read argument with the following
construction:
• -e sharedread=allow permits NFS requests to ignore
the “no shared read” flag. NFS requests are allowed, and
NFS clients are able to read files on the volume.
• -e sharedread=disallow causes NFS requests to
respect the “no shared read” flag. NFS requests are
not allowed, and NFS clients are not permitted to
read files on the volume.
-g MINAUTOGROW An optional argument that specifies the smallest amount of
storage that the volume can automatically grow if it needs
more space. Enter the volume’s absolute maximum size in
MB. If you set this argument to 0 there is no minimum limit, so
the NAS Gateway can get a chunk of disk space that is any
size. The default value is 500 MB.
6-8
Options and
Description
Arguments
-h HIGHWATERMARK An optional argument that enables the AutoGrow feature for

the volume. It specifies the trigger that causes the volume
space to grow by the amount specified in the
MINAUTOGROW argument. Enter the value as a percentage
of the total amount of currently allocated space. The NAS
Gateway uses the percentage of total used space to calculate
the actual amount of disk space required. Set the high water
mark to a value between 25% and 100%. If you set the value
to zero (0), then automatic volume space growth is disabled.
Default value: 0, no threshold is set for automatic volume
space growth.
-j SECURITYSTYLE Controls the security style supported by the file system. When
creating a new filesystem object, any supplied security
information will be honored only if the filesystem security style
matches the style of the security information. Otherwise,
security information from the parent directory is inherited.
Possible values are: normal, nfs, cifs, and
cifsWithSilentNfsFailures.
• When set to normal, both NFS and CIFS security styles
are supported. While an object can have only one form of
security style at any point, it is set by the last protocol that
created or modified it.
• When set to nfs, setting CIFS ACLs will not be supported.
• When set to cifs, any attempt to change security
information by NFS will be ignored.
• When set to cifsWithSilentNfsFailures, any attempt to
change security information by NFS will appear to be
successful, but no change is made to the security
information.
-l MINLUNSIZE An optional argument that specifies the smallest LUN to be

used in AutoGrow. Set this argument to 0 (the default) to allow
any size of LUN to be used.
-L LANGUAGE Specifies the language code that you are using to create the
volume. For a list of language codes, use the online help by
running the help volume create command.
6-9
Options and
Description
Arguments
-m Creates the volume as a mirror volume.
-o OPLOCKS An optional argument that specifies whether CIFS requests

are permitted to obtain OPLOCKS (opportunistic locks) on
files. The values for this option are allow and disallow. When
allowed, CIFS requests are permitted to obtain oplocks on
files. When disallowed, no CIFS oplocks are granted.
The default value for OPLOCKS is allow. Ensure that the
volume is online before setting this option.
-q HARDQUOTA An optional argument that specifies the hard quota, which is

the maximum size of the volume. Enter the volume’s absolute
maximum size in 1 MB blocks. Set this argument to 0 (the
default) if you want unlimited growth for the volume.
-r RAIDLEVEL An optional argument that specifies the RAID level of the LUNs
that will be used to create the volume. The NAS Gateway
supports RAID 0, 1, 0 + 1, 3, and 5. Specify the RAID level as
the word RAID plus a dash, then the RAID level. For example,
you would enter the strings “RAID-0+1”, “RAID-3”, or “RAID-5”
(minus the quotation marks) for the corresponding RAID
levels. By default, the NAS Gateway does not pay attention to
RAID level, it just builds the volume on the first available LUN
on the specified array. Therefore, if you want to create a
volume out of LUNs of a specific RAID level, you need to
specify the RAID level.
Note - If you also configure volume AutoGrow parameters, the

AutoGrow uses only LUNs of the same RAID level. Therefore,
if you are creating a volume with LUNs of a specific RAID level
and you also want to configure AutoGrow for the volume, you
need to have some unused LUNs of the same RAID level.
Otherwise, AutoGrow will not find an available LUN of the
same RAID level to add to the volume.
6-10
Options and
Description
Arguments
-s SOFTQUOTA An optional argument that specifies a percentage of the

hardquota. When the volume usage equals or exceeds the
percentage you specify, another free LUN is taken and added
to the volume. An Elog message is posted on the management
console when the soft quota triggers the addition of another
LUN to the volume. Enter a percentage value from 1 to 100.
The default value is 0, which means that the NAS Gateway
does not track the softquota value.
-t CHARSUBSTTABLE An optional argument that sets the CIFS illegal character

substitution table. CHARSUBSTTABLE is a comma-delimited
list of 2-byte Unicode values in hexadecimal format to be
substituted for the characters “*:<>?\ /, for example,
FF82,FF89, FF8A, FF8C, FF8E, FF8F, FF7F, and FF88.
-u MAXLUNSIZE An optional argument that specifies the size of the LUN to be

used in AutoGrow. Set this argument to 0 (the default) to allow
any size of LUN to be used.
Adding Arrays to a Volume

You can add up to eight arrays to a volume by following this procedure.
To Add Arrays to a Volume
Step 1: Run the following command to list the created volumes:
volume show
Step 2: From the resulting output, locate the volume that will receive the
additional arrays and note the volume name.
Step 3: Run the lun show command and find the names of the arrays that
you want to add.
Step 4: Add up to eight arrays to the volume by running the following
command:
6-11
volume add array VOLNAME ARRAY
Options and
Description
Arguments
VOLNAME Specifies the name of the volume to which you are adding an array.
Volume names can be a maximum of 127 characters.
ARRAY Specifies a list of controller names for one or more arrays from
which the volume will obtain its LUNs. You can enter a single array
name. Enter the controller names as shown in the lun show
command.
Deleting Arrays From a Volume

You can delete arrays from a volume by running the volume delete array
command.
Note - If a volume is contained in part or in whole on an array, the NAS

Gateway will not allow this command to complete. The volume delete
array command will complete only if the array contains none of the volume’s
data. If you want to delete an array that does contain some or all of the
volume’s data, run the volume delete command to delete the volume’s data.
Running the volume delete command will immediately delete all of the
volume’s data.
To Delete a Volume From An Array

Step 1: Run the following command to list the created volumes:
volume show
Step 2: Locate the volume that will have its arrays deleted and note the
volume name.
Step 3: Delete the arrays from the volume by running the following
command:
6-12
volume delete array VOLNAME ARRAY
Options and
Description
Arguments
VOLNAME Specifies the volume you are deleting.
ARRAY Specifies a list of device names that you will be deleting from the volume.
You can enter a single array name, or a comma separated array list up to
a maximum of eight arrays. Enter the device names as shown in the lun
show command.
Assigning a Volume to a Virtual Server

Assign a volume to a virtual server only if the volume is not already associated with a
virtual server. For example, if the NAS Gateway configuration is lost or becomes
corrupted, you can use this command as part of the recovery process for the NAS
Gateway. Restart the NAS Gateway restarted after the recover process.
Note - You cannot assign a volume that is already assigned to a virtual server.
To determine whether a volume is currently owned by a virtual server, run the
volume show command. If the Virtual Server column is empty, the volume
is not assigned to a virtual server.
To Assign a Volume to a Virtual Server

volume add vsvr VOLNAME VIRTUALSERVER
Options and
Description
Arguments
VOLNAME Specifies the existing volume to be assigned to the virtual server.

The volume name can be from 1 to 127 characters.
VIRTUALSERVER Specifies the virtual server to assign to the volume.
6-13
Displaying Volume Information

The NAS Gateway tracks all the configured volumes for usage information. The
configured volumes are displayed in the volumes table regardless of the volume’s
operational state. You can display a listing of all volumes or you can display detailed
information about a specific volume.
The volume table displays a listing of all volumes with the following information:
• Status information for each volume. Valid values for volume status are:
- Online
- Mounted
- Mounted-RO, for a volume that is mounted read-only (for example, a
mirror volume)
- Paused
- NotMounted
- Unmounting
- Failing
- Offline
• Type information, such as whether the volume is configured as a standard file
system volume for file system data, or a mirror volume for receiving file system
data as the result of a mirroring operation.
• Usage information in MB, such as the current volume size, hard quota, amount of
space used, and amount of space available. The percentage of used space
compared to available space is also displayed.
• Virtual Server information, which indicates the virtual server that contains the
volume.
Displaying the volume table for a specific volume, shows the following information:
• Status information, such as whether the volume is mounted, online, or offline.
• Virtual Server information, which indicates the virtual server that contains the
volume.
6-14
• Volume ID information, which is used for NAS Gateway internal computations.

• Type information, such as whether the volume is configured as a standard file
system volume for file system data, or a mirror volume for receiving file system
data as the result of a mirroring operation.
• Usage information in MB, such as the current volume size, amount of space used,
and amount of space available. The percentage of used space compared to
available space is also displayed.
• Volume quota information for disk usage and AutoGrow, such as the hard quota,
soft quota, high watermark, and minimum AutoGrow parameters.
• Device information for the LUNs associated with the volume, such as the device
name, make and model, and RAID level of the array on which the volume has been
configured. The minimum and maximum LUN size parameters for the array are
also displayed.
• LUN List information, which identifies each LUN that is assigned to the volume.
To Display Volume Information
volume show [(VOLNAME|-r)]
VOLNAME is an optional argument that specifies the name of a
configured volume for which to display information. If you do
not supply a volume name, a list of all volumes is displayed.
The -r option displays the volume’s RAID level.
Modifying a Volume’s Parameters

You can modify a volume’s characteristics, including its name and automatic resizing
parameters by running the volume modify command. This command is useful for
renaming a volume or changing its quota parameters. For the volume modify
command to complete, the volume must be offline or online depending on the
parameter that you want to modify:
• To change the -h HIGHWATERMARK, -e SHAREREAD, or -L LANGUAGE, or the -
j SECURITYSTYLE parameters, the volume must be online. If the volume is offline,
6-15
you can explicitly bring the volume online by running the volume online
command. (See “Bringing a Volume Online” on page 6-19.)
• To change the -p NEWVOLNAME parameter, the volume must be offline. If the
volume is online, you can take the volume offline by running the volume offline
command. (See “Taking Volumes Offline” on page 6-18.)
• To change the -q HARDQUOTA, -s SOFTQUOTA, -g MINAUTOGROW, or -d
DEVICENAME (regardless of whether you are using -f) parameters, the volume
can be online or offline.
To Modify a Volume
volume modify VOLNAME [-A ATIMEUPDATES]
[-c CHARSUBST] [-d DEVICENAME][-e SHAREDREAD]
[-f] [-g MINAUTOGROW] [-h HIGHWATERMARK]
[-j SECURITYSTYLE] [-L LANGUAGE] [-o OPLOCKS]
[-p NEWVOLNAME] [-q HARDQUOTA] [-s SOFTQUOTA]
[-t CHARSUBSTTABLE]
Options and
Description
Arguments
VOLNAME Specifies the volume you want to modify.
-A ATIMEUPDATES Disables or enables the automatic last access time updates

option. When enabled, the file system automatically updates
the last access time on files and directories when they are read.
When disabled, the last access time is only updated when an
NFS or CIFS client explicitly sets the time stamp. Enabling this
option increases the file system update load, but enables
clients to see which files are being used. The values for
ATIMEUPDATES are enabled or disabled. The default is
enabled.
6-16
Options and
Description
Arguments
-c CHARSUBST An optional argument that sets the CIFS illegal character

substitution option to enabled or disabled. When enabled, if
NFS creates a filename with the illegal characters "*:<>?\|, then
the NAS Gateway automatically substitutes a list defined by
CHARSUBSTTABLE. The value for CHARSUBST can be
enabled or disabled. By default, CHARSUBST is disabled. You
cannot set this to enabled without also providing a value for
CHARSUBSTTABLE.
-d DEVICENAME and Allows you to specify one device to trigger growth of the
-f volume:
• If you specify -d DEVICENAME, the device is not added to
the volume if it is configured with a different RAID level than
the volume.
• If you specify -d DEVICENAME -f, the device is added to
the volume even if the specified device is a different RAID
level.
The device name is a string that consists of
make_serial#_LUN. For example, IBM_60432_255.
-e SHAREDREAD An optional argument that specifies the state of the CIFS “no
shared read” open flag for the volume. This flag is read by NFS
requests, and the state you set will affect whether NFS clients
can access files on the volume. You can set this variable to
allow or disallow. By default, the shared read is allowed. The
shared read argument must be specified with the following
construction:
• -e sharedread=allow permits NFS requests to ignore
the “no shared read” flag. Therefore, NFS requests will be
allowed and NFS clients will be able to read files on the
volume.
• -e sharedread=disallow causes NFS requests to
respect the “no shared read” flag. Therefore, NFS requests
are not allowed, and NFS clients are not permitted to read
files on the volume.
6-17
Options and
Description
Arguments
-g MINAUTOGROW An optional argument that specifies the smallest amount of

storage that the volume can automatically grow if it needs more
space. Enter the volume’s absolute maximum size in MB. This
value must be a nonzero value. The default value is 500 MB.
-h HIGHWATERMARK An optional argument that specifies the trigger that causes the
volume space to grow by the amount specified in the
MINAUTOGROW argument. Enter the value as a percentage
of the total amount of currently allocated space. The NAS
Gateway uses the percentage of total used space to calculate
the actual amount of disk space required. Set the high water
mark to a value between 25% and 100%. If you set the value to
zero (0), then automatic volume space growth is disabled.
Default value: 0, no threshold is set for automatic volume space
growth.
-j SECURITYSTYLE An optional argument that specifies the security style supported

by the file system. When creating a new file system object, any
supplied security information will be honored only if the file
system security style matches the style of the security
information. Otherwise, security information from the parent
directory is inherited. Possible values are: normal, nfs, cifs, and
cifsWithSilentNfsFailures.
• When set to normal, both NFS and CIFS security styles are
supported. While an object can have only one form of
security style at any point in time, it is set by the last
protocol that created or modified it.
• When set to nfs, setting CIFS ACLs will not be supported.
• When set to cifs, any attempt to change security
information by NFS will be ignored.
• When set to cifsWithSilentNfsFailures, any attempt to
change security information by NFS will appear to be
successful, but no change is made to the security
information.
-L LANGUAGE The language code that you are using to create the volume. For
a list of language codes, use the online help by running the
help volume create command.
6-18
Options and
Description
Arguments
-o OPLOCKS An optional argument that specifies whether CIFS requests are

permitted to obtain OPLOCKS on files. The values for this
option are allow and disallow. When allowed, CIFS requests are
permitted to obtain oplocks on files. When disallowed, no CIFS
oplocks are granted.
The default value for OPLOCKS is allow. Ensure that the
volume is online before setting this option.
-p NEWVOLNAME An optional argument that specifies the new name that you are
assigning to the volume. When you set the new volume name
the name used in VOLNAME no longer applies.
-q HARDQUOTA An optional argument that specifies the hard quota, which is the
maximum size of the volume. Enter the volume’s absolute
maximum size in MB. Set this argument to 0 (the default) if you
want unlimited growth for the volume.
-s SOFTQUOTA An optional argument that specifies a percentage of the

hardquota. When the volume usage equals or exceeds the
percentage you specify another free LUN is taken and added to
the volume. An Elog message is posted on the management
console when the soft quota triggers the addition of another
LUN to the volume. Enter a percentage value from 1 to 100.
The default value is 0, which means that the NAS Gateway
does not track the SOFTQUOTA value.
-t CHARSUBSTTABLE An optional argument that sets the CIFS illegal character

substitution table. CHARSUBSTTABLE is a comma-separated
list of 2-byte Unicode value in hexadecimal format to be
substituted for the characters "*:<>?\|, for example,
FF82,FF89,FF8A,FF8C,FF8E,FF8F,FF7F,FF88.
Taking Volumes Offline

You can take a volume offline to perform diagnostics or for maintenance to the
physical devices that support the LUNS that the volume owns. When you take a
volume offline, all of its configured parameters remain intact until you bring the
volume back online.
6-19
To Take a Volume Offline

Note - This command can be intrusive. Make sure that no one is currently
using the volume when you take the volume offline.
volume offline VOLNAME

VOLNAME is the name of a currently online volume that you want
to take offline.
Bringing a Volume Online

You can bring a volume online after performing diagnostics or for maintenance to the
physical devices that support the LUNs that the volume owns. When the volume
comes back online, it is automatically mounted with its previously configured
parameters.
By default, the volume can be brought online only by the virtual server that owns it.
However, mirror volumes are the exception. Mirror volumes can be brought back
online in read-only mode by any virtual server.
Note - When you bring an offline volume back online, the shares for the
volume become visible again in the list of shares.
To Bring a Volume Online

volume online VOLNAME [-o MODE]
Options and
Description
Arguments
VOLNAME Specifies the currently offline volume that you want to activate.
6-20
Options and
Description
Arguments
-o MODE An optional argument that sets the access mode for the volume
when it is brought back online:
• -o ro allows read-only access when the volume comes
back online.
• -o rw allows read-write access when the volume comes
back online. Read-write access is the default.
Importing a Volume From One Cluster to Another

The NAS Gateway supports importing volumes from the source virtual server of one
cluster to the target virtual server of another cluster.
The volume import feature is supported on standard volumes and mirror volumes.
Anytime a volume is imported, the NAS Gateway recognizes it as a takeover event, so
volume ownership changes. Do not import core volumes and management volumes.
The volume import feature supports importing volumes regardless of a cluster’s state.
Importing volumes is helpful if, for example, a cluster fails. In that case, you can
import any number of volumes from the failed cluster into a virtual server of another
cluster. You also use the volume import feature as part of performing a baseline mirror
operation. See “Creating a Local Mirror to Perform Baseline Data Copy for a Data
Mirror over IP” on page 13-7. You can import only one volume at a time.
Considerations for Importing Volumes
To import a volume into a cluster, consider the following:
• Before importing a volume, disable the volume to be imported and stop any active
backup or mirror sessions on that volume.
• You need to be in the context of the virtual server to which you are importing the
volume. The command fails if you run it from the NAS Gateway context.
• The volume import feature supports only volumes that are visible through network
or SAN connectivity.
To Import a Volume to a Cluster
Step 1: From the context of the virtual server that will receive the
6-21
imported volume, run the lun rescan all command. Allow

approximately 30 seconds before proceeding to the next step.
The 30-second interval allows the lun rescan all command to
complete and refresh the LUN list.
Step 2: Run the lun show all command and note the cluster name and
volume name for the volume that you will be importing.
Step 3: Take the volume to be imported offline by running the following
command:
VOLNAME is the name of the volume you are importing.
Step 4: From the context of the virtual server to receive the imported
volume, run the volume import command:
volume import CLUSTERNAME SOURCEVOLNAME
[DESTVOLNAME] [-m]
Options and
Description
Arguments
CLUSTERNAME Specifies the cluster from which you are importing the volume.
SOURCEVOLNAME Specifies the volume that you are importing.
DESTVOLNAME An optional argument that allows you to rename the volume that
you are importing to the new virtual server. If you use this
option, the new name must be unique in the new cluster. If you
do not use this option, the volume is imported with its original
name if that name is not already in use in the new cluster.
-m Sets the type of volume to be imported to a mirror volume.

When you import a volume as a mirror volume, a mirror demote
operation is performed. See “Working with ONStor Data Mirror”
on page 13-1 for details on demoting a mirror volume.
Step 5: From the context of the virtual server that received the imported
volume, run the volume show command to verify that the volume
6-22
exists on the target virtual server. When you perform this step, the
newly imported volume’s state is offline.
Note - At this point, the volume can appear in both the original cluster and the
new cluster. If the source cluster or virtual server’s state is UP, the volume you
imported still appears in the original cluster until you bring the imported
volume online in the new cluster.
Step 6: From the context of the virtual server that received the imported
volume, put the volume into service by running the volume online
command.
Note - This step causes the volume in the source cluster or virtual server to
automatically go offline in the original cluster because all the LUNs have been
moved. At this point, the imported volume is no longer part of the original
cluster, so it cannot be brought online or managed through the original cluster.
Step 7: From the original cluster, run the volume delete command and
specify the name of the offline volume that has been moved. This
step deletes the offline volume from the source cluster.
Deleting a Volume
By deleting a volume, you delete the file system data on it, any share configured for
the volume, and release the disk space that was assigned to the volume.
To Delete a Configured Volume
Step 1: Run the following command to identify the volume you want to
remove:
volume show
Step 2: Run the following command to remove the volume:
volume delete VOLNAME
6-23
VOLNAME is the name of the volume you want to delete.

When you run the following command, the NAS Gateway
prompts you for confirmation. Press the Y key to accept the
deletion or the N key to abort the deletion when you see this
prompt:
Are you sure? [y|n]
6-24
File System Statistics

The NAS Gateway supports multiple file system operation and performance counters.
The following file system statistics are available:
• Cache statistics, which include the file system cache usage for common file system
operations.
• Performance statistics, which include file system usage by file system request
type, and average response or completion times for each file system request type.
• Resource statistics, which include file system resource usage and availability prior
to an NFS request being completed.
Displaying the File System Cache Statistics

File system cache statistics display the cache usage for the file system including the
traffic usage of I/O operations.
The file system cache statistics track the information about various user data metadata
events in the file system, such as:
• Types of file system user data and metadata events.
• Current maximum size of the cache for various user data and metadata functions.
• Number of times the cache has hits for various metadata and user data functions.
• Number of times that an object needed to be written to disk.
To Display the File System Cache Statistics
filesystem show stats cache [-n NODENAME|VOLNAME]
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system cache

statistics for a specific node. This is the default setting.
VOLNAME An optional argument that displays the file system cache

statistics for a specific volume.
6-25
Displaying File System Cache Hash Statistics

File system information is hashed to more efficiently locate metadata in NAS Gateway
memory. The NAS Gateway’s file system cache hash statistics focus primarily on
inode and metadata usage. These statistics show information about the following:
• Inodes
• Memory buffers
• User data
• Pages
• Disks
To Display the File System Cache Hash Usage Statistics
filesystem show stats cache hash
[-n NODENAME|VOLNAME]
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system cache hash
VOLNAME An optional argument that displays the file system cache hash
Displaying File System Cache Verbose Statistics

The file system tracks verbose cache statistics for metadata. Verbose cache statistics
track the usage of the writeback cache and the writeback daemon:
• The writeback cache is used whenever a user or metadata object is modified and
the cache is full, which causes the user or metadata to be written to disk.
• The writeback daemon is triggered on regular intervals and when specific file
system events occur.
6-26
To Display the File System Cache Verbose Statistics

filesystem show stats cache verbose
Options and
Description
Arguments
-n NODENAME An optional argument that displays the verbose cache statistics for a
specific node. This is the default setting.
VOLNAME An optional argument that displays the verbose cache statistics for a
specific volume.
Displaying File System Performance Statistics

The file system performance statistics show information about the runtime operation
of the file system based on specific NFS request types. The performance statistics also
list average response or completion times for each NFS request type. Through the
completion times you can assess file system performance by noting how quickly
requests are processed. Many of the file system requests tracked resemble NFS v3 or
CIFS requests.
To Display the File System Performance Statistics
filesystem show stats performance
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system performance

VOLNAME An optional argument that displays the file system performance

6-27
Displaying File System Input/Output Performance

The file system I/O performance statistics track the operation and performance of
specific user data and metadata functions. The file system I/O performance statistics
include the standard file system performance statistics for reference, but the I/O
statistics elaborate on the statistics tracked in the ioUsec column. The statistics in this
column are provided as more detailed statistics and counters for each of the supported
file system request types. Many of the file system requests tracked resemble NFS v3 or
CIFS file system requests, just like the file system performance statistics.
To Display the File System I/O Performance Statistics
filesystem show stats performance io
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system I/O performance
VOLNAME An optional argument that displays the file system I/O performance
Displaying File System Daemon Performance Statistics

The file system daemon statistics show the time that is spent by the NAS Gateway’s
daemons. The file system daemon performance statistics also list average response or
completion times for each file system request type.
6-28
To Display the File System Daemon Performance Cache

filesystem show stats performance daemon
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system daemon

performance statistics for a specific node. This is the default setting.
VOLNAME An optional argument that displays the file system daemon

performance statistics for a specific volume.
Displaying File System Resource Statistics

Before executing a file system request, the NAS Gateway runs a resource checking
algorithm to determine whether enough resources exist to provide a reasonable
attempt at completing the request.
• If resources exist, then the file system request completes.
• If no resources exist, the file system request is blocked and queued, while the NAS
Gateway rechecks resource availability.
The file system resource statistics show file system resource usage and availability
before a file system request is completed. These conditions are displayed as counters
that describe the number of successful or blocked file system requests.
6-29
To Display the File System Resource Statistics

filesystem show stats resource
Options and
Description
Arguments
-n NODENAME An optional argument that displays the file system resource

performance statistics for a specific node. This is the default
setting.
VOLNAME An optional argument that displays the file system resource

performance statistics for a specific volume.
6-30
Chapter 7: Managing Shares
This chapter documents setting up the NAS Gateway for CIFS, NFS, and
multiprotocol file sharing services. This chapter contains the following sections:
• “NFS Environment” on page 7-2
• “CIFS Environment” on page 7-6
• “Global Namespace (GNS)” on page 7-8
• “GNS Root Management” on page 7-10
• “Junction Management” on page 7-15
• “Virtual Directory Management” on page 7-18
• “Shares Management” on page 7-22
• “Multiprotocol Environment” on page 7-28
• “Configuring CIFS and NFS Shares and Services” on page 7-33
• “Managing NFS Shares” on page 7-46
• “Managing CIFS Shares” on page 7-50
• “Managing CIFS Wide Links” on page 7-56
• “Exporting and Importing Shares” on page 7-62
• “Managing ID Mappings” on page 7-66
• “Multiprotocol File Access Without Using NIS” on page 7-71
• “Working With Symbolic Links” on page 7-75
7-2
NFS Environment
The network file system (NFS) protocol is an industry-standard, file-access protocol
that is platform neutral. The NAS Gateway provides file-level services for NFS v.2
and NFS v.3 clients in IP networks. The NAS Gateway does not require NLM requests
on the share, but you can use the SECURE_LOCK option of the nfs share add
command to configure the requirement for NLM requests. See the ONStor 2200
Bobcat NAS Gateway Command Reference for details on how to use this command.
Figure 7-1 shows a typical configuration in which the NAS Gateway provides file
services for NFS clients in an IP data network.
ONStor 2200 NAS Gateway Cluster
Gigabit
Ethernet
W orkstation
Fibre Channel
NFS
Client
IP SAN
hub/router
W orkstation
NFS
Client
IBM Compatible
File Server
Disk ar ray Disk ar ray
Consolidated NAS
IBM Compatible
Application Server and SAN Storage
Figure 7-1 NFS Topology

For details on how to configure NFS shares, see “Configuring CIFS and NFS Shares
and Services” on page 7-33.
NFS Share Considerations

When preparing to share resources to clients, consider the following:
7-3
• Specify a full path name to the resource.

• You cannot share the root directory
Sharing Nested Directories
You can configure the NAS Gateway to share nested directories.
Note - The EverON file system has no software restriction on the number of
nested directories when sharing. However, implicit practical limits exist, such
as buffer sizes, that can apply a limit to the number of levels for nested shares.
Each directory in the file system supports a maximum of 65533 unique

subdirectories. This number is a total of 65535, but accounting for the . and ..
subdirectories, the number is 65533.
Share Permissions
Permissions indicate how resources are shared with client. The NAS Gateway
supports the following permissions on share:
• Controlling read-only access
• Controlling read-write access
• Controlling the root squash access
• Controlling root access
Sharing with Root Access
Root access enables the clients to access shared resources as the root user, UID 0. The
NAS Gateway supports up to 255 root hosts, and root access can be applied to subnets
and individual hosts.
The NAS Gateway responds to file system requests from hosts depending on what root
access options you have specified for shared resources. Requests can be accepted or
denied as follows:
• When you configure a host with root access on share, the root user on that host
keeps root level access (UNIX UID 0) when accessing the resource.
7-4
• When you do not configure root access on share, either root access is denied or the
NAS Gateway performs a root squash, which modifies the root UID for the
request.
By default, the NAS Gateway’s root squash ID is 65534 for “nobody,” but supports
customizable root squash IDs through the ANON_UID and ANON_GID options. You
can configure these options on each NFS share.
Share’s Client List
The client list is the section of the nfs share add command that enables you to specify
one or more clients that are permitted to access the share. The client list supports
single clients, domains, netgroups, or all clients by including an asterisks (*) as a
wildcard.
Note - The maximum number of clients per client list is 16. The maximum
client string size is 255 characters.
Exclusions to the Share’s Client List

The share’s client list supports exclusions. An excluded client gets no access through
the share. You can create an exclusion to the client list by using one of the following
methods:
• Indicate the excluded clients with a hyphen (-).
• In the clients list, always list excluded clients before the domain or netgroup they
belong to, or before the asterisk ( * ). The NAS Gateway scans shares in a left-to-
right order and stops at the first match. Therefore, list the exclusion first on the
clients list.
Examples:
- nfs share add /vol1 rw,nosub=-192.168.22.24 :192.168.0.0/24
- nfs share add /vol1 rw,no_root_squash,nosub=

-192.168.22.24:onstor.com
- nfs share add /vol1 ro,anon_uid99=-192.168.22.24

:@mygroup
7-5
- nfs share add /vol1 ro=-192.168.22.24:*
7-6
CIFS Environment
The Common Internet File System (CIFS) is a file access protocol that supports IP-
connected clients in a Windows environment. Figure 7-2 shows a typical configuration
in which the ONStor Bobcat 2200 Series NAS Gateway provides file services for
CIFS clients in an IP data network.
Gigabit FibreChannel
Ethernet
IP SAN
hub/router
IBM Compatible
Primary Windows
Workstation
Windows
98 Client Domain Controller
IBM Compatible
Windows
W orkstation W orkstation
Windows
Workstation
Windows Secondary Windows Consolidated NAS

NT Client XP Client 2000 Client Domain Controller and SAN Storage
Figure 7-2 Example CIFS Topology

The NAS Gateway CIFS environment supports the following features:
• The NAS Gateway supports wide links. Wide links are supported on CIFS shares.
This feature, which is similar to Microsoft’s distributed file system (DFS), allows
CIFS clients access to shares on multiple volumes on multiple virtual servers or
NAS Gateways. For more information regarding DFS, see www.microsoft.com.
For details about managing wide links, see “Adding Wide Links” on page 7-58.
• The NAS Gateway supports Microsoft’s volume shadow copy service for CIFS
clients. This service helps prevent users from accidentally overwriting or deleting
files. Volume shadow copy service allows users to browse a file’s snapshot history
using the Previous tab in/]777 the Microsoft Internet Explorer browser. The
feature is run as a schedule process on the NAS Gateway, and operates on the same
schedule as the NAS Gateway’s snapshot schedule. For details about snapshot
schedules, see “Managing Snapshots” on page 9-1.
7-7
• The NAS Gateway supports Windows mandatory byte-range locking and network
lock manager (NLM) advisory byte-range locking. The NAS Gateway is aware of
each lock algorithm and ensures consistent operation of each lock method without
allowing the violation of either one. The NAS Gateway supports 2 million file
locks and 1.5 concurrent locked files.
Opportunistic locks (oplocks) increase network performance by allowing clients to
cache specific information in some file sharing situations. Because the client
retains necessary information in its cache, the client can perform read and write
operations on files without having to consult the server whenever it needs to access
a file. Oplocks are always enabled on the NAS Gateway. They cannot be disabled.
For details about using oplocks, see “Managing Volumes and File Systems” on
page 6-1.
Note - Because read, write, and lock information is cached on the client, events
such as cache flush messages, file close operations, oplock break messages, or
network errors on the client can negatively affect oplocks.
• The NAS Gateway supports symbolic links so that CIFS users can follow UNIX/
NFS symbolic links to their target. Symbolic links are a way of representing a real
directory path in a shorter and easier way to comprehend. For details on how to
manage symbolic links, see “Working With Symbolic Links” on page 7-75.
You can configure CIFS shares by using either the NAS Gateway command-line
interface (CLI) or the Microsoft Windows computer management tool. This chapter
describes how to configure CIFS shares by using the NAS Gateway CLI. For more
information, see “Configuring CIFS and NFS Shares and Services” on page 7-33.
7-8
Global Namespace (GNS)

Global Namespace (GNS) is the ONStor implementation that allows administrators to
build virtual file systems from CIFS shares on ONStor file systems, Windows CIFS
shares, and Windows DFS roots. GNS is comprised of multiple GNS root directories,
each of which is visible as a CIFS share on all virtual servers. GNS contains virtual
directories and junctions. A virtual directory is a directory entry for GNS. A junction
is a name space object that redirects CIFS clients to a list of paths of the form
\\server\share\dir1\dir2\etc, where these paths can be shares in the local cluster, a
remote cluster, a Windows system, other GNS roots, other virtual directories, or even
other junctions.
GNS allows administrators to group shared folders located on different servers by
connecting them to one or more namespaces. A GNS namespace is a virtual view of
shared folders in an organization. Administrators use GNS commands to select the
shared folders to present in the namespace, design the hierarchy in which the folders
appear, and determine the names that the shared folders show in the namespace. The
folders appear to reside on a single, high-capacity hard disk, through which users can
navigate without needing to know the server names. GNS also provides other benefits,
such as fault tolerance and load-sharing capabilities.
GNS simplifies the process of moving data from one file server to another.
Administrators can physically move data to another server without needing to
reconfigure applications or reeducate users about where they can find their data. This
minimizes the impact of server consolidation on users. It also allows administrators to
deploy additional file servers and present the folders on those new servers as new
folders within an existing namespace.
Note - The CIFS share permissions on the alternate paths must match,
otherwise clients will get unexpected access errors. Windows clients will only
traverse up to eight ONStor GNS junctions. This can be the cause of client
access failures.
Offline settings for junction targets are set on the individual CIFS shares that
are specified as targets. If a junction has multiple targets with different offline
settings, the client will use whatever settings are applied to the target.
7-9
You must have cluster network privileges to make any changes or to view the global
namespace. The Web UI must support the following operations as well.
7-10
GNS Root Management

A GNS root is logically the top of the global namespace. There can be more than one
of these, such as one for Marketing and another for Engineering. Each one might lead
to a different, but overlapping set of virtual servers and shares.
Note - You cannot access the GNS root if you login as the local user account.
Creating a New GNS Root

You can create a new GNS root using the gns add root command. The GNS root will
be exported by every virtual server in the cluster as the CIFS share
\\vsvr\ROOTNAME.
To Create a GNS Root
gns add root cifs ROOTNAME [-a ACCESSBASEDENUM]
[-c COMMENT] [-d DOMAIN\USERGROUP:RIGHTS]
[-g DOMAIN\USERGROUP:RIGHTS] [-o CACHING]
Options and
Description
Arguments
ROOTNAME Specifies the name of the root. It cannot match any existing root
or CIFS share name in the cluster. It can have a maximum of
250 characters.
Note - Win32 applications cannot access a path greater than

260 total bytes. In practice, the length of \\Server\ROOTNAME
must not exceed 258 characters, where Server is any virtual
server name in the cluster.
7-11
ACCESSBASEDENUM Enables or disables the access-based enumeration support for

this root. When enabled, CIFS users will only see files and
directories on which they have FILE_GENERIC_READ rights.
Legal values are enabled or disabled. The default value is
disabled.
COMMENT Specifies the new comment string that will be reported to CIFS
clients when they enumerate the shares on any virtual server.
The default value is no comment.
DOMAIN Specifies the domain associated with the user or group.
USERGROUP Specifies the name of the user or group to which the ACL
applies.
RIGHTS Specifies the access rights to grant or deny. The legal value is: r
– Read access.
CACHING Specifies how files are cached on clients. The default value is
manual. The legal values are:
• none - Clients should not cache files to make them available
when working offline.
• manual - Users must manually specify any files they want
available when working offline. To ensure proper file sharing,
the server version of the file is always opened.
• documents - Opened files are automatically downloaded
and made available when working offline. Older copies are
automatically deleted to make way for newer and more
recently accessed files. To ensure proper file sharing, the
server version of the file is always opened.
• programs - Opened files are automatically downloaded and
made available when working offline. Older copies are
recently accessed files. File sharing is not ensured.
-a The -a option sets the access-based enumberation feature to

enabled or disabled. When enabled, CIFS users will only see
files and directories on which they have read rights.
7-12
-d The -d option specifies an ACL entry that should be added into

the deny list. These entries are users or groups that are explicitly
denied certain access rights. The caller should be in some virtual
server context to specify grant or deny ACL entries. This option
is necessary to be able to convert the names to ids.
-g The -g option specifies an ACL entry that should be added into

the granted list. These entries are users or groups that are
explicitly granted certain access rights. The caller should be in
some virtual server context to specify grant or deny ACL entries.
This option is necessary to be able to convert the names to ids.
-o The -o option sets the client-side caching options. This controls

how clients cache files for use when working offline.
Note - If Win2k clients are used, it is not a good idea to enable

client-side caching.
Note - The -d and -g options can appear multiple times to build a larger ACL.
By default, the root is created with the Everyone group having Read Access.
Since a GNS root is itself a CIFS share, there is the possibility that a customer
will attempt to modify its security and comment via the Windows Control
Panel. This is not allowed.
Modifying the GNS Root

This command modifies the global namespace root.
To Modify the GNS Root
gns modify root cifs ROOTNAME
[-a ACCESSBASEDENUM] [-c COMMENT]
[-d DOMAIN\USERGROUP:RIGHTS]
7-13
[-g DOMAIN\USERGROUP:RIGHTS] [-n NEWNAME]

[-o CACHING] [-r DOMAIN\USERGROUP]
Options and
Description
Arguments
250 characters.

-a Enables or disables the access-based enumeration support for

ACCESSBASEDENUM this root. When enabled, CIFS users will only see files and
directories on which they have FILE_GENERIC_READ rights.
Legal values are enabled or disabled. The default value is
disabled.
-c COMMENT Specifies the new comment string that will be reported to CIFS
applies.
RIGHTS Specifies the access rights to grant or deny. The legal value is
r – Read access.
-n NEWNAME Specifies the new name for this root. The object will stay within
the current parent directory.

260 total bytes. In practice, the length of \\Server\NEWNAME
7-14
-o CACHING Specifies how files are cached on clients. This controls how
clients cache files for use when working offline. The default
value is manual. The legal values are:
Note - If Win2k clients are used, it is not a good idea to enable

client-side caching.

is necessary to be able to convert the names to IDs.

This option is necessary to be able to convert the names to IDs.
-r The -r option removes the ACL entry associated with the user
or group.
7-15
Junction Management
A junction is an object within the global namespace below a root that points to a list of
paths of the form \\server\share\path. These paths can point to a GNS root, a virtual
directory, another junction, a CIFS share, or a directory path below a CIFS share. The
target can be in the same cluster, another cluster, or even to paths outside of ONStor
filers, like a Windows CIFS share
A GNS junction specifies zero or more targets. Each target contains a server, share,
and optional path portion. Each target within a junction must specify a unique server,
share combination. Duplicate targets are not allowed within a junction, nor are targets
that differ only in the path specified.
Since Active Directory is not supported, junction targets are sorted so that targets that
match more IP address octets are sorted first. If a client and a junction server are in the
same subnet, it is more likely to be chosen than a target that is in a different subnet. If
multiple targets have an equal number of matching octets, they are sorted randomly so
clients are load spread.
Note - In case of failure of a junction target, the client should switch to

alternate targets. This failover is totally dependent on the client detection of
failure. The failover depends on the client to select available alternate targets.
Creating a Junction
This command adds a new global namespace junction to every virtual server.
To Create a Junction
gns add junction cifs ROOTNAME\PATH [-t TARGET]
Options and
Description
Arguments
7-16
250 characters.

PATH Specifies one or more path names delimited by a backslash (\).

The last name must not already exist but the previous ones must
already exist. Case is ignored. Each name can be at most 250
characters.
-t TARGET Specifies a target path to which ONStor GNS clients will be

redirected of the form \\server\share\path.
The -t option can appear multiple times to build up a list of
alternate paths.
Note - It is a Windows restriction that there can only be a single

target path when it’s a domain-based DFS path. A domain-
based DFS path is one where the DFS path is stored in the
Active Directory.
Note - It is the responsibility of some external process, like ONStor Data

Mirror, to guarantee that all alternate paths have the same contents.
Modifying a Junction
Modifies a CIFS junction in the global namespace.
7-17
To Modify a Junction
gns modify junction cifs ROOTNAME\PATH
[-n NEWNAME] [-r TARGET] [-t TARGET]
Options and
Description
Arguments
250 characters.

characters.
-n NEWNAME Specifies the new name for this root, the object will stay within
TARGET Specifies a target path to which ONStor GNS clients will be

redirected of the form \\server\share\path.
-t The -t option can appear multiple times to build up a list of

alternate paths.
or group.
Note - The -t and -r options can appear multiple times.
7-18
Virtual Directory Management

A virtual directory is any directory within the global name space below a root that is
not a junction.
Creating a Virtual Directory

This command adds a new global namespace directory to every virtual server.
To Create a Virtual Directory
gns add dir cifs ROOTNAME\PATH
[-g DOMAIN\USERGROUP:RIGHTS]
Options and
Description
Arguments
250 characters.

characters.
applies.
RIGHTS Specifies the access rights to grant or deny. The legal values is
r – Read access.

7-19

Note - By default, the virtual directory is created with the Everyone group
having Read Access.
Modifying a Virtual Directory

This command modifies a global namespace directory in every virtual server.
To Modify a Virtual Directory
gns modify dir cifs ROOTNAME\PATH
[-g DOMAIN\USERGROUP:RIGHTS] [-n NEWNAME]
[-r DOMAIN\USERGROUP]
Options and
Description
Arguments
250 characters.

The last name must not already exist, but the previous ones
must already exist. Case is ignored. Each name can be at most
250 characters.
applies.
7-20
RIGHTS Specifies the access rights to grant or deny. The legal value is:
r – Read access.
-n NEWNAME Specifies the new name for this root, the object will stay within


or group.
Listing GNS Objects

This command displays information about global namespace objects.
To List GNS Objects
gns show cifs [all | ROOTNAME[\PATH]]
Options and
Description
Arguments
ROOTNAME Specifies the name of the GNS root.
PATH Specifies one or more path names delimited by a blackslash (\).
If ROOTNAME is omitted, or all is specified, the names of all of the roots are listed. If
it is provided and PATH is omitted, the detailed information about the root is listed,
including the comment, the ACL, and the list of child GNS objects. For each child
object, the name and the object type, either virtual directory or junction is listed.
7-21
If ROOTNAME and PATH are provided and they refer to a virtual directory, detailed
information about the directory including the ACL and the list of child GNS objects is
displayed. For each child object, the name and the object type, either virtual directory
or junction is displayed.
If ROOTNAME and PATH are provided and they refer to a junction, the list of target
paths to which this junction points is listed.
Note - If the virtual server context is not set, it might not be possible to convert
the security information into normal user and group names.
Deleting GNS Objects

This command deletes global namespace objects.
To Delete GNS Objects
gns delete cifs ROOTNAME[\PATH] [-r]
Options and
Description
Arguments
ROOTNAME Specifies the name of the root to delete or the parent of the path
that is to be deleted. The name is case insensitive.
PATH Specifies the optional path within the global namespace to be

deleted.
-r The -r option denotes a recursive delete of all the objects from

ROOTNAME\PATH, but only within the global namespace. The
-r option will not delete the CIFS shares or files to which child
junctions point.
Note - Without the -r option, this command will fail if there are child objects.
7-22
Shares Management
An administrator can show, modify, and delete a CIFS Share even if the virtual server
is disabled. Creating a new share will still require the virtual server to be enabled so
that we can verify that the path being shared actually exists. Modifications of ACL
information also require the virtual server to be enabled so that we can map names to
IDs.
Creating CIFS Shares

A new option has been added to control widelinks support. Support has also been
added for CLI control on all attributes of a CIFS share, eliminating the need to use the
Windows Control Panel application for share management.
To Create a CIFS Share
cifs share add VOLNAME SHARENAME PATHNAME
[-A DOMAIN\USERGROUP:AUDITTYPE:RIGHTS]
[-s SESSIONS] [-w WIDELINKS]
Options and
Description
Arguments
VOLNAME Specifies the name of the volume for which the CIFS share is
created.
SHARENAME Specifies the name of the CIFS share.
PATHNAME Specifies the export path name within the volume.
ACCESSBASEDENUM Enables or disables the access-based enumeration support for

this root. Legal values are enabled or disabled. The default
value is disabled.
-c COMMENT Specifies the new comment string that will be reported to CIFS
7-23
applies.
AUDITTYPE Specifies the type of Audit ACL. The legal values are:
• success – Audit successful accesses when they use the
specified RIGHTS.
• failed – Audit failed accesses when they use the specified
RIGHTS.
RIGHTS Specifies the access rights to grant or deny. The legal values
are:
• r – Read access.
• c – Change access.
• f – Full access.
-o CACHING Specifies how files are cached on clients when working

offline.The default value is manual. The legal values are:
-s SESSIONS Specifies the maximum number of client sessions on this share

at any one time. This must be in the range 1 to 65535, where
65535 means unlimited. The default value is unlimited.
-w WIDELINKS Enables or disables support for widelinks on this share. When

enabled, CIFS clients can be redirected using widelinks, but this
CIFS share cannot be a target of a GNS junction. Legal values
are enabled and disabled. The default value is disabled.
7-24
-A The -A option specifies an ACL entry that should be added to

the Audit ACL list. These entries are users or groups for which
audit records should be generated when they successfully use
certain access rights, or when they fail to use certain access
rights. The administrator must have SECURITY privileges to
change the Audit ACL.
-a The -a option sets the access-based enumeration feature to

enabled or disabled. When enabled, CIFS users only see files
and directories on which they have read rights.
-d The -d option specifies an ACL entry that should be added to

-g The -g option specifies an ACL entry that should be added to

Note - The -A, -d, and -g options can appear multiple times to build up a
larger ACL.
By default the share is created with the Everyone group having Full Access.
Modifying a CIFS Share

This command modifies the a CIFS share's options. The volume does not need to be
online for this command to be run.
To Modify a CIFS Share
cifs share modify SHARENAME
[-A DOMAIN\USERGROUP:AUDITTYPE:RIGHTS]
7-25
[-d DOMAIN\\USERGROUP:RIGHTS]
[-R DOMAIN\USERGROUP:AUDITTYPE]
[-r DOMAIN\USERGROUP] [-s SESSIONS]
[-w WIDELINKS]
Options and
Description
Arguments
-a Enables or disables the access-based enumeration support for

ACCESSBASEDENUM this root. When enabled, CIFS users will only see files and
directories on which they have read rights. Legal values are
enabled or disabled. The default value is disabled.
-c COMMENT Specifies the new comment string that is reported to CIFS clients
when they enumerate the shares on any virtual server. The
default value is no comment.
applies.
AUDITTYPE Specifies the type of Audit ACL. The legal values are:
• success – Audit successful accesses when they use the
specified RIGHTS.
• failed – Audit failed accesses when they use the specified
RIGHTS.
RIGHTS Specifies the access rights to grant or deny. The legal values
are:
• r – Read access.
• c – Change access.
• f – Full access.
7-26
-o CACHING Specifies how files are cached on clients. This controls how
clients cache files for use when working offline. The legal values
are:
-s SESSIONS Specifies the maximum number of client sessions on this share

at any one time. This must be in the range 1 to 65535, where
65535 means unlimited. The default value is unlimited.
-w WIDELINKS Enables or disables support for widelinks on this share. When

enabled, CIFS clients can be redirected using widelinks, but this
CIFS share cannot be a target of a GNS junction. Legal values
are enabled and disabled. The default value is disabled.
-A The –A option specifies an ACL entry that should be added into

the Audit ACL list. These entries are users or groups for which
audit records should be generated when they successfully use
certain access rights, or when they fail to use certain access
rights. The administrator must have SECURITY privileges to
change the Audit ACL.

7-27

or group and can appear multiple times.
-R The -R option specifies an ACL entry that should be removed

from the Audit success or failure ACL list, depending on the
AUDITTYPE setting. This option can appear multiple times. The
administrator must have SECURITY privileges to change the
Audit ACL.
7-28
Multiprotocol Environment
In a multiprotocol environment, also known as a mixed CIFS and NFS environment,
files are created or accessed through both Windows and UNIX domains. Figure 7-3
shows a typical configuration in which the NAS Gateway provides file and block
services for CIFS clients in an IP data network.
Gigabit
Ethernet FibreChannel
NIS
IBM Compatible
Server
IP SAN
hub/router
IBM Compatible
Primary Windows
W orkstation
NFS
Client Domain Controller
IBM Compatible
Windows Secondary Windows

W orkstation Workstation W orkstation
Windows Windows Consolidated NAS

NT Client XP Client 2000 Client Domain Controller and SAN Storage
Figure 7-3 Example CIFS and NFS Multiprotocol Topology

For details on how to configure a multiprotocol file sharing environment, see
“Configuring CIFS and NFS Shares and Services” on page 7-33.
In a multiprotocol environment, the NAS Gateway has two roles, NFS server and
CIFS server:
• As the NFS server, the NAS Gateway supports the NFS protocol operating
between a client workstation, file server, or application server, and the NAS
Gateway to enable the end user to access files. The NAS Gateway uses NFS shares
to export file system mount points to authorized clients in the IP data network.
SAN resources are only available to NFS clients when exported.
7-29
• As the CIFS server, the NAS Gateway enables clients that run Windows OS to
read and write to the resources in the SAN at the disk block and file system block
level. The NAS Gateway also participates in the Windows or NetBIOS domains.
Note - The NAS Gateway has no role in client access to specific shares in the
file system. It trusts the challenge results from the domain controllers.
The NAS Gateway supports the following features in a multiprotocol environment:

• Multiprotocol access without requiring an NIS domain controller to process user
and group ID mappings. A local copy of the password and group files for every
virtual server is stored in the cluster database. For details, see “Setting the Local
NIS Domain” on page 7-71.
• Object locking. Object locking allows subsequent operations on a file that was
opened by CIFS, but only if the file is configured with the appropriate share value,
either Delete, Read, or Write.
- NFS reads and writes will be unsuccessful when the NFS client
attempts to read or write to a file that is locked by a CIFS client if CIFS
deny-read and deny-write open modes exist.
- NFS writes will be unsuccessful when the written range of the file is
locked with an exclusive CIFS bytelock.
• ID mapping. The ID map consists of any number of rules that determine how a
user from one type of domain, either NFS or CIFS, is mapped into the other
domain. The ID map rules are created to allow mapping in the following ways:
- Unidirectionally, to translate a CIFS user into an NFS user
- Unidirectionally, to translate an NFS user into a CIFS user
- Bidirectionally, to equally translate a user between both CIFS and NFS
Understanding ID Mapping
The NAS Gateway supports identity mapping between NFS and CIFS shares. The ID
maps are required only for users that do not have identical logons in both NFS or CIFS
7-30
domains. If a user has logons that are identical in both domains, you do not need to
create an ID mapping rule for that user.
The following is an example of an ID map:
Type Index
--------------------------------------------
user 1 spectrum\paulw==paulwilson@chromatis
user 2 *\johndoe=>johndoe@bentoptics
Type Index
--------------------------------------------
group 1 spectrum\domain admins==admins@chromatis
group 2 prism\*=>*@bentoptics
In these samples, the ID map lists users in one section, and groups in another. In the
users section:
• Entry 1 is mapping the CIFS user “paulw” in the CIFS domain “spectrum” to the
NFS user “paulw” in the NFS domain “chromatis” and the NFS user “paulw” in
the NFS domain “chromatis” to the CIFS user “paulw” in the CIFS domain
“spectrum.”
• Entry 2 is mapping the CIFS user “johndoe” from any CIFS domain to the NFS
user “johndoe” in the NFS domain “bentoptics.”
In the groups section:
• Entry 1 is mapping a member of the CIFS group “domain admins” in the CIFS
domain “spectrum” to the NFS group “admins” in the NFS domain “chromatis.”
Because this mapping is bidirectional, the NFS group “admins” in the NFS domain
“chromatis” are being mapped as members of the CIFS group “domain admins” in
the CIFS domain “spectrum.”
• Entry 2 is mapping a user who is a member of any CIFS group in the CIFS domain
“prism” to any NFS group in the NFS domain “bentoptics.”
7-31
Note - The mapping does not control access to CIFS files, just the translation
of users from one domain type to another. Whether a mapped user can actually
access a CIFS file depends on what Access Control (ACE) information is
configured on the CIFS file.
ID Map Scanning Logic

The NAS Gateway uses the following logic to scan through the ID map:
• The NAS Gateway scans the ID map in ascending index order and stops scanning
when it reaches the first matching rule.
• For the rule to match and stop the scan, a match must exist for the domain name
and user name (for CIFS the match is case sensitive), and the translation director
needs to be valid.
• If no match is found, the NAS Gateway maps the NFS name to the exact same
name in the CIFS domain that the virtual server belongs to, and it maps the CIFS
name to the same name in lowercase (remember, that CIFS is case sensitive) in the
NFS domain that the virtual server belongs to.
ID Map Components
The ID map is positional in that it expects the left most entry as the CIFS user and the
right most user as the NFS user.
In addition to the position of parameters, the ID map uses three specific components:
• A CIFS name, which is typically in the form WindowsDomainName\username.
• A translation director, which specifies the direction of the ID mapping. The
translation director can take one of three forms:
- == which indicates a bidirectional mapping between NFS to CIFS.
- => which indicates a unidirectional mapping from CIFS to NFS.
- <= which indicates a unidirectional mapping from NFS to CIFS.
• An NFS name, which typically takes the form “username@DomainName.”
7-32
Naming Conventions
The NAS Gateway supports NIS or LDAP and CIFS style names in its ID map.
Therefore, the ID map accept names in the form of name@domain for NFS users or
groups, and Windowsdomain\user for CIFS users.
The NAS Gateway also supports special characters in the ID map:
• An asterisk (*) represents the value any.
• A blank space represents no mapping—no domain if used in the domain position,
or “nobody” if used in the user name position.
• Some domain names, might contain a dot and suffix, or a dot as a separator.
The NAS Gateway supports the NetBIOS naming style only. User names with dots are
not supported. Enter domain names containing dots in the ID map without the dot. The
user name can have up to 20 characters and the domain name can have up to 15
characters. A user name or domain name can contain an internal blank space.
Note - Except for strings in ID mappings, when you use the NAS Gateway’s
CLI to run a command, you need to enclose a name string with an internal
blank space in double quotes.
7-33
Configuring CIFS and NFS Shares and Services

To perform the configuration process, it is assumed that you have:
1. Configured your IP data network.
2. Installed the NAS Gateway.
3. Connected the NAS Gateway to the network.
4. Logged in to the NAS Gateway and have an active command-
line.
Preconfiguration Considerations
Consider the following issues before performing the virtual server configuration
procedure:
• Decide whether you want the virtual server configured in protected mode for
failover to a different NAS Gateway.
• Decide the virtual server’s name. Virtual server names are used as the NetBIOS
name. To comply with NetBIOS, virtual server names are a maximum of 15
characters.
• Gather the IP addresses that you want assigned to the virtual server.
• Gather the Windows domain and user names. The virtual server uses the Windows
domain.name.
• Gather the IP address of the primary WINS server and secondary WINS server (if
any). The WINS server might be configured on the domain controller, in which
case, you will need the domain controller’s IP address.
• Decide if the virtual server will support home directories. If so, then gather the
name of the volume where the home directories exist and the path to the users’
home directories. Be aware that:
- the volume that supports the home directories must already exist before
starting this procedure.
- the path to the home directories must already exist on that volume.
• Gather the name of the NIS domain that the virtual server will join.
7-34
Configuration Steps
For this procedure, ONStor makes the following assumptions for illustrative purposes
only:
• The virtual server is named “vs1-production.”
• The NIS domain is named “spectrum”.
• The NFS clients reside on 192.168.12.0/24.
• The NIS server is 192.168.12.100.
• The NAS Gateway’s Gigabit Ethernet interface is 192.168.148.61.
• The gateway router is 192.168.148.1.
• The volume to be shared is named “engineering.”
• The volume “engineering” will be shared on the NAS Gateway’s Gigabit Ethernet
interface with read and write access for two NFS clients.
• Home directories will be supported on the volume “homebase” through
\users\local\homes.
Note - The home directory must be configured in the Windows domain. If you
choose to create this path later, the path to the home directories must exist on
the volume where the home directories will be.
• The WINS servers are 192.168.24.100 and 192.168.24.101.

• The Windows domain that the virtual server will be joining is “effigy”.
• The Windows domain controller is 129.192.24.1.
• The Windows domain login user name you can use is “onstoruser”.
• The Windows domain admin user name is “onstoradmin”.
• The CIFS share that will be exporting “engineering” is “eng”.
7-35
Configuring CIFS and NFS Shares

To Configure the NAS Gateway for a NFS, CIFS, or Multiprotocol Domain
To configure the NAS Gateway for an NFS, CIFS, or multiprotocol domain, follow the
steps outlined in the following procedure. Follow the steps as required, depending on
the type of share environment you want to set up.
Whether you are setting an NFS protocol, a CIFS protocol, or a multiprotocol, you
need to first begin by creating a virtual server.
Step 1: From the NAS Gateway context, create a virtual server by
running the vsvr create command from the NAS Gateway
context. For example, to create a virtual server named “vs1-
production,” run the following command:
vsvr create vs1-production
You are now in the virtual server context. The commands in the
following section are run from the context of the virtual server.
Note - The virtual server name you create is also the NetBIOS name by
default.
Step 2: From the virtual server context, assign an IP interface to the virtual
server by running the interface create command. For example,
to create interface 192.168.148.61 on Gigabit Ethernet port 3 as
part of the logical port “lp.3,” run the following command:
interface create fp1.3 -l lp.3 -a 192.168.148.61/24
Note - The same physical port can be used by different virtual servers, but the
same IP address cannot be used on multiple virtual servers.
Step 3: From the virtual server context, create a default route for the
current virtual server by running the route add command:
route add default -g 192.168.148.1
7-36
Do Steps 4 and 5 only if you are configuring for CIFS. If you are configuring only for
NFS, go to Step 6.
Step 4: From the virtual server context, specify the WINS server(s) that the
virtual server should use, by running the vsvr set wins
command. For example, to configure the primary WINS server at
192.168.12.100, and the secondary WINS server at
192.168.12.101, enter the following command:
vsvr set wins 192.168.24.100,192.168.24.101
Step 5: From the virtual server context, specify the Windows domain that
the NAS Gateway will join by running the domain add windows
command. For example, for the NAS Gateway join the Windows
domain “effigy” whose domain controller is at 192.168.24.1, and
use the login name “onstoruser”, run the following command:
domain add windows effigy onstoruser 192.168.24.1
Note - When you run this command, the NAS Gateway prompts you for the
password for the login name.
Do Step 6 if you are configuring only for NFS or multiprotocol.

Step 6: From the virtual server context, specify the NIS domain that the
NAS Gateway will join by running the domain add nis command.
For example, to have the NAS Gateway join the NIS domain
“spectrum” whose domain controller is at 10.5.129.1, run the
following command:
domain add nis spectrum 192.168.12.100
Note - The NIS domain name can be a maximum of 63 characters.
Do Step 7 if you are configuring only for CIFS or multiprotocol.
7-37
Step 7: From the virtual server context, specify the Windows domain in
which the virtual server will register by running the vsvr set
domain command. For example, to set the Windows domain
“effigy” with an admin user “onstoradmin,” run the following
command:
vsvr set domain windows effigy onstoradmin
You would also need to specify the password for the admin user
“onstoradmin”.
Note - The Windows domain name can be a maximum of 63 characters.
Do Step 8 only if you are configuring NFS or multiprotocol.

Step 8: From the virtual server context, specify the NIS domain in which
the virtual server will register by running the vsvr set domain
command. For example, to set the NIS domain “spectrumV”, run
vsvr set domain nis spectrumV
Note - The NIS domain name can be a maximum of 63 characters.
Do Step 9 only if you are configuring Kerberos.
Note - For more information on Kerberos, check the Kerberos Network

Authentication Service at http://www.ietf.org/rfc/rfc4120.txt
Step 9: From the virtual server context, specify the Kerberos domain in
which the virtual server will register by running the vsvr set
domain command. For example, to set the Kerberos domain
ORGUNIT, run the following command:
vsvr set domain windows -o ORGUNIT
7-38
Do Steps 10-15 for configuring NFS, CIFS, or multiprotocol.

Step 10: From the virtual server context, run the vsvr show command to
verify the virtual server’s configuration, and double check that you
have assigned the resources to the correct virtual server. For
example, to check the virtual server configuration of “vs1-
production”, run the following command:
vsvr show vs1-production
Virtual server parameters should be reconfigured while the virtual
server is disabled.
Step 11: Enable the virtual server, by running the vsvr enable command.
For example, to enable the virtual server “vs1-production” run the
following command:
vsvr enable vs1-production
Step 12: Label a foreign LUN so that the NAS Gateway can use it to create
the home directories volume by running the lun label command.
For example:
lun label DEVICE_NAME
where DEVICE_NAME is the device name of the array you will
use to create the volume.
Note - The NAS Gateway will post the message “Done” when the LUN has
been completely labelled.
Step 13: Find an array on which to create a volume as the home directories
volume, by running the lun show command. For example:
lun show
LUNs known to the NAS Gateway can be in different states. You
need a LUN with a state of “foreign.”
Step 14: From the virtual server context, create a volume for user data and
specify the array that you are configuring the volume on by running
7-39
the vol create array command. For example, to create the

volume “engineering” on the array named “IBM_ECV52AZB”,
run the following command:
vol create engineering IBM_ECV52AZB
Step 15: From the virtual server context, create the home directories volume
and specify the array that you are configuring the volume on by
running the vol create command. For example, to create the
“homebase” volume on IBM_ECV52AZB_0, run the following
command:
vol create homebase IBM_ECV52AZB_0
Note - This command creates the volume with default parameters. You can set
additional parameters, such as disk usage and AutoGrow parameters, by using
non-default values for those parameters.
Do Steps 15-21 for configuring NFS, CIFS, or multiprotocol.

Step 16: From the virtual server context, create a default CIFS share for the
volume you created in the previous step by running the cifs
share add command. This share has to be created on the root of
the volume. For example, to create a default share named “dir” on
the volume “homebase”, run the following command:
cifs share add homebase dir \
Note - This share supports the default share to the root volume. You can create
directories through the Windows client for additional paths you want to share.
By default, the original security on the root of a volume does not allow write
access. To allow write access, change the security, by right clicking the client,
then selecting Properties>Security.
7-40
Step 17: If the virtual server supports home directories through the
autocreate facility, add an admin privilege for the admin that is
configuring the virtual server by running the priv add command.
For example, to add the admin user “nate7” for the Windows
domain “shire”, run the command as follows:
priv add allow shire\nate7 CLUSTER cluster
Step 18: (Optional) From the virtual server context, if the virtual server will
be supporting home directories through the autocreate facility, from
a Windows client, connect to the root share that you just created in
Step 13.
Step 19: (Optional) You can create the directories that will reside on the
volume, including the directory structure for the home directories.
Ensure that each user’s directory exists on the volume you named
in Step 13.
Step 20: (Optional) From the virtual server context, you can set the NAS
Gateway’s autocreate facility to display shares to the user home
directories on the volume you specified in Step 13. To configure
this feature, you need to configure the path to the home directories
on the volume you specified in Step 13, and each of the individual
user directories. For example, to connect to the volume
“homebase” and create \user\local\homes, create each of the
user directories that would reside in that path–for example
\user\local\homes\paulw.
Step 21: (Optional) From the virtual server context, you can have the virtual
server support autocreated home directories, by specifying the
volume which will host the user home directories, and specifying
the file path so CIFS autocreate can support a user’s home
directory. To accomplish this, run the vsvr set autocreate
command.
7-41
Note - The volume that you specify in the vsvr set autocreate command
must already exist.
To enable this feature, the path to the home directories must already exist on
the volume.
A directory must exist for each user that will have a user directory. This
directory must exist in the last directory of the path.
For example, to assign “homebase” as a volume on which

autocreate will run, run the following command:
vsvr set autocreate homebase \user\local\homes
This argument takes the file path to the directory where user
home directories are configured. The NAS Gateway prepends the
volume to the file path to create the export.When the user logs in,
the user name is automatically appended to the end to create the
entire export to each user’s home directory. You do not need to
specify the user name in the file path.
Step 22: From the virtual server context, create a default CIFS share for the
user data volume by running the cifs share add command. This
share has to be created on the root of the volume. For example, to
create a share named “eng” on the volume “engineering”, run the
following command:
cifs share add engineering eng \
Do Steps 22-26 only if you are configuring CIFS or multiprotocol.
Step 23: From the virtual server context create an admin user on the NAS
Gateway as documented in Step 16. If you already have the admin
user configured in the virtual server, you can use the same admin
user for the next two steps on the Windows client.
Step 24: From a Windows client, connect to the root share that you just
created in the previous step.
7-42
Step 25: From a Windows client, create the directories that will reside on the
volume.
Step 26: From the virtual server context, verify that the share appears in the
Shares List, by running the cifs show command. For example:
cifs show
This command shows the shares that can be browsed by a
Windows client.
Step 27: From the virtual server context, verify that the share has the correct
parameters, by running the cifs show command name against the
share. For example, to view the configuration of the share “eng”,
run the following command:
cifs show eng
This command provides a detailed display of all the parameters
that are assigned to the share.
Do Step 27 for configuring NFS, CIFS, or multiprotocol.
Step 28: From the virtual server context, you can create additional volumes
in the virtual server by repeating Steps 10 through 12.
Do Step 28 only if you are configuring CIFS or multiprotocol.
Step 29: From the virtual server context, you can create additional CIFS
shares in the virtual server by repeating Steps 15 through 20.
Note - When you are configuring shares through either the NAS Gateway or
through a Windows client, you can add a dollar sign ($) at the end of the share
name (for example, eng$) to configure a hidden share. You cannot browse
hidden shares in the list of shares, but you can still connect to them by
explicitly entering the share name, for example, \\pubstest\eng$.
If you have been configuring CIFS shares, the CIFS shares creation process is
complete at this point.
Do Steps 29-33 only if you are configuring NFS or multiprotocol.
7-43
Step 30: From the virtual server, for NFS access, create a route to the IP data
network where the NFS clients reside, by running the route add
net command. For example, to configured a route to the
192.168.12.0/24 network through the gateway router
192.168.148.1, run the following command:
route add net -g 192.168.148.1 -a 192.168.12.0/24
Step 31: From the virtual server context, create an administrator share for
the volume.
• Configure the share with the no root squash option to allow
you to access the share as root.
• Create the administrator share with read-write permission so
that you can configure options on the volume that will be
exported to users.
For example, to configure an administrator share on the volume
called “engineering”, to a client called “admin-pc”, run the
following command:
nfs share add /engineering -o
rw,no_root_squash=admin-pc;rw=*
Step 32: Set the ownership bits to allow you administrator access through
the standard UNIX chown command. For example, run the
following command:
chown usera:usergroup /mnt/nfs-share
usera:usergroup is the name of the administrator and the name of
the administrator group to which the admin belongs.
Step 33: Set the mode bits to allow you administrator access through the
standard UNIX chmod command. For example, run the following
command:
chmod 775 /mnt/nfs-share
7-44
Note - Specific permission can vary from company to company based on

security policies. The mode bits shown in the preceding example are for
illustrative purposes only.
Step 34: Verify that the share has the correct parameters, by running the nfs
show command against the share. You can view the NFS shares on
a per-volume level. For example, to view the NFS shares exporting
the volume “engineering,” run the following command:
nfs show engineering
If you are setting up a multiprotocol share environment, do the following steps to
create the ID mapping between the different types of shares.
idmap insert {user|group} INDEX
Options and
Description
Arguments
user|group Specifies the translation semantics for users or groups.
INDEX Specifies a number that controls where in the Identity List the ID mapping
will be added. Enter a number that refers to the ID map’s position in the
list.
Step 36: Press the Enter key to receive the mapping prompt, which looks
like this:
Enter the user mapping:
windowsDomain\name ==/<=/=>name@NIS, or LDAPDomain
(*=wildcard, name empty=no mapping)
Step 37: Enter the mapping information at the mapping prompt. Mapping
information takes three building blocks: the CIFS identity, the
mapping director, and the NFS identity. An example of the MAP
argument would be
7-45
epicenter\paulw==paul@spectrum. For more information, see

“ID Map Components” on page 7-31.
• The first building block is windowsDomain\name, where
name is a CIFS user or group name that will be mapped to an
NFS user or group. The windowsDomain and name
components must be separated with a backslash (\). Both
components support an asterisk (*) to represent “any” or a
blank space to represent no mapping.
• The second building block is the mapping director. This
building block specifies the direction of the translation for the
ID mapping. The NAS Gateway supports unidirectional or
bidirectional translation. For more information, see “ID Map
Components” on page 7-31.
- == indicates bidirectional translation between the
CIFS domain and the NFS domain.
- => indicates unidirectional translation from the
CIFS domain to the NFS domain.
- <= indicates unidirectional translation from the
NFS domain to the CIFS domain.
• The final building block is name@NIS or LDAPDomain user
or group name that will be mapped to a CIFS user or group.
Both components support an asterisk (*) to represent “any” or
a blank space to represent no mapping.
7-46
Managing NFS Shares

You can manage existing NFS in one of the following ways:
• Displaying NFS share parameters
• Enabling and disabling NFS shares
• Modifying NFS share parameters
Displaying NFS Share States and Mount Options

The NAS Gateway contains its NFS shares in the NFS Shares List. To display the NFS
Shares List and the detailed information about all clients configured on a specific
share, run the nfs show command. This command displays the following information
in the current virtual server:
• The state of each share (either Enabled or Disabled)
• Each share path configured
• The specific mount options configured on the share and the clients to which the
mount options apply
• The client auth level (either 0,0 or 0,1 or 1,1)
To Display the NFS Shares List
nfs show {[PATHNAME|[all]|[-v VOLNAME
[-P PAGENUMBER [-S PAGESIZE]]])
Options and
Description
Arguments
all Specifies the mount options for all shares.
7-47
Options and
Description
Arguments
PATHNAME Specifies the name of a path for which to display mount options.
The path name you enter is the path you noted in the previous
step.
If you specify the pathname, detailed information about options
and the clients to which they apply is displayed.
If you do not specify the pathname, only the share and its state
are displayed.
-v VOLNAME Displays all NFS shares on a volume.
-P PAGENUMBER Specifies the number of the page to display.
Enabling or Disabling NFS Shares

You can enable or disable the NFS protocol on each interface by using the -p
nfs=enable|disable argument of the interface create and interface modify
commands.
• When you first create the interface that supports the NFS share, you can set the
state of NFS on that interface through the interface create command.
• After the initial creation of the interface that supports the NFS share, you can set
the state of NFS on that interface through the interface modify command.
Modifying NFS Shares

When you run the nfs share modify command, a vi editor starts that enables you to
modify a share by editing the share options list or the client list you have configured
with the nfs share add command.
7-48
Note - If you need to modify an NFS share, you can also overwrite the share by
running the nfs share add command and recreating the share with the mount
options you want to change. If you overwrite the share, you are prompted with
a confirmation message similar to the one shown below:
Existing share configuration will be overwritten.
Are you sure? [y|n]:
Answering yes (Y) overwrites the existing share with the new one. Answering
no (N) cancels overwriting the existing share.
When you edit the NFS share list, consider the following:
• Each line in the NFS share file contains information about each parameter that you
can configure in the share.
• The sort order for the clients in each line of parameters in the file is from left to
right.
• The first match of a client and its permissions halts the search.
• Clients must be specified by their IP address or host name. You can specify all
clients by using the asterisk ( * ) as a wildcard operator for “all.” You can also use
subnet masking to allow all clients within a configured network address space to
use the share.
• If a client is not listed in the NO_ROOT_SQUASH parameter, it is assumed to
have root-squash capability.
To Modify an NFS Share
Step 1: Run the nfs share modify command to start the vi editor:
nfs share modify PATHNAME
PATHNAME is the name of the exported path for which the NFS
Shares List is editable.
7-49
Step 2: When the editor starts, use standard vi commands to search the file
and edit its contents.
Step 3: When you are done editing the share, use the standard vi commands
to save and close the file.
Step 4: After editing shares, run the nfs show command to check that they
are configured correctly.
Deleting NFS Shares

You can delete individual NFS shares at any time by running the nfs share delete
command. When a share is deleted, it is completely removed from the virtual server. If
you have configured the share with submount functionality, the share’s submounts are
also unavailable after the share is deleted. You can delete an NFS share regardless of
whether the share is enabled or disabled. Share deletion is immediate and intrusive.
When you delete a share, you are not prompted with a confirmation message and any
clients currently using the share are immediately disconnected.
To Delete an NFS Share
Step 1: Run the nfs show command to locate the share that you want to
delete:
nfs show
Step 2: Run the nfs share delete command to individually delete a
share:
nfs share delete PATHNAME
PATHNAME specifies the name of a specific path for which you
want to delete the share.
7-50
Managing CIFS Shares

You can manage CIFS share in one of the following ways:
• Displaying CIFS shares
• Enabling or disabling CIFS shares
• Modifying CIFS shares
• Deleting CIFS shares
Displaying CIFS Share Information

When you configure a CIFS share, it is added to a list of shares. This list contains the
share definition as well as path and parameter information for the share. You can
display the list in its entirety, or list a specific share by name, by running the cifs
show command.
In the list, you will see not only the file system shares, but also the hidden shares.
Hidden shares are always hidden from the clients, but they are visible to you, the NAS
Gateway administrator. A dollar sign ($) indicates that a share is hidden from the end
user or client. If you create a share with an ending $, it will not show up in the list of
shares when a client is browsing, but you (as admin) can still connect to it directly. The
NAS Gateway supports the IPC$ share by default.
After a CIFS share has been configured, you can display a list of the shares and the
SAN resources that the shares are advertising by running the cifs show command.
This command displays the list of configured shares.
Note - You can view the list of configured shares through standard CIFS client
browsing as well, for example, through the Network Neighborhood display
when you are using a Windows client. The resulting list of Network Places is
the contents of the CIFS Shares List.
Autocreate shares (home directory shares) are not listed in the Shares List by
running the cifs show command. You can see home directory shares only by
browsing the virtual server through the Network Neighborhood display.
7-51
To Display CIFS Share Information

cifs show [SHARENAME]|[all|[-v VOLNAME
[-P PAGENUMBER [-S PAGESIZE]]])
Options and
Description
Arguments
SHARENAME An optional alphanumeric character string from 1 to 128

characters in length that describes the share that you want to
display.
• If you enter no share name, then the Shares List is displayed
for the current virtual server. Only the share names are listed.
• If you enter a share name, then the specifics of that share are
displayed, such as the volume in which the share is
configured, the configured path to the resource in the volume,
and any comment text.
all Displays a list of all shares.
-v VOLNAME Displays a list of all shares on a specific volume.
-P PAGENUMBER Specifies the page to display.
Note - Administrative shares are visible through the Shares List, but not
through the NAS Gateway’s command line. For example, if you run the cifs
show command against the share IPC$ to view detailed information about the
IPC$ share, the NAS Gateway will not show any information about this share.
Enabling or Disabling CIFS

The CIFS protocol can be enabled or disabled on a per-interface basis. The protocol
state is controlled through the -p cifs=enable|disable argument of the interface
create and interface modify commands.
7-52
• When you first create the interface that will support the CIFS share, you can set the
state of CIFS on that interface through the interface create command.
• After the initial creation of the interface that supports the CIFS share, you can set
the state of CIFS on that interface through the interface modify command.
Configuring ABE CIFS Shares

The NAS Gateway supports the Microsoft Windows feature access-based enumeration
(ABE) of CIFS shares.
With this feature, more control exists over what users see when they enumerate a
directory to only those files and directories for which they have
FILE_GENERIC_READ rights. ABE provides more security. For more information
about ABE, you can search the Microsoft web site.
You configure ABE on the NAS Gateway’s CIFS shares by using the -a
ACCESSBASEDENUM argument with the cifs share modify command. With this
new argument, you can enable or disable ABE. By default, ABE is disabled. To set the
state of ABE, the volume must be online.
Here is the syntax of the cifs share modify command:
cifs share modify SHARENAME [-a ACCESSBASEDENUM]
-a ACCESSBASEDENUM Specifies the state of ABE: enabled or disabled.

• When enabled, CIFS users only see files and
directories on which they have FILE_GENERIC_READ
rights.
• When disabled, CIFS users see an unfiltered directory
listing.
Deleting a CIFS Share

You can delete a CIFS share at any time by running the cifs share delete
command. This command immediately deletes the share, so the shared file system
resource is made unavailable. When you delete the share, the path to the resource is
7-53
removed, so the domain controller is no longer aware of the resource, and clients that
request the resource are denied.
Note - You cannot delete the system hidden share IPC$.
To Delete a CIFS Share

cifs share delete SHARENAME
SHARENAME is the name of the share that you want to delete.
7-54
Managing CIFS Servers

CIFS servers control the CIFS client connectivity by responding to client connection
requests. CIFS servers can be associated with a virtual server so that only a specified
CIFS server can support client connectivity on the virtual server. CIFS servers that are
associated with a virtual server manage the authentication and access of shares in the
virtual server. The NAS Gateway supports a maximum of 32 CIFS server names. The
following sections document the NAS Gateway commands that enable you to
configure one or more CIFS servers for a virtual server.
Creating a CIFS Server in a Virtual Server

You can create one or more CIFS servers for a virtual server by running the cifs
server create command. This command associates one CIFS server name with the
current virtual server. You can use this command to associate multiple CIFS servers
with a single virtual server.
When the CIFS server is specified for a virtual server, that CIFS server name is added
to the CIFS Server List. The virtual server scans the list in a top-down order to
determine if the CIFS server can respond to access requests from CIFS clients that are
attempting to access the virtual server.
To Create a CIFS Server for a Virtual Server
Step 1: Make sure are in virtual server context. If you are not in the
virtual server for which you want to create the CIFS server, run
the vsvr set command to change to that virtual server.
Step 2: Run the following command, from the virtual server context:
cifs server create NAME
NAME is the name of the CIFS server that you are creating in the
virtual server. The CIFS server name is an alphanumeric
character string from 1 to 15 characters in length.
Displaying the CIFS Server for a Virtual Server

You can display the CIFS servers that are a part of the virtual server by running the
cifs server show command. This command displays the CIFS Server List for the
current virtual server.
7-55
To Display the CIFS Server List for a Virtual Sever

Step 1: Make sure you are in the virtual server context. If you are not in
the virtual server for which you want to display the CIFS Server
List, run the vsvr set command to change to that virtual server.
cifs server show NAME
NAME is the name of the CIFS server that you are displaying.
Enter the name of the share that you want to display exactly how
it appears in the CIFS Servers List.
Deleting a CIFS Server from a Virtual Server

You can delete a CIFS server from a virtual server by running the cifs server
delete command. When you delete a CIFS server, that specific named server can no
longer process CIFS client access requests from CIFS clients that attempt to access a
virtual sever through any shares supported by the virtual server.
To Delete a CIFS Server From a Virtual Server
Step 1: Make sure you are in the virtual server context. If you are not in
the virtual server for which you want to delete the CIFS server,
run the vsvr set command to change to that virtual server.
Step 2: Run the cifs server show command to locate the CIFS server
you want to delete from the current virtual server.
Step 3: Run the following command to delete the CIFS server:
cifs server delete NAME
NAME is the name of the CIFS server that you are deleting.
7-56
Managing CIFS Wide Links

Wide links allow CIFS shares to span volumes in one or more virtual severs or NAS
Gateways. Wide links are supported in a multiprotocol environment because the CIFS
wide link interacts with an NFS symbolic link to allow access. When you add a wide
link, you are creating a rule for a symbolic link, and that rule determines the target
volume or CIFS server that the client wants to access. The following section provides
some examples of how wide links operate. By default, wide links are enabled.
Note - Before you can use the wide link feature, you need to set up domain
trusts. For more information on how to setup domain trusts, see
www.microsoft.com. Wide links can allow clients to follow shares to different
domains only if the domains are trusted.
Examples of Wide Link Behavior

When you configure a CIFS wide link, you are configuring a mapping rule through
symbolic link. The mapping rule sets the target volume for the CIFS link, so that when
the CIFS share is accessed, the wide link mapping translates to the correct volume,
directory, or file at the end of the link.
The following examples show some wide link rules created on the ONStor NAS
Gateway and the symbolic links on a UNIX client, then explain the wide link behavior.
Consider the following wide link rules on the NAS Gateway:
1. symlink add vol1 /Redir1 /mnt/vol1
2. symlink add vol1 /Redir2/Redir3 /mnt/vol1/Test
3. symlink add vol1 \\srv\share\Redir4 /mnt/vol2
And, assume the following symbolic links have been created on an UNIX box:
1. ln -s /mnt/vol1/afile.txt sym1
2. ln -s /mnt/vol1/Test/dirB sym2
3. ln -s /mnt/vol2/dirC/dirD sym3
When a CIFS client accesses sym1, mapping rule 1 is applied and the client is
redirected to the path /Redir1/afile.txt at the root of volume vol1. The software
7-57
took the path /Redir1 from the mapping rule and /afile.txt from the remaining
symbolic link target text.
When a CIFS client accesses sym2, mapping rule 2 is applied because it matches more
characters than mapping rule 1. The client is redirected to the path /Redir2/Redir3/
dirB at the root of volume vol1. The software took the path /Redir2/Redir3 from
the mapping rule and /dirB from the remaining symbolic link target text.
When a CIFS client accesses sym3, mapping rule 3 is applied and the client is
redirected to \\srv\share\Redir4\dirC\dirD. The CIFS server srv can be any
CIFS server on the network and share can be any CIFS share on that server. EverON
software took the path \\srv\share\Redir4 from the mapping rule and /dirC/dirB
from the remaining symbolic link target text.
CIFS Behavior Considerations with Wide Links

Before you begin managing wide links, consider the following notes about CIFS
behavior:
• If you attempt to delete a wide link in Explorer, Explorer first follows the link to
the target directory and deletes all of the files in that directory. It then appears to
have deleted the wide link itself, but refreshing the directory shows that it still
exists. When this operation completes, the wide link can point to a nonexistent
target, because the target directory was deleted.
• If the target of the wide link is not available, Explorer displays an error message
and the cmd shell when you try to access the wide link.
• If you already have a drive mapped to any share on the target server of a wide link,
and that user name used to connect to that server is not the same one as you used to
connect to the originating virtual server, you are denied access when trying to
follow the wide link. You will see the following error message about attempting to
log on to the target server with multiple user IDs:
Multiple connections to a server or shared
resource by the same user, using more than one
user name, are not allowed. Disconnect all
previous connections to the server or shared
resource and try again.
7-58
• If the target of a wide link is a server and share in another authentication domain,
access is denied without a logon dialog.
• Macintosh (Mac) clients do not support wide links/DFS. The Mac displays wide
links, but when clients click the wide link, nothing is returned.
• A cmd shell deletion cannot remove a wide link.
• You cannot rename a wide link.
Adding Wide Links

Wide link functionality is configured and controlled through a symbolic link. To add a
wide link, run the symlink add command. This command adds a mapping rule for
CIFS clients when they access an absolute NFS symbolic link. NFS clients find the
target of an absolute symbolic link by checking their locally mounted file systems,
while the NAS Gateway finds the target for CIFS clients.
The target of the wide link can be a path within the same volume, or a path to another
CIFS server which then processes the access request through the wide link feature.
To Add a CIFS Wide Link
symlink add VOLUME REDIRECTEDPATH LINKTARGETTEXT
Options and
Description
Arguments
VOLUME Specifies the name of the volume on which to apply symbolic

link mapping rule.
7-59
Options and
Description
Arguments
REDIRECTEDPATH Specifies the path the CIFS client should follow when it
encounters an absolute symbolic link whose target text starts
with the text in the LINKTARGETTEXT argument. The
REDIRECTPATH can be either of the following:
• A path within the same volume of the form /dir1/dir2/dir3/...
This form redirects the CIFS client to a specific directory
within the same volume as the symbolic link.
• A CIFS share path of the form
\\server\share\dir1\dir2\dir3\.... This form redirects the CIFS
client using ONStor GNS and Microsoft DFS to any other
CIFS server and share.
LINKTARGETTEXT Specifies an NFS-style path of the form /dir1/dir2/... When a

CIFS client encounters a symbolic link whose target text starts
with LINKTARGETTEXT, the client is redirected to the path
REDIRECTEDPATH. The longest matching rule is applied.
To delete a wide link, run the symlink delete command. This command
immediately removes the wide link functionality. Therefore, the client accesses the
link or symbolic link as normal. Be aware that if your data is accessible through a wide
link, and you delete the wide link, the data is no longer accessible until you create a
mount point on the volume that contains it.
Note - When a wide link rule is deleted, the link between source and target
does not become immediately inaccessible. Instead, the link can remain
displayed and accessible for up to 10 minutes. This behavior is controlled by a
link timeout that is set on the client, not by the NAS Gateway.
7-60
To Remove a Symbolic Link

symlink delete VOLUME LINK
Options and
Description
Arguments
VOLUME Specifies the volume from which you are deleting a mapping rule.
Enter the name of the volume from which you will be deleting a
symbolic link.
LINK Specifies the symbolic link that you are deleting. Because you are
creating a mapping for an absolute symbolic link, enter the name of
the configured symbolic link that you want to delete, and include the
root slash (/). For example:
/pubs/ paulw/filter
Viewing Wide Links

To view a wide link, run the symlink show command. This command displays the
current list of all wide links and symbolic links on the current NAS Gateway.
To Display the Symbolic Links Configured on a Volume
symlink show VOLUME
VOLUME specifies the volume for which you want the symbolic
link mapping rules displayed. Enter the name of the volume for
which you want to display symbolic links.
As an alternative, you can also view the wide link from the Link Properties window on
the Windows client. You cannot administer the link from this window. Figure 7-4
shows the Link Properties widow.
7-61
Figure 7-4 Properties Dialog Showing Configured Wide Link
7-62
Exporting and Importing Shares

Exporting and importing CIFS and NFS shares facilitates recovery efforts. It is used
for disaster recovery in the following way:
Step 1: Create a remote mirror (with local baseline or not).
Step 2: Export the shares of the source volume.
Step 3: Start the mirror.
Step 4: Halt the source cluster/filer.
Step 5: Promote the target volume.
Step 6: Rename it the same as the source volume, or when importing the
shares specify the name of the target volume.
Step 7: Verify client can access (probably need to unmount/mount on NFS
and reconnect on CIFS) CIFS and NFS shares are exported to a
share list text file from the source volume.
The share list text file is then imported to a target volume. The share list file consists of
a list of shares and corresponding options, share names, and comments, one per line.
The share list file also contains the source release version, and the file format is as
follows:
version
share1path [NFSoptions|CIFSoptions]
NFS shares are exported using a path relative to the volume name, so the source and
target volume names can differ. CIFS share path names are independent of the volume
name. Table 7-9 lists actual share paths and the exported share path.
Table 7-9: Share Paths
Actual Share Path Exported Share Path Description
\ \ CIFS root share
/vol1 / NFS root share
\dir1 \dir1 CIFS share
7-63
Table 7-9: Share Paths (Continued)
Actual Share Path Exported Share Path Description
/vol1/dir1 /dir1 NFS share
IPCS$ Hidden CIFS shares are not

exported
When importing shares to a target volume, the share list file is parsed, and each share
is created on the target volume. The target volume must be online. An event log is
generated for each share to indicate whether the share creation on the target volume
succeeded or failed.
Note - You can have spaces in share names, share paths, and comments.
However, you need to enclose share names with spaces in double quotation
marks.
Exporting Shares Lists

Exports CIFS and NFS shares to a file on a specified volume. Exported shares can be
subsequently replicated (imported) on another volume. Shares are typically replicated
to another volume after the volume data is replicated or moved to another volume or
gateway.
To Export a List of Shares from a Source Volume to a Share List File for
Importing to a Target Volume
volume share export VOLNAME LOCATION [-V
VIRTUALSERVER] (all|SHARELIST) [SHARELIST...]
Options and
Description
Arguments
all All CIFS and NFS shares to be exported.
7-64
Options and
Description
Arguments
LOCATION Specifies the path to a file where to store the exported shares.
SHARELIST Specifies one or more space-separated CIFS and NFS shares to

be exported.
VOLNAME Specifies a source volume where file specified with the

LOCATION argument resides.
-V VIRTUALSERVER Specifies the virtual server that owns the source volume specified
with VOLNAME. The default is the current virtual server. If you are
already in the context of the virtual server that owns the source
volume, this argument is optional.
Importing Shares Lists

Imports CIFS or NFS shares previously exported through the volume share export
command. Shares are typically replicated to another volume after the volume data is
replicated or moved to another volume or gateway.
To Import a Previously Exported List of Shares Onto a Target Volume
volume share import VOLNAME LOCATION
[-V VIRTUALSERVER]
Options and
Description
Arguments
LOCATION Specifies the path to a file containing the share list information or
created using the volume share export command.
VOLNAME Specifies a target volume where file specified with the

LOCATION argument resides.
-V VIRTUALSERVER Specifies the virtual server that owns the target volume specified
with VOLNAME. The default is the current virtual server. If you
are already in the context of the virtual server that owns the
target volume, this argument is optional.
7-65
Note - Use the vol import command only if the volume to be moved is from
another cluster.
7-66
Managing ID Mappings
You can manage ID mappings in one of the following ways:
• Editing ID mappings
• Showing ID mappings
• Deleting ID mappings
• Forcing an update of ID mapping rules
Editing an ID Mapping
The NAS Gateway supports identity mapping between NFS and CIFS domains. With
identity mapping, you can specify rules that govern the following translations:
• How NFS user and group IDs (UIDs and GIDs, respectively) are translated to
CIFS users and groups
• How CIFS users and groups are translated to NFS UIDs and GIDs
You can edit an ID mapping by running the idmap edit command. The process of
editing allows you replace an ID mapping in the Identity List. As part of this
command, you specify an index number, which is a numerical value that indicates
which entry in the list will be replaced. Because an entry in the list will be replaced
with a new entry, the net result is zero, and no movement occurs in the list.
This command operates in two steps:
1. You enter the command syntax shown except for the mapping
information. For example, you would run the idmap edit
user 1 command to edit the first user ID map entry. The NAS
Gateway will accept the command syntax then prompt you
with the > for the actual syntax of the map entry that you are
editing.
2. You enter the actual map entry after the NAS Gateway
presents you with the > prompt.
To Edit an ID Mapping
7-67
idmap edit {user|group} INDEX
Options and
Description
Arguments
user|group Specifies the translation semantics for users and groups. This
argument takes the specific syntax that is referenced in the idmap
insert command.
INDEX Specifies the number that controls where in the list the ID mapping will
be added. Enter the same index number as the entry that you are
replacing.
Step 2: When the NAS Gateway prompts you with the > prompt, enter the
mapping information. Mapping information is a construction of
CIFS identity, translation director, and NFS identity that you want
to edit. For example:
• spectrum\user7077=>user7077@onstorlab could be a
map for a user.
• spectrum\techpubs==publications@stylus could be a
map for a group.
• spectrum\ <=user7077@onstorlab could be a map that
creates an entry for a user that maps to nobody in the CIFS
domain.
• spectrum\guest<=user7077@onstorlab could be an map
that creates an entry for a user that maps to the “guest” user in
the CIFS domain.
Showing the ID Mappings

When you configure ID mappings, the NAS Gateway adds the user and group
mappings to the Identity List. You can display the Identity List by running the idmap
show command.
The Identity List contains separate sections for user and group mappings. As part of
this command, you can filter the output by specifying the type of ID mapping–either
7-68
user or group–that you want the NAS Gateway to display. As an option, you can use
the “all” keyword to see both sections of the Identity List.
The Identity List contains information about the user or group names for CIFS and
NFS, the index number for each mapping, and the direction of name mapping.
To Display ID Mappings
idmap show {all|user|group}
Choose on of all|user|group to display the contents of the
Identity List:
• all displays all entries in the Identity List. Users are
displayed at the top of the Identity List, then groups are
displayed.
• user causes the NAS Gateway to display only the user entries
in the Identity List.
• group causes the NAS Gateway to display only the group
entries in the Identity List.
Deleting an ID Mapping
You can delete an ID mapping any time after it has been created. When you delete an
ID mapping the user or group for which you created the mapping can no longer be
translated between a CIFS or NFS domain. Therefore, that user or group can log in to
their native domain only. For example, a native CIFS user or group will not be able to
log in to a NFS domain, and a native NFS user or group will not be able to log in to a
CIFS domain.
To Delete an ID Mapping
Step 1: Run the following command and locate the user’s or group’s ID
mapping that you want to delete:
idmap show all
Step 2: Run the following command to delete the ID mapping:
7-69
idmap delete {user|group} INDEX
Options and
Description
Arguments
user|group Specifies which type of user map you want to delete.

• Enter user to delete a user ID mapping.
• Enter group to delete a group ID mapping.
INDEX Specifies the index number associated with the ID map entry that you
are deleting.
Note - Note - The entries in the Identity List are numbered

sequentially, so when you delete an index entry, the remaining entries
will renumber to move up or down in the Identity List to keep a
contiguous range of numbers.
Forcing an Update of the ID Mapping Rules

Certain conditions on the Windows or NIS domain controllers can affect how the NAS
Gateway recognizes and maps NFS and CIFS users through the ID map. For example,
if a new NIS username is created, it might cause a new mapping to match to a CIFS
user that did not exist before. In this type of situation, the NAS Gateway must update
some system cache information and user and group mappings in the Security file. You
can cause an explicit update by running the idmap notify change command.
The idmap notify change command is helpful for situations where you know of
changes to the CIFS or NIS configuration. For example, assume you need to change an
NIS map on your NIS server. When you add an entry for the user “timg” to your NIS
password map, you know it will have an impact on the NAS Gateway’s identity
mapping because “timg” has an account in a CIFS domain. In situations like this, you
use the idmap notify change command so that quotas are recomputed to properly
account for the charge.
The idmap notify change command allows you to alert the NAS Gateway to changes
in the ID Map. The NAS Gateway can then reconstruct the ID map with new quota-
related information. When the new ID map is constructed, internal caches, and the user
and group records in the Security file are refreshed. The relevant entries are updated to
7-70
use the most recent version of the ID Map, which ensures that the user and group
entries are kept current. The idmap notify change command invokes a quota rebuild
phase.
To Force an Update of the ID Mapping Rules
Step 1: Create a virtual server and configure a volume in it. For more
information about configuring virtual servers, see “Working with
Virtual Servers” on page 3-1.
Step 2: From the context of the virtual server that contains the volume
where the quota is configured, run the following command:
idmap notify change {user|group}
Choose either user or group to specify the type of quota you are
enabling on the volume named in volname. You can specify one
or more quota types. If you specify multiple quota types, separate
each quota type with a comma—for example, user,group.
7-71
Multiprotocol File Access Without Using NIS

EverON software supports multiprotocol file access without having to use an NIS
domain controller to process user and group ID mappings. A local copy of the
password and group files for every virtual server is stored in the cluster database.
• The local password file contains the user name, the UID, and the primary GID for
every user. The information is stored in the following form:
- uname1::uid1:pgid1:::
- uname2::uid2:pgid2:::
• The local group file contains the group name, the GID, and a list of every user
name for that group. The information is stored in the following form:
- gname1::gid1:user-list1:::
- gname2::gid2:user-list2:::
ID mapping for multiprotocol file access is performed on a per-virtual-server basis
using local password and group files. The local file enable a virtual server to use a
localhost NIS domain instead of an external remote NIS domain. You can import and
edit the password and group files from external servers or clients, or create new
password and group files. A separate set of files must be created for each virtual server
that is used for multiprotocol file access.
Setting the Local NIS Domain

Local NIS domains are configured on a per-virtual server basis through the vsvr set
domain nis command. To support the local NIS domain, the NAS Gateway uses a
reserved domain name called localhost with the IP address of 0.0.0.0. The localhost
domain must be created once per cluster with the command:
domain add nis localhost 0.0.0.0
To configure a virtual server in the reserved NIS domain localhost, set the context to
the specific virtual server and add it to the localhost domain with the commands:
vsvr set <vsvr name> vsvr diag vsvr set domain nis
localhost
7-72
Importing Password, Netgroup, and Group Files for

Multiprotocol File Access
You can import the password and group files for multiprotocol file access from an FTP
server by running the localmap import command. Because local host information is
kept on a per-virtual server basis, you need to run the command from the virtual server
context.
Note - Export functionality is not supported in this release.
NIS mappings support local password and group files for multiprotocol file access
without an NIS server. If you are using this feature, consider the following:
• You need to import and/or configure both the passwd and group files for correct
configuration. The netgroup file is optional.
• You need to manually refresh the cached user name and group name information
for virtual servers that are using the local NIS maps. To refresh the information,
you can do either of the following:
- Disable, then re-enable the virtual server by running the vsvr disable
command followed by the vsvr enable command.
- Run the idmap notify change user|group command to flush any
old mappings out of the cache, and allow the new mappings to be
cached.
To Import Password, Netgroup, and Group Files From an FTP Server
Step 1: From within the virtual server context, set the virtual server to the
domain localhost by running the command:
vsvr set domain nis localhost
Step 2: Import the password or group file by running the localmap
import command from the virtual server context:
7-73
localmap import {passwd|netgroup|group}

ftp://USER:PASSWORD@IPADDR/PATHNAME
Options and
Description
Arguments
passwd Imports the password file to be used by the current virtual server.
netgroup Imports the netgroup file to be used by the current virtual server.
group Imports the group file to be used by the current virtual server.
USER Specifies the user account on the FTP server.
PASSWORD Specifies the user password on the FTP server.
IPADDR Specifies the IP address of the FTP server from where to download the
file.
PATHNAME Specifies the directory path to the file to be downloaded. PATHNAME

is the location on the server specified by IPADDR.
Editing Password, Netgroup, and Group Files for Multiprotocol

File Access
You can create and edit password and group files for multiprotocol access by running
the localmap edit command. This command starts a vi editor that allows you to
modify the password and group files. You can use this command to:
• Add user names and IDs, and group names and IDs to the password and group
files.
• Delete user names and IDs, and group names and IDs from the password and
group files.
To Edit Password and Group Files
Step 1: From within the virtual server context run the command to start a
vi text editor with the contents of the respective file:
7-74
localmap edit {passwd|netgroup|group} -g|-s
Options and
Description
Arguments
passwd Specifies to edit a password file.
netgroup Specifies to edit a netgroup file.
group Specifies to edit a group file.
-g Displays the file.
-s Specifies that the edits are saved. When you edit the file, press Enter at
each line you are editing. When you have finished editing, type exit and
press Enter again.
Step 2: Make your edits from within the vi text editor.

Step 3: When you have finished editing the file, save the file in the vi text
editor and close it.
7-75
Working With Symbolic Links

Symbolic links are a way of representing a real directory path in a shorter and easier
way to comprehend. Symbolic links relate to a volume or directory in the EverON file
system. For example, the path /vol1/marketing/users/paulw/home could be represented
much more intuitively through the use of a symbolic link as /marketing/paulw. The
implementation of CIFS by the ONStor software provides a mechanism to create
symbolic links.
The NAS Gateway supports relative and absolute symbolic links. However, absolute
symbolic links require a symbolic link mapping rule. The CIFS server on the NAS
Gateway processes the link to access the storage area network (SAN) resource that is
the target of the symbolic link.
Symbolic links are native to UNIX, so NFS clients support symbolic link functionality
natively. However, CIFS clients do not recognize symbolic links natively, so you need
to configure a symbolic link map if the link is an absolute symbolic link. The map
contains rules that allow the CIFS client to understand and follow the path represented
in the symbolic link to its target. For more information about the symbolic link map,
see “Creating Symbolic Link Mapping Rules” on page 7-77.
CIFS clients evaluate the symbolic link on the NAS Gateway, and interpret where to
orient the path based on whether the symbolic link is an absolute or relative link. For
more information about types of symbolic link supported on the NAS Gateway, see
“Support for Absolute and Relative Symbolic Links” on page 7-77.
Symbolic Links and the Directory Tree

By definition, the CIFS protocol cannot open a file directory above your point in the
directory tree. However, the NAS Gateway has optimized the usage of this rule with
symbolic links. The NAS Gateway enforces some rules on navigating a symbolic link:
• When a client receives its connection point in the directory tree, the NAS Gateway
will allow a symbolic link to move anywhere from the connection point down the
directory tree without restriction.
• When a client needs to navigate up the directory tree, the NAS Gateway allows the
symbolic link to move anywhere above the connection point, but only temporarily
7-76
and only if the symbolic link’s target is equal to or below the directory tree
connection point.
• The NAS Gateway never allows a symbolic link to move to a target that is above
the client’s initial connection point in the directory tree.
Deletions and Symbolic Links

The NAS Gateway’s implementation of CIFS includes a mechanism that ensure
correct deletion of objects linked by symbolic links. The NAS Gateway tracks the
name of the object you opened and allows for the correct deletion of the opened object.
Consider the following example.
A symbolic link named \e is targeting \a\b\c. When a Windows user attempts to
delete \e, the NAS Gateway responds by deleting \e, which is the open object,
whereas some other devices would delete \c, which is the target of the symbolic link.
Deletion of All Objects in a Path

The NAS Gateway’s implementation of CIFS handles deletion of all objects in the
path through the del * command. In some cases, when a user deletes all objects on a
path that includes a symbolic link, some other devices can fail to delete all objects.
Consider this example.
Parent
dirA dirB dirC

A.doc
Figure 7-5 Sample Deletion Through Symbolic Link
On a Windows client, you are at the top level directory and three subdirectories exist
below called dirA, dirB, and dirC. The directory dirA contains the file A.doc that is a
symbolic link to \C. When a user on the Windows client run the del * operation from
the top level, the NAS Gateway correctly deletes all files in the subdirectories and the
subdirectories themselves. Some other devices would fail the deletion because when
the devices reach dirC it’s an empty directory and cannot be removed.
7-77
Support for Absolute and Relative Symbolic Links

The NAS Gateway supports both absolute and relative symbolic links. An absolute
symbolic link always begins with a slash (/) and the path is always oriented to the root
of the file system. A relative symbolic link always begins with a nonslash character,
and the path is always oriented to the parent directory of the symbolic link. The NAS
Gateway has a symbolic link feature that supports relative symbolic links. You don’t
have to create a mapping for a relative symbolic link.
The NAS Gateway supports absolute symbolic links through a rule that maps the
symbolic link to an actual file system volume and directory. After the rule is created,
CIFS clients that seek to access that directory are subject to the rule. The symbolic link
and the actual link can exist simultaneously, and users can navigate to the appropriate
directory using either method. But, by default the NAS Gateway will always choose
the symbolic link first. To support absolute symbolic links, you need to create a
symbolic link mapping. See “Creating Symbolic Link Mapping Rules” on page 7-77.
Note - Symbolic link mappings are per-volume, and the target of the symbolic
link must always lead to the same volume. You cannot create a symbolic link
whose target is on a different volume.
Creating Symbolic Link Mapping Rules

Symbolic links can facilitate file access. A symbolic link is a mapping between a
representative path and an actual path to a volume or directory. For example, a
symbolic link for /pubs/projects/users/paulw/filter could be created as
/filter. However, in a mixed CIFS and NFS environment, problems can arise
because NFS can process a file system path that uses an absolute symbolic link, but
CIFS cannot.
To allow CIFS clients to process absolute symbolic links, you create a rule for
mapping an absolute symbolic link so that every CIFS client’s access request for that
target can be processed. When the client follows the symbolic link, security settings
are applied to the directory and target in the symbolic link as if the client was
following a standard path.
7-78
The NAS Gateway will not support absolute symbolic links without a symbolic link
mapping. The mapping allows a CIFS client to follow a symbolic link to a target that is
supported on the same share only. Without a symbolic link mapping, a target volume
or directory is still available through the actual path.
If a symbolic link is configured to a target, the NAS Gateway always follows that link.
However, based on permissions, a user might not be able to open or manipulate the
target of the symbolic link. In such cases, the NAS Gateway will allow the client to
traverse the directory, but will display an empty directory if the permissions disallow
the manipulation of the object at the target of the symbolic link.
If multiple links are configured, the NAS Gateway matches to the longest path. By
default, a symbolic link is active when it is added to the NAS Gateway. The NAS
Gateway can support a total of 32 symbolic links in one path.
The NAS Gateway also uses symlinks to support wide link functionality. A wide link
is a CIFS share that is interacts with an NFS symlink to allow access to domain
controller that can be in another domain or accessable through another virtual server.
When you add a wide link, you are creating a rule for a symlink, and that rule
determines the target volume or CIFS server that the client wants to access. Consider
the following example of a wide link rule added to the NAS Gateway:
symlink add vol1 \\srv\share\Redir4 /mnt/vol2
Assume the following symbolic link exists on an UNIX client:
ln -s /mnt/vol2/dirC/dirD sym3
When a CIFS client accesses the symbolic link, the mapping rule is applied and the
client is redirected to \\srv\share\Redir4\dirC\dirD. The CIFS server srv can be
any CIFS server on the network and share can be any CIFS share on that server. The
NAS Gateway takes the path \\srv\share\Redir4 from the mapping rule and /
dirC/dirB from the remaining symbolic link target text.
You can create a symbolic link’s mapping rule by running the symlink add command.
7-79
Note - The symlink add command creates a symbolic link mapping rule for
absolute symbolic links only. Symbolic links are always available through
NFS, and they can be created through NFS without using this command.
However, NFS-created symbolic links might not be accessible through CIFS
unless you map the symbolic link with the symlink add command.
To Create a Symbolic Link Mapping Rule

symlink add VOLUME TARGET LINK
Options and
Description
Arguments
VOLUME Specifies the volume on which the mapping rule applies.
TARGET Specifies the directory to which the symbolic link is pointing. Enter the
name of the directory without specifying the root slash or the parent
directories that precede the target directory. When you specify the target
directory, enter just the directory name and use a blank space to
separate the target directory from the volume listed in VOLUME.
LINK Specifies the symbolic link that you are creating to represent the actual
path to the target. Because you are creating a mapping for an absolute
symbolic link, enter the symbolic in reference to the root, so include the
root slash (/). For example: /pubs/paulw/filter
Displaying a Symbolic Link Mapping Rule

You can display the symbolic link mappings configured on a volume by running the
symlink show command. This command displays the symbolic links on a per-volume
basis, so you need to run this command on each volume if you want to see all symbolic
links configured.
To Display the Symbolic Links Configured on a Volume
symlink show VOLUME
7-80
VOLUME specifies the volume for which you want the symbolic
link mapping rules displayed. Enter the name of the volume for
which you want to display symbolic links.
Removing a Symbolic Link Mapping Rule

You can remove a symbolic link mapping rule any time after it has been configured by
running the symlink del command. When you remove a symbolic link mapping rule,
the mapping and rule is completely deleted from a specified volume. You need to
remove symbolic link mapping rules individually. Therefore, you need to run the
symlink del command once for each symbolic link mapping rule you want to
remove, and once on each volume. After a symbolic link mapping rule is removed,
you can still access the previously linked volume or directory by navigating through
the actual path.
To Remove a Symbolic Link
symlink del VOLUME LINKTARGETTEXT
Options and
Description
Arguments
VOLUME Specifies the volume from which you are deleting a mapping rule.
Enter the name of the volume from which you will be deleting a
symbolic link.
LINKTARGETTEXT Specifies the symbolic link that you are deleting. Because you are
creating a mapping for an absolute symbolic link, enter the name
of the configured symbolic link that you want to delete, and
include the root slash (/). For example: /pubs/paulw/filter.
Chapter 8: Managing File Auditing
• “Understanding File Auditing” on page 8-2
• “Managing File Auditing” on page 8-9
• “Configuring File Auditing” on page 8-19
8-2
Understanding File Auditing

The ONStor implementation of file auditing occurs on a per-volume basis. Each
volume contains one audit log file. File auditing occurs at the file or directory level,
when the user actually attempts to perform an action on a specified file or directory.
However, the file or directory access requests are queued on the Gigabit Ethernet (GE)
file processor (FP) element while the NAS Gateway checks the user’s permissions and
the system control access list (SACL) on the file or directory. If the user is allowed to
access the file or directory, the request is allowed to proceed past the FP element. If
access is not allowed, the request is denied and does not proceed past the FP element.
If auditing is enabled, the resulting success or failure result will be written to the audit
log.
Audit log files are created on disk in a secure directory when you create the volume.
To ensure complete security, each volume’s audit log file resides in a hidden portion of
disk space. You can view its contents through a command that posts the audit log
contents to the management console. By default, file auditing is disabled.
Note - The NAS Gateway supports viewing the audit log only through the
audit show log command. Therefore, the NAS Gateway, Windows clients,
or Windows servers cannot display the audit log file through the Windows
Event Viewer.
File auditing for NFS is not supported.
File Auditing in CIFS

File auditing in CIFS occurs when a user attempts to perform an action on a file.
Concurrent with the user’s request for access to the file, the NAS Gateway checks two
components at the file level:
• The SACL which is part of the Windows ACL. The SACL indicates which file
operations should generate an audit or alarm, and which file access types should
generate an audit event. The result of the SACL and the attempted operation by the
user is either successful or failed. The SACL can specify which outcome, either
8-3
success or failure, generates the audit event. The success or fail event is then
written to the audit log file.
• Execution privileges, grant users access rights to files. The privileges that are
audited are:
- SECURITY
- BACKUP
- RESTORE
- TAKEOWNERSHIP
- TRAVERSE
For file auditing in a CIFS environment, configure the file auditing feature on the NAS
Gateway, but also configure the Auditing tab for the file or directory that you want to
audit. For example, you would:
• Log on as an administrator on a Windows client.
• Map a drive to a CIFS share.
• Select a directory.
• Select Properties>Advanced>Auditing for that directory.
Note - CLUSTER or SECURITY privilege are required for accessing the

Auditing tab.
For more information about File Auditing in a Windows environment, see the
Microsoft documentation at www.microsoft.com.
Audit Events
The audit events are represented in the audit log file by ONStor abbreviations that
represent Microsoft standard file access events. Each entry in the audit log contains an
access mask that displays the information about the file operation that was audited.
Table 8-1 shows the mapping of the Microsoft label to the ONStor abbreviation that is
displayed in the audit log file. Use this table to decode the access mask in the audit log
8-4
file. The NAS Gateway performs auditing on file access operations only. Auditing
does not occur on logon or logoff events.
Table 8-1: Audit Log Event Abbreviations
Abbreviation Event Description
RD FILE_READ_DATA For a file, indicates the right to

read a file’s file data.
For a directory, indicates the right
to read a directory’s data.
WD FILE_WRITE_DATA For a file, indicates the right to

write file data to the file.
to create file in the directory.
AD FILE_APPEND_DATA For a file, indicates the right to

append data to an existing file.
to create a subdirectory.
REA FILE_READ_EA Indicates the right to read

extended file attributes.
WEA FILE_WRITE_EA Indicates the write to read

extended file attributes.
EX FILE_EXECUTE For a native code file, indicates

the right to execute the file. If
given to scripts, this right might
cause scripts to be executable if
the script interpreter allows.
DC FILE_DELETE_CHILD For a directory, indicates the right

to delete a directory and the files
in it, including read-only files.
RA FILE_READ_ATTRIBUTES Indicates the right to read file

attributes.
WA FILE_WRITE_ATTRIBUTES Indicates the right to write file

attributes.
8-5
Table 8-1: Audit Log Event Abbreviations (Continued)
Abbreviation Event Description
DEL DELETE Indicates the right to delete the file

or directory.
RC READ_CONTROL Indicates the right to read

information in the file or directory’s
security descriptor.
WDAC WRITE_DAC Indicates the right to modify the

DACL on the security identifier.
WOWN WRITE_OWNER Indicates the right to change the

owner in the security identifier.
SYNC SYNCHRONIZE Indicates the right to specify a

write handle in a wait function
during a synchronous I/O.
SEC ACCESS_SYSTEM_SECURITY Indicates a backup system’s rights

to access the system level access
control settings.
MAX MAXIMUM_ALLOWED Indicates that the file can be

opened for as many of the other
desired access right types as
allowed by the ACL.
GR GENERIC_READ Indicates generic read access for

a file or directory.
GW GENERIC_WRITE Indicates generic write access for

a file or directory.
GE GENERIC_EXECUTE Indicates generic execute attribute

for a file or directory.
GA GENERIC_ALL Indicates generic read, write, and

execute access for a file or
directory.
An example entry in the audit log file is shown below.
8-6
Tue Aug 5 13:39:08 GMT 2003 -- Audit clear

user : root@local
Tue Aug 5 13:39:08 GMT 2003 -- Audit modify
user : user1@domainX
Tue Aug 5 14:44:04 GMT 2003 -- Audit modify
user name: domainY\user2
Tue Aug 5 14:49:13 GMT 2003 -- File access
Path name: /test.tst
Access granted: yes
Request type: Access file
Access mask: 00020000 - RC
Privileges used: restore
user : domainY\user2
Access granted: yes
Access mask: 00020000 - RC
user : domainY\user2
Access granted: yes
Access mask: 00020089 - RD REA RA RC
8-7
Access granted: yes

Access mask: 00020080 - RA RC
This example audit log text contains entries for config records and audit records. In the
example, the config records are smaller. They have a title that is anything other than
“file access,” and the titles indicate which action was performed. For example, the first
three entries in this example are config records. These entries indicates that the NAS
Gateway admin with ID “root@local” changed the auditing configuration by first
clearing the audit log file, then NAS Gateway admin “user1@domainX” modified the
auditing configuration. The last config record shows that NAS Gateway admin
“domainY\user2” also changed the auditing configuration.
Note - You can determine the domain type by the admin ID format. IDs from a
UNIX domain have the format “admin@domain”, as in user1@domainX. IDs
from a Windows domain have the format “domain\admin”, as in
domainY\user2.
The remainder of the entries are audit records as indicated by their title “file access.”
In this example audit log, you can see the following information is contained in each
audit record:
• The date and timestamp at which the audit record was created, and the reason for
the record. In these examples, a file access request was sent.
• User name information, including the domain in which the user is requesting
access to a file.
• The path that the user used to attempt access to the file.
• The access information about the request, including whether file access was
allowed or denied.
• The type of request the NAS Gateway received from the user.
• The access mask, which is the string of numerals and the file access
abbreviation(s) that indicate which actions were attempted on the file. These
8-8
abbreviations map closely to access mask values used by Windows devices, but the
abbreviation for each label is related to the EverON file system. For a list of access
mask values and their ONStor abbreviations, see Table 8-1 on page 8-4.
• The privileges used to access the file.
8-9
Managing File Auditing

File auditing is supported on files and directories that are configured in a volume that
is accessed by UNIX and CIFS clients.
Enabling and Disabling File Auditing on a Volume

When you enable file auditing for the first time, the NAS Gateway creates the audit
log file on disk for the specified volume, and the same audit log file is used for
subsequent audits regardless of how many times the auditing software is enabled or
disabled on that volume. By default, file auditing is disabled.
Note - File auditing can impact the NAS Gateway while enabled based on the
volume of transactions and amount of data scanned in each file transaction.
When you disable file auditing, all entries in the audit log file are retained. The audit
file will remain configured on the volume.
To Enable File Auditing
audit enable VOLNAME
To Disable File Auditing
audit disable VOLNAME
VOLNAME specifies the volume on which the file auditing is
being enabled or disabled.
Setting or Deleting Success Parameters

As part of file auditing, you need to specify the audit parameters that will be tracked.
Parameters can be tracked for positive events on the volume, such as successful file
operations. You can determine if a file operation has been successful by comparing
privilege levels, such as backup, take ownership, and restore, to file level permissions.
8-10
If this comparison results in acceptance of the operation, the file operation is

successful.
You can declare which successful file operations are tracked by configuring a success
parameter. The success parameters specifies all the file operations that you want to
appear in the audit log when a comparison of the ACL to the SACL on the file allows
the operation to occur.
Note - You cannot configure actual permissions through any auditing

commands. You only specify the permissions that will create an audit record in
the audit log file. To configure permissions, run the priv add command. For
more information about this command, see “Managing Privileges” on page 2-
1.
The NAS Gateway compares the permission that is attempting a file access
with the permission required for that file access. In the case of success
parameters, the NAS Gateway then adds a record to the audit log file whenever
the comparison allows the file access.
A deleted success parameter is not automatically tracked as a failure parameter. If you

want a deleted success parameter to be tracked for failures, you need to configure it as
a failure parameter. For more information about configuring failure parameters, see
“Setting or Deleting Failure Parameters” on page 8-11.”
To Set the Success Parameters
audit set success_privilege VOLNAME PRIVILEGES
8-11
To Delete One or More Success Parameters

audit unset success_privilege VOLNAME PRIVILEGES
Options and
Description
Arguments
VOLNAME Specifies the name of the volume on which you want to track file
operations that resolve if you are setting success parameters, or the
name of the volume on which you want to delete success parameters.
PRIVILEGES Specifies one or more file privileges that you want the NAS Gateway to
record in the audit log file if you are setting success parameters, or one
or more file privileges that you no longer want the NAS Gateway to
record in the audit log file. Enter one or more of the following privileges:
• security
• backup
• restore
• takeownership
• traverse
If you enter multiple file operations, separate each operation with a blank
space.
Setting or Deleting Failure Parameters

As part of file auditing, you need to specify the audit parameters that will be tracked.
Parameters can be tracked for negative events on the volume, such as failed file
operations. The determination of a failed file operation is made through a comparison
of privilege levels, such as backup, takeownership, or restore, to file level permissions.
If this comparison results in denial of the operation, the file operation fails.
You can declare which failed file operations are tracked by configuring a failure
parameter. This parameter specifies all the file operations that you want to appear in
the audit log when a comparison of the ACL to the SACL on the file prevents the
operation from occurring.
8-12
Note - You cannot explicitly configure actual permissions, for example

“backup”– through any auditing commands. You only specify the permissions
that will create an audit record in the audit log file. To configure permissions,
run the priv add command. For more information about this command, see
“Managing Privileges” on page 2-1.
The NAS Gateway compares the permission that is attempting a file access
with the permission required for that file access. In the case of failure
parameters, the NAS Gateway then adds a record to the audit log file whenever
the comparison disallows the file access.
You can delete failure parameters that are configured for the audit log. A deleted
failure parameter is not automatically tracked as a success parameter. If you want a
deleted failure parameter to be tracked for success, you need to explicitly configure it
as a success parameter.
To Set the Failure Parameters That Are Tracked in the Audit Log
audit set fail_privilege VOLNAME PRIVILEGES
To Delete the Failure Parameters That Are Tracked in the Audit Log
audit unset fail_privilege VOLNAME PRIVILEGES
Options and
Description
Arguments
VOLNAME Specifies the name of the volume on which you want to configure or
delete failure parameters.
8-13
Options and
Description
Arguments
PRIVILEGES Specifies one or more file privileges that you want the NAS Gateway
to record in the audit log file if you are configuring failure parameters,
or one or more file privileges that you no longer want the NAS
Gateway to track if you are deleting failure parameters. Enter one or
more of the following privileges:
• security
• backup
• restore
• takeownership
• traverse
If you enter multiple file operations, separate each operation with a
blank space.
Disallowing File Operations From the Audit Log File

The NAS Gateway’s ability to record operations in the audit log file can affect the
completion of file operations. You can configure the NAS Gateway to disallow an
attempted file operation if that operation cannot be recorded in the audit log file. The
specified operation will fail, and the client will not be allowed to perform the operation
because there is no way to track it.
To Disallow File Operations From the Audit Log File
audit set fail_flag VOLNAME {yes|no}
Options and
Description
Arguments
VOLNAME Specifies the name of the volume on which you want to file operations to
fail if they cannot be written to the audit log file.
8-14
Options and
Description
Arguments
yes|no Specifies the state of denying a file operation that cannot be recorded in
the audit log file:
• yes causes the NAS Gateway to deny the file access operation if it
cannot be written into the audit log file.
• no causes the NAS Gateway to allow the file access operation even
if it cannot be written into the audit log file. The default value is no.
Setting the Audit Log File’s Capacity

You can set the total size of the file with the audit set filesize command. This
command enables you to customize the audit log file’s capacity based on your use of
file auditing. For example, if you intend to track few file operations for success or
failure, you could set the audit log file to a smaller size. Conversely, if you want to
enforce a very strict and detailed implementation of auditing, or if your network is
exceptionally large or busy, you might want to set a large audit log file. There is a trade
off with either situation:
• Smaller audit log files consume less disk space for the volume, but do not store an
extensive audit trail.
• Larger audit log files consume more disk space for the volume, but provide a much
more detailed and informative audit trail.
The default size of the file is 0 for unlimited space. The file behaves differently
depending on whether the file is configured as a circular file:
• If the file size is 0 and the file is circular, the file will not wrap.
• If the file size is 0 and the file is not circular, it will continue to grow until it
reaches the maximum disk space minus the amount of user data. At this point, the
file will no longer accept new audit log entries. However, if you have configured
AutoGrow on the volume, prior to the file reaching the truncation point, the NAS
Gateway can automatically add more disk space.
Because the audit log file contains a full path, the size of each record in the file can
vary, and therefore, the size of each file can vary. If you create success and failure
8-15
parameters that track many or all privileges, set your audit log file to a larger size than
if you have fewer success or failure parameters.
To Set the Audit Log’s Size
audit set filesize VOLNAME FILESIZE
Options and
Description
Arguments
VOLNAME Specifies the volume on which you are setting the audit log file capacity.
FILESIZE Specifies the total size, in number of Kilobyte blocks, of the audit log file.
Controlling Audit File Behavior

Because the audit file has a finite capacity, it behaves in one of two ways when it
reaches capacity:
• It performs a circular write by wrapping to the beginning of the file and writing
new entries over the first entry. For example, if the file is configured for 56 audit
log records, the 57th audit log record will be written at location 1 of the file.
• It does not write any more entries. Instead it sends an audit log file notification that
the file is full.
You can control the audit file by activating or deactivating the circular write. By
default, circular write is disabled.
Note - If you elect not to enable circular write, you can clear the audit log file
by running the audit clear command.
8-16
To Control the Audit File Behavior

audit set circular VOLNAME {yes|no}
Options and
Description
Arguments
VOLNAME Specifies the volume on which you are enabling or disabling the circular
write feature. Enter the name of the volume whose audit log you setting
with the circular write feature.
yes|no Sets the state of the circular write:

• yes activates circular write of new entries when the audit log file
reaches capacity.
• no causes the file not to write new entries when the audit log file
reaches capacity.
Displaying the File Audit Configuration

Displays the audit configuration settings for the specified volume.
To View the File Auditing Configuration for a Volume
audit show config VOLNAME
VOLNAME is the name of the volume for which you want to
display the currently configured file auditing parameters.
Displaying the Audit Log File

The NAS Gateway supports viewing the audit log only through the audit show log
command. Therefore, the NAS Gateway, Windows clients, or Windows servers cannot
display the audit log file through the Windows Event Viewer.
8-17
To View a Volume’s Audit Log File

audit show log VOLNAME MAXRECORDS
Options and
Description
Arguments
VOLNAME Specifies volume for which you want to display the audit log file.
MAXRECORDS Specifies the number of audit records to display, from 1 to 20.
Clearing the Contents of an Audit Log File

Clears the audit log file for the specified volume. The audit log file contains logs
corresponding to file accesses within a volume.
To Manually Clear the Audit Log File
audit clear VOLNAME
VOLNAME is the name of the volume that contains the audit log
file you want to clear. All entries in the audit log file are erased,
and the empty audit log file remains configured and ready to
accept new entries.
Exporting the Audit Log File

Exports the audit logs for a specified volume to a file.
8-18
To Export the Audit Log File

audit export VOLUME LOCATION
[-m MINUTE] [-h HOUR] [-d DATE] [-M MONTH]
[-D DATE]
Options and
Description
Arguments
VOLNAME Specifies the volume for which the audit log file is exported.
LOCATION Specifies the file path to store the audit log. If the path name
is a directory, the audit log is stored in a default file name in
the specified directory.
The default file name is <VOLNAME>.<YYYYMMDD>.
<NUMBER> where YYYYMMDD represents the date of the
export.
For example, in the case of an hourly export of volume
VOL1 on 2/1/07, the export files would be
VOL1.20070201.0, VOL1.20070201.1, ...
VOL1.20070201.23.
-m MINUTE The -m parameter is the minutes (0-59) of the hour at which
the report should be generated and sent.
-h HOUR The -h parameter is the hour (0-23) at which the report
should be generated and sent.
-d DATE The -d parameter is the date (1-31) on which the report
should be generated.
-M MONTH The -M parameter is the month (1-12) in which the report
should be generated and sent.
-D DATE The -D parameter is the day of the week (0-7) on which the
report should be generated. Day 0 or 7 is Sunday.
8-19
Configuring File Auditing

The following procedure describes how to figure file auditing on a volume. For this
procedure, assume the following:
• The NAS Gateway has been configured with at least one virtual server. For more
information about configuring virtual servers, see “Working with Virtual Servers”
on page 3-1.
• The volume on which you want file auditing configured is named payroll.
• A client is attempting to access the target file “file1” in the file system.
• The audit log file will be set to 500 KB.
• The audit log file will be set to circular mode.
To Configure File Auditing
Step 1: Configure the audit log file’s capacity, by running the audit set
filesize command:
audit set filesize payroll 500
where 500 is the 500 KB file size of the audit log file.
Step 2: Configure the audit log file’s behavior by configuring it to wrap or
discard new entries at capacity, and fail or allow file access based
on whether the NAS Gateway can write an audit record into the
audit log file, by running the audit set circular command.
audit set circular payroll yes
• circular allows the file to wrap new entries to the beginning
of the audit log file and overwrite the oldest entries.
• payroll is volume on which you are configuring whether
access to target file can be allowed or not based on whether
the NAS Gateway can write an audit record into the audit log
file.
• yes indicates that audit entries will be overwritten when the
audit log reaches capacity.
8-20
Step 3: Configure the failure events for the privileges that attempt file
access, by running the audit set command:
audit set fail_privilege payroll takeownership
• payroll is the volume on which you want file access attempts
logged in the audit log file.
• takeownership is the privilege that will be audited for
successful file access attempts.
Note - The NAS Gateway supports takeownership, traverse, security, backup,

and restore privileges for auditing. You can enter these privileges as a space-
separated list.
Step 4: Configure the success events for the privileges that attempt file
access, by running the audit set command:
audit set success_privilege payroll takeownership
• payroll is the volume on which you want file access attempts
logged in the audit log file.
• takeownership is the privilege that will be audited for
successful file access attempts.
Step 5: Enable file auditing by running the audit enable command:
audit enable payroll
payroll is the volume on which you are enabling file auditing.
When file auditing is enabled, it applies to all clients that use
shares configured for the volume. For example, if payroll has 46
shares configured on it, the NAS Gateway will apply file auditing
to all clients that use any of the 46 shares that export the volume,
regardless of the file access protocol–NFS or CIFS–the share uses
to advertise payroll to clients.
Step 6: Check the audit log configuration and verify that the auditing
parameters are set correctly, by running the audit show config
command:
8-21
audit show config payroll

payroll is the volume on which you are checking the auditing
configuration.
8-22
Chapter 9: Managing Snapshots
• “Snapshots Overview” on page 9-2
• “Managing Snapshots on the NAS Gateway” on page 9-4
9-2
Snapshots Overview
Snapshots are static images of the EverON™ file system. Each file system can support
a maximum of 48 snapshots. The maximum size of these snapshots is limited by the
amount of disk space. The NAS Gateway supports two types of snapshots: on-demand
and scheduled.
• You can create an on-demand snapshot manually at any time. For more
information about on-demand snapshots, see “Creating Snapshots On-Demand” on
page 9-4.
• A scheduled snapshot occurs automatically at a preset time and frequency. For
more information about scheduled snapshots, see “Creating Snapshot Schedules”
on page 9-6.
Scheduled Snapshots
Scheduled snapshots can occur either hourly, daily, or weekly. Daily snapshots are
taken at midnight, and weekly snapshots are taken at midnight on every Sunday. Daily
and weekly snapshots have the following scheduling considerations:
• If daily snapshots are configured, hourly snapshots do not occur at midnight.
• If weekly snapshots are configured, daily snapshots do not occur at midnight on
every Sunday.
The NAS Gateway supports a default snapshot schedule, as shown in Table 9-2.
Table 9-2: Default Snapshot Schedule
Snapshot Type Supported? Maximum Snapshot Schedule
weekly no n/a n/a
daily yes 2 kept by default n/a
hourly yes 8 kept by default 8 a.m., 12 p.m.,

4 p.m., 8 p.m.
9-3
File System Quotas and Snapshots

The snapshots functionality includes the ability to revert a volume from a saved
snapshot. These features can affect the NAS Gateway’s quota configuration. Restoring
affects all types of quota: user, group, and tree.
Snapshot Location on the NAS Gateway

Snapshots reside in the designated /.snapshots directory of the EverON file system.
The /.snapshots directory is a central directory for each file system supported by
the NAS Gateway. The NAS Gateway does not currently support one /.snapshots
directory for each data directory within a file system.
All files in the /.snapshots directory are read only. The snapshots directory is
created automatically at the time the file system is created. No default name exists for
on-demand snapshots files, so when you create a snapshot, you need to name it with
the snapshot create command before it can be saved to the /.snapshots directory.
Snapshots appear in the /.snapshots directory in most-recent to least-recent order.
Because snapshots are numbered incrementally when newer snapshots arrive, the most
recent snapshots are named hour.0, daily.0 or weekly.0. Older snapshots have a larger
number, such as hourly.12, daily.5, or weekly.3.
9-4
Managing Snapshots on the NAS Gateway

Snapshot management consists of the following tasks:
• “Creating Snapshots On-Demand” on page 9-4
• “Deleting On-Demand Snapshots” on page 9-5
• “Creating Snapshot Schedules” on page 9-6
• “Enabling and Disabling the Snapshot Schedule” on page 9-7
• “Viewing Snapshot Usage” on page 9-8
• “Restoring a Snapshot as a Live File System” on page 9-9
• “Renaming a Snapshot” on page 9-9
• “Pinning and Unpinning a Snapshot” on page 9-10
Creating Snapshots On-Demand

This command is used to create a snapshot of a volume.
To Create an On-Demand Snapshot
snapshot create VOLNAME SNAPNAME -m
Options and
Description
Arguments
VOLNAME Specifies the volume that contains the file system that you are capturing
with a snapshot.
SNAPNAME Specifies the name of the on-demand snapshot that you are taking. The
file suffix (.ss) indicates that the file is a snapshot file. Snapshot names
up to 31 characters long.
-m Creates a snapshot with a name reserved for mirror snapshots. Use this
command if the volume is going to be replicated by array replication and
subsequently used as a part of a mirror. The created snapshot will be
used as the mirror baseline.
9-5
Note - If you name the on-demand snapshots with any of the default names for
scheduled snapshots, the command fails. For more information about default
names, see Table 9-3 on page 9-6. Do not name any on-demand snapshots with
the following file names:
• hourly.x.ss
• daily.y.ss
• weekly.z.ss
Deleting On-Demand Snapshots

If a snapshot is pinned, you need to unpin it before you can delete it. For more
information about unpinning a snapshot, see “Pinning and Unpinning a Snapshot” on
page 9-10. By default, the snapshots scheduled for mirrors are always pinned.
To Manually Remove an On-Demand Snapshot
snapshot delete VOLNAME SNAPNAME
Options and
Description
Arguments
VOLNAME Specifies the volume that contains the snapshot snapshot you are
deleting.
SNAPNAME Specifies the name of the on-demand snapshot that you are deleting.
9-6
Creating Snapshot Schedules

Scheduled snapshots are named automatically based on the type of snapshot you
schedule. See Table 9-3.
Table 9-3: Snapshot File Naming and Maintenance
Snapshot
File Name Maintenance Method
Type
hourly hourly.n n is an integer that indicates the snapshot number. The

NAS Gateway increments this integer from most
recent to least recent snapshot.
daily daily.n n is an integer that indicates the snapshot number. The

weekly weekly.n n is an integer that indicates the snapshot number. The

When scheduled snapshots are completed, they reside in the /.snapshots directory
along with on-demand snapshots.
When creating the snapshot schedule consider the following:
• The default snapshots schedule should be adequate if:
- Files are not lost often.
- Lost files are noticed quickly after they are lost.
• A customized schedule that keeps snapshots for a longer amount of time should be
used if:
- Files are lost often.
- Lost file are not noticed quickly after they are lost.
• Different snapshot schedules are supported on different volumes enabling you to
customize snapshot schedules to closely match the activity of the volume.
9-7
To Create Scheduled Snapshots

snapshot schedule VOLNAME [-w MAXWEEKLY[
[-d MAXDAILY[ [-h MAXHOURLY[ [-l HOURS]
Options and
Description
Arguments
VOLNAME Specifies the volume on which you want to take snapshots of the file
system.
-w MAXWEEKLY Specifies the maximum number of weekly snapshots to be kept.
-d MAXDAILY Specifies the maximum number of daily snapshots to be kept.
-h MAXHOURLY Specifies the maximum number of hourly snapshots to be kept.
-l HOURS An optional hours list that specifies the times at which to take
snapshots. Hours in the list are separated with a comma. Valid range
is 1 to 24, where 1 is 1 a.m., 12 is mid-day, and 24 is midnight. By
default hourly snapshots occur at 8 a.m.,12 p.m.,4 p.m., and 8 p.m.
Enabling and Disabling the Snapshot Schedule

By default, the snapshot scheduler is enabled, so if you create a schedule, the
snapshots automatically occur at the configured date and time. However, if the
snapshot scheduler becomes disabled, you can manually enable the snapshot schedule.
Note - You can check the status of the snapshot scheduler by running the
snapshot show schedule command. If the snapshot scheduler is disabled,
the output of the show schedule command will show the following message:
**snapshot scheduling currently disabled for this volume**

If you attempt to modify the current snapshot schedule while the
snapshot scheduler is disabled, the following error message is
displayed:
snapshot operation not allowed
9-8
To Enable the Snapshot Scheduler

snapshot enable VOLNAME
VOLNAME is the name of the volume on which you are enabling
the configured snapshot schedule.
Note - These commands affect scheduled snapshots only. On-demand

snapshots are not affected by command.
Viewing Snapshot Usage

You can use the snapshot show command to display all the snapshots that have been
taken for a specific volume and the disk usage of snapshots. Through the disk usage,
you can determine whether the snapshot schedule is too frequent by the amount of disk
space that is consumed.
To View Snapshot Usage
snapshot show VOLNAME {schedule|list|usage}
Options and
Description
Arguments
VOLNAME Specifies the volume associated with the snapshots whose

usage you want to view.
schedule|list|usage Specifies what type of snapshot you want to display:

• schedule shows the volume’s current snapshot schedule.
• list shows the all snapshots names, creation times, and
internal snapshot IDs.
• usage shows the volume’s disk usage for snapshots.
9-9
Restoring a Snapshot as a Live File System

You can restore a specified scheduled snapshot or an on-demand snapshot as a live file
system.
Note - After the snapshot has been restored as the live file system, the NAS
Gateway retains the target snapshot as a normal snapshot. The snapshot is not
deleted when it has been restored as the new file system, and the NAS Gateway
does not take a duplicate snapshot of the new file system. Snapshots occur as
normal after a new file system has been created from a snapshot.
To Restore a Snapshot as the Live File System

snapshot revert VOLNAME [-n SNAPNAME]
Options and
Description
Arguments
VOLNAME Specifies the volume on which you are restoring a snapshot as a live file
system.
-n SNAPNAME An optional argument that specifies the name of the snapshot to be

reverted as the file system. If you specify no SNAPNAME, by default,
the NAS Gateway uses the most recent snapshot as the live file system.
Renaming a Snapshot
You can rename an on-demand snapshot or a scheduled snapshot by running the
snapshot rename command.
9-10
Note - The NAS Gateway uses reserved names for some of its snapshots. If
you are renaming a snapshot, you cannot use any of the following names or the
command fails:
• hourly.x.ss, where x is a number.

• daily.y.ss, where y is a number.
• weekly.z.ss, where z is a number.
To Rename a Snapshot
snapshot rename VOLNAME OLDNAME NEWNAME
Options and
Description
Arguments
VOLNAME Specifies the volume that holds the snapshot you are renaming.
OLDNAME Specifies the current name of the snapshot.
NEWNAME Specifies the new name of the snapshot.
Pinning and Unpinning a Snapshot

When a snapshot is pinned, it cannot be deleted until it is unpinned. The NAS
Gateway supports pinning and unpinnning on-demand and scheduled snapshots.
Snapshots that use reserved names cannot be pinned.
To Pin a Snapshot and Prevent Its Deletion
snapshot pin VOLNAME SNAPNAME
9-11
To Unpin a Snapshot
snapshot unpin VOLNAME SNAPNAME
Options and
Description
Arguments
VOLNAME Specifies the volume on which you are pinning or unpinning a

snapshot.
SNAPNAME Specifies the name of the snapshot to be pinned or unpinned.
9-12
Chapter 10: Managing File System
Quotas
• “Quotas Overview” on page 10-2
• “Quota Interaction with Other NAS Gateway Features” on page 10-3
• “Configuring Default Quotas” on page 10-9
• “Enabling or Disabling Quotas” on page 10-17
• “Configuring Quotas” on page 10-19
• “Updating ID Mapping Rules” on page 10-22
• “Working With the Quota Log” on page 10-23
10-2
Quotas Overview
Quotas help to control the amount of disk space that can be used by a user, group, or
part of the directory tree. You can ensure that disk space is available to other users,
groups, and parts of the directory tree by controlling the amount of disk space that can
be used.
File System Quotas and Volume-Level Quotas

The NAS Gateway supports volume-level quotas and file system quotas:
• Volume-level quotas can be configured with the volume create or volume
modify command. Volume-level quotas are for setting usage and warning
thresholds for a volume that is reaching capacity. For more information about
volume-level quotas and the NAS Gateway’s AutoGrow feature, see the
“Managing Volumes and File Systems” on page 6-1.
• File system quotas are configured to enforce usage conditions for clients that
attempt to allocate space in the file system. File system quotas are used to deny a
client the ability to allocate a file system object, or deny the allocation of a specific
path element in the file system’s name space.
File system quotas enforce usage conditions first, and, therefore, volume-level quotas
do not activate.
Quota Types
The NAS Gateway’s quota implementation supports the following types of quotas:
• User quotas are usage conditions configured for a specific user or all users.
Note - User quotas cannot be deleted through the NAS Gateway’s CLI. If you
no longer want quotas to operate in the file system, you can disable the quota.
(See “Enabling or Disabling Quotas” on page 10-17.
• Group quotas are usage conditions configured for a specific group or all groups.
• Tree quotas are usage conditions configured on a specific location of the directory
path, either on the root or anywhere along the directory path. Quota conditions on
10-3
lower levels of the directory structure are inherited from a higher-level tree quota.
Inheritance of quota conditions moves downward from the directory where the tree
quota is configured, so children of the directory inherit the quota usage conditions
from the parent. Tree quotas can be either simple or nested. The main difference
between simple and nested quotas is where usage is charged.
Note - The NAS Gateway supports a maximum of 64 levels of nesting, but

configuring more than four levels of nesting can negatively affect
performance.
For each quota type, you can set either default quotas or specific quotas:
• Default quotas apply the same usage conditions to every user, group, or tree quota
that uses the volume. Default quotas are helpful when you want to set the same
usage conditions for all user, group, or tree quotas in a volume.
• Specific quotas apply usage conditions that are different from the default quota’s
conditions. Specific quotas are helpful when you want to set special usage
conditions for some, but not all, user, group, or tree quotas on the volume.
Quota Interaction with Other NAS Gateway Features

File system quotas have some interdependency with other file system features on the
NAS Gateway. This section documents how the quotas are affected by the following:
• Backup and restore operations. See “File System Quotas and Backup and Restore
Operations” on page 10-3.
• ONStor Data Mirror. See “File System Quotas and Mirrors” on page 10-8.
• Snapshots and snapshot revert operations. See “File System Quotas and
Snapshots” on page 10-9.
File System Quotas and Backup and Restore Operations

File system quotas are metadata that can be backed up when the NAS Gateway’s
NDMP services run:
10-4
• During a full backup, any configured user, group, or tree quotas are backed up to
tape. During a partial backup, quotas are not backed up to tape.
• During a full restore operation, the backed up file system quotas are restorable.
During a partial restore operation, any quotas backed up are not restored.
Behavior is different if the quotas are being restored. When a restore operation occurs,
two outcomes can exist for the backed up quota information:
• Quotas on tape can overwrite any quotas configured in the live file system.
• Quotas on tape can be discarded in favor of quotas in the live file system.
Both scenarios are controlled by ONStor-specific environment variables that
determine whether quotas on tape should be restored to the live file system or not. See
“Setting ONSTOR_SUPERSEDE_QUOTAS” on page 10-4.
File system quotas do not affect the data that is restored. For example, if an enforce
tree quota allows 50 GB of file system space, and a restore operation contains 51 GB
of data, the entire restore operation completes to the live file system. Quotas disregard
data in restore operations to allow the entire data set to be restored.
The NAS Gateway’s implementation of quotas includes the following environment
variables that affect how quotas are restored from tape:
• ONSTOR_SUPERSEDE_QUOTAS, which controls whether quota information on tape is
overwritten when an NDMP restore session occurs.
• ONSTOR_IGNORE_USR_GROUP, which controls the behavior of user and group quotas
when an NDMP restore session occurs.
• ONSTOR_IGNORE_QTREE, which controls the behavior of tree quotas when an
NDMP restore session occurs.
For more information about the NAS Gateway’s implementation of NDMP, see
“Managing Backup and Restore” on page 14-1.
Setting ONSTOR_SUPERSEDE_QUOTAS
The NAS Gateway’s decision to overwrite or disregard the quota information from
tape is based on the ONStor-specific environment variable
ONSTOR_SUPERSEDE_QUOTAS that can be configured by a data management
application (DMA) that moves data in an NDMP operation. This environment variable
10-5
accepts a “yes” or “no” value. The default is “yes.” If this variable is set to “no,” the
variable affects different types of quota differently:
• If a user or group quota already exists, it is not updated with the limits and warning
information from tape.
• If a tree record already exists on the directory in the destination volume, the tree
quota is not updated with values from tape.
Table 10-4 explains the ONSTOR_SUPERSEDE_QUOTAS environment variable if it is
set to “yes.”
Table 10-4: ONSTOR_SUPERSEDE_QUOTAS Set to Yes
On Tape On Disk Action on Restore
No tree quota Tree quota Files are added to the quota

tree. The directory still
remains a tree quota.
Tree quota Empty non-tree quota Tree quota warning and

directory limit values are restored
from tape, directory
becomes a quota tree.
Tree quota Non-empty, non-tree quota Fail to set the tree quota
directory values. In this situation, the
data is restored but the
quota metadata is not. A
message is transmitted to
the DMA to indicate that
some of the contents of the
tape are not restored.
Tree quota Non-empty tree quota Tree quota warning and

directory limit values are restored
from tape.
Tree quota (simple) Tree quota (simple) Warning and limit values
are restored from tape.
10-6
Table 10-4: ONSTOR_SUPERSEDE_QUOTAS Set to Yes (Continued)
On Tape On Disk Action on Restore
Tree quota (nested) Tree quota (nested) Warning and limit values
are restored from tape. Tree
quota settings are restored
from tape.
Tree quota (simple) Tree quota (nested) Warning and limit levels are
restored from tape. A
warning message is
transmitted to the DMA to
indicate that the change
from a nested quota to a
simple quota is not
supported. The nested tree
is retained.
Tree quota (nested) Tree quota (simple) Warning and limit levels are
restored. A warning
message is transmitted to
the DMA to indicate that the
change from a simple quota
to a nested quota is not
supported. The simple tree
is retained.
Setting ONStor Ignore User or Group Quotas

The NAS Gateway’s decision to restore or disregard the specific user or group quota
information from tape is based on the ONStor-specific environment variable
ONSTOR_INGORE_USR_GRP_QUOTAS that can be configured by a DMA that moves
data in an NDMP operation.
With this environment variable, you can control how specific user and group quotas
are restored. Default user or group quotas can also be restored but only in the case of a
full restore operation of / (root directory) to either / (root directory) or a nonroot
directory.
10-7
In some circumstances, the ONSTOR_INGORE_USR_GRP_QUOTAS variable can be set

to “yes” automatically. The restore operation implicitly sets this variable to “yes”
under the following conditions:
• When performing a selective restore operation of a file or a nonroot directory
• When performing a restore operation of a partial dump (a dump of a nonroot
directory)
Table 10-5 describes the ONSTOR_IGNORE_QTREES environment variable.
Table 10-5: ONSTOR_IGNORE_USR_GRP_QUOTAS
Variable Options Description
ONSTOR_INGORE_ y or n Used in restore session. Controls

USR_GRP_QUOTAS Default: n restoration of user and group quotas. If set
to Yes, this variable causes only tree
(hierarchical) quota records to be restored.
User or group group quotas are ignored.
Restore can implicitly set this variable
when restoring dump formats that do not
support quotas. If set to No, this variable
allows user and group quotas to be
restored.
Setting ONStor Ignore Tree Quotas

The NAS Gateway’s decision to restore or disregard the tree quota information from
tape is based on an ONStor-specific environment variable that can be configured by a
data management application (DMA) that moves data in an NDMP operation. This
environment variable is called ONSTOR_INGORE_QTREES.
With this environment variable, you can control how specific tree quotas are restored.
Default tree quotas can also be restored but only in the case of a full restore of / (root
directory) to / (root directory). Default quotas are not restored in the following cases:
• Restoring a partial backup
• Restoring / to a nonroot directory
• Selectively restoring files directories
10-8
The following list shows special cases for restoring quota tree root directories, and the
resulting action in each case:
• If the tree quota’s root directory does not exist on the destination volume, tree
quota information is restored when the tree quota’s root directory is created.
• If the tree quota’s root directory exists on a destination volume as an empty
directory, the tree quota information is restored from tape to the destination
directory regardless of whether the target directory is a tree quota root directory or
not.
• If the tree quota’s root directory exists on the destination volume as a directory
with content, tree quota information is restored from tape and the directory is made
a tree quota root. In all other situations, the tree quota warning and limit values are
not restored. A message is transmitted to the DMA to indicate that the tree quota
information was not restored. Any files or directories on the directory are restored.
Table 10-6 describes the ONSTOR_IGNORE_QTREES environment variable.
Table 10-6: ONSTOR_IGNORE_QTREES
ONSTOR_IGNORE_ y or n Controls restoration of tree (hierarchical)

QTREES Default: N quotas. If this variable is set to Yes, then no
tree quota information from tape will be
restored. If it is set to No, then the tree
quota information will be restored.
Restoration of quota tree information
involves restoring only the default and limit
values for tree. Usage is not restored.
File System Quotas and Mirrors

In a typical configuration, quota configuration information is mirrored from the source
volume to the target volume. However, because the target volume is read-only, data
operations that require disk block allocations in the live file system are not mirrored to
the target. Therefore, quotas are not be enforced or tracked on the target.
10-9
Because quota information is present on both the source and target volumes, if the
target volume is promoted, it already owns a copy of the quota conditions that were
active the last time the mirror occurred.
For more information about ONStor Data Mirror, see “Working with ONStor Data
Mirror” on page 13-1.
File System Quotas and Snapshots

A snapshot revert can affect the NAS Gateway’s quota configuration. Performing a
snapshot revert to recreate data from snapshots affects all types of quota—user, group,
and tree. If you perform a snapshot revert, and the snapshot has different quota
conditions, the conditions from the snapshot are put into effect.
Using snapshots to rebuild part or all of your file system can change configured quota
conditions if the quota conditions on the snapshot are different than the quota
conditions in the file system.
For more information about snapshots, see “Managing Snapshots” on page 9-1.
Configuring Default Quotas

Quotas are assigned to a volume, so you need to be in the context of the virtual server
that owns the volume on which to configure the quotas to be able to define the quotas.
The virtual server must be in enabled state, and the volume must be online and in read-
write mode.
Multiple tree quotas can be assigned to a single directory in the directory path, but
only if the directory is part of a nested tree quota. Otherwise, the directory can be part
of only one tree quota.
To Configure Default User Quotas
filesystem quota user config VOLNAME
[-e {enforce|trackonly}] [-l LIMIT] [-L {yes|no}]
[-w WARNING] [-W {yes|no}] [-d]
10-10
To Configure Default Group Quotas

filesystem quota group config VOLNAME
[-e {enforce|trackonly}] [-l LIMIT] [-L {yes]|no}]
[-w WARNING] [-W {yes|no}]
To Configure Default Tree Quotas

filesystem quota tree config VOLNAME
[-e {enforce|trackonly}] [-l LIMIT] [-L {yes|no]}
[-w WARNING] [-W {yes|no}]
Options and
Description
Arguments
VOLNAME Specifies the name of the volume where the quota will be
configured.
-e An optional argument that causes the NAS Gateway to track and

enforce|trackonly enforce usage on the volume, or to only track usage on the volume.
• -e enforce tracks and enforces usage on the volume. With this
argument, allocation is prevented if a usage threshold is met or
exceeded. trackonly is the default.
• -e trackonly tracks usage, but allocation can continue even if a
usage threshold is exceeded.
-l LIMIT An optional argument that specifies the absolute limit (in MiBs) for
the quota. A MiB is 1048576 bytes. You can set an infinite limit by
entering the keyword -l followed by a blank space then the word
“infinite.” By default, the limit is “infinite.”
• This argument interacts with the -e enforce argument to
indicate the threshold at which quota enforcement occurs. If
this threshold is exceeded, then an allocation fails.
• This argument also interacts with the -L yes argument to
indicate the threshold at which usage events are recorded
when the log limit has been exceeded.
10-11
Options and
Description
Arguments
-L yes|no An optional argument that specifies that usage events should be

logged for events that exceed the value specified for the -l LIMIT
argument.
• If the -L yes argument is specified, and the value specified for -
l MiB is exceeded, the event is written to the quota log the first
time that usage exceeds the limit.
• If the -L no argument is specified, usage events are not logged
if they exceed the value specified for the -l MiB argument. The
default is -L no.
Note - Events are logged once per day regardless of how many times the
log limit has been exceeded in a 24-hour period. This argument allows the
admin to know that usage is getting high before the hard limit is reached
and user requests might fail. If you do not specify this argument, then the
default is -L no, and not logging occurs.
-w WARNING An optional argument that specifies the soft limit (in MiBs) for the
quota. To specify this argument, enter the keyword -w and the
value. You can set an infinite limit by entering the keyword -w
followed by a blank space then the word “infinite.”
This argument works with the -W yes argument. If the user or group
exceeds the -w WARNING usage limit, an event is written to the
quota log if the -W yes argument is configured. If the log limit has
been exceeded, the event is written to the log the first time that
usage exceeds the limit.
Note - Events are logged once per day regardless of how many times the
log limit has been exceeded in a 24-hour period. If you specify no limit,
the default is “infinite.”
10-12
Options and
Description
Arguments
-W yes|no An optional argument that specifies that usage events should be

logged if the soft limit is exceeded. This argument governs whether
an event is written to the quota log when usage exceeds the value
specified in -w WARNING:
• If you specify -W yes, logging occurs when the warning limit
threshold is met or exceeded. If the -W yes argument is
configured, you can disable logging by using the -W no
argument.
• If you specify -W no, logging does not occur if the warning limit
threshold is met or exceeded. The default is -W no.
-d Specify this option to generate a default configuration of the quota.

The default configuration is as follows:
Enabled: yes
Enforcement: enforced
Limit: infinite
Log Limit: yes
Warn: infinite
Log Warn: yes
Setting Specific Quotas

You can set specific quotas for user, group and tree quotas. If a default quota and a
specific quota are configured on the same volume, the specific quota is applied.
Specific quotas inherit the following quota parameters from the default quota
configured on a volume:
• Type (either enforce or track-only)
• Log warnings, or do not log warnings
• Log when limits are exceeded, or do not log when limits are exceeded
Specific Tree Quotas
Specific tree quotas support tracking or enforcing usage conditions on a specific part
of the directory structure (for example, a directory and its children). When you
configure a tree quota, its conditions are inherited by child directories. If a quota
10-13
definition is inherited by the children directories, the quota is applied to all children in
the directory tree. If the specific tree quota is nested, usage of a directory is recursively
charged up the tree to all quota tree roots until the closest simple quota is encountered
(or the root directory), whichever is first. If a directory is not a quota tree directory, it
does not get charged for usage.
The directory you specify must always be in relation to the root of the volume, so you
need to include the root slash ( / ) when you specify the directory path. You can
configure specific tree quotas as either simple or nested, which changes how the disk
allocation and usage is charged.
For specific tree quotas, you can specify the directory paths in either Windows or
UNIX formats. Because the NAS Gateway is multiprotocol, it reads the path correctly
and applies the quota. The directory path where the quota is being applied must
already exist.
Specific Tree Quotas Removal
The filesystem quota tree remove command removes a directory which is the
root of tree quota. All the directories and files under the quota tree will be removed
recursively.
To Remove Specific Tree Quotas
filesystem quota tree remove <VOL> <PATH>
This command does not wait for the actual file removals, but all of them will be taken
out of the namespace and no further access to them allowed. If the path is not a
directory or quota tree root, this operation will fail.
Specific User and Group Quotas
Specific user or group quotas enable you to set specific usage conditions for individual
users or groups that access the volume. These usage conditions for specific user or
group quotas are applied along with the default user or group quotas on the volume.
When multiple specific quotas are configured for a user or group, the NAS Gateway
analyzes all of them, and applies the strictest to offer the most control over usage.
Specific user or group quotas are optional.
10-14
When setting specific quota, you can specify the name of the user or group to which
the quota applies. You can specify a user ID (UID) for a user quota, a group ID (GID)
for group quota, an NIS user or group name, or a Windows user or group name. The
following is the correct syntax for specifying names and IDs with specific quotas:
• 99@onstor (NIS or LDAP UID format)
• user@onstor (NIS or LDAP user name format)
• onstor\user (Windows user name format)
User and group names must be valid and known to the Windows or NIS domain
controllers. Because the NAS Gateway is multiprotocol, CIFS and NFS users and
groups can be seamlessly mapped between domain types through ID Mapping. For
more information about ID Mapping, see “Managing ID Mappings” on page 7-68.
Note - Problems with accessing the Windows or NIS domains can prevent the
NAS Gateway from displaying per-user quota information.
To Set Specific User Quotas

filesystem quota user set VOLNAME USERNAME
[-l LIMIT] [-w WARNING] [-d]
To Set Specific Group Quotas

filesystem quota group set VOLNAME GROUPNAME
[-l LIMIT] [-w WARNING [-d]
10-15
To Set Specific Tree Quotas

filesystem quota tree set VOLNAME PATHNAME
[-l LIMIT] [-w WARNING] [-n {yes|no}] [-d]
Options and
Description
Arguments
VOLNAME Specifies the volume where the quota is configured.
USERNAME Specifies the name of the user to which you are assigning the quota
usage conditions. User names can be either Windows, LDAP, or NIS
formats, and they must match the user name that is configured on the
NIS or LDAP server or Windows domain controller.
Note - You cannot assign specific user quotas to the root user, for example
UID 0.
GROUPNAME Specifies the name of the group to which you are assigning the quota.
Group names can be either Windows, NIS, LDAP formats, and they
must match the group name that is configured on the NIS or LDAP
server or Windows domain controller.
PATHNAME Specifies the first object in the directory path where the tree quota is
configured. Specify the directory path in relation to the root of the
volume, for example /dir1. Children of this object inherit the quota
conditions of the parent.
10-16
Options and
Description
Arguments
-l LIMIT An optional argument that specifies the absolute limit (in MiBs) for the
specific quota. The default is whatever LIMIT value is configured for
the default quota, or “infinite” if no value is specified for default and
specific quotas. You can set an infinite limit by entering the argument
-l followed by a blank space then the word “infinite.”
• This argument interacts with the enforce argument to indicate the
threshold at which quota enforcement occurs. If this threshold is
exceeded, then an allocation fails.
• This argument also interacts with the -L yes argument to indicate
a threshold when usage events are recorded if the log limit has
been exceeded.
Note - It is possible to configure a 0 MiB quota. Although unusual, it is a

valid configuration in some cases.
-w WARNING An optional argument that specifies the soft limit (in MiBs) for the
specific quota. To specify this argument, enter the argument -w
followed by a blank space then the value. You can set an infinite limit
by entering the argument -w followed by a blank space then the word
“infinite.” If you specify no warn MiB value, the default is “infinite.”
This argument works with the -L yes argument to specify when an
event is written to the quota log.
-d An optional argument that causes the specific quota to use the values
from the default quota on the volume. This option is useful for
resetting a specific quota’s usage conditions to the same usage
conditions that are assigned to the default quota quota. This option
cannot be combined with the -l LIMIT or -w WARNING arguments.
Note - The -d argument does not set all arguments in the filesystem
quota user config command to their default values. It is used to set a
specific quota to the default quota’s values.
10-17
Enabling or Disabling Quotas

You can simultaneously enable or disable all quotas of any or all types on a volume.
For example, you could enable all user quotas on vol1 at the same time. Or, by using a
comma-separated list, you could enable all user and group quotas on vol1 at the same
time, or all user, group, and tree quotas on vol1 at the same time.
Note - Power cycles and reboots do not change quota state. The quota will be
in the same operational state that it was in before the power cycle or reboot
occurred.
To Enable or Disable Quotas That Contains the Volume Where the Quota
Is Configured
filesystem quota enable|disable VOLNAME
{user,group,tree}
Options and
Description
Arguments
VOLNAME Specifies the name of the volume where the quota is configured.
user,group,tree Specifies the type of quota you are enabling or disabling. You can
specify one or more quotas. If you specify multiple quotas,
separate each quota type with a comma.
Displaying Quotas
When you display quotas, the information shown varies depending on the following
conditions:
• If the quota feature is enabled and the quota configuration contains no specific user
quotas, the output of this command shows the default quotas assigned to everyone
on the volume.
• If quotas are enabled and the quota configuration contains one or more specific
user, group, or tree quotas, the output of this command shows the specific quota
10-18
configuration for the users, groups, or directory trees. If no limit or warning has
been configured, the output of this command shows infinite warning and limit
levels.
• If the quota feature is disabled, the output shows “unknown (disabled)” to indicate
that usage cannot currently be measured because quota is disabled.
• If the quota rebuild phase is in progress, the output of this command shows
“unknown (rebuilding)” to indicate that usage cannot currently be measured
because quota is rebuilding.
Note - In cases where a CIFS and an NFS identity exist, the NAS Gateway
gives preference to the CIFS identity and the NFS user’s usage is charged to
the CIFS identity.
To Display User Quota Information

filesystem quota user show VOLNAME [USERNAME|-all]
[-P PAGENUMBER [-S PAGESIZE]]
To Display Group Quota Information

filesystem quota group show VOLNAME [GROUPNAME|-
all] [-P PAGENUMBER [-S PAGESIZE]]
To Display Tree Quota Information

filesystem quota tree show VOLNAME [PATHNAME|-all]
[-P PAGENUMBER [-S PAGESIZE]]
10-19
Note - A quota tree always owns its root directory, which is 8K in size, and
usage is always rounded up. Therefore, if you have configured a tree quota that
has no data contents, the output of filesystem quota tree show command
can show 1 MiB of usage because of the root directory.
Options and
Description
Arguments
VOLNAME Specifies the volume where the quota is configured.
USERNAME| An optional argument for looking up quotas based on user name.

To lookup quotas by user name.The names need to match the user name
that is configured on the NIS or Windows domain controller.
GROUPNAM An optional argument that specifies the name of the group quota to be
E displayed. The names need to match the group names that are
configured on the NIS or Windows domain controller.
PATHNAME An optional argument that specifies the path for which you are displaying
the tree quota. Paths can be specified in either Windows or NIS format
and can have a maximum length of 1024 characters.
Note - Note - You use either \ or / in this command. The

NAS Gateway always represents the directory structure as \.
-all An optional argument for looking up all user or group quotas.

To lookup all user or group quotas. If the quotas are enabled when you
run this command, the NAS Gateway displays the quota records and the
usage information. If you do not specify the -all keyword, only the
default quotas are displayed.
Configuring Quotas
This section documents the step-by-step procedures for configuring user, group, and
tree quotas on the NAS Gateway.
Before configuring quotas, decide the following:
10-20
• Whether are configuring default or specific quotas

• Whether you are configuring track-only or enforce quotas
To Configure Quotas
Step 1: Make sure that you have a virtual server configured and enabled.
For more information about configuring virtual servers, see
“Working with Virtual Servers” on page 3-1.
Step 2: From the virtual servers’ context, verify that the volume where you
want to configure quotas is enabled and online, by running the
volume show command.
Step 3: To configure default user, group, or tree quotas in track-only or

track enforce mode, run the following commands:
filesystem quota user config
filesystem quota group config
filesystem quota tree config
Example for a track-only user quota:
filesystem quota user config vol1 -e trackonly -l 88
-L yes -w 77 -W yes
Example for a track and enforce group quota:
filesystem quota group config vol1 -e enforce -l 88
-L yes -w 77 -W yes
Example for a track-only tree quota:
filesystem quota tree config vol1 -e trackonly -l 88
-L yes -w 77 -W yes
Step 4: To configure specific user, group, or tree quotas, run the following
commands:
filesystem quota user set
filesystem quota group set
filesystem quota tree set
Example for a specific user quota:
10-21
filesystem quota user set vol1 user1@onstor -l 150 w

140 -W yes
Example for a specific group quota:
filesystem quota group set vol1 pubs@onstor
-l 150 -w 140 -L yes -W yes
Example for a simple tree quota:
filesystem quota tree set vol1 /dir1/dir2 -l 88
-w 77
To create a nested tree quota, run the following command:
filesystem quota tree set vol1 /dir1/dir2 -l 88
-w 77 -n yes
Step 5: Enable the quota by running the following command:
filesystem quota enable|disable VOLNAME
{user,group,tree}
Example for enabling user quota:
filesystem quota enable vol1 user
Example for enabling group quota:
filesystem quota enable vol1 group
Example for enabling tree quota:
filesystem quota enable vol1 tree
Note - Each time you run the filesystem quota enable command, the NAS
Gateway rebuilds the user quota definition on the volume. To save time
configure all user quotas, and run the filesystem quota enable command
once to enable all user quotas as a batch instead of enabling them individually.
Enabling configured quotas can affect performance. If you choose not to

configure quotas, no group disk space usage limits are tracked or enforced.
10-22
Updating ID Mapping Rules

The NAS Gateway supports multiple protocols and therefore can serve NFS and CIFS
clients. The NAS Gateway uses ID maps to translate user and group names between
CIFS and NFS domains. For more information about ID Mapping, see “Managing ID
Mappings” on page 7-68.
You can alert the NAS Gateway to changes in the ID map. The NAS Gateway then
reconstructs the ID map with new quota-related information, and relevant entries are
updated to use the most recent version of the ID map.
To Alert the NAS Gateway to Changes in the ID Map
idmap notify change {user,group}
user,group specifies the type of quota you are enabling on the
volume. You can specify one or more quota types. If you specify
multiple quota types, separate each quota type with a comma.
Note - When you run the idmap notify change command, the NAS Gateway
preforms a quota rebuild.
10-23
Working With the Quota Log

The NAS Gateway automatically tracks the use of storage space and its configuration
and writes usage events to the quota log. The quota log stores this information for later
retrieval and analysis.
Quota log messages contain information about specific usage events that meet or
exceed a warning or limit threshold. The quota log receives messages when a quota is
configured with the following parameters:
• A noninfinite limit or warning value
• -W (log warning) or -L (log limit), or both
Events are logged once per day regardless of how many times a warning or limit
threshold is exceeded in a 24-hour period. The log shows how many times the
particular message has been received in the 24-hour period. Quota activity can be
posted to the NAS Gateway’s quota log or sent to an external syslog host.
Displaying the Quota Log

You can display locally stored log messages by running the filesystem quota log
show command. Quota log messages contain information about specific usage events
that meet or exceed a warning or limit threshold.
To View the Quota Log
• Run the following command from the NAS Gateway context:
filesystem quota log show [NUMLINES]
NUMLINES is an optional argument that specifies the number of
lines you want to display. The number of lines you specify are
displayed in most-recent to least-recent order. NUMLINES can be
a 32-bit number. By default, the entire quota log is displayed.
Clearing the Quota Log

Clearing the quota log is immediate and removes all entries from the quota log. If the
quota is enabled after clearing the log, new entries are posted to the quota log
whenever a usage event causes a message to be posted.
10-24
To Clear the Quota Log

• Run the following command from the NAS Gateway context:
filesystem quota log clear
Specifying the Syslogd Host for Sending Quota Log Messages

You can forward quota log messages to syslog daemons running on a specified host.
• If the host address is set to 0.0.0.0, all quota log messages are forwarded to the
local syslogd daemon.
• If the host address is set to other than 0.0.0.0, all quota log messages are forwarded
to the specified host using the currently configured facility code.
If you are sending the quota log output to a remote syslog host, make sure that the
remote syslog host is configured to receive syslog messages from other hosts because
some implementations, by default, are configured not to receive syslog messages
forwarded by other hosts. Remote logging is disabled by default, so all messages are
sent to the local host.
To Specify the Syslogd Host for Sending Quota Log Messages
filesystem quota log host IPADDR
IPADDR specifies the IP address of a remote host that runs
syslogd and can receive quota log messages from this NAS
Gateway.
Specifying the Facility Code To Be Used by the Quota Log

The quota log facility interfaces with the standard syslogd capability to provide
logging of system information at the desired level of priority. Using this facility,
system messages can be locally saved, forwarded to a remote host, or displayed on the
system console. Quota log messages use the same user-level facility codes as the
standard UNIX syslog program. The facility codes are local0, local1, local2, local3,
local4, local5, local6, and local7. These facility levels can be used to filter messages
10-25
from different NAS Gateways at a common syslog host. Table 10-7 lists the default
facility values for the different log files that can be exported off of the NAS Gateway.
Table 10-7: Log Files and their Default Facility Levels
Log File Default Facility Level
Elog local0
Quota log local6
Virus scan log local7
To Specify the Facility Code To Be Used By the Quota Log

filesystem quota log facility
{local0|local1|local2|local3|local4|local5|local6|
local7}
local0|local1|local2|local3|local4|local5|local6|
local7 is a list of the facility codes that you can use for quota log
messages. By default, the local facility level is local6. Make sure
you do not use the same facility level as another log, or it can be
difficult to determine which log is being reported.
Displaying the Quota Log Configuration

You can display the current quota log configuration to obtain the following
information about the quota log:
• The log facility used for the quota log
• The remote host used for the quota log
To View the Current Quota Log Configuration
filesystem quota log show config
10-26
Chapter 11: Monitoring the NAS
Gateway
• “Monitoring with the NAS Gateway” on page 11-2
• “Supported RFCs and MIBs” on page 11-3
• “Managing SNMP” on page 11-4
• “Adding an SNMP Community” on page 11-4
• “Deleting an SNMP Community” on page 11-4
• “Adding an SNMP Trap” on page 11-5
• “Deleting an SNMP Trap” on page 11-7
• “Adding a Trap Specification List” on page 11-7
• “Deleting an SNMP Trap Specification List” on page 11-8
• “Showing an SNMP Configuration” on page 11-8
• “Deleting an SNMP Configuration” on page 11-9
• “Setting the System Contact and System Location” on page 11-9
11-2
Monitoring with the NAS Gateway

The ONStor NAS Gateway supports the simple network management protocol
(SNMP), version 2. The ONStor implementation of SNMP operates at the cluster or
the virtual server level. Therefore, SNMP functions are applied to either the cluster or
virtual server.
Through a configured community string, management stations that communicate with
the cluster or virtual server are allowed to access the virtual server if packets
transmitted from the network device to the virtual server contain the community
string. The virtual server supports both read-only and read-write community strings.
However, you can add, change, or delete communities on each NAS Gateway through
the snmp commands documented later in this document. SNMP configuration changes
made from one NAS Gateway are now applied to all NAS Gateways in the cluster. The
maximum of 10 read-only and 10 read-write community strings applies to the cluster
entity and each individual virtual server.
You can configure one or more SNMP agents. You can set the community string so
that it can be polled by third-party management software. The NAS Gateway supports
the following statistics information:
• 10/100 Ethernet interface statistics
• Gigabit Ethernet interface statistics
• Volume Manager statistics
• Fibre Channel (FC) port statistics
• NFS protocol statistics
• CIFS protocol statistics
• Cluster and Filer Group statistics
• Virtual Server statistics
• Environmental statistics
• Hardware specific statistics
• Storage statistics
11-3
Supported RFCs and MIBs

The NAS Gateway supports some standard MIBs (Management Information Base). In
this version of the software, the NAS Gateway supports RFC 1213, also known as
MIB-II for its internal SNMP agent.
The NAS Gateway also supports the following proprietary MIBs:
• ONStor-NASGW-MIB
• ONStor-SYSSTAT-MIB
• ONStor-EVM-MIB
• ONStor-CIFS-MIB
• ONStor-NFS-MIB
11-4
Managing SNMP
The NAS Gateway uses SNMP commands to configure the SNMP agent on the NAS
Gateway.
Adding an SNMP Community

When you add an SNMP community, the hosts that are configured with that string can
view information on the NAS Gateway. When the string is configured, it is added to
the NAS Gateway’s SNMP agent.
Note - The community string that you configure on the NAS Gateway’s SNMP
agent must also be configured on the SNMP management console. Otherwise,
the two devices will not be able to communicate because they are in different
community strings.
To Add a Community to the NAS Gateway

snmp add cluster|VIRTUALSERVER community COMMUNITY
[-w]
COMMUNITY is the name of the community string that you are
configuring on the NAS Gateway. Enter an alphanumeric
character string of up to 31 printable non-white space characters.
-w option is specified to indicate that it is read-write. if you do not
specify this option, it will be presumed to be read-only. A
maximum of 10 read-only and 10 read-write community strings
are supported.
Deleting an SNMP Community

When you delete a community string from the SNMP agent configuration file, it can
no longer be used to contact SNMP agent on the filer.
11-5
To Delete a Community String

snmp delete cluster|VIRTUALSERVER COMMUNITY
COMMUNITY is the community that you are deleting from the
NAS Gateway. Enter the name of the community string that you
want to delete.
Adding an SNMP Trap

You can add an SNMP trap to include management of trap-related configuration
parameters. When a trap is not specified, the type of traps that may be sent to the trap
host recipient is limited to generic traps and elog traps with severity equal to or greater
than the severity threshold level.
To Add an SNMP Trap Host
snmp add cluster|VIRTUALSERVER trap HOST[:PORT]
[-s SEVERITY] [-c COMMUNITY] [-t TRAPSPEC]
HOST is the trap recipient name that can be up to 31 characters in
size, printable non-white space or IP address.
PORT is the trap recipient UDP port. The default is162. You can
enter any non-zero 16-bit port number, 1 to 0xFFFF.
SEVERITY is the elog event severity threshold level. The default is
warning.
COMMUNITY is the trap community string. The default is public.
TRAPSPEC specifies the enterprise trap specification list name.
The Specific Event traps are uniquely defined based on the event type. These specific
Event traps are listed below with accompanying object parameters:
Trap Object
Trap Name Trap Group/Number
Paramenters
11-6
Cold Start gen/1
Power Supply Ok (number=1,2) env/2
Power Supply Error (number=1,2) env/3
Elog String(Format: elog/1

slot:cpu:appName:severity:
eventDesc)
Fan Ok (number=1,2 description) env/4
Fan Error (number=1,2 description) env/5
Temperature Ok (tempValue, desc) - Temp env/6

reduced below max
threshold
Temperature Error (tempValue, desc) - Temp env/7

exceeds max threshold
Node Up (nodeName) node/8
Node Down (nodeName) node/9
Port Up (portName=sp2.0-sp2.1, port/10

fp1.0-fp.1.3)
Port Down (portName=sp2.0-sp2.1, port/11

fp1.0-fp.1.3)
vsvr IP Interface Added (vsvrName) vsvr/12
vsvr IP Interface Removed (vsvrName) vsvr/13
Virtual Server Fail Over (vsvrName) vsvr/14
Virtual Server Disabled (vsvrName) vsvr/15
Virtual Server Up (vsvrName) vsvr/16
Virtual Server Down (vsvrName) vsvr/17
Volume Created (volName) vol/18
Volume Deleted (volName) vol/19
Volume Grow (volName) vol/20
11-7
Volume SoftQuota (volName) vol/21
Volume Full (volName) vol/22
Volume Modify (volName) vol/23
Volume Broken (volName) vol/24
Volume Takeover (volName) vol/27
Volume Online (volName) vol/29
Volume Offline (volName) vol/30
Note - A maximum of 10 trap recipients and 10 trap specs are supported.
Deleting an SNMP Trap

Deletes a trap host recipient from the SNMP configuration of the cluster entity or a
virtual server. Once a trap host is deleted, the configuration change becomes effective
immediately.
To Delete an SNMP Trap
snmp delete cluster|VIRTUALSERVER trap HOST[:PORT]
HOST is the IP address or trap recipient name that can be up to 31
characters in size, printable non-white space.
PORT is the trap recipient UDP port. The default is 162. You can
enter any non-zero 16-bit port number, 1 to 0xFFFF.
Adding a Trap Specification List

Adds a trap specification to the SNMP configuration of the cluster entity or a virtual
server. The trap specification defines specific traps of interest by type that may be sent
to a trap recipient. It consists of a list of trap numbers or range of trap numbers. The
traps may also be referenced by keywords that map to a group of traps related by
11-8
function. When a trap spec by the same name is already defined, the new trap spec
entries are appended to the existing list.
To Add a Trap Specification List
snmp add cluster|VIRTUALSERVER trapspec TRAPSPEC
TSLIST
TSLIST is the trap specification list. It is specified in a comma-
delimited list of trap types where each trap list entry is a keyword,
trap group, or trap number(s) as follows:
• gen includes generic traps (Cold-Start, Warm-Start,
AuthenErr).
• elog includes elog event generated enterprise traps with
severity at or above severity threshold.
Deleting an SNMP Trap Specification List

Deletes a trap specification or specified entries within a trap specification from the
SNMP configuration for the cluster or a specific virtual server.
To Delete an SNMP Trap Specification List
snmp delete cluster|VIRTUALSERVER trapspec TRAPSPEC
[TSLIST]
TSLIST is the trap specification list. It is specified in a comma-
delimited list of trap types where each trap list entry is a keyword,
trap group, or trap number(s).
Showing an SNMP Configuration

The snmp show command option is used to distinguish between read-only and read-
write community strings.
11-9
To Display the SNMP Configuration

snmp show cluster|VIRTUALSERVER
Deleting an SNMP Configuration

The snmp command includes a delete all option to clear out the entire SNMP
configuration of a virtual server or for the cluster entity.
To Delete the SNMP Configuration
snmp delete cluster|VIRTUALSERVER all
Setting the System Contact and System Location

The snmp modify command can be used to set syscontact and syslocation values:
To Set the SNMP System Contact and System Location
snmp modify cluster|VIRTUALSERVER
syscontact|syslocation OBJVALUE
OBJVALUE is a string of 1 to 63 characters.
11-10
Chapter 12: Autosupport and Event
Monitoring
• “Understanding Autosupport” on page 12-2
• “Configuring Autosupport” on page 12-4
• “Event Monitoring and Reporting Services” on page 12-10
12-2
Understanding Autosupport
The ONStor NAS Gateway’s autosupport feature enables real time e-mail alerts for
system events. The autosupport feature tracks a specific set of events that the NAS
Gateway reports to the administrator. The tracked events can be:
• System-level, such as node resets.
• Element-level, such as card resets.
• Component-level, such as CPU resets.
For a full list of the events that the NAS Gateway tracks through autosupport, see
“Displaying and Clearing Autosupport Statistics” on page 12-9.
Use the autosupport feature to specify e-mail aliases for receiving system events.
When you specify the e-mail aliases, the NAS Gateway can notify an administrator
through e-mail when system events occur that might present a problem.
For autosupport to function, the management virtual server must have the DNS
resolver configured. For more information about the DNS resolver, see “Configuring
DNS Name Resolution for a Virtual Server” on page 3-46.
Understanding Autosupport and Event Logs

Event logs (elog) and autosupport are similar but not the same. These features
complement each other. Events might be written to the log and also generate
autosupport e-mails, but not everything that is logged will also generate e-mails.
Table 12-8 lists the differences between the Elog and autosupport features.
Table 12-8: Differences Between Elog and Autosupport
Elog Autosupport
Forwards elog output to an Forwards system events to one or more e-mail

administrator-configured external addresses.
syslog daemon.
Posts an event to an Elog file on the Forwards an e-mail of autosupport events and a
SSC, or displays the Elog message snapshot of the system configuration to the
output on the management console. administrator in real time.
12-3
Table 12-8: Differences Between Elog and Autosupport (Continued)
Elog Autosupport
Summarizes system events that are Can summarize the system configuration at the
equal to or more severe than an time of the system event in addition to the
administrator configured severity level. system event.
For more information about the NAS Gateway’s Elog facility, see “Setting Elog
Message Levels” on page 16-10.
Understanding Autosupport Message Types

Autosupport tracks system events in any of the following ways:
• A notification, which is a detailed message that includes a summary of the NAS
Gateway’s configuration at the time of the event as well as the summary of the
system event. For details see “Creating E-mails for Autosupport Notifications” on
page 12-4.
• A note, which is a brief message that includes only a summary of the system event.
Autosupport notes do not contain the NAS Gateway’s configuration at the time the
event occurred. For details see “Creating E-mails for Autosupport Notes” on
page 12-5.
12-4
Configuring Autosupport
The following sections document how to configure autosupport.
Creating E-mails for Autosupport Notifications

This command lets you specify an email address to which a detailed autosupport note
will be sent either on demand or upon the occurrence of specific events.
To Create E-mail Autosupport Notifications
autosupport email to EMAIL
EMAIL is the address of an administrator or ONStor support
contact that is managing the NAS Gateway. Enter a valid e-mail
address of up to 256 characters, including the e-mail suffix. The
NAS Gateway supports all common domain suffixes, such as
.com, .org, .gov, and .edu.
Note - The e-mail address does not have to exist prior to entering it as part of
the autosupport feature on the NAS Gateway.
You can send notifications and notes sent to the same or a different e-mail
address.
Configuring the Address From Which Autosupport E-mail Is

Sent
You can now configure the address from which you are sending autosupport e-mail.
To Configure the Autosupport From E-mail Address
autosupport email from EMAIL
EMAIL is the e-mail address from which all autosupport e-mail is
being sent on generation of important events and on demand. You
12-5
can enter any e-mail address.
Note - You can specify only one e-mail ID in the EMAIL field.
If you don’t configure the e-mail address, it defaults to the NAS Gateway node name.
Creating E-mails for Autosupport Notes

This command lets you specify an email address to which a brief autosupport note will
be sent either on demand or upon occurrence of specific events.
To Designate the E-mail Recipient for Autosupport Notes
autosupport email noteto EMAIL
EMAIL is the address of an administrator or ONStor support
contact that is managing the NAS Gateway. Enter a valid e-mail
address of up to 256 characters, including the e-mail suffix. The
NAS Gateway supports all common domain suffixes, such as
.com, .org, .gov, and .edu.
Note - The e-mail address does not have to exist prior to entering it as part of
the autosupport feature on the NAS Gateway.
You can send notifications and notes sent to the same or a different e-mail
address.
Specifying the SMTP Server to Receive Autosupport E-mails

You can now configure the simple mail transfer protocol (SMTP) server to which to
direct autosupport e-mails by specifying the IP address of the SMTP server.
12-6
To Configure the SMTP Server for Autosupport Email

autosupport email server SERVER
SERVER is the IP address of the SMTP server to which to route
autosupport e-mail. To specify the default IP address use 0.0.0.0.
The default mail server is automatically determined using DNS MX records, so run
this command only when you want to override the default SMTP server.
Setting an Autosupport Schedule

You can schedule autosupport reports to occur at regular intervals. By default all
parameters except minutes in the autosupport schedule are configured with an asterisk
(*) which indicates that the autosupport feature report can occur at all times in the
range.
Note - By default, the autosupport schedule’s minutes parameter is set to 0 to

disable autosupport reports every minute. The smallest default autosupport
schedule is hourly.
12-7
To Configure an Autosupport Schedule

autosupport schedule [-m MINUTE] [-h HOUR]
[-d DATE] [-M MONTH] [-D DAY]
Options and
Description
Arguments
-m MINUTE Specifies the minutes of the hour at which to generate the

system report. Use a numeric value between 0 and 59. For
example, if you set 30, the system report will be generated on
the half hour of whichever hour you specify. You can enter
multiple values for this argument by specifying a comma-
separated list of values. By default, this parameters is set to
zero (0), which disables the scheduling of autosupport
messages every minute.
-h HOUR Specifies the hour at which to generate the system report. Use a
numeric value between 0 and 23. 0 is midnight, and 23 is 11 pm.
You can use the -m MINUTE argument to specify the
generation of the system report at a time other than the top of
the hour. You can enter multiple values for this argument by
specifying a comma-separated list of values.
-d DATE Specifies the date on which you want the system report
generated. Enter one of the following:
• The numerical date of a particular day in the month. For
example, generate a system report on the first day of each
month, enter 1. Also, you can enter a comma-separated list
of dates.
• A specific date. For example, to generate a system report
on the September 27, 2003, specify the date as 092703.
Note - Do not separate the numbers with any special characters.
12-8
Options and
Description
Arguments
-M MONTH Specifies the month of the year at which to generate a system

report. Use a numeric value between 1 and 12. For example, if
you set 6, the system report is generated in the month of June.
You can enter multiple values for this argument by specifying a
comma-separated list of values.
-D DAY Specifies the day of the week at which to generate a system

report. Use a numeric value between 1 and 7. 1 is Sunday, and
7 is Saturday. You can enter multiple values for this argument by
specifying a comma-separated list of values.
Generating Autosupport Reports

Autosupport reports contain the same content as autosupport notifications, but the
information can be generated at any time instead of scheduled intervals. The
autosupport report is forwarded to the recipients in the noteto and notification email
alias fields.
To Generate an Autosupport Report
autosupport generate report
Enabling or Disabling the Autosupport Feature

If you disable autosupport, the NAS Gateway retains all the configured autosupport
parameters until you re-enable the feature. Autosupport is disabled by default.
To Set the Operational State of the Autosupport Feature
autosupport state {disable|enable}
disable|enable specifies the state of autosupport that you are
setting.
12-9
Displaying the Autosupport Configuration

The NAS Gateway stores the configured autosupport parameters in memory as the
Autosupport Configuration List. You can view the autosupport configuration on the
local node only.
To Display the Autosupport Configuration
autosupport show config
Displaying and Clearing Autosupport Statistics

The NAS Gateway tracks performance and operation statistics for system events. The
following event are listed in the Autosupport Statistics Summary:
• Node failures or resets
• Card failures or resets
• CPU failures or resets
• Volume failures or volume space violations
• Core dump events
The statistics are gathered in real time whenever the system event is forwarded to the
administrator in a notification or a note. The statistics are tracked in runtime, so if the
NAS Gateway is reset, the statistics reset to zero and begin incrementing again
whenever a system event occurs.
To Display the Autosupport Statistics Summary
autosupport show statistics
To Clear the Autosupport Statistics Summary
autosupport clear statistics
12-10
Event Monitoring and Reporting Services

The NAS Gateway supports event monitoring and reporting services (EMRS). This
feature enables the NAS Gateway to securely transmit event logs (elogs),
configuration information, and performance statistics through HTTPS to a secure
server on site at ONStor. EMRS is enabled by default.
EMRS uses SSL to transmit NAS Gateway information, including the following:
• System information, such as NTP server information, system date, time, and
timezone stamps, system chassis configuration, and software versions
• Cluster and virtual server information, such as cluster configuration, the number
and names of virtual servers in the cluster, cluster and virtual server states, and
information about each virtual server in the cluster
• File system information, such as data and metadata counters, snapshots, CIFS hash
statistics, and NFS hash statistics
• Storage information, such as SCSI level information, Fibre Channel I/O
information, tape and RAID devices attached to the NAS Gateway, and storage
port state information
• Network information, such as route and interface table information, file processing
port state and configuration information, and domain information
Note - No user data is transmitted to ONStor.
EMRS facilitates diagnosing and troubleshooting the NAS Gateway and provides the
following benefits:
• Faster resolution of issues
• Automatic transmittal of problems to ONStor
• Facilitated analysis of non-optimal NAS Gateway configurations, which can
prevent issues that might arise from a misconfigured NAS Gateway
12-11
• Enhanced communication of performance histories, uptime, and MTBF numbers,

which allow ONStor continued improvements in the NAS Gateway products and
services
EMRS Upload Methods

EMRS can upload information to the secure ONStor server using any of the methods
listed in Table 12-9.
Table 12-9: EMRS Upload Methods
Method Description
Nightly Sends a day’s worth of system configuration information and

statistics to the ONStor secure server every night at midnight.
Admin-initiated Sends the output of the system get commands to the ONStor
secure server. For details about these commands, see “Managing
NAS Gateway System Health” on page 16-19.
Note - Admin-initiated EMRS requires a Customer Support case number.

If you don’t have a case number, you need to open a case.
Event-initiated When selected system events occur, the NAS Gateway transmits
information about those events to the ONStor secure server. CPU
reboot events are not currently a trigger for EMRS to send
information. Event-initiated EMRS enables information to be sent to
the ONStor secure server asynchronously after CPU events occur.
The information is transmitted when a CPU reboots, not when a
CPU crashes.
Configuring and Managing EMRS

EMRS is an extension of the NAS Gateway’s autosupport feature, and the commands
that configure and manage EMRS are in the autosupport command group.
EMRS configuration affects the entire cluster. When you configure the settings for
EMRS, the information is written into the cluster database, and other NAS Gateways
in that cluster use the same information.
12-12
However, system information is gathered and uploaded on a per-NAS Gateway basis.

Therefore, when gathering system information for NAS Gateways in a multinode
cluster, you need to run the system get command on each NAS Gateway the cluster.
Prerequisites for EMRS
To support EMRS:
• The network must support HTTPS traffic to the Internet.
• You need to have administrator privileges on the NAS Gateway and in your
network.
• Some networks use a proxy to support traffic to the Internet. If the network uses a
proxy to route traffic to the Internet, you will need the proxy’s IP address, the port
number that supports traffic, and any user name and password to access the proxy.
Enabling or Disabling Proxy Support for Transmitting EMRS

Information
By default, the EMRS information is gathered on a NAS Gateway and transmitted to
the secure ONStor server by the NAS Gateway itself. However, the EMRS
information can be sent by proxy.
The following information about the proxy device is needed for configuring EMRS:
• The proxy’s IP address
• The port that the proxy will be using to transmit the EMRS information
• The user name and password that are used to authenticate the NAS Gateway with
the proxy if the network’s proxy requires a user name and password
12-13
To Set EMRS’s Proxy Parameters

autosupport emrs proxy enable -i IPADDR -p PORT
[-u USER -P PASSWORD]
Options and
Description
Arguments
-i IPADDR Specifies the IP address of the proxy.
-p PORT Specifies the proxy port that supports the EMRS information from the
NAS Gateway.
-u USER Specifies the user name if the proxy requires one for access.
-P PASSWORD Specifies the password if the proxy requires one for access.
To Disable Proxy Support for Transmitting EMRS Information

autosupport emrs proxy disable
Enabling Automatic Transmission of EMRS Data

By default the EMRS feature is enabled. But if this feature is disabled, you can
explicitly enable it by running the autosupport emrs send enable command.
To Enable Automatic Transmittal of EMRS Data
autosupport emrs send enable
Disabling Automatic Transmission of EMRS Data

By default the EMRS feature is enabled. But you can explicitly disable this feature by
running the autosupport emrs send disable command. When you disable the
EMRS feature, the NAS Gateway stops sending system information through nightly or
event-initiated uploads to the ONStor server, and the EMRS configuration is removed
from the cluster.
12-14
To Disable the Automatic Transmittal of EMRS Data

autosupport emrs send disable
Displaying the EMRS Configuration

You can display the current settings and operational state of the EMRS feature. If the
no proxy server information is specified, the display shows an asterisk (*) for each of
the proxy parameters.
To Display the Current Configuration of EMRS Parameters
autosupport emrs show config
Displaying Information Supported by EMRS

You can display the configuration information and performance statistics that are
transmitted automatically through nightly EMRS uploads.
To Display the Configuration Information and Performance Statistics
system get config -s
The -s option displays the output on the management console.
Note - The system get config -s command does not support displaying
information contained in admin-initiated uploads.
Uploading Information Through a Case Number

To manually transfer system information to the ONStor secure server, run the system
get command. With this command, the NAS Gateway transfers configuration
information and performance statistics to the secure ONStor server. This method
requires a case number, so there must be a case filed with ONStor Customer Support.
12-15
After the information is uploaded to the ONStor secure server, Customer Support can
begin analysis of the information.
To Upload System Information Through a Case Number
Step 1: Make sure there is case opened with ONStor Customer Support.
The case number must be used in uploading the information.
Step 2: When you receive the case number, make a note of it.
Step 3: Run the system get command for the type of information that you
want to upload, and include the case number in the command. For
example, to upload the system information for case number 2659,
run the command as follows:
• system get all -c 2659 to transmit all logs, statistics,
crash information, and configuration information.
• system get config -c 2659 to transmit configuration
information.
• system get logs -c 2659 to transmit various log files.
• system get stats -c 2659 to transmit system and volume
statistics.
• system get tse -c 2659 to transmit pertinent technical
support information.
12-16
Chapter 13: Working with ONStor
Data Mirror
• “Managing ONStor Data Mirror” on page 13-2.
• “Configuring Data Mirrors” on page 13-7.
13-2
Managing ONStor Data Mirror

The ONStor NAS Gateway uses the ONStor Data Mirror functionality to support
configuration and management of mirrors for data replication. Use data mirroring to
replicate a file system from one volume to another one as a read-only mirror copy.
The NAS Gateway supports two types of data mirroring:
• Data mirroring over IP
• Local data mirroring
Data Mirroring Over IP

Data Mirror over IP mirrors files from a source volume to a target volume using IP.
The source and target volumes are volumes in different clusters, and the volumes
might be in geographically different locations.
Read and write operations in Data Mirror over IP occur as parallel operations. In Data
Mirror over IP, you can run some commands from the virtual server associated with
source volume, some commands from the virtual server associated with the target
volume, and some commands from the virtual server with either volume as shown in
Table 13-10.
Table 13-10: Mirror Commands in Data Mirror Over IP
Run from Virtual Server Run from Virtual Server

Command Associated with Source Associated with Target
Volume Volume
mirror create yes no
mirror delete yes yes
mirror demote no yes
mirror disable yes no
mirror enable yes no
mirror kill yes yes
mirror modify yes no
13-3
Table 13-10: Mirror Commands in Data Mirror Over IP (Continued)
Run from Virtual Server Run from Virtual Server

Command Associated with Source Associated with Target
Volume Volume
mirror pause yes no
mirror promote no yes
mirror resume yes no
mirror reverse yes no
mirror schedule yes no
mirror show yes yes
mirror start yes no
mirror testconnect yes yes
Features and Functionality Supported by Data Mirror over IP

Data Mirror over IP supports the following features and functionality:
• Whole-volume asynchronous replication over IP
• One source pointing to one target volume
• Ability to schedule, suspend, and restart replications
• Provide resynchronization capability after suspending (using mirror pause and
mirror resume commands) without level 0 copy again
• Block-based incremental mirrors
• Break mirror and promote target to read/write
• CLI and NAS Cluster Manager Web UI
• A maximum of 20% degradation in performance and throughput when replication
is enabled
• Source and destination volumes and virtual servers on different clusters
• A maximum of 16 concurrent Data Mirror over IP sessions per NAS Gateway
13-4
• Target read-only with the ability to move live file systems on a target volume to the
latest snapshot
• Backup of remote mirror target
Data Mirror over IP Prerequisites
For Data Mirror over IP to work you need to open the following specific ports in your
firewalls:
• The sanm agent on the target file processor listens on TCP port 58502.
• The sanmd daemon on the system switch and controller (SSC) listens on UDP port
36035.
ONStor does not support changing these ports.
Local Data Mirror

In local data mirroring the source and target volumes are on the same NAS Gateway
and the same virtual server. Read and write operations in local mirroring occur as
serial operations.
Data Mirroring Methods

The NAS Gateway supports the following methods of data mirroring:
• Asynchronous storage area network (SAN) based mirroring for intermittently
synchronizing file system information between a source volume and a read-only
target volume. The data is mirrored through the SAN because the source and target
volumes reside on disk arrays accessible by the same NAS Gateway.
• Volume mirroring from multiple source disk arrays to target volumes on a single
high-capacity disk array. The AutoGrow feature can increase the size of a target
volume automatically as needed. However, it is good practice to create the target
volume in the same size or larger as the source volume. For information about
supported disk arrays, contact your customer support representative and request a
copy of the Compatibility Matrix.
• The NAS Gateway supports mirroring a source small computer system interface
(SCSI) disk array to a slower but higher capacity target integrated drive electronics
disk array as long as the disk array has a Fibre Channel (FC) interface.
13-5
During a base line data copy, a baseline mirror session takes place, which transfers the
file system in its entirety. Subsequent mirror sessions are incremental.
Asynchronous and Synchronous Mirroring
Two types of mirroring exist: synchronous and asynchronous. With synchronous
mirroring, the file system is replicated to the target volume in real time. With
asynchronous mirroring, the file system is replicated to the target volume at recurring
synchronization intervals. The ONStor Data Mirror solution supports asynchronous
mirroring through two methods: a mirror schedule and an on-demand mirror session.
• The mirror schedule is a policy you can configure that sets various time parameters
for managing the mirroring interval of file system data from the source volume to
the target volume.
• The on-demand mirror enables you to manually invoke the transmission of file
system data from the source volume to the target volume. The on-demand mirror
session requires more user intervention because the on-demand session occurs
only once each time you start the session by running a user interface command.
A configured mirror schedule can exist concurrently with an on-demand mirror
session, but only one mirror session per volume can be active.
Volumes and Automatic Growth

For more information about volume AutoGrow, see “Managing Volumes and File
Systems” on page 6-1.
When the NAS Gateway’s Volume Manager (VM) requests an AutoGrow event, the
VM checks for the presence of a target volume, and enforces AutoGrow in the
following ways:
1. If a target volume exists, AutoGrow occurs on the target
volume first.
2. If no target volume exists, AutoGrow occurs on the source
volume.
3. If a target volume exists, but there is not enough space to
automatically grow the volume, the AutoGrow fails.
If situation 3 occurs, you can resolve the disk space problem by one of two methods:
13-6
• Expand the target disk space.

• Delete or break the mirror. At the conclusion of target disk expansion or mirror
deletion, AutoGrow resumes on the source volume as configured.
Tracking File System Quotas on Target Volumes

In a typical configuration, quota configuration information is mirrored from the source
volume to the target volume. However, because the target volume is read-only, data
operations that require disk block allocations in the file system are not mirrored to the
target volume. Therefore, quotas are not enforced or tracked on the target.
Because quota information is present on both the source and target volumes, if the
target volume is promoted, it will already own a copy of the quota conditions that were
active the last time the mirror was synchronized.
13-7
Configuring Data Mirrors

Before configuring a mirror, consider the following:
• You need to be in the virtual server context to configure and manage mirrors.
• The LUNs for the target volume and the file system can be on different or the same
disk arrays.
• You need LUNs that are free and labeled for the target volume, or you can use a
volume that has been created with the -m option. If the mirror existed before and
has been deleted, thus promoting the target volume, you can demote the original
target volume using the mirror demote command, and re-use it for the mirror. It has
to have the same source volume and same mirror name. See “Demoting a Mirror
Volume for Data Analysis” on page 13-16.
• Mirroring occurs on a 1:1 ratio between the source volume and the target volume.
• The entire file system is mirrored. You cannot mirror a part of a file system.
• Zoning must not eliminate an identical view of the target disk array.
• The NAS Gateway has no fault tolerance or autorepair of the source or target disk
array. If the source disk array fails, manually repair it.
- If the source disk array fails, you can promote the mirror. For more
information, see “Promoting Mirrors” on page 13-21.
- If the target disk array fails, you can perform the physical repairs, then
recreate the source data on the new target disk array.
Creating a Local Mirror to Perform Baseline Data Copy for a

Data Mirror over IP
When you create the first mirror on your cluster, you use a local mirror to perform a
baseline data copy onto an existing target volume on your cluster. After the initial data
copy, mirroring operations are incremental. Incremental mirroring can be done on a
local or a data mirror over IP.
Within a NAS Gateway, you can configure mirrors for multiple volumes, one mirror
per volume. You can configure mirrors for up to half of the maximum number of
volumes allowed per NAS Gateway because each target volume counts against the
13-8
maximum number of volumes allowed per NAS Gateway. You can schedule multiple
mirror sessions to start concurrently. The NAS Gateway processes a maximum of 16
mirror sessions at a time. Any sessions beyond the first 16 sessions scheduled to start
at the same time are placed on a pending list. As mirror sessions complete, the NAS
Gateway automatically starts mirror sessions from the pending list.
To Perform a Baseline Data Copy
Step 1: Create a mirror on the source cluster by running the following
command:
mirror create MIRRORNAME SRC-VOL TGT-VOL
[-R TARGETARRAYORDEVICE] [-S STATE] [-m MINUTE]
[-h HOUR] [-d DATE] [-M MONTH] [-D DAY]
[-l{low|med|high}]
MIRRORNAME Specifies the name of the mirror you are creating. Use an
alphanumeric character string of up to 16 characters.
Avoid using special characters such as *,?, ~, and /.
SRC-VOL Specifies the name of the source volume that the NAS
Gateway will be mirroring onto the target volume.
TGT-VOL Specifies the name of the target volume that will receive
the data copy from the source volume on the source disk.
For a baseline data copy, use an existing volume.
-R TGTARRAYORDEVICE The name of the device controller for the target disk.
Type the name of the array controller. You cannot
mirror a file system volume across multiple arrays.
The name string can be up to 127 characters. This
optional parameter becomes required if the target
volume does not yet exist.
13-9
-S STATE An optional argument that sets the operational state

of the mirror schedule when you configure it.
Specify either enable or disable.
If you specify enable, the mirror schedule is
immediately active when you complete configuring
it. This state is the default.
If you specify disable, the mirror schedule is not
active when you complete configuring it.
-m MINUTE An optional argument that specifies the minutes of
the hour at which to initiate a mirror session. Type a
value from 0 to 59 where 0 is the top of the hour and
59 is the 59th minute of the hour.
Multiple values can be entered in a comma-delimted
list.
-h HOUR An optional argument that specifies the hour of the
day at which to initiate a mirror session. This
parameter accepts 24-hour time, so type a value
from 0 to 23 where 0 is midnight and 23 is 11:00
p.m.
If you do not specify a minutes value, the session
occurs at the top of the hour that you specify.
If you specify a minutes value, the session occurs at
the number of minutes in the hour you specify.
list.
-D DATE An optional argument that specifies the date in a
month on which to initiate a mirror session. Type a
value from 1 to 31 where 1 is the first of the month
and 31 is the last day of the month.
list.
13-10
-M MONTH Specifies an optional month of the year in which to

initiate a mirror session. Type a value from 1 to 12
where 1 is January and 12 is December.
If you do not specify a month value, the mirror
session occurs every month based on the time values
configured with the other time parameters.
If you specify a month value, the mirror session
occurs at that month within the year. For example, if
you specify 6, the mirror session occurs in June of
each year.
list.
-d DAY An optional argument that specifies the day on
which to initiate a mirror session. Type a value from
0 to 6 where 0 is Sunday and 6 is Saturday.
If you do not specify a day of the week value, the
session occurs as configured by the other
parameters.
If you specify a day of the week value, the session
occurs on the day that you specify.
list.
-l low|med\high Specifies the the mirror load at either low, medium
or high. You select the mirror load that is put on the
NAS Gateway and disk arrays during a mirror
session.
Step 2: Start the mirror with the mirror start command to perform a
baseline data copy to the target volume on the source cluster. For
details on how to use this command, see “Starting or Stopping a
13-11
Step 3: When the baseline data copy is completed, delete the local mirror
with the mirror delete command on the source cluster. Deleting
the local mirror that you created for the baseline data copy
operation automatically promotes the target volume to a standard
volume. For details on how to use this command, see “Deleting a
Step 4: Disconnect the target volume storage and move the storage to the
remote site. Then connect it to the target cluster.
Step 5: Delete the target volume from the source cluster with the volume
delete command. For details on how to use this command, see
“Deleting a Volume” on page 6-22.
Step 6: Rescan all LUNs on the source cluster with the lun rescan all
command. For details on how to use this command, see the ONStor
Bobcat 2200 Series Command Reference.
Step 7: Rescan all LUNs on the target cluster with the lun rescan all
command. For details on how to use this command, see the ONStor
Bobcat 2200 Series Command Reference.
Step 8: Import the target volume in a virtual server of the remote cluster as
a mirror volume with the volume import command. For details on
how to use this command, see “Importing a Volume From One
Cluster to Another” on page 6-20.
Step 9: Bring the target mirror volume on the remote cluster online by
running the volume online command. For details on how to use
this command, see “Bringing a Volume Online” on page 6-19.
Step 10: On the source cluster, create a data mirror over IP with the mirror
create command by using the source and target volumes, and the
IP or DNS name of the virtual server where you imported where
you imported the target volume. You do not need to specify the -R
option at this point because the target volume already exists. For
details on how to use this command, see “Creating Local Mirror
and Data Mirror over IP Schedules” on page 13-12.
13-12
Note - Ensure that the remote mirror name is the same as the local mirror name
you previously created.
At this point, each subsequent mirror session is incremental, and you can
create mirror schedules.
Creating Local Mirror and Data Mirror over IP Schedules

If a schedule is configured for a mirror at create time, then this command is used to
replace the schedule with a new one. If no schedule was specified at mirror create
time, then this command may be used to add one. If this command is run with no
options, the schedule for the specified mirror is deleted.
Note - For a remote mirror, this command must be run in the context of the
virtual server associated with the remote mirror's source volume.
To Create a Mirror Schedule

mirror schedule MIRRORNAME [-m MINUTE] [-h HOUR]
[-d DOM] [-M MONTH] [-D DOW]
Options and
Description
Arguments
MIRRORNAME Specifies the name of the mirror you are creating. Use an
alphanumeric character string of up t 15 characters. Avoid using
special characters such as *,?, ~, and /.
13-13
Options and
Description
Arguments
-m MINUTE An optional argument that specifies the minutes of the hour at which
to initiate a mirror session. Enter a value from 0 to 59 where 0 is the
top of the hour and 59 is the 59th minute of the hour. This value can
interact with the -h HOUR argument to specify an hour at which the
mirror session will occur. If you do not specify a minute value, the
mirror session will occur at the top of the hour. If you do specify a
minute value, the mirror session occurs at that minute within an hour.
By default, this argument is set to zero (0).
Multiple values can be entered in a comma-delimted list.
-h HOUR An optional argument that specifies the hour of the day at which to
initiate a mirror session. This parameter accepts 24-hour time, so
enter a value from 0 to 23 where 0 is midnight and 23 is 11:00 p.m.
This value can interact with the -m MINUTES argument to specify a
time other than the top of the hour. If you do not specify a minutes
value, the session will occur at the top of the hour that you specify. If
you do specify a minutes value, the session will occur at the number
of minutes in the hour you specify.
-d DOM An optional argument that specifies the date in a month on which to

initiate a mirror session. Enter a value from 1 to 31 where 1 is the first
day of the month and 31 is the last day of the month.
-M MONTH An optional argument that specifies the month of the year in which to
initiate a mirror session. Enter a value from 1 to 12 where 1 is January
and 12 is December. This value can interact with the -d DOM
argument. to specify a particular date at which the mirror session will
occur. If you do not specify a month value, the mirror session will
occur every month based on the time values configured with the other
time parameters. If you do specify a month value, the mirror session
occurs at that month within the year.
13-14
Options and
Description
Arguments
-D DOW An optional argument that specifies the day on which to initiate a

mirror session. Enter a value from 0 to 6 where 0 is Sunday and 6 is
Saturday. If you do not specify a day of the week value, the session
will occur as configured by the other parameters. If you do specify a
day of the week value, the session will occur on the day that you
specify.
Note - You can also create a mirror schedule when you first create a mirror
with the mirror create command.
Verifying Data Mirror over IP Port Connectivity

For Data Mirror over IP to work, the following ports must be accessible:
• 48502, the port on which the sanm agent on the target FP port listens
• 36035, the port used by the sanmd daemon on the SSC
Firewalls might block the sanm ports used for data mirroring over IP, so you need to
check these ports for accessibility.
To Check Port Accessibility
mirror testconnect {HOSTNAME|IPADDR}
{HOSTNAME|IPADDR} specifies either a DNS, NIS, or LDAP
host name or an IP address of the location to check for port
accessibility across firewalls.
Note - You need to run this command from the context of the virtual server of
the NAS Gateway that you are logged on.
13-15
Backing Up Mirror Volumes

You can back up system or user-created snapshots on mirror volumes. The following
limitations apply to backing up a mirror volume:
• Backup of a mirror volume fails on a running mirror.
• If a backup of a mirror volume is running, a mirror will fail to start if the snapshot
being backed up on the target volume has been deleted from the source volume. If
the snapshot still exists on the source volume, the mirror and backup will run
concurrently. This limitation applies for both local and remote mirrors.
Modifying Mirror Attributes

You can modify the following attributes of an existing mirror with the mirror modify
command:
• The mirror source volume
• The mirror target volume
• The mirror load
For a remote mirror, you need to run this command in the context of the virtual server
associated with the remote mirror’s source volume.
To Modify a Mirror’s Attributes
mirror modify MIRRORNAME [-s SRCFSYS] [-tTGTFSYS]
[-l {low|high|med}]
Options and
Description
Arguments
MIRRORNAME Specifies the name of the mirror you are modifying. Use an
alphanumeric character string of up to 16 characters. Avoid using
special characters such as *,?, ~, and /.
-s SRCFSYS Specifies the name of the source volume. You can change this
attribute only when the mirror is idle.
13-16
Options and
Description
Arguments
-t TGTFSYS Specifies the name of the target volume.You can change this
attribute only when the mirror is idle.
-l Specifies the relative load that the mirror session should place on
{low|high|med} the NAS Gateway. The default is med.
Demoting a Mirror Volume for Data Analysis

You can demote a mirror volume that was previously promoted to a live file system
volume with the mirror promote command back to a mirror volume by running the
mirror demote command. This command reverts the volume to the last mirror
snapshot. When you demote a mirror volume, you will lose all file system
modifications you might have made since the last mirror snapshot. You can demote
local mirrors and data mirrors over IP. For a data mirror over IP, run this command
from the context of the virtual server associated with the remote mirror’s target
volume. Demoting a mirror is helpful when you need to perform data analysis and
need to write data on the target volume but do not need to keep that data.
To Demote a Mirror Volume
Step 1: After the mirror has transferred the data to the target volume,
disable the mirror with the mirror disable command. For
details on how to use this command, see “Enabling or Disabling a
Step 2: Promote the target volume using the mirror promote command.
For details on how to use this command, see “Promoting Mirrors”
on page 13-21.
Step 3: Perform the data analysis.
Step 4: Demote the target volume back to a mirror volume using the
following command:
mirror demote VOLNAME
VOLNAME is the name of the mirror volume you are demoting.
You will lose all modifications made to the volume made since
13-17
the last mirror snapshot.

Step 5: Bring the target mirror volume online with the volume online
command. For details on how to use this command, see “Bringing a
Volume Online” on page 6-19.
Note - Mirror sessions can now resume, and subsequent mirror sessions will be
incremental.
Reversing a Mirror for Disaster Recovery

Use the mirror reverse command to reverse the direction of a mirror. This is helpful
after disaster recovery because you can revert a mirror back to the source volume with
data modifications made on the target volume after the failure occurred. You need to
run this command from the virtual server context of the mirror source virtual server
when the source cluster has recovered and is back up again.
To Reverse the Direction of a Mirror
Note - This procedure assumes that the target volume has been promoted and is
currently servicing data from the remote site.
Step 1: When the source NAS Gateway is back up, run the mirror
disable command on the source NAS Gateway to prevent the
source NAS Gateway from attempting to send data to the target
volume. Any such attempt would fail because you promoted the
target volume in Step 2.
Step 2: Reverse the mirror by running the following command on the
source NAS Gateway:
mirror reverse MIRROR
MIRROR is the name of the mirror you are reversing. Reversing a
mirror automatically enables the mirror.
13-18
Step 3: Run the mirror start command on the source NAS Gateway that
recovered to transfer back to the original source volume all target
volume modifications made to the target since the target volume
was promoted. Before doing this, you might want to disable CIFS
and NFS services to prevent additional modifications to the target
volume. For details on how to use the mirror start command, see
“Starting or Stopping a Mirror” on page 13-20. For details on how
to disable NFS and CIFS shares, see “Enabling or Disabling NFS
Shares” on page 7-49 and “Enabling or Disabling CIFS” on page 7-
53.
The following steps are intended to restore your original mirror direction after a
disaster recovery.
Step 4: Take the source volume on the original NAS Gateway that serviced
the data offline by running the volume offline command. For
details on how to use this command, see “Taking Volumes Offline”
on page 6-18.
Step 5: Promote the source volume on the original source cluster that had
the disaster with the mirror promote command. For details on
how to use this command, see “Promoting Mirrors” on page 13-21.
Step 6: On the original target NAS Gateway that serviced the data
temporarily, reverse the mirror by running the following command:
mirror reverse MIRROR
MIRROR is the name of the mirror you are reversing.
Step 7: Bring the source and target volumes online on their respective
clusters by running the volume online command. For details on
how to use this command, see “Bringing a Volume Online” on
page 6-19.
Mirror sessions can now resume through the mirror schedule or
by using the mirror start command.
13-19
Deleting a Mirror
When you delete a mirror, all its configured parameters are deleted, but the file system
data associated with the mirror is not deleted from the target disk array. Deleting a
mirror when the target volume has not yet been promoted will promote the target
volume from a mirror to a standard volume. The target volume has to be offline.
To Delete a Mirror Schedule
mirror delete MIRRORNAME
MIRRORNAME is an alphanumeric character string of up to 15
characters.
Enabling or Disabling a Mirror

Mirrors are automatically enabled when they are created. However, for mirrors that
have been manually disabled, you need to explicitly enable each mirror by name.
When you enable the mirror, one of two situations occurs:
• If the NAS Gateway is configured for scheduled mirroring, it begins mirroring
based on the mirror schedule’s time parameters that you have configured.
• If the NAS Gateway is configured for on-demand mirroring, it waits for you to
manually invoke a mirror session.
When you disable a mirror, any configured parameters in the mirror schedule are not
deleted, but remain configured and suspended until the mirror is re-enabled.
To Enable a Mirror
mirror enable MIRRORNAME
characters.
To Disable a Mirror
mirror disable MIRRORNAME
13-20

characters.
Starting or Stopping a Mirror

You can start either one mirror or multiple mirror sessions concurrently. The NAS
Gateway processes a maximum of 16 mirror sessions at a time. Any sessions beyond
the first 16 sessions you have started at the same time are placed on a pending list. As
mirror sessions complete, the NAS Gateway automatically starts mirror sessions from
the pending list.
You can stop in-progress or paused mirror sessions by name regardless of whether
they are on-demand or scheduled. If you stop a scheduled mirror session, only the
current session is halted. The next mirror session will occur at its regularly scheduled
time.
To Start a Mirror Session
mirror start MIRRORNAME
characters.
To Stop a Mirror Session
mirror kill MIRRORNAME
MIRRORNAME is a free-form alphanumeric character string from
1 to 15 characters in length. Enter the name of the configured
mirror that you want to stop.
Displaying Mirror Session Information

You can display general information about all mirror sessions on the current NAS
Gateway, or obtain detailed information about a specified mirror session.
13-21
To Display Mirror Session Information

mirror show [MIRRORNAME]|[-v SRCVOLNAME]
MIRRORNAME is an optional alphanumeric character string of up
to 15 characters.
• If you specify a name, only that mirror is displayed.
• If you specify no name, all configured mirror schedules are
displayed.
-v SRCVOLNAME displays mirrors for the specified source
volume.
Promoting Mirrors
You can promote a mirror to a mountable, read-write file system.
Note - ONStor recommends promoting a mirror to a read-write file system

only in the case of an emergency because you lose redundancy.
Before you can promote a mirror, ensure that the target volume is in an operational
state of IDLE and that the target volume is offline.
To Promote a Mirror to a Read-Write File System
Step 1: Check whether the mirror you want to promote is in IDLE state
by running the following command:
mirror show
From within the context of the NAS Gateway, this command
displays a list of all mirrors associated with that NAS Gateway
and the mirror’s operational state.
If the mirror you want to promote is in paused or in-progress
state, wait for it to reach idle state.
13-22
Step 2: If the mirror you are promoting has is scheduled to occur at regular
intervals, turn off the mirror schedule by running the following
command:
mirror schedule MIRRORNAME
MIRRORNAME is the name of the mirror.
Clear all parameters presently specified in the mirror schedule to
remove the mirror schedule.
Step 3: Run the following command to obtain the latest mirror before
promoting it:
mirror start MIRRORNAME
MIRRORNAME is the name of the mirror.
Step 4: Take the target volume offline by running the following command:
VOLNAME is the name of the target volume to be taken off line.
Step 5: Promote the mirror to the role of file system by running the
following command:
mirror promote MIRRORNAME
characters.
Step 6: Unless you plan to demote the target volume, you can delete the
mirror information from the cluster database by running the
following command:
mirror delete MIRRORNAME
MIRRORNAME is the name of the mirror you just promoted to the
role of file system.
Note - Using mirror delete on the source cluster in Step 5 instead of mirror
promote automatically promotes the target volume and deletes the mirror.
13-23
The target volume can now be brought online and service data after you add shares.
Promoting a Remote Mirror to Restore Services If the Source

NAS Gateway Is Down
You can promote a remote mirror to restore file system services if the source NAS
Gateway is down.
To Promote a Remote Mirror If the Source NAS Gateway Is Down
Step 1: Take the target mirror volume offline by running the volume
offline command. For details on how to use this command, see
“Taking Volumes Offline” on page 6-18.
Step 2: Promote the target mirror volume by running the mirror promote
command. For details on how to use this command, see “Promoting
Mirrors” on page 13-21.
Step 3: Configure the target NAS Gateway to provide file services while
the source NAS Gateway is down.
Pausing and Resuming a Mirror Session

By pausing the mirror session, you stop the open disk-to-disk connection of the mirror
without halting the session or deleting the target disk’s copy of the file system. The
paused mirror session retains the configured mirror schedule and all other configured
mirror parameters, but the file system and snapshot updates are suspended while the
mirror session is paused.
Note - When you pause a mirror session, the file system can change without
the mirror reflecting the changes.
Paused mirror sessions do not time out or restart. When a mirror session is paused, it
remains paused until you resume the mirror session.
13-24
To Pause a Mirror Session

mirror pause MIRRORNAME
MIRRORNAME is an alphanumeric character string from 1 to 15
characters in length. Enter the name of the configured mirror that
you want to pause.
When you resume a paused mirror session, the configured schedule and mirror
parameters are available again, and the file system and mirror file system synchronize
and are able to replicate any changes from the source volume to the target volume.
To Resume a Mirror Session
mirror resume MIRRORNAME
characters.
Removing a Mirror Schedule

You can modify or remove a mirror schedule at any time. When you modify the mirror
schedule, the modified parameters become active immediately, but they will not take
effect until the next scheduled update of the mirror. You can perform the following
tasks with the mirror schedule command.
To Remove a Mirror Schedule
Step 1: Locate the mirror with the schedule that you want to modify by
mirror show
Step 2: Run the mirror schedule command, but specify no parameters to
clear the current mirror schedule:
mirror schedule MIRRORNAME
Chapter 14: Managing Backup and
Restore
• “Introducing Backup and Restore” on page 14-2
• “Adding Local User Accounts for NDMP Services” on page 14-18
• “Managing NDMP Sessions” on page 14-28
• “Configuring the NAS Gateway for NDMP Services” on page 14-39
14-2
Introducing Backup and Restore

In the ONStor implementation of backup and restore operations, the terms backup and
restore describe moving data between disk and tape:
• A backup operation moves data from a primary storage disk to a tape drive.
• A restore operation retrieves archived data from secondary storage, such as a tape
to primary storage, such as a disk.
The ONStor backup and restore solution supports two backup and restore topologies:
• Network data management protocol (NDMP)
• CIFS or NFS
Backing Up and Restoring Data Using NDMP

The NDMP defines an open-standard mechanism and protocol for controlling backup,
recovery, and other transfers of data between primary and secondary storage. A disk or
disk array is considered primary storage. A tape device is considered secondary
storage. A tape device can be a standalone tape drive or it can reside in a tape library,
also known as a media changer.
Because NDMP is an open-standard protocol, it does not specify the data format for
the data stream written to the tape device. Instead, the ONStor NAS Gateway supports
a proprietary format for the data stream. Therefore, if you have backed up a file system
through a NAS Gateway, you can restore it only through a NAS Gateway.
The NAS Gateway is always the NDMP server in backup, restore, and media
operations. As the NDMP server, the NAS Gateway receives and fulfills requests from
the NDMP client. The NAS Gateway does not schedule or create backup or restore
sessions. Instead, it supports the backup and restore conditions that are requested by a
backup and restore application.
The NAS Gateway supports backup and restore on a per-virtual-server basis. Each
virtual server acts as a separate instance of NDMP server, and therefore, each virtual
server communicates with an NDMP client to support NDMP backup and restore
operations.
14-3
The NDMP architecture separates the network-attached data management application

(DMA), data servers and tape servers participating in archival or recovery operations.
NDMP also provides low-level control of tape devices and SCSI media changers.
You can install data servers and tape servers either on separate devices or on the same
device. In the ONStor implementation of backup and restore through NDMP, tape and
data servers are not required to be on the NAS Gateway. Tape and data servers can be
independent equipment or exist on the same physical device. They can also be the
ONStor NAS Gateway, or a product from an NDMP-compliant, third-party equipment
vendor that ONStor supports. If you are using a third party tape or data server, it must
be NDMP-compliant, and it must be supported by ONStor. To find out which third-
party equipment vendors ONStor supports, you can contact ONStor Customer Support
and request the latest version of the Compatibility Matrix.
To use the ONStor NDMP backup and restore solution, you need a third-party NDMP
DMA. The ONStor NAS Gateway is always the NDMP server. In this client/server
model, the NDMP client controls the scheduling of backups and restores, and the
NDMP server is the entity that processes any NDMP request that the NDMP client
sends.
Note - All aspects of scheduling and activating backups are configured through
the NDMP client, not on the ONStor NAS Gateway (NDMP server).
For details about supported DMAs and how to configure the NAS Gateway to
interoperate with DMAs see “Supported Data Management Applications” on page 14-
5 and “Configuring the NAS Gateway for NDMP Services” on page 14-39. For more
information about NDMP, consult www.ndmp.org.
Backing Up and Restoring Data Using CIFS or NFS

You can perform backup and restore operations by using a CIFS or NFS client to
backup and restore a mounted CIFS or NFS file system.
When performing backup by using CIFS or NFS clients, certain file system meta data
might not be backed up. For example, when backing up from NFS, CIFS ACLs are not
backed up, and when backing up from CIFS, NFS ACLs are not backed up. You might
14-4
also lose quota information. Consequently, during a restore operation that file system
meta data is not restored. However, all files with file data are restored.
Note - Using a CIFS or NFS client for backing up data might adversely affect
performance.
This chapter does not describe in detail backup and restore operations using a
CIFS or NFS client. The remainder of this chapter focusses on NDMP backup
and restore operations.
Supported Backup and Restore Configurations

The NAS Gateway supports two backup and restore configurations:
• Local backup and restore. In a local configuration, you can back up data or restore
data that belongs to a virtual server to and from tape devices controlled by the
same virtual server.
• Remote backup and restore. The NAS Gateway supports acting as both a data
server and as a tape server in remote NDMP configurations. You can back up data
from a NAS Gateway to a tape device connected to a remote NDMP server. In a
remote configuration you can back up data or restore data that belongs to a virtual
server to and from tape devices controlled by a different virtual server.
Supported Backup and Restore Types

The NAS Gateway supports the following types of backup and restore operations:
• Full backup, in which the NAS Gateway performs the backup of 100 percent of the
data on a per-file-system or partial-file-system basis.
• Partial backup, in which the NAS Gateway can back up a file hierarchy of
directories and subdirectories that does not begin at the root of the file system.
• Incremental backup, in which the NAS Gateway performs a backup of only the
data that has changed since the last full, or lower level backup. You can also
perform an incremental backup in a partial backup operation.
14-5
On the NDMP client, you can give incremental backups a level that ranks them
and allows a backup only when a higher ranking increment occurs. For details on
how to assign levels to incremental backups, see the documentation that
accompanied your backup application.
• The NAS Gateway supports cumulative and differential backups for full and
partial backups. In a cumulative backup, a backup of the changed data since the
last full backup occurs. In a differential backup, only the changes in the data that
occurred since the last backup are backed up. Some DMA vendors use different
terminology and time intervals for differential, partial, or cumulative backup. For
specifics, consult the documentation that accompanied your DMA product.
Supported Data Management Applications

NDMP clients use third-party DMAs for data processing. The ONStor implementation
of NDMP supports the following DMAs:
• IBM Tivoli® Storage Manager (TSM)
• Veritas® NetBackup™ (VN)
• BakBone NetVault™
• Computer Associates International, Inc., BrightStor® ARCServe
• Networker by EMC Legato
• CommVault Galaxy
For details on which versions of these DMAs are supported, contact the ONStor
technical support department and request the latest issue of the Compatibility Matrix.
For details on how to configure the NAS Gateway for NDMP Services using any of
these DMAs, see “Configuring the NAS Gateway for NDMP Services” on page 14-39.
Supporting the NDMP Snapshot Management Extension

The NAS Gateway supports the NDMP snapshot management extension. The NDMP
snapshot management extension interface defines a mechanism and protocol for
controlling snapshots. For details about snapshots, see “Managing Snapshots” on
page 9-1.
14-6
Performing NDMP Services Through the NAS Gateway

The NAS Gateway supports a full implementation of the services listed in the NDMP
specification. Functioning as the NDMP server, the NAS Gateway supports the
following main services for backup and restore operations:
• Tape services, which control the following:
- Reading data from tape drives to an active data stream during a restore
- Writing data from an active data stream to tape drives during a backup
Supported tape and media changer services are in accordance with the NDMP
specification. The NAS Gateway supports tape services for FC-attached tape devices.
• Data services, which control the following:
- Writing data from disk to an active NDMP session during a backup
operation
- Reading the NDMP session’s data to disk during a restore operation
Supported data services are in accordance with the NDMP specification.
• SCSI services, which support SCSI pass-through functions and relay SCSI control
data blocks (CDBs) initiated by the NDMP client. SCSI services command the
SCSI tape changer to automatically perform actions, such as changing tapes or
ejecting them from a drive whenever a tape becomes full.
• Mover services, which control reading data from and writing data to a tape device
and applying buffering of data where required.
Performing Backup and Restore Through the NAS Gateway

To perform a successful backup or restore, the NDMP client and server communicate
through a series of requests and responses that occur in two sequential phases: setup
and communication. During these phases, and during backup and restore sessions, the
NAS Gateway is always the NDMP server.
In the setup phase for local backup and restore, the client issues commands to establish
a control connection to the server.
14-7
In the setup phase for remote backup and restore, the client issues commands to
establish two control connections: one to the tape server handling all tape control and
one to the data server to control the backup and restore operation.
The commands that the NDMP client issues can include:
• Authentication and queries for NDMP server information
• The types of backup supported
• File system information
• Tape information
• SCSI tape changer information
Using the control connection, the NDMP client is the initiator of requests that trigger
responses from the NDMP server. The NDMP client opens control connections in the
setup phase. After successful discovery of the target device and its characteristics, the
NDMP client requests a data connection for actual transfer of data to a storage device.
For a local backup and restore session, the address type is always local. For a remote
backup and restore session, the address type is TCP.
In the communication phase, the actual transfer of data between the disk and the target
storage device that was discovered in the setup phase occurs. In the communication
phase, the NDMP client is still the initiator of requests, and the NDMP server is the
agent that activates drivers that place data on, or pull data from, one or more tape
14-8
devices. Figure 14-3 shows the local backup and restore operations and related control
connections and data flow.
NDMP Client
Control Connection
NDMP Server
(ONStor NAS Gateway)
Data Flow Data Flow
Data
Disk
Tape Library
Figure 14-3 NDMP Client and Server in Simple Topology
During the setup phase, the NAS Gateway listens for the NDMP client’s requests on
the NDMP server’s TCP port. The NAS Gateway also contacts the tape drive or the
robot arm of a tape library and prepares the tape to receive data. In Figure 14-3, the
dashed line shows this as the control connection. During the communications phase,
on each instance of backup or restore, the NAS Gateway creates an NDMP session on
a one-to-one basis with each client.
In each NDMP backup session, the backup application transmits data from the disk
and writes it to the tape drive, as shown by the solid black line in Figure 14-3. The
NDMP client governs opening and closing the backup session, and transmitting the
data.
In each NDMP restore session, the restore application reads data from the tape library
and writes it to disk, as shown by the grey line in Figure 14-3. The NDMP client
governs opening and closing the backup session, and transmitting the data.
14-9
Understanding Backup and Snapshots

Each volume contains its own snapshots in the /.snapshots directory. For more
information about snapshots, see “Managing Snapshots” on page 9-1.
The NAS Gateway uses snapshots as part of the backup procedure in either of the
following ways:
• Backing up a standard file system. When backing up a standard file system, the
NAS Gateway does the following:
- Creates a snapshot of the file system.
- Pins the snapshot. Pinning the snapshot prevents anyone from deleting
or renaming the snapshot while the backup is in progress.
- Runs the backup session.
- Unpins the snapshot.
- Deletes the snapshot.
• Backing up a directory within the /.snapshots directory. When backing up a
directory within the /.snapshots directory on a volume, the NAS Gateway runs a
backup session without creating and pinning a new snapshot for the purpose of the
backup session.
Understanding Restore and File System Quotas

When a restore occurs, two outcomes can exist for the backed up quota information:
• Quotas on tape can overwrite any quotas configured in the live file system.
• Quotas on tape can be discarded in favor of quotas in the live file system.
Both scenarios are controlled by NDMP environment variables that determine whether
quotas on tape should be restored to the live file system.
The NAS Gateway’s implementation of quotas includes NDMP environment variables
that affect how quotas are restored from tape:
• ONSTOR_SUPERSEDE_QUOTAS, which controls whether quota information on tape
is restored when an NDMP restore session occurs.
14-10
• ONSTOR_IGNORE_USR_GROUP, which controls the behavior of user and group

quotas when an NDMP restore session occurs.
• ONSTOR_IGNORE_QTREE, which controls the behavior of tree quotas when an
NDMP restore session occurs.
Backing Up an ONStor Data Mirror

Mirror and backup services cannot operate concurrently on the same NAS Gateway. If
both services are configured on the same NAS Gateway, the service that starts first
takes priority.
• A mirror start will fail if a backup session is in progress.
• A backup start will fail if a mirror session is in progress.
To avoid this service conflict, you can run the mirror session on the NAS Gateway
with the live file system and run the backup and restore services on the NAS Gateway
with the read-only mirror. In this configuration, both services can operate concurrently
without intruding on each other. However, during a backup session no changes can
occur on the read-only mirror, and the source volume (the live file system) will contain
a pinned mirror snapshot. You cannot rename or delete the pinned snapshot until the
backup session completes.
During a backup session, the mirror data on the target volume is backed up to tape. No
snapshot is taken. For more information about the ONStor Data Mirror feature, see
“Working with ONStor Data Mirror” on page 13-1.
During the backup session, the live file system can continue to process file requests
from common Internet file services (CIFS) or network file system (NFS) clients, and
I/O can still be read to and written from disk.
The NAS Gateway automatically generates a name for the mirror snapshot. The
name’s format is similar to: SANM_SS_m1_000001, where:
- SANM_ indicates that the snapshot has been automatically generated
by the NAS Gateway.
- SS_ indicates a snapshot file.
- m1_000001 is an identifier string for the mirror snapshot.
14-11
To Back Up a Mirror
Step 1: Create a snapshot on the source volume by running the snapshot
create command. This command requires a volume name and a
snapshot name.
A snapshot name can be in any alphanumeric character format of
up to 256 characters. However, do not use any of the following
snapshot names:
• Reserved snapshot names, such as hourly.x, daily.y., or
weekly.z. For more information about reserved snapshot
names, see “Managing Snapshots” on page 9-1.
• Mirror snapshot names, such as SANM_SS_m1_000001.
Step 2: Note the name of the snapshot that you just created, you will use it
later.
Step 3: Create the mirror by running the mirror create command. For
more information about this command, see “Working with ONStor
Data Mirror” on page 13-1.
Step 4: Start the mirror by running the mirror start command.
Note - Wait for the mirror to complete successfully before continuing with
Step 5.
Step 5: Configure the backup session for the appropriate DMA, as

documented in the following sections:
• “Preconfiguration Considerations” on page 14-39
• “Configuring the NAS Gateway for Interoperability with
DMAs for NDMP Services” on page 14-44
Step 6: After the backup has completed, delete the snapshot that you
created in Step 1.
14-12
Understanding Management Volumes and NDMP Sessions

Each volume on the NAS Gateway exists within the context of a virtual server. Backup
of the volumes in a virtual server only occurs if NDMP is enabled on that virtual
server. For details, see the “Working with Virtual Servers” on page 3-1.
Each NAS Gateway contains a management virtual server that is used for system
functions. Within the management virtual server resides the management volume. For
backup and restore sessions to operate, you need to configure a management volume
for each management virtual server that will support backup and restore. For details,
see “Managing Volumes and File Systems” on page 6-1.
Note - Although you can use the management virtual server for configuring
user data or populating it with file system data, ONStor recommends to reserve
the management virtual server for system functions.
The management volume is used to store state information when performing a backup
or restore operation. Do not delete any files or directories within the temporary
directory on the management volume.
Ensure that you have enough free space on the management volume during a backup
or restore sessions:
• For backup operations, use the following formula as a general guideline for
determining how much free space you need on the management volume: On the
management volume, reserve 0.3 percent of the size of the volume you are backing
up.
• For restore operations, use the following formula as a general guideline for
determining how much free space you need on the management volume: On the
management volume, reserve 1 percent space of the amount of space used on the
volume you are restoring. This formula is based on an average file size of 16 K.
Space requirements change linearly with changes of the average file size.
AutoGrow parameters are in effect when backup or restore occurs. If the amount of
data for a backup or restore operation is larger than the volume can hold, the
AutoGrow feature is triggered and the volume manager obtains enough LUN space to
accommodate the amount of data in the operation.
14-13
Understanding NDMP Environment Variables

You can use NDMP environment variables to control the following aspects of a
backup or restore operation:
• Parts of the backup or restore session
• What data is backed up or restored
• How the NAS Gateway processes certain phases of the backup or restore session
Typically, environment variables are set automatically by the backup application.
However, some are configurable so that you can customize the operation or
performance of the backup or restore sessions.
Note - Backup applications can have expected or optimized values for

environment variables. Changing these values can cause the backup
application to behave unpredictably or can negatively affect the performance
of the backup or restore session. Therefore, set or change environment
variables only if you are familiar with the environment variables and the
backup applications that are using them.
Some environment variables are supported by the NDMP specification, and others are
specific to ONStor. Table 14-11 lists all environment variables defined by the NDMP
protocol and ONStor and supported by the NAS Gateway. In the table, all variables
specific to ONStor are indicated as such. The NAS Gateway ignores any unsupported
14-14
variables and does not send a message to the DMA or the NAS Gateway’s
management console.
Table 14-11: Supported NDMP Environment Variables
BASE_DATE 0 or Used in backup sessions. Specifies the a reference time

DUMP_DAT for incremental backup. A value of zero (0) indicates a full
E backup. Any other value indicates a reference time of a
Default: previous backup. An incremental backup includes only
none those files modified since the reference time. This
reference time should be a value returned at the
conclusion of a previous backup through the DUMP_DATE
variable. If not set, the LEVEL variable is used to specify
full or incremental backup and the backup timestamp is
stored in an NAS Gateway’s local database if the UPDATE
variable is true.
DIRECT y or n Used in restore sessions. Controls the support of Direct

Default: Access Restore (DAR) functionality. If set to Yes, a tape
n device forwards space directly to the location on the tape
where a specified file exists, instead of scanning the
whole tape. If set to No, no space is forwarded to the file’s
location, thus the entire tape is scanned for the file. Set
this variable only to Yes if the backup being restored was
performed with HIST set to Yes.
DUMP_DATE return value Used in backup sessions. Returned at the conclusion of a

Default: successful backup if BASE_DATE was set. If BASE_DATE
none was not set, this variable is not returned. Specifies a
backup reference time that may be passed as the value
of BASE_DATE in a subsequent incremental backup.
EXTRACT y or n Used in restore sessions. Controls the processing of files

Default: y that were renamed or deleted between backups. This
variable is analogous to the UNIX restore -x and
restore -r commands. If set to Yes, no file deletions or
renaming occurs when restoring an incremental backup.
If set to No, file deletion and renaming occurs to restore
the file system to the exact state at the time of the
incremental backup.
14-15
Table 14-11: Supported NDMP Environment Variables (Continued)
FILESYSTEM Default: Used in backup and restore sessions. Defines the root of
none the backup. The path must include the volume name and
must begin with a forward slash ( / ), for example, /vol1, /
vol1/homes. Also include the snapshot directory for the
volume, for example, /vol1/.snapshots, so that the
volume’s snapshots are also backed up and restored.
When backing up a read-only mirror, set this variable to a
path within a snapshot that was created on the NAS
Gateway where the volume is writable.
HIST y or n Used in backup sessions. Controls the generation of file

Default: n history data during a backup session. File history data
enables the use of DAR. If set to Yes, file history
information is sent during a backup session. If set to No,
file history information is sent. By setting this variable to
No, you disallow DAR functionality.
LEVEL 0 to 9 Used in backup sessions. Controls the level of backup to

Default: 0 be started. If set to 0, all data is copied on backup. If set
to a value greater than 0, incremental backup occurs.
With incremental backup, all files with a lower level that
have been modified are backed up. This variable is
ignored if BASE_DATE is set.
ONSTOR_ y or n Used in restore sessions. Controls whether to restore “8

EXTRACT_8.3 Default: y dot 3” file names from tape. If set to Yes, any 8.3 file
name that was backed up is restored. However, this can
(ONStor- cause a naming conflict. If a naming conflict occurs, the
specific) NAS Gateway posts a warning message and uses a new
file name. If set to No, a file name is generated by the file
system, which can result in a name that is different from
the one that was backed up.
14-16
ONSTOR_ y or n Used in restore sessions. Controls whether to restore the

EXTRACT_AC Default: y ACLs on a backed up file. If set to Yes, this variable
LS restores the same ACLs that were on a file when it was
backed up. If set to No, when the file is restored, the
(ONStor- ACLs that were backed up with the file are discarded, and
specific) the file’s ACLs are inherited from the parent directory
where the file is being restored.
ONSTOR_ y or n Used in restore sessions. Controls the restore behavior

OVERWRITE Default: y on existing files. If set to Yes, this variable preserves
existing files in the restore. If set to No, the existing files
(ONStor- are overwritten during the restore.
specific)
ONSTOR_ y or n Used in restore sessions. Controls restoration of tree

SUPERSEDE_ Default: y (hierarchical) quotas. If set to Yes, this variable restores
QUOTAS no tree quota information from tape. If set to No, the tree
quota information is restored. Restoration of tree quota
information involves restoring only the default and limit
values for a tree. Usage is not restored. For more
information, see “File System Quotas and Backup and
Restore Operations” on page 10-3.
ONSTOR_ y or n Used in restore sessions. Controls restoration of user and

IGNORE Default: n group quotas. If set to Yes, this variable restores only tree
USR_GRP (hierarchical) quota records. User or group quotas are
ignored. You can implicitly set this variable when restoring
dump formats that do not support quotas. For more
information, see “File System Quotas and Backup and
Restore Operations” on page 10-3.
14-17
ONSTOR_ y or n Used in restore sessions. Controls whether to restore tree

IGNORE_ Default: n (hierarchical) or directory quota information from tape to a
QTREE live file system. If set to Yes, tree and directory quota
configuration information and usage conditions are
restored. If set to No, tree and directory quota
configuration and usage conditions are left on tape, and
log messages are generated. For more information, see
“File System Quotas and Backup and Restore
Operations” on page 10-3.
PATH_ return value Used in backup sessions as a return value to the DMA.
SEPARATOR Default: Defines the character to be used as a separator in the
none path. The forward slash ( / ) is always returned as the
path separator at the end of each backup session. The
DMA must use the character specified by
PATH_SEPARATOR when specifying files to be restored.
RECURSIVE y or n Used in restore sessions. Controls the behavior of

Default: y restoring directories. The NDMP restore request contains
a list of paths to be restored. This variable only takes
effect if a path represents a directory. If set to Yes, the
entire directory hierarchy specified by the path is
restored. If set to No, this variable restores the directory
path, but does not restore any of the files or directories
within the directory path.
TYPE Default: Used in backup or restore sessions. Defines the backup

none type to be used. Overrides the butype_name specified in
the NDMP_DATA_START_BACKUP or
NDMP_DATA_START_RESTORE request.
14-18
UPDATE y or n Used in backup sessions. Updates the dump data section

Default: y in the NAS Gateway’s cluster database by writing the
time stamp part of the backup START_REQUEST message
into the cluster database. If set to Yes, this variable writes
a backup session’s timestamp to the NAS Gateway’s
cluster database. If set to No, the configuration database
is not updated with the backup session’s time stamp. This
variable is ignored if BASE_DATE is set.
Adding Local User Accounts for NDMP Services

NDMP client and server communication occurs only after authentication.
Authentication can be one way from either the client to the server or the server to the
client, or two way, where the client and server authenticate each other. The
authentication routine can be either a clear text password or an MD5 hash constructed
from part of a username and password. The username and password for authentication
are configured through a local user account.
You need to add a local user account on the NAS Gateway for NDMP authentication.
The local user account is “local” because it is configured and resides on the NAS
Gateway. The local user account has no effect outside the NAS Gateway, unlike
Windows and NIS user accounts that reside on the domain controller or NIS server.
Each local user account is a cluster-wide entity, so you can use the same local user
account on any NAS Gateway in a cluster. However, each local user account must be
unique within a cluster.
The user account added for NDMP sessions must have privileges, otherwise, NDMP
authentication and authorization will fail. For details on how to add privileges, see
“Managing Privileges” on page 2-1.
To Add a Local User Account
14-19
useraccount add USERNAME [-k “PUBKEY”]
Options and
Description
Arguments
USERNAME Specifies the user account name. Use an alphanumeric character string
between 3 to 63 characters.
-k “PUBKEY” Specifies the SSH key for a local user account when the user account is
created. The -k PUBKEY argument must be the SSH key that the client
generated. If the key is not supplied or is not an exact match with the
client’s SSH key, the user account cannot automatically log in. Therefore,
you need to enter a password every time the user account accesses the
NAS Gateway.
The first time you create a local user account, you need to specify the
password, even if you use the -k PUBKEY argument. The NAS Gateway
gives precedence to the SSH key, so if it is specified, it is used instead of
the password. If the SSH key is removed, the password is still configured,
and you need to enter it for the local user account to be granted access to
the NAS Gateway.
The PUBKEY value is a character string from 1 to 4094 characters
enclosed in double quotation marks.
Step 2: When prompted, enter the password for the user account you just
created. The password for the local user account is an alphanumeric
Step 3: Set the privileges for the user account you just created by running
the priv add allow command. For more information about this
command, see “Managing Privileges” on page 2-1. As part of this
command, you need to set a scope at which the privilege is applied.
For NDMP functionality, valid scopes are cluster or vsvr (virtual
server). The scope cluster is greater than the scope vsvr and
therefore includes the scope vsvr. You can also provide various
levels of functionality with this command:
• For adding a user with full NDMP administrative privileges,
set the user to cluster privilege.
14-20
• For security, you might want to allow someone to back up

files but not restore them. For this situation, set the user to
BACKUP privilege.
• For security, you might want to allow someone to restore files
but not do any backup. For this situation, set the user to
RESTORE privilege.
Setting an Alias for a Tape Device

You can assign an alias to tape devices to facilitate identification of the device. When
you assign an alias, you associate a text string with the tape device’s actual device
name. For example, you could create an alias called “tapedrive22” to identify a single
tape drive instead of referring to it as QUANTUM_PMC01P3145_0.
To Create a Tape Alias
Step 1: Run the following command to discover the media changer’s
device name:
tape devlist -v
Note the tape device’s physical and logical device name. You will
use this information in the next step.
Step 2: Run the following command to create an alias for the tape device:
tape alias set DEVNAME LOGICALNAME ALIAS [-f]
Options and
Description
Arguments
DEVNAME Specifies the physical device name of the tape device as known
to the NAS Gateway.
LOGICALNAME Specifies the logical device name of the tape device for which
you are creating an alias.
ALIAS Specifies the alternate name of the tape device. Use an

alphanumeric character string between 1 and 32 characters.
-f An optional argument that allows your to overwrite any existing

alias.
14-21
Listing Tape Devices and Their Aliases

Tape devices that have aliases are kept in the Tape Devices Alias List. This list
contains the following information for tape devices that have been aliased:
• The device name
• The alias that has been assigned
To Display the Tape Devices Alias List
tape alias show [DEVICE_NAME]
DEVICE_NAME displays the list of tape aliases and logical names
for a specific physical device.
Removing an Alias from a Tape Device

When remove an alias from a tape device, you can manage the tape device only
through the device name or the logical device.
To Remove a Tape Device Alias
Step 1: Run the following command to locate the media changer:
tape alias show
Step 2: Run the following command to delete the alias from the tape
device:
tape alias clear ALIAS
ALIAS is the name of the tape device alias that you are removing.
Listing Tape Devices

When the NAS Gateway completes its SAN discovery, the tape resources are
virtualized and posted to the tape devices list. The list provides operational and
performance information about each device. You can display either basic information
about all tape devices, detailed information about all devices, or detailed information
about a specific device.
Information displayed in this list can include the following:
• The tape device’s physical name.
14-22
• The tape device’s logical device name. Each physical device can support up to 12
logical device names.
• The tape’s state. Valid states are:
- CLOSED
- OPENING
- OPEN
- BUSY
- REWINDING
- UNLOADING
- CLOSING
• Any configured alias for each tape device. If the device has no configured alias,
the Alias field contains NA.
• The tape’s attributes. Valid values are:
- Density, either high density (HIGH-DENSITY) or low density (LOW-
DENSITY).
- Compression state, either compression is enabled (COMPRESSED) or

compression is not enabled. If the tape attributes do not explicitly say
COMPRESSED, then compression is not enabled on the tape drive.
- Rewind state, either rewind (REWIND) or do not rewind (NO-REWIND)

when the tape is closed.
- Unload state, either unload a tape (UNLOAD) or do not unload (NO-
UNLOAD) a tape when it is closed.
14-23
To View the Tape Device List

tape devlist [-v [DEVNAME]]
Options and
Description
Arguments
-v Displays detailed information about all tape devices in the list.
-v DEVNAME Displays detailed information about a specified tape device in

the list.
Displaying the Operational State of a Tape Device

When you display the operations state of a tape device, the following information is
provided. This command displays the following information about a specific tape
device:
• Flags, such as rewind state, unload state, density, and so on.
• The current file number on which the tape head is located.
• The current block number on which the tape head is located.
• The tape device’s fixed block size, if the tape device is configured for fixed block
size. If the tape device is configured for variable block size, this field displays a
zero (0).
• The total space, in bytes, that the tape device supports.
• The amount of available space that remains on the tape device. If this value shows
INVALID, the NAS Gateway does not support calculating available space.
• A list of the soft errors on the tape device. If this value shows INVALID, the NAS
Gateway does not support soft error detection.
To View a Tape Device’s Operational Parameters
tape devstate DEVNAME
14-24
DEVNAME is the tape device’s name. The DEVNAME string can be

a physical device name or a logical device name.
Note - The tape must be open for this command to complete. Otherwise, the
NAS Gateway displays an error message indicating that the device is not open.
Closing a Tape Device

You can close a tape device to reading and writing, which is helpful if the tape device
is stuck in a busy or open state.
To Close the Tape Device
Step 1: Run the following command to determine whether the device is
open or closed:
tape devlist
tape close DEVNAME [-f]
Options and
Description
Arguments
DEVNAME Specifies the tape controller that you want to close to read and write
operations.
-f An option that forces the tape controller to close. Any client that
attempts a subsequent session will get an error message.
Displaying the Media Changers

When the NAS Gateway discovers media changers in the SAN, they are added to the
Media Changers List. This list contains the following information about the media
changers:
• The media changer’s physical device name
• The media changer’s vendor or manufacturer
14-25
• The media changer’s product or model number

• The media changer’s alias, if an alias is configured
The media changers are listed by their physical or logical device name, and the media
changers displayed are listed regardless of their state.
To Display the Media Changer List
tape mc devlist
Setting an Alias for a Media Changer

You can assign an alias to media changers to facilitate identification of the device.
When you assign an alias, you associate a text string with the media changer’s actual
device name.
To Create an Alias for a Media Changer
Step 1: Run the following command to discover the media changer’s
device name:
tape mc devlist
Note the media changer’s device name. You will use this
information in the next step.
Step 2: Run the following command to create the alias for the media
changer:
tape mc alias set DEVNAME ALIAS [-f]
Options and
Description
Arguments
DEVNAME Specifies the device name of the media changer as known to

the NAS Gateway.
ALIAS Specifies the alternate name of the media changer. Use an

alphanumeric character atring between 1 and 32 characters.
14-26
Options and
Description
Arguments
-f An optional argument that allows you to overwrite the existing

alias.
Listing Media Changers and Their Aliases

Media changers and their aliases are kept in the Media Changers Alias List. This list
contains the following information for media changers that have been aliased:
• The device name
• The alias that has been assigned
To Display the Media Changers Alias List
tape mc alias show
Removing an Alias from a Media Changer

When you remove an alias from a media changer, it is immediately removed, and you
can manage the media changer only through the device name or the logical device.
To Remove a Media Changer’s Alias
Step 1: Run the following command to locate the media changer alias:
tape mc alias show
Note the name of the alias. You will use it in the next step.
Step 2: Run the following command to delete the alias from the media
changer:
tape mc alias clear ALIAS
ALIAS is the alias you are removing.
Releasing a Reserved Tape Device

When a tape device is opened, the NAS Gateway posts a SCSI_Reserve lock on the
device that provides exclusive access to the device so that no other devices can open
14-27
the device. When the device is closed, the SCSI_Release flag is sent to the NAS
Gateway to remove the lock and allow the device to be opened.
In some error cases, the SCSI_Reserve flag is not removed even when the device is
closed, so the device remains unavailable. The NAS Gateway supports the scsi
release command to explicitly remove the SCSI_Reserve flag. ONStor recommends
using the scsi release command only after you determine that the device is actually
closed. Run the scsi release command from the same NAS Gateway that reserved
the tape device.
To Release a Reserved Tape Device
Step 1: Run the following command to determine whether the device is
open or closed:
tape devlist
Note the physical name of the device you want to release. You
will use this information in the next step.
Step 2: Run the following command to display detailed information about
the device:
tape devlist -v DEVNAME
DEVNAME is the unique name of the tape device you want to
release.
Note the WWN and LUN ID of the device. You will use this
information in the next step.
Step 3: Run the following command to release the device:
scsi release WWN LUN
Options and
Description
Arguments
WWN Specifies the world wide name of the device you want to
release.
LUN Specifies the LUN ID of the device you want to release.
14-28
Managing NDMP Sessions

Because NDMP is configured and operates on a per-virtual-server basis, you need to
run the commands for configuring and managing NDMP functionality from the
context of a virtual server.
Enabling or Disabling NDMP

NDMP must be enabled on a virtual server for successful backup and restore
operations. When you create a virtual server, NDMP is enabled by default. When
NDMP is enabled, the virtual server can respond to NDMP client requests.
To Enable NDMP on a Per-Virtual-Server Basis
ndmp enable
When you disable NDMP, any in-progress NDMP sessions will complete, but all
subsequent sessions will not run.
Note - Use this command with caution. Many DMAs use multiple sessions to
perform a backup or restore operation. In some cases, if you run this command
while a session is active, you might cause an error that stops the entire
operation. For example, if multiple sessions comprise a single backup
operation, and you run this command while one session in the operation is
active, the entire backup operation can be stopped. ONStor therefore
recommends that you verify that all sessions in the virtual server are closed
before running the ndmp disable command.
You can verify that all sessions in the current virtual server are closed by
running the ndmp show status -v command. If you run this command and no
sessions are listed, no sessions are active, and you can safely run the ndmp
disable command.
To Disable NDMP on a Virtual Server

Step 1: Run the following command to determine if any sessions are
14-29
active:
ndmp show status
• If this command returns an empty list, proceed to the next
step.
• If this command returns one or more sessions, wait until the
in-progress sessions complete.
Step 2: When no sessions are active, run the following command from
within the context of a virtual server to disable the NDMP software
on that virtual server:
ndmp disable
Setting the DMA Type

Setting a specific DMA may enable workarounds to NDMP protocol conformance
issues present in the DMA. Not all DMAs have conformance issues. For details on
which versions of these DMAs are supported, contact the ONStor technical support
department and request the latest issue of the Compatibility Matrix.
To Set the DMA Type for the NAS Gateway
• Run the following command, and specify the DMA type:
ndmp set dma
{generic|bakbone|ca|commvault|legato|oracle|tivoli|
veritas}
Choose from
generic|bakbone|ca|commvault|legato|oracle|tivoli|
veritas to determine the type of DMA that is communicating
with the NDMP server:
- generic sets an unspecified DMA. This setting is the default.
- bakbone sets BakBone NetVault.
- ca sets Computer Associates BrightStor.
- commvault sets CommVault Galaxy.
- legato sets Legato NetWorker.
14-30
- oracle sets Oracle.

- tivoli sets Tivoli Storage Manager.
- veritas sets Veritas NetBackup.
Setting the NDMP Protocol Version

You can set the NDMP version number to be supported for NDMP services for each
virtual server, so different virtual servers can support different versions.
The backup application and the NAS Gateway must be using the same version of
NDMP protocol for backup and restore to be successful. When the application
connects to the NAS Gateway, the NAS Gateway returns its default version. If both
versions match, backup or restore can occur.
Note - For more information about what version of NDMP your backup
applications supports, refer to the product documentation that accompanied
your backup application.
If a protocol version mismatch occurs between the client and NAS Gateway, automatic
negotiation occurs with between the NDMP client and the NAS Gateway to reach
agreement on which version of NDMP to use. The NAS Gateway, as the NDMP
server, responds to the version requested by the client. Therefore, the client must
support either NDMP v3 or v4.
To Set the Active Version of NDMP
ndmp set version NUM
NUM indicates the version of the NDMP protocol that should be
negotiated. By default, v4 is used, but if the client cannot support
NDMP v4, the client and NAS Gateway will renegotiate to
NDMP v3. However, certain DMAs fail to perform protocol
negotiation. If you are using such a DMA, you can use this
command may restrict the NDMP server to version 3.
14-31
Note - Use this command only if you are an experienced administrator.
Displaying an NDMP Log

You can display the locally stored NDMP protocol log messages for each NAS
Gateway.
To Display the NDMP Log
ndmp show log [NUMLINES]
NUMLINES is an optional argument that specifies the number of
lines that you want to display. The number of lines you specify
are counted in most-recent to least-recent order to facilitate seeing
the most recent usage events. Enter a 32-bit number for
NUMLINES. By default, the entire NDMP log is displayed.
Note - This command is presently supported at the CLI only. It is not supported
by the NAS Cluster Manager.
Setting Tape Devices to Alternative Tape Models

You can configure each virtual server to use a specified tape model within an NDMP
v3 environment. The configured tape model determines the behavior of the tape
driver:
• The Veritas tape model causes the tape driver to consume the file mark and
position the tape at the end of tape (EOT) side of the file mark. To support Veritas
interoperability with NDMP v3, configure this tape model behavior by setting the
alternative tape model parameter to “true.”
Note - This configuration is only required for older Veritas NetBackup

versions that do not support NDMP version 4.
14-32
• The standard tape model used causes the tape driver to halt at a file mark and
position the tape at the beginning of tape (BOT) side of the file mark. To support
Veritas interoperability with NDMP v3, configure this tape model behavior by
setting the alternative tape model parameter to true. To support Tivoli TSM
interoperability, set the alternative tape model parameter to false.
By default, the alternative tape model feature is set to false, which supports
interoperability with Tivoli TSM and all versions of Veritas that use NDMP v4. When
set to true, the virtual server supports the default tape driver functionality within a
negotiated NDMP v3 environment.
Configuring the alternative tape model enables the NAS Gateway to conform to other
vendors’ backup implementations. For more information about which version of tape
driver model to set, consult the documentation that accompanied your NDMP backup
solution. Then, set the NAS Gateway to comply with that implementation.
Note - This command has no effect if the DMA negotiates protocol version 4,
which is the default. Use this command only if version 3 is negotiated.
To Set the Tape Driver Version Compatibility on the NAS Gateway

ndmp set tape altmodel {true|false}
true causes the NAS Gateway to support the alternative model
that allows the Veritas tape model to operate in an NDMP v3
environment. false causes the NAS Gateway to support the
standard tape model for an NDMP v3 environment.
Setting the Tape Block Mode

You can configure the NAS Gateway to support one of the following tape block
modes:
• The default of the tape device
• Fixed block mode
14-33
• Variable block mode

You can also specify the tape block size to be used if fixed block mode is configured.
ONStor recommends using variable block mode unless the NDMP client requires
fixed block mode. Consult the documentation that accompanied your backup solution
to discover which mode is supported. Then, set the NAS Gateway to comply with that
mode.
Note - If you are specifying the tape block size, specify a multiple of 512-
bytes. Otherwise, you might experience I/O errors.
Setting this parameter can change the tape device’s read and write speed.
A mismatch occurs between the tape block mode configured on the NAS
Gateway and the tape block mode configured on the DMA can cause I/O
errors.
To Set the Tape Block Mode and Size

• From within the context of a virtual server, run the following
command:
ndmp set tape blksize <-1|0|SIZE>
Options and
Description
Arguments
-1 Sets the virtual server to use the default tape block mode and size that are
in use on the tape device.
0 Sets the virtual server to support variable block mode.
SIZE Specifies the size, in bytes of a tape block, for the virtual server to support
fixed block mode.
14-34
Setting the TCP Port for NDMP Services

By default, the NAS Gateway listens for services on TCP port 10,000. However, you
can set a different TCP port for NDMP by issuing the ndmp set port command. If
you set the port to a different value, you disallow any other functionality supported on
that port. For example, if you set the port to 80, the NAS Gateway supports NDMP on
that port, but disallow World Wide Web HTTP support, which uses that TCP port by
default.
To Set a TCP Port for Supporting NDMP Services
ndmp set port PORT
PORT is the TCP port number on which you want to configure
NDMP services. By default, port 10,000 is used.
Resetting the NDMP Configuration to Defaults

If you have configured a virtual server with custom NDMP settings, you can return the
NDMP feature to default state. The default NDMP parameters are as follows:
• NDMP state: Enabled
• NDMP version: 4
• TCP port for NDMP services: 10000
• Tape block size: 0 (variable block mode)
• Tape Alternate Model: false
Note - You can view the current state of the NDMP software by running the
ndmp show config command.
To Set NDMP Parameters to Their Defaults

ndmp reset
14-35
Displaying the NDMP Configurations for Virtual Servers

The NAS Gateway tracks the NDMP parameters configured for each virtual server
supporting NDMP functionality. This information is displayed in the NDMP
Configuration Table that contains general NDMP configuration and state information,
such as:
• Whether the virtual server’s NDMP software is currently enabled or disabled.
• The NDMP version that the virtual server advertises it can support.
• The tape block size. This information is valid for either fixed block or variable
block mode.
• Whether the alternative tape model flag is set.
You can view the NDMP configuration for either all virtual servers or for a specific
virtual server.
To View the Configuration Information for All Virtual Servers
ndmp show config
To View the NDMP Configuration Information for a Specific Virtual Server
ndmp show config [VIRTUALSERVER]
VIRTUALSERVER is the name of the virtual server for which to
display the detailed NDMP configuration information.
Displaying Status for NDMP Sessions

You can display information about the status of current NDMP sessions by one of the
following types of display options:
• Display information on all active NDMP sessions on all virtual servers within an
NAS Gateway.
• Display information on a specified active NDMP session.
• Display information on all active NDMP sessions on a specified virtual server.
14-36
To View Information on All Active NDMP Sessions on All Virtual Servers

Within a NAS Gateway
• To view information on all active NDMP sessions on all virtual
servers within an NAS Gateway, run the following command from the
context of a NAS Gateway:
ndmp show status -a
-aindicates to display all active NDMP sessions on the current
NAS Gateway.
To View Information on All Active NDMP Sessions on a Specified Virtual
Server
• To view information on all active NDMP sessions on a specified
virtual server, run the following command from the virtual server context:
ndmp show status [-v VIRTUALSERVER]
-v VIRTUALSERVER is the virtual server for which you want to
display all active NDMP sessions. If you don’t specify the virtual
server name with this command, the status of all active NDMP
sessions on the current virtual server displays by default.
Displaying Details for NDMP Sessions

You can display detailed information for all NDMP sessions by one of the following
types of display options:
• Display details on all active NDMP sessions on all virtual servers within a NAS
Gateway.
• Display details on a specified active NDMP session.
• Display details on all active NDMP sessions on a specified virtual server.
To View Details of All Active NDMP Sessions of All Virtual Servers Within
a NAS Gateway
• Run the following command from a NAS Gateway context:
ndmp show detail -a
14-37
-a indicates to display all active NDMP sessions in detail.

To View Details of All Active NDMP Sessions Within a Particular Virtual
Server
• Run the following command from a virtual server context:
ndmp show detail [-v VIRTUALSERVER]
-v VIRTUALSERVER is the name of the virtual for which you want
to display the detailed NDMP session information. If you don’t
specify the virtual server name with this command, the details of
all active NDMP sessions on the current virtual server display by
default.
To View Details of a Single Active NDMP Session
Step 1: Run the following command to locate the NDMP session and
session ID:
ndmp show detail -a
-a indicates to display all active NDMP sessions.
Step 2: Run the following command to view detailed information for the
session:
ndmp show detail -s SESSIONID
SESSIONID is the unique ID assigned to the session.
Deleting NDMP Sessions

Deleting NDMP sessions is useful when the TCP/IP session is not closed completely
the session deletion forces the TCP/IP session to close completely. Only the current
session is deleted. You can delete either all NDMP sessions in a virtual server or a
specific NDMP session.
Delete NDMP sessions only if you think the session is hung. You can discover if the
session is hung when a backup session fails by:
1. Querying the DMA for active sessions.
14-38
2. If the DMA responds that no sessions are active, check the

NAS Gateway by running the ndmp show status -a
command.
3. If the NAS Gateway shows a session, run the ndmp show
status -s command. Then check for a DMA’s IP address.
4. Check the tape device for an active session. For more

information about checking the tape device, consult the
documentation that accompanied your tape device or media
changer.
To Delete All NDMP Sessions in a Virtual Server
ndmp delete session -a
-a indicates to delete all NDMP sessions.
To Delete a Specific NDMP Session
Step 1: From the context of a virtual server, run the following command
to locate the NDMP session and session ID:
ndmp show detail -a
-a lists all NDMP sessions.
Note the session ID. You will use it in the next step.
Step 2: From the context of a virtual server, delete the NDMP session by
ndmp delete session -s SESSIONID
SESSIONID is the unique ID assigned to the NDMP session to be
deleted.
14-39
Configuring the NAS Gateway for NDMP

Services
To use NDMP services you need to configure the NAS Gateway to interoperate with
one or more DMAs. For a list of supported DMAs, see “Supported Data Management
Applications” on page 14-5.
NDMP services are configured on a per-virtual-server basis. Therefore, configure the
NDMP backup and restore services in each virtual server that is to use NDMP
services. For more information about virtual servers, see “Working with Virtual
Servers” on page 3-1.
Typical Task Sequence in Configuring the NAS Gateway for

NDMP
A typical sequence of tasks when configuring NDMP services might be the following:
1. Configure the NAS Gateway.
• Enable NDMP. See page 14-28.
• Add a local user account. See page 14-18.
• Add a privilege to the user. See page 14-18.
• Ensure that the management volume has been configured. See
page 14-40.
• Get the tape drive and media changer name. See page 14-21
and page 14-26.
2. Configure the DMA. See the documentation that came with
you data management application.
3. Add a new drive and connect it to a robotic library column.
See the documentation that came with your tape drive.
Preconfiguration Considerations
Most NDMP applications require some information to set up the application. Obtain
the following information before performing the configuration procedure:
14-40
• Device paths. For more information, see “Mapping Device Paths to Physical
Devices” on page 14-41.
• The IP address of the virtual server in which you are configuring NDMP
functionality. Run the vsvr show command from the virtual server context to view
this information.
• The TCP port that will support NDMP services. By default, this is 10,000, but you
can set it to a different value with the ndmp set port command.
• The username and password for authentication. This information is configured
with the NAS Gateway’s useraccount add command. For more information
about this command, see “Adding Local User Accounts for NDMP Services” on
page 14-18.
Configuring a Management Volume

For backup and restore sessions to operate, you need to configure a management
volume for each management virtual server that will support backup and restore. See
“Understanding Management Volumes and NDMP Sessions” on page 14-12 for more
details.
To Configure a Management Volume
Step 1: To display the management virtual server, run the following
command from the NAS Gateway context:
vsvr show all
Note the name of the management virtual server. You will need it
in the following step. Management virtual server names contain
the string VS_MGMT_XXXX where xxxx is a series of numbers. For
example, VS_MGMT_5343.
Step 2: Switch to the context of the management virtual server by running
the vsvr set command. For example, to switch context to the
management virtual server VS_MGMT_4353, you would run the
command as follows:
vsvr set vs_mgmt_4353
The NAS Gateway’s command-line prompt changes to indicate
14-41
that you are in the context of VS_MGMT_4353.

Step 3: Run the system create mgmtVolume command from within the
context of the management virtual server to create the management
volume. Also specify the array on which to create the management
volume. For example, to create the management volume on the
array IBM_ECV5TUHB within the management virtual server
vs_mgmt_4353, you would run the following command:
system create mgmtVolume IBM_ECV5TUHB
This creates the management volume name string. The
management volume name string is always vol_mgmt_XXXX
where X is the same number string as the management virtual
server. For example, if you ran this command within management
virtual server VS_MGMT_4353, this command would create the
management volume called vol_mgmt_4353.
Note - If you create the management volume with default parameters, you can
always configure custom usage and AutoGrow parameters later by running the
volume modify command against the management virtual server. You cannot
change the management volume’s name through the volume modify
command because the management volume name is automatically generated.
interface create fp1.0 -a 10.123.48.101

Step 4: Exit the management virtual server context, and return to the NAS
Gateway context by running the vsvr clear command:
vsvr clear
Mapping Device Paths to Physical Devices

The NAS Gateway provides a path ID that you can map to a physical device to
determine which path ID is for which physical tape device. You can determine the
device path in one of two ways, each of which represents a standard tape device
topology:
14-42
• Through a SCSI bridge, for topologies with a SCSI bridge. See “Mapping a Device
Path to a Physical Device by Querying a SCSI Bridge”.
• By querying the tape library, for topologies with a direct-attached tape. See
“Mapping a Device Path to a Physical Device by Querying a Tape Library” on
page 14-43.
Note - Determining the device path is optional for configuring NDMP services
on the NAS Gateway. In standard configurations, the tape device is directly
connected to the SAN, and mapping device paths is not necessary.
Mapping a Device Path to a Physical Device by Querying a SCSI Bridge

When you know a device’s path ID, you can map the path to the actual physical drive
that owns it. When you map a path to a device, you use the Path ID displayed on the
NAS Gateway, relate that value to a LUN, and locate the LUN on the SCSI bridge.
To Map Which Path Equates to Which Drive
Step 1: Obtain the mapping for a tape device by running the tape
devlist -v command. Note the device name.
• If the device is in a tape library, proceed to Step 2.

• If not, proceed to Step 3 on page 14-42.
Step 2: If the drive exists within a tape library, obtain the mapping for the
library as well by running the tape mc devlist if the tape device
is in a media changer. Note the device name. You will use it in the
next step.
Step 3: Run the scsi show detail command against the device name you
learned from the tape devlist or tape mc devlist command.
Note the values in the WWN and LUN ID field. You will use this
information in the next step. The value in the WWN field
corresponds to the WWN of the SCSI bridge. The value displayed
in the LUN ID is the FC LUN ID, not the SCSI LUN ID.
14-43
Step 4: Access the SCSI bridge. For more information about accessing or
using the SCSI bridge, consult the documentation that accompanied
the SCSI bridge.
Step 5: On the SCSI bridge, display the WWNs and LUNs and locate the
tape device associated with the LUN you learned from the NAS
Gateway’s scsi show detail command. With the LUN
information, you can map the FC LUN on the NAS Gateway to the
SCSI LUN on the SCSI bridge. For more information about using
the SCSI bridge, consult the documentation that accompanied the
SCSI bridge.
The information from the NAS Gateway and the SCSI bridge is
sufficient to determine which path is for which physical device.
Mapping a Device Path to a Physical Device by Querying a Tape Library
When you know a device’s path ID, you can map the path to the actual physical drive
that owns it. When you map a path to a device, you use the Path ID displayed on the
NAS Gateway, relate that value to a LUN, and locate the LUN on the tape library.
To Map Which Path Equates to Which Drive
Step 1: Obtain the mapping for a tape device by issuing the tape
devlist -v command. Note the device name.
• If the device is in a tape library, proceed to Step 2.

• If not, proceed to Step 3 on page 14-43.
Step 2: If the drive exists within a tape library, obtain the mapping for the
library as well by issuing the tape mc devlist if the tape device is
in a media changer. Note the device name. You will use it in the
next step.
Step 3: Issue the scsi show detail command against the device name
that you learned from the tape devlist or tape mc devlist
command.
Note the values in the WWN and LUN ID field. You will use this
information in the next step. The value in the WWN field
corresponds to the WWN of the tape library. The value displayed
14-44
in the LUN ID is the FC LUN ID, not the SCSI LUN ID.
Step 4: Access the tape library. For more information about accessing or
using the tape library, consult the documentation that accompanied
the tape library.
Step 5: On the tape library, display the WWNs and LUNs and locate the
tape device associated with the LUN you learned from the NAS
Gateway’s scsi show detail command. With the LUN
information map the FC LUN on the NAS Gateway to the SCSI
LUN on the tape library. For more information about using the tape
library, consult the documentation that accompanied the tape
library.
The information from the NAS Gateway and the tape library is
sufficient to determine which path is for which physical device.
Configuring the NAS Gateway for Interoperability with DMAs

for NDMP Services
NDMP services are configured on a per-virtual-server basis. Therefore, you will need
to perform this configuration procedure for each virtual server you want to support
NDMP.
Before you begin configuration, ensure that you have fulfilled the following
preconfiguration requirements:
• Obtain all information required for configuration, such as an IP address, or TCP
port number. See page 14-39.
• Run the ndmp show config command to check whether NDMP is enabled. By
default NDMP is enabled. See page 14-28.
• Configure a management volume. See page 14-40.
• Map the device path to the physical device. See page 14-41.
Note - TSM supports only local NDMP backup and restore operations.Veritas
supports local and remote backup and restore operations.
14-45
To Configure the NAS Gateway for Interoperability With DMAs

Step 1: From the NAS Gateway context, add a local user account on the
NAS Gateway by running the useraccount add command. For
more information about adding local user accounts, see “Adding
Local User Accounts for NDMP Services” on page 14-18.
Step 2: From the NAS Gateway context, add a privilege for the username
you configured for the local user account by running the priv add
allow user command. For NDMP functionality, valid scopes are
cluster or vsvr (virtual server). The scope cluster is greater than the
scope vsvr and therefore includes the scope vsvr. You can also
provide various levels of functionality with this command:
• For adding a user with full NDMP administrative privileges,
set the user to cluster privilege. The scope cluster includes
virtual server scope.
• For security, you might want to allow someone to back up
files but not restore them. For this situation, set the user to
BACKUP privilege.
• For security, you might want to allow someone to restore files
but not do any backup. For this situation, set the user to
RESTORE privilege.
For more information about the priv add allow user
command, see “Managing Privileges” on page 2-1.
Step 3: Switch to the virtual server on which you want to configure NDMP
services by running the vsvr set command. For example, to
configure NDMP in the virtual server “pubstest,” you would run
vsvr set pubstest
Note - The remaining NDMP commands will be run in the context of the
current virtual server.
14-46
Step 4: As an option, configure the port on which NDMP services will be

configured by running the ndmp set port command. For example,
to set the TCP port to 10100, you would run the command as
follows:
ndmp set port 10100
By default, this port is 10,000
Step 5: As an option, you can set the version of NDMP to be supported, by
running the ndmp set version command. However, explicitly
setting the protocol version is not required because the NDMP
client and the NAS Gateway will automatically negotiate for the
protocol version of NDMP by first trying NDMP v4, and if that
version is not supportable in the configuration, negotiating NDMP
v3. For example, to explicitly set the protocol version to NDMP v3,
you would run the command as follows:
ndmp set version 3
Step 6: As an option, you can activate and set the trace level for NDMP
message by running the following command:
ndmp set trace {0|1|2}
The default is 0, tracing is deactivated.
You can display the trace level with the ndmp show trace
command.
Step 7: Determine the tape device name by running the following
command:
tape devlist -v
Note the tape device name. You will need this information for
configuring the DMA.
Step 8: Determine the media changer device name by running the
following command:
tape mc devlist
Note the name of the media changer device. You will need this
information for configuring the DMA.
14-47
Step 9: As an option, configure the tape model for use in NDMP v3 by

running the ndmp set tape altmodel command.
When working with TSM, set the tape model to false as follows:
ndmp set tape altmodel false
When working with NetBackup, set the tape model to true as
follows:
ndmp set tape altmodel true
Step 10: As an option, configure the tape mode and block size by running
the ndmp tape set tape blksize command.
With TSM, the NAS Gateway supports only variable block mode.
With NetBackup, the NAS Gateway supports variable and fixed
block mode. The NAS Gateway can support fixed block mode
only if it is set in multiples of 512 bytes.
Note - Setting this parameter can change the tape device’s read and write
speed. Your NDMP sessions will slow down if you set fixed block mode with
an invalid size.
For example, to configure the NAS Gateway for variable block

mode operation, you would run the command as follows:
ndmp set tape blksize 0
Step 11: Repeat Step 3 through Step 10 for each virtual server in which you
want NDMP services.
Step 12: On the NDMP client, supply the full device path wherever
required. For more information about determining the full device
path, see “Mapping Device Paths to Physical Devices” on page 14-
41.
Step 13: On the NDMP client, enter the IP address of the virtual server for
which you are configuring NDMP wherever required. Enter the IP
address that you configured in Step 3 on page 14-41.
14-48
Step 14: On the NDMP client, enter the TCP port on which the NAS
Gateway is supporting NDMP services. If you changed the TCP
port where NDMP will be supported, enter the port that you
configured in Step 4 on page 14-46.
On the NDMP client, supply the username and password for use in authentication.
Enter the username and password that you configured in Step 1 on page 14-45.
Chapter 15: Managing Virus
Scanning
• “Introducing Virus Scanning” on page 15-2
• “Installing the VirusScan Applet” on page 15-4
• “Unregistering the VirusScan Applet” on page 15-17
• “Configuring the VirusScan Applet” on page 15-18
• “Configuring the CIFS Domain” on page 15-23
• “Prerequisites and System Recommendations” on page 15-27
• “Configuring the Symantec AntiVirus Scan Engine” on page 15-29
• “Configuring the McAfee VirusScan Enterprise 8.0i Software” on page 15-30
• “Managing Virus Scanning From the CLI” on page 15-31
15-2
Introducing Virus Scanning

The ONStor NAS Gateway supports virus scanning with the ONStor VirusScan applet.
You can access, configure, and monitor the virus-scanning capability on a per-virtual-
server basis from the following access points:
• The command-line interface (CLI)
• The ONStor NAS Cluster Manager browser-based GUI
To use the virus scan feature, you need to add a virus-scan server to your NAS
Gateway network topology and configuration. The virus-scan server is connected to
your network and communicates with the NAS Gateway through the Gigabit Ethernet
ports to provide the virus scanning. The VirusScan applet that is installed on the virus-
scan server provides the necessary connectivity between the NAS Gateway and the
virus-scan software.
Supporting Third-Party Virus Scanning Solutions

EverON software supports integration with third-party virus-scanning software. The
virus-scanning software is installed on the virus-scan server where the VirusScan
applet is also installed. You can choose from one of the following virus-scanning
packages supported by EverON software:
• Symantec AntiVirus™ Scan Engine 5.0 and earlier
• On-Access Scanner (AOS) of the McAfee® VirusScan Enterprise 8.0i virus
scanning software. For details, see the McAfee VirusScan Enterprise, version 8.0i
Product Guide.
Note - Although it is possible to install the Symantec AntiVirus Scan Engine

and the VirusScan applet on separate servers, we recommend that you keep
them on the same machine in your network. The McAfee VirusScan Enterprise
8.0i software always resides on the same server as the VirusScan applet.
Although a virtual server can use multiple VirusScan applets, all applets a
virtual server uses must be of the same type, either Symantec or McAfee.
15-3
For a detailed listing of requirements, see “Prerequisites and System

Recommendations” on page 15-27.
15-4
Installing the VirusScan Applet

The VirusScan applet handles the communication between the NAS Gateway and the
virus-scanning function on the server. An InstallShield guides you through the
installation process.
Installation Prerequisites
Before installing the VirusScan applet, verify the following:
• Verify that your NAS Gateway is installed, powered up, and configured.
• If you are using the Symantec AntiVirus Scan Engine, ensure that it is installed and
configured to use ICAP. Refer to the Symantec AntiVirus Scan Engine
documentation on how to do this.
• If you are using the McAfee AntiVirus Engine API, ensure that the .DAT files are
available to enable the virus-scan engine to run.
• Verify that both the VirusScan applet and the virus-scan engine (if you are using
Symantec) are installed on servers configured with a static IP address.
• You are logged in as an administrator or with an account that has administrator
privileges for installing the VirusScan applet.
• CIFS domain users must have administrator privileges on the machine where the
applet is installed.
Installing the VirusScan Applet for the Symantec AntiVirus

Scan Engine
To Install the VirusScan Applet by Using the InstallShield Utility
Step 1: Double-click the setup application icon to launch the installation
wizard.
15-5
Figure 1 ONStor VirusScan Applet Installation Wizard
You can click Cancel at any time to stop the installation. Click
Next to continue with the installation.
Step 2: Select Symantec as the applet that you want to install and click
Next.
15-6
Figure 2 Feature Selection
Step 3: The Custom Setup dialog box enables you to customize the default
setup of the applet. You can make the following changes:
• Change the directory location where the applet will be
installed.
• Select from a dropdown list whether you want to install the
basic features or all features of the applet, and when and
where you want to install them.
• View the disk space requirements for the installation.
15-7
Figure 3 Custom Setup
Step 4: From the Symantec Virus Scanner dropdown list, select the features
you want.
Figure 4 Custom Setup Feature List
15-8
Step 5: If you want to change the location of the applet, click Change on
the Custom Setup dialog box. You can either browse to the
directory where you want the applet to install or you can enter the
directory path.
Figure 5 Change Current Destination Folder
Step 6: To view disk space requirements for the installation of the applet,
click Space on the Custom Setup menu. Disks that are highlighted
on the Disk Space Requirements list do not have enough disk space
available for the installation of the applet.
15-9
Figure 6 Disk Space Requirements
Step 7: When you have completed the custom setup, click Next to continue
the installation.
Step 8: On the Ready to Install the Program window, click Install to
continue the installation of the applet.
15-10
Figure 7 Ready to Install the Program
Step 9: Click Finish to allow the InstallShield wizard to complete the

installation and exit.
Figure 8 Installation Complete
15-11
Installing the VirusScan Applet for the McAfee AntiVirus Scan

Engine API
To Install the VirusScan Applet By Using the InstallShield Utility
Step 1: Double-click the setup application icon to launch the installation
wizard.
Figure 9 ONStor VirusScan Applet Installation Wizard
You can click Cancel at any time to stop the installation. Click
Next to continue with the installation.
Step 2: Select McAfee as the applet that you want to install. Click Next.
15-12
Figure 10 Feature Selection
Step 3: The Custom Setup dialog box enables you to customize the default
setup of the applet. You can make the following changes:
• Change the directory location where the applet will be
installed.
• Select from a dropdown list whether you want to install the
basic features or all features of the applet, and when and
where you want to install them.
• Select the disk space for the installation.
15-13
Figure 11 Custom Setup
Step 4: From the McAfee Virus Scanner dropdown list, select the features
you want.
Figure 12 Custom Setup Feature List
15-14
Step 5: If you want to change the location of the applet, click the Change
on the Custom Setup dialog box. You can either browse to the
directory where you want the applet to install or you can enter the
directory path.
Figure 13 Change Current Destination Folder
Step 6: To select the disk to which to install the applet, click Space on the
Custom Setup dialog box. Disks that are highlighted on the Disk
Space Requirements list do not have enough disk space available
for the installation of the applet.
15-15
Figure 14 Disk Space Requirements
Step 7: When you have completed the custom setup, click Next to continue
the installation.
Step 8: On the Ready to Install the Program window, click Install to
continue the installation of the applet.
15-16
Figure 15 Ready to Install the Program
Step 9: Click Finish to allow the InstallShield wizard to complete the

installation and exit.
Figure 16 Installation Complete
15-17
Unregistering the VirusScan Applet

You may need to update or remove the VirusScan applet from your machine. The
applet must be unregistered before updating and reinstalling the ONStor virus scan
application.
To Unregister the VirusScan Applet
Step 1: To unregister or remove the VirusScan applet, run the following
command on the virus scan server from within the VirusScan
applet directory:
OnStorVirusScanApplet.exe -unregister
Step 2: To unregister or remove the port map service, run the following
command on the virus scan server from within the VirusScan applet
directory:
portmap -unregister
15-18
Configuring the VirusScan Applet

After the InstallShield has installed the VirusScan applet in either the default directory
or one that you specified, configure the applet and register the port map service and
applet service. The default directory for the installation is
applet_installation_directory. The directory contains the VirusScan applet
executable and its associated files as described in Table 15-12.
Table 15-12: Contents of the VirusScan Applet Directory
File Description
Common files needed for either one, Symantec or McAfee installation
ONStorVirusScanApplet.exe Application.
VScanEngine.dll ONStor dll.
oncrpc.dll ONC/SUN RPC dll for Windows.
PortMap.exe RPC port mapping utility—Window Service

application.
msvcr70d.dll Used by portmap.exe. Some machines might need

that library.
Files needed for Symantec installation only
symcsapi.dll Symantec dll.
ONStorVirusScanApplet.config Configuration file for entering the Symantec scan

engine IP and ICAP port for the VirusScan applet.
Files needed for McAfee installation only
ONStorVirusScanApplet.config Configuration file for entering the McAfee scan

engine API path for the VirusScan applet.
Enginepath="" Location of the virus definition files for the McAfee

AntiVirus Engine API.
ONStorMcUpdate.bat Batch file used for an autoupdate.
DoMcafeeAutoupdate.vbs File used for an autoupdate.
15-19
Configuring the VirusScan Applet for the Symantec AntiVirus

Scan Engine
The VirusScan applet file is an XML file that enables you to specify the Symantec
AntiVirus Scan Engine IP address and ICAP port number for the applet to use. If no
alternate configuration file is available, the applet uses the Symantec AntiVirus Scan
Engine on the designated default machine, 127.0.0.1, and it uses the default ICAP
port, 1344. The following example shows the applet with the default IP and ICAP port
specified:
Note - If you do not use the default port for ICAP, you need to specify the port
number in the applet configuration file.
<ONStorVirusScanApplet>
<LogFile mode="disable" name="VScanApplet.log" />
<Resource MaxNumberofParallelFileScanning="100" />
<ScanEngine>
<Symantec™>
<Engine IP="127.0.0.1" Port="1344" />
</Symantec>
</ScanEngine>
</ONStorVirusScanApplet>
• You can specify for the virus-scan application to write a virus-scan log to a log file
in the same directory in which the applet is installed. The applet shown previously
includes a log-file entry that is disabled.
- If you specify the log file mode by replacing “disable” in the shown
code with “enable”, the applet creates a log file or writes to the existing
log file either in the current directory or in a path you provide within
the applet.
- If the log file mode is specified to be “disable”, the applet sends output
to the console only.
15-20
Note - Enabling the log file mode is not recommended because it slows down
the virus-scanning performance. Even when the applet log file mode is
disabled, the applet will log errors and some warnings to the Windows Event
Log.
If the current log file reaches the maximum size of 5MB, the file is automatically
renamed (for example, from applet.log to an older version log file, such as
applet.log.old). If an older version already exists, the newer version overwrites the
older version, and new incoming messages are written to the active log file.
• You can configure the applet to scan a number of files concurrently. The
MaxNumberOfParallelScanning parameter in the configuration file specifies the
maximum number of files the applet can scan concurrently. The default is 100.
Note - Parallel scanning affects memory usage. Depending on the memory

available, if you set the value for parallel scanning too high, your network
operations might take a longer time or the entire network might fail.
• If you want the applet to use more than one virus-scan engine, add the IP addresses
for each into the configuration file so the client library can automatically load
balance over the virus-scan engines. The following example shows an applet using
two Symantec AntiVirus Scan Engines, 10.2.14.150 and 10.2.14.151. Both use the
default port, 1344.
<LogFile mode="enable" name="VScanApplet.log" />
<ScanEngine>
<Symantec>
<Engine IP="10.2.14.150" Port="1344" />
<Engine IP="10.2.14.151" Port="1344" />
</Symantec>
</ScanEngine>
15-21
Configuring the VirusScan Applet for the McAfee AntiVirus

Engine API
The VirusScan applet file is an XML file that enables you to specify the McAfee
definition file location. The following example shows the applet with the default file
location specified:
<LogFile mode="disable" name="VScanApplet.log" />
<ScanEngine>
<McAfee>
<Engine DatPath="" Enginepath="" />
</McAfee>
</ScanEngine>
• You can specify for the virus-scan application to write a virus-scan log to a log file
in the same directory in which the applet is installed. The applet shown previously
includes a log-file entry that is disabled.
- If you specify the log file mode by replacing “disable” in the shown
code with “enable”, the applet creates a log file or writes to the existing
log file either in the current directory or in a path you provide within
the applet.
- If the log file mode is specified to be “disable”, the applet sends output
to the console only.
Note - Enabling the log file mode is not recommended because it slows down
the virus-scanning performance. Even when the applet log file mode is
disabled, the applet will log errors and some warnings to the Windows Event
Log.
15-22
If the current log file reaches the maximum size of 5MB, the file is automatically
renamed (for example, from applet.log to an older version log file, such as
applet.log.old). If an older version already exists, the newer version overwrites the
older version, and new incoming messages are written to the active log file.
• You can configure the applet to scan a number of files concurrently. The
MaxNumberOfParallelScanning parameter in the configuration file specifies the
maximum number of files the applet can scan concurrently. The default is 100.
Note - Parallel scanning affects memory usage. Depending on the memory

available, if you set the value for parallel scanning too high, your network
operations might take a longer time or the entire network might fail.
• The DatPath and EnginePath parameters contain the path to the location of the DAT
files and the engine DLLs. By default the values of these parameters are set to
empty string (“ ”) to enable the applet to use the DAT files and engine DLLs from
the McAfee VirusScan Enterprise 8.0i package. You can however use these
parameters to specify a different location for downloading the required files.
Updating McAfee .DAT files

The ONStor VirusScan applet depends on information in the virus definition (.DAT)
files to identify viruses. Without updated .DAT files, the virus scan software might not
detect new virus strains or respond to them effectively. McAfee releases new .DAT
files every week and occasionally a new version of the virus scan engine, and makes
them available for updating.
You can schedule automatic updates of the .DAT files at regular intervals. For details,
see the McAfee VirusScan Enterprise, version 8.0i Product Guide.
15-23
Configuring the CIFS Domain

In the Windows Settings, ensure that the designated domain (CIFS) user for virus scan
operations is configured as an administrator. See your Windows documentation for
more information on how to set up the domain user as an administrator.
Step 1: Verify that the domain user has “Log on as a service” privileges
granted in the local setting. To check this, use the Windows path
Start>Control Panel>Administrative Tools>Local Security
Policy>Local Policies>User Rights Assignments>Log on as a
service. Clicking along this path invokes the “Local Security
Policy Setting” as shown in Figure 17.
Figure 17 Local Security Policy Setting
Step 2: Make sure that the checkbox for the user is marked to set the “Log
on as service” privileges for this user on Local Policy Setting. If the
designated virus scan administrator is not listed in the dialog box
that displays, click Add. Clicking Add invokes the “Security
Policy—Select Users or Groups” as shown in Figure 18 on
page 15-24.
15-24
Figure 18 Security Policy—Select Users or Groups
Step 3: Find and click the proper user in the scroll list or type the user name
in the space provided.
Step 4: Click OK when done. Make sure that the checkbox for the user for
Local Policy Setting is marked to set the “Log on as service”
privileges for this user. For more information, see your Windows
documentation.
Step 5: Within the context of the directory where the VirusScan applet files
are located, use the DOS Prompt utility to install and register the re-
implemented ONC/SUN RPC port map service by running the
following command:
portmap -register
This step registers the port mapping as a Windows Service (logon
as local system account) and starts the port map service
automatically.
15-25
Step 6: Within the context of the directory where the VirusScan applet files
are located, use the DOS Prompt utility to register and start the
VirusScan applet as a Windows service by running the following
command:
OnStorVirusScanApplet.exe -register DOMAIN USER
where:
• DOMAIN specifies the domain name.
• USER specifies your user name.
This command starts the VirusScan applet as a Windows service
automatically (logon as domainName\userName account).
Step 7: Check the service status for each of the preceding Windows
services in the Windows Service file. The registered service names
should be “ONStorRPCPortmapper” and
“OnStorVirusScanApplet”.
The two registered ONStor Windows service names should
appear as shown enclosed within the box in Figure 19.
Figure 19 Windows Service Folder Showing ONStor Windows Services
15-26
Receiving Virus Notification on CIFS Clients

To receive virus notifications on CIFS clients, the Windows Messenger Service must
be enabled on the client machines. To verify this, use the following path:
Control Panel>Administrative Tools>Services>Windows
Messenger Service
Verify that the Windows Messenger Service is started and that its startup is automatic,
which typically is no problem because Windows Messenger Service is usually enabled
by default.
Note - Ensure that the CIFS client is on the same subnet as the NAS Gateway
and that WINS is configured. Otherwise, virus notification messages might not
transmit.
15-27
Prerequisites and System Recommendations

The following sections detail the operating and hardware system recommendations for
the Symantec AntiVirus Scan Engine 5.0 or earlier, the McAfee VirusScan Enterprise
8.0i software, and the VirusScan applet.
Virus-Scan Server Recommendations for the Symantec

AntiVirus Scan Engine
The following are the operating system and hardware recommendations for running
the Symantec AntiVirus Scan Engine 5.0 or earlier:
• Microsoft® Windows Server 2000 or Advanced Server with Service Pack 2 or
later
• 500 MHz Pentium III
• 256 MB RAM
• 25 MB hard disk space available
• 1 NIC running TCP/IP with a static IP address
• Web-based administration requires Microsoft Internet Explorer 6.0 with Service
Pack 1 or later
• Live update of virus definitions requires an Internet connection
Virus-Scan Server Recommendations for the McAfee

VirusScan Enterprise 8.0i Software
See the documentation that accompanied your McAfee VirusScan Enterprise 8.0i
software package for details on system requirements.
Virus-Scan Server Recommendations for the VirusScan Applet

Follow these considerations for running the VirusScan applet:
• For running the VirusScan applet, we recommend the Windows 2000, with Service
Pack 2, or a later operating system.
15-28
• If you are running the VirusScan applet on the same server as the McAfee
VirusScan Enterprise 9.0i software, 15 MB hard disk space is required for the
installation of the applet and one network interface card (NIC) running TCP/IP
with a static IP address.
• The ONStor VirusScan applet needs to access files in read/write mode in the
virtual server. Therefore the user account that launches the applet must be
configured with the BACKUP and RESTRORE privilege. The scope of the
privilege can be either VIRTUAL SERVER or CLUSTER. To enable virus
scanning, configure the privilege before starting the ONStor VirusScan applet, or
restart the applet after you configure the privilege. Use the priv add command to
configure privileges for the user account. For more information about this
command, see “Managing Privileges” on page 2-1.
15-29
Configuring the Symantec AntiVirus Scan

Engine
To the VirusScan applet, the Symantec AntiVirus Scan Engine is an out-of-process
scan engine. The applet uses the Symantec scan engine’s client API library. Virus-
scanning operations can have the following results from the Symantec AntiVirus Scan
Engine viewpoint:
• File is clean (read and write operations can proceed).
• File was infected and deleted.
• Insufficient server resources.
• Access denied.
• License expired.
• Internal error.
You need to configure the Symantec AntiVirus Scan Engine to use Internet Content
Adaptation Protocol (ICAP), a request/response-based protocol, to communicate with
the clients (ICAP version 1.0—RFC 3507, April 2003). Refer to the Symantec
AntiVirus Scan Engine documentation for instructions on how to do this.
15-30
Configuring the McAfee VirusScan Enterprise

8.0i Software
The VirusScan applet uses the McAfee AntiVirus Engine API of the McAfee
VirusScan Enterprise 8.0i package as an in-process scan engine. The applet links the
scan engine DLLs and accesses the scan engine directly in the same process.
Virus-scanning operations can have the following results from the McAfee Anti-Virus
Engine API viewpoint:
• File is clean (read and write operations can proceed).
• Insufficient server resources.
• Access denied.
• License expired.
• Internal error.
Refer to the documentation that accompanied your McAfee VirusScan Enterprise 8.0i
package for details on how to configure the software package.
15-31
Managing Virus Scanning From the CLI

Managing virus scanning from the CLI can involve the following tasks:
• Adding a virus scan server
• Deleting a virus scan server
• Showing the virtual server virus scan server configuration
• Listing virus scan statistics
• Displaying the virus scan log
• Clearing the virus scan log
• Enabling virus scanning for incoming traffic
• Disabling virus scanning for incoming traffic
• Enabling virus scanning for outgoing traffic
• Disabling virus scanning for outgoing traffic
• Listing the file extensions that should be scanned
• Adding file extensions for scanning
• Removing file extensions from scanning
• Replacing the list of file extensions to be scanned
Adding or Deleting a Virus Scan Server

The virtual server can be in enabled or disabled state when you add or delete a virus
scan server. You can add or delete virus scan servers one at a time. For details on how
to configure a virtual server, see “Working with Virtual Servers” on page 3-1.
Have the IP addresses of available virus scan servers ready for entering into the
appropriate commands.
15-32
Note - Have your third-party equipment with the virus scanning engine set up,
powered on, connected, installed, and configured before you add a virus scan
server.
Have your VirusScan applet installed and properly configured on the server
running the virus scanning engine such that it communicates with the virus
scanning engine.
To Add a Virus Scan Server to the List of Available Virus Scan Servers
for Your Virtual Server
Step 1: In the virtual-server context, run the vscan server show
command to see if any virus scan servers have been added to the
virtual server and to see what the configurations are.
Step 2: To add a virus scan server (the virtual server can be in enabled or
disabled state), run the following command:
vscan server add IPADDR
IPADDR is the IP address of the selected virus scan server.
Before deleting the last virus scan server from a virtual server, disable virus scanning
on that virtual server.
To Delete a Virus Scan Server
• To delete a virus scan server, run the following command from a
virtual server context:
vscan server delete IPADDR
IPADDR is the IP address of the selected virus scan server.
Displaying the Virtual Server Virus Scan Server Configuration

The virtual server virus scan configuration status information display includes:
• Delete infected files (yes or no, default is no)
• Quarantine infected files (yes or no, default is no)
15-33
• Incoming CIFS (disabled or enabled, default is disabled)

• Outgoing CIFS (disabled or enabled, default is disabled)
• Allow access to CIFS clients if scan fails (yes or no, default is no)
• Incoming NFS (disabled or enabled, default is disabled)
• Outgoing NFS (disabled or enabled, default is disabled)
• Allow access to NFS clients if scan fails (yes or no, default is no)
• The virus scan servers (IP address or multiple IP addresses of assigned virus scan
servers)
To Display the Configuration of a Virtual Server’s Virus Scan
vscan server show
Displaying the Virus Scan Log

One log exists for all virtual servers, but after the date-time stamp, the records are
prefixed with the virtual-server name ID for filtering.
The log’s display includes the following:
• Events logged with most recent event at top, in chronological order:
- month, day, time (hh:mm:ss)
- NAS Gateway name ID
- scanner (Symantec AntiVirus Scan Engine or McAfee AntiVirus
Engine API)
- status of the scanner
- applet restarts
- file names of infected files and action taken
- communication errors between the NAS Gateway and applet
You do not need to be in virtual-server context to use this command.
15-34
To List the Virus Log

vscan log show [NUMLINES]
NUMLINES is the number of lines from the end to be displayed.
Clearing the Virus Scan Log

One log exists for all virtual servers but after the date-time stamp, the records are
prefixed with the virtual-server ID for filtering. You can clear the log of all records
from the CLI by running the vscan log clear command from the virtual server
context.
To Clear the Virus Log
vscan log clear
Configuring Virus-Scanning Activity with the Virus-Scan Log

Virus-scanning activity is logged, and you can configure some virus-scanning
activities with the log from the NAS Cluster Manager. One log exists for all virtual
servers, but after the date-time stamp, the records are prefixed with the virtual-server
name ID for filtering. Configuring virus-scanning activities with the virus-scan log can
only be done from the CLI. You can configure and display the following:
• Specify the syslog host for sending virus scan log messages using the vscan log
host command.
• Specify the facility code to be used by the virus scan log using the vscan log
facility command.
• Display the current virus scan log configuration using the vscan log show config
command.
To View the Current Virus Scan Log Configuration
vscan log show config
15-35
This command displays the current virus scan log configuration that applies to the
virus scan log.
Note - If the virus scan log is on a remote host, this command does not display
any virus scan log messages. You can specify the virus scan log to be located
on a remote host by the vscan log host command. See the next section for
details.
Specifying the syslogd Host for Sending Virus Scan Log

Messages
The virus scan log facility interfaces with the standard syslogd capability.
To Specify the Syslogd Host for Sending Virus Scan Log Messages
vscan log host IPADDR
IPADDR specifies the IP address of a remote host that runs
syslogd and can receive virus scan log messages from this NAS
Gateway.
Specifying the Facility Code to Be Used by the Virus Scan Log

The virus scan log facility interfaces with the standard syslogd capability.
To Specify the Facility Code to be Used By the Virus Scan Log
vscan log facility {local0 | local1 | local2 | local3
| local4 | local5 | local6 | local7}
The default facility code is local0.
15-36
Enabling or Disabling Virus Scanning for Incoming Traffic

To Enable or Disable Virus Scanning on a Virtual Server for Incoming
Traffic
Step 2: To enable virus scanning for incoming traffic, run the following
command:
vscan enable incoming PROTOCOL [,PROTOCOLS]
PROTOCOL is a protocol, which can be either CIFS or NFS. Case
is ignored. Multiple protocols are separated by commas.
Step 3: To disable virus scanning for incoming traffic, run the following
command:
vscan disable incoming PROTOCOL [,PROTOCOLS]
Step 4: You are prompted to confirm disabling virus scanning of incoming
traffic. Enter “y” to confirm the action, or “n” to continue virus
scanning of incoming traffic.
Enabling or Disabling Virus Scanning for Outgoing Traffic

Displays the list of virus scan servers configured for the virtual server and current
configuration settings.
To Enable or Disable Virus Scanning on a Virtual Server for Outgoing
Traffic
Step 2: To enable virus scanning for outgoing traffic, run the following
command:
15-37
vscan enable outgoing PROTOCOL [,PROTOCOL]

[-scanfailureok]
Options and
Description
Arguments
PROTOCOL Specifies either the CIFS or NFS protocol. Case is ignored.

Multiple protocols are separated by commas.
-scanfailureok An optional parameter to allow the read to proceed if a virus scan

cannot be completed. By default, if virus scanning cannot be
completed, the scan fails and the file transfer does not occur.
Step 3: To disable virus scanning for outgoing traffic, run the following
command:
vscan disable outgoing PROTOCOL [,PROTOCOL]
Step 4: You are prompted to confirm disabling virus scanning of outgoing
traffic. Enter “y” to confirm the action, or “n” to continue virus
scanning of outgoing traffic.
Listing the File Extensions that Should Be Scanned

The NAS Gateway accesses a list of common extensions that have been known to
contain malicious code. This default list is used to determine which files are scanned
for viruses.
To List the File Extensions That Should Be Scanned
vscan extension show
The following default extensions are scanned by the NAS Gateway virus scan
application:.
386 CPL HTM MSO PPT VSD
15-38
ACM CSC HTML OBD RTF VSS
ACV CSH HTT OBT SCR VST
ADT DLL INF OCX SH VXD
AX DOC INI OV. SHB WSF
BAT DOT JS PIF SHS WSH
BIN DRV JSE PL SMM XL
BTM EXE JTD PM SYS
CLA HLP MDB POT VBE
COM HTA MP. PPS VBS
Adding or Deleting File Extensions For Scanning

A default list of extensions exists, but you can add or delete extensions on your NAS
Gateway virus-scan configuration extension list.
To Add or Delete File Extensions
Step 1: In the virtual server context, run the vscan extension show
command to display what extensions are currently enabled for
scanning.
Step 2: To add a file extension, run the following command:
vscan extension add EXTENSION [,EXTENSION]
EXTENSION is any alphanumeric string between 1 and 4
characters. It can also include a “.” that matches any single
character. Case is ignored. Choose an extension from the default
list below, or if you have a specific extension not mentioned in
the following list, specify it in this command with this string.
Multiple extensions are separated by commas.
Step 3: To delete a file extension, run the following command:
vscan extension delete EXTENSION [,EXTENSION]
EXTENSION is an alphanumeric string between 1 and 4
15-39
characters. Only an exact match with an existing scanned

extension is removed. It can also include a “.” that matches any
single character. Case is ignored. Multiple extensions are
separated by commas.
Replacing the List of File Extensions to be Scanned

Sets the list of extensions as the virus scan extensions.
To Replace the List of File Extensions That Should Be Scanned
Step 1: In the virtual-server context, run the vscan extension show
scanning.
vscan extension set EXTENSION [,EXTENSION]
EXTENSION is any alphanumeric string between 1 and 4
characters. It can also include a “.” that matches any single
character. Case is ignored. Multiple extensions are separated by
commas.
Resetting the List of File Extensions to the System Default

EverON software supports the following default file extensions that can be scanned:
386 CPL HTM MSO PPT VSD
ACM CSC HTML OBD RTF VSS
ACV CSH HTT OBT SCR VST
ADT DLL INF OCX SH VXD
AX DOC INI OV. SHB WSF
BAT DOT JS PIF SHS WSH
BIN DRV JSE PL SMM XL
BTM EXE JTD PM SYS
15-40
CLA HLP MDB POT VBE
COM HTA MP. PPS VBS
To Reset a Customized List of File Extensions to the Default List

Step 1: In the virtual-server context, run the vscan extension show
scanning.
vscan extension reset
Chapter 16: Managing NAS Gateway
System Settings
• “Introducing NAS Gateway System Management” on page 16-2
• “Displaying IP Statistics” on page 16-17
• “Displaying File Processing Port Load Statistics” on page 16-18
• “Managing NAS Gateway System Health” on page 16-19
• “Working with the Read Ahead Cache” on page 16-32
• “Working with Core Dumps” on page 16-34
16-2
Introducing NAS Gateway System Management
Displaying System Software Version

Displays a version string that identifies the system software that is currently installed
on the NAS Gateway.
To View the Current System Software Version
system version [-s]
-sdisplays the software version running on the standby
CompactFlash card.
Displaying Specific Software Versions

Displays version information about the hardware and software that is operating on the
NAS Gateway. The version information includes software revisions for each module
and version numbers of major hardware components.
To View Details of the Current System Software Version
system show version
Displaying NAS Gateway System Information

Displays summary information about the NAS Gateway, such as NAS Gateway name,
current date & time, timezone, system uptime, system temperature, active flash
software version, chassis information, NTP configuration, sc1 & sc2 IP addresses, and
the total number of virtual servers.
To View Detailed System Information About the Current NAS Gateway
system show summary
This command displays the following details:
• NAS Gateway name
16-3
• NAS Gateway date, time, time zone, and system uptime

• NAS Gateway temperature
• NAS Gateway software version
• NAS Gateway chassis information
• NTP servers configured for this NAS Gateway
• sc1 and sc2 IP addresses
• Number of virtual servers assigned to this NAS Gateway
Displaying the System Time

Shows the current time and how long the system has been running.
To Display the Current System Time and How Long the System Has Been
Running
system show uptime
Displaying the Chassis Temperature

The NAS Gateway displays the last gathered temperature reading in number of
degrees centigrade (ºC). The formula for converting ºC to ºF is [(ºC * 1.8) + 32]. If the
temperature sensor is not able to read the temperature, the NAS Gateway displays a
zero (0).
To Display the Chassis Temperature
system show temperature
Displaying the NAS Gateway’s Node Name

The NAS Gateway’s node name is a unique name that is assigned as part of the startup
script. The node name enables NAS Gateway’s to interact with each other as unique
entities.
16-4
To Display the NAS Gateway’s Node Name

system show nodename
Displaying the Chassis Configuration

Displays information about the hardware that is installed in the NAS Gateway.
Information displayed includes:
- Which module is installed in each slot
- The number of modules installed in the NAS Gateway
- The number and state of the CPUs on each module
To View the Chassis Configuration
system show chassis
Halting the NAS Gateway

Use the system halt command to stop all active internal processes on the NAS
Gateway without having to power cycle the system or initiate a restart. When you halt
the system, you can expect the following occurrences:
• All user transactions stop.
• All internal processes halt, with the exception of a few management functions.
• The system remains online, but inactive.
• The system remains powered on.
• The configuration file does not change.
To reactivate the NAS Gateway, you need to power cycle or restart.
To Stop the NAS Gateway
system halt
16-5
Pinging Another Device from the NAS Gateway

The NAS Gateway supports ping functionality to an IP address or host name.
To Send a Ping
system ping {HOSTNAME|IPADDR} [-n COUNT]
Options and
Description
Arguments
HOSTNAME Specifies the host name of the device you are pinging. If you are
pinging to a host name or gateway name, the name needs to be a DNS
of NIS resolvable name.
IPADDR Specifies the IP address of the node that you are pinging.
-n COUNT Specifies the number of responses to display.
Performing Traceroute to an IP Address

The NAS Gateway supports traceroute functionality to an IP address or host name.
To Perform a Traceroute From the NAS Gateway
system traceroute {HOSTNAME|IPADDR}
HOSTNAME is the name of the host or gateway you are tracing. If
you are tracing the route to a hostname or gateway name, the
name must be resolvable through DNS or NIS.
IPADDR is the IP address of the node to which you are performing
a traceroute.
Working with System Time

The NAS Gateway keeps accurate system time for time stamping of many features
such as event log (elog) and autosupport, and operations such as uptime and file
system creation time. System time is maintained through one of two sources:
16-6
• An NTP server. The NAS Gateway uses an NTP v4 implementation.

• The real-time clock chip on the SSC.
Note - To avoid discrepancies, always run the system time set command on
all NAS Gateways in the cluster, and run this command before configuring the
NTP server.
Change in Daylight Saving Time (DST)

ONStor’s product release has been modified to reflect the latest available timezone
information for all zones. The US Congress mandated that there should be a change to
the Daylight Saving Time (DST) start and end days from 2007.
Note - ONStor recommends that an upgrade of a cluster be started with plenty

of time to complete the update on all filers in a cluster before DST starts.
Otherwise, until all filers are updated to the same version, it is possible that
some show different times during DST.
Setting System Time

Always set the system time on all NAS Gateways in a cluster.
To Set the System Time
system time set [[[[[[cc]yy]mm]dd]HH]MM[.SS]]
Options and
Description
Arguments
cc Specifies two digits of the current millennium.
yy Specifies two digits for the current year.
mm Specifies two digits for the current month.
16-7
Options and
Description
Arguments
dd Specifies two digits for the current date.
HH Specifies two digits for the current hour, in 24-hour time.
MM Specifies two digits for the current minutes.
.SS Specifies two digits for the current seconds. Separate minutes (MM) and
seconds (.SS) with a period.
Synchronizing System Time with an NTP Master Time Server

The NAS Gateway listens for NTP time signals on TCP port 123.
To Synchronize the NAS Gateway With an NTP Master Server
system time ntp server -a|-d IPADDR
-a|-d indicates that you are adding a server to the server list
(-a) or deleting a server from the list. (-d).
IPADDR is the IP address of an NTP server.
Disabling the NAS Gateway from Synchronizing with NTP

Servers
Note - If NTP was active on the NAS Gateway, then you disable NTP, the NAS
Gateway must be rebooted in order for it to begin re-synchronization with a
specific server or a broadcasted time signal on TCP port 123.
To Disable Listening for NTP Broadcasts

system time ntp disable
16-8
Setting the NAS Gateway’s Time Zone

You can program the NAS Gateway’s realtime clock automatically with time from a
NTP server. Because NTP uses GMT, the NAS Gateway uses the local time zone and
converts it to GMT.
To Set the NAS Gateway’s Time Zone
Step 1: Run the following command to display the current time zone
programmed into the NAS Gateway:
system time zone
• If the time zone displayed is correct, no further configuration
is required.
• If the time zone displayed is incorrect, proceed with the next
steps.
Step 2: Run the following command to display all the current time zones
available to the NAS Gateway:
system time zone -l
-l lists all the supported time zones by geographical region. Pick
the time zone that is closest to your location. Make sure you note
the time zone exactly as it is displayed. You will need to enter the
time zone string exactly as it is displayed.
Step 3: Run the following command to program in the time zone you found
from the time zone list:
system time zone TIMEZONE
TIMEZONE is the time zone string that you have noted from the
time zone list displayed in the previous step.
Displaying the Current System Time

This command displays the NAS Gateway's day of the week, month and date, time
zone, and year.
16-9
To Display the Current System Time

system time show [-v]
-v is an optional argument that indicates verbose mode for NAS
Gateways that receive their time information from an NTP server.
Verbose mode shows not only the system time, but also
information about the NTP server, stratum, the amount of time
lost as time signals traverse servers and stratum, and so on. If you
do not use the -v argument, the currently programmed system
date and time are displayed.
Displaying Load Average for CPUs in the Main Data Path

The NAS Gateway enables you to see the amount of load that each CPU in the main
data path by running the stats show ldavg command. The main data path is the
series of hardware components that are involved with processing file service I/O to or
from CIFS or NFS clients. The stats show ldavg command tracks information for
the amount of load on each of the following processors, and is useful for determining
which CPUs are more busy or less busy for any given user load:
• The NCPU, which processes transport traffic
• The ACPU, which processes the bulk of the CIFS and NFS traffic
• The FP1 and FP2 CPUs, which processes the file system traffic
• The FC CPU, which processes the SCSI traffic
Note - The SSC is not in the main data path, so the load on SSC CPUs is not
displayed.
For these processors, the load average displays a value between zero (0) and one (1)
that indicates how loaded each processor is. Zero indicates that the processors has no
load; one indicates that the processor is at full load; and a decimal value between 0 and
1 indicates the percentage of load on the processors. The stats show ldavg command
16-10
gathers the processor loads by using a polling model. Each polling interval is
approximately 1 to 2 seconds long.
To Display the Load Average for CPUs in the Main Data Path
stats show ldavg
Working With an Event Log (elog)

Elog provides messages about system activity of various levels. Elog messages are
prioritized with the same priority levels used by the standard UNIX syslog program.
You can display elog messages on the console or forward them to an elog host.
Setting Elog Message Levels

You can set specific elog levels to have the NAS Gateway report system events to
either the console or to a remote elog host.
The following list shows elog messages in least-severe to most-severe order:
• Debug
• Info
• Notice (this is the default level)
• Warning
• Error
• Critical
• Alert
• Emergency
To Set the Elog Level
elog level {debug|info|notice|warning|error|
critical|alert|emergency}
• debug|info|notice|warning|error|critical|alert|em
16-11
ergency is the minimum level of elog message that you want the NAS
Gateway to report. Select only one value and that value plus all values of
greater severity will be reported. The default level is warning.
Enabling or Disabling Elog Messaging Software

This command is used to enable or disable the elog state. When the elog state is
disabled, no elog messages are forwarded to the syslog daemon. By default elog state
is enabled.
To Enable or Disable the Elog Messaging Software
elog state {enable|disable}
Setting the Elog Local Facility Level

The elog facility interfaces with the standard syslogd capability to provide logging of
important system information at the desired level of priority. By using this facility,
system messages can be saved locally, forwarded to a remote host, and displayed on
the system console.
To Set the Elog Local Facility Level
elog facility {local0|local1|local2|local3|local4
|local5|local6|local7}
• local0|local1|local2|local3|local4|local5|local6|
local7 is a list of choices that set the local facility level for
the elog message coming from a specific NAS Gateway to an
elog host.
Specifying the Elog Host

The elog host is the system that is running Syslog functionality to receive elog
messages. Elog messages can be forwarded to Syslog daemons running on the
specified elog host. The address you specify determines whether elog messages are
forwarded to a remote host or the local host:
16-12
• If the host address is set to 0 all elog messages are forwarded to the local syslog
daemon and eventually stored in /usr/local/agile/log/messages.
• If a non-zero syslog host is specified all messages are forwarded to the specified
host using the currently configured facility code.
Note - If you set the Syslog host to a valid IP address, make sure that the
remote syslog host is configured to receive syslog messages from other hosts.
To Specify the Elog Host

elog host IPADDR
IPADDR is the address of the network-attached host that will
receive elog messages.
Displaying the Elog Message Log

This command displays the locally stored elog messages.
To Display the Elog Message Log
elog show log [NUMLINES]
NUMLINES is an optional numerical value that causes the NAS
Gateway to display the number of lines that is specified. The
number of lines is displayed descending from the most recent
message.
Searching the Elog Message Log

Because the event log message log can support numerous messages, the NAS Gateway
supports a basic keyword search engine for locating text strings within the event log
message log.
16-13
To Perform a Keyword Search Through the Elog Message Log

elog find KEYWORD
KEYWORD is a character string from 1 to 32 characters in length
that you want to find in the elog message log. The NAS Gateway
will attempt to exactly match the character string you enter with a
character string in the elog message log.
Clearing the Elog Message Log

The elog clear log command deletes all entries in the event log. When you run this
command, the event log is immediately cleared, and it can begin accepting messages
whenever new system events occur.
To Delete the Elog Message Log
elog clear log
Displaying Elog System Settings

You can display the following elog configuration information:
• The state of elog software, either enabled or disabled.
• The configured elog message level. All messages equal to or greater than the
configured severity are displayed.
• The currently configured elog level for reported messages.
• The currently configured elog facility
• The currently configured elog host address.
To View the Elog System Configuration
elog show config
16-14
Enabling or Disabling Elog Console Display

By default, the elog messages are enabled so that you can view the any elog messages
on the management console.
To Enable or Disable the Display of Elog Messages on the Management
Console
elog display {enable|disable}
• If enabled, whenever system events equal to or greater than
the configured severity occur, the elog message is displayed.
Messages can be displayed during any management task you
are performing. This is the default.
• If disabled, elog messages are written to the elog messages
file, but not displayed on the SSC.
Making a Backup Copy of the System Configuration

The NAS Gateway’s configuration exists in the cluster database. The NAS Gateway
supports the cluster database on one of two CompactFlash cards. You can copy the
NAS Gateway configuration from the database of the active CompactFlash card to the
database of the standby CompactFlash card.
To Make a Backup Copy of the System Configuration
system config copy
Note - This command is closely associated with the system config restore
command, which enables you to restore the secondary system configuration
that has been saved through the system config copy command.
16-15
Resetting the NAS Gateway Configuration to Defaults

Resetting the NAS Gateway’s system configuration to an initial configuration removes
the existing cluster database from the CompactFlash card, allowing you to reconfigure
the NAS Gateway.
Note - To reconfigure the NAS Gateway after deleting the cluster database,
reboot the NAS Gateway. When the NAS Gateway reboots, it proceeds
through the ONStor Configuration Tool (OCT) through which you can
configure the NAS Gateway. When you finish the bootup script, the NAS
Gateway will be online and operating with a default configuration that you can
customize to your needs.
To Reset the NAS Gateway Configuration

system config reset
Restoring the Last Saved System Configuration

If you have a backup copy of the NAS Gateway’s system configuration, you can
restore the NAS Gateway from the most recently saved cluster database.
After you restore the configuration, you can modify the active configuration to your
needs without affecting the saved backup copy of the system configuration. When you
restore the configuration, you do not delete the secondary copy of the cluster database
that resides on CompactFlash card.
To Restore the Last Saved Configuration File
system config restore
16-16
Note - This command is closely associated with the system config copy
command, which enables you to create a backup copy of the system
configuration that can then be restored through the system config restore
command.
Copying All Files

The NAS Gateway supports copying all files on the NAS Gateway’s CompactFlash
card from the active CompactFlash card to the standby CompactFlash card. You might
experience a delay as the files are copied, but the system remains online and serves
read and write requests during any delay from the copying.
To Copy All Files on the NAS Gateway’s CompactFlash
system copy all
Initializing the Standby CompactFlash Card

You initialize the standby CompactFlash card then duplicate the file system from the
primary CompactFlash card on the secondary disk through. Initializing the standby
CompactFlash card is analogous to formatting a disk. It clears the CompactFlash card
of any contents and formats the disk with file system structure prior to copying any
files from the active CompactFlash card to the standby CompactFlash card.
To Initialize the Standby CompactFlash Card
system copy init
16-17
Displaying IP Statistics
The NAS Gateway compiles statistics and usage information for its IP interfaces and
its connection-oriented interfaces, such as transmission control protocol (TCP) and
user datagram protocol (UDP) ports. You can display system wide information about
the IP layer protocols supported, and the TCP and UDP connections established on the
NAS Gateway. The IP statistics table consists of the following parts that are displayed
in a scrolling list:
• IP statistics
• ICMP statistics
• IGMP statistics
• IP Encapsulation statistics
• TCP statistics
• UDP statistics
Note - Some of listed statistics are returned by the kernel software. The NAS
Gateway does not use all of the listed statistics.
To Display the IP Statistics

system show ipstat
16-18
Displaying File Processing Port Load Statistics

You can view the amount of traffic load that occurs on all file processing ports.
The statistics gathered are:
• The speed, measured in packets per second, of transmitted and received traffic.
This statistic uses either Kilo (1024) or Mega (1024 * 1024) to indicate a large
value of packets per second.
• The throughput, measured in bytes per second, of transmitted and received traffic.
This statistic uses either Kilo (1024) or Mega (1024 * 1024) to indicate a large
value of bytes per second.
The NAS Gateway tracks the file processing port usage on a port by port basis and
displays the output for each port.
To Display File Processing Port Load Statistics
port show loadstats [-i SECONDS]
-i SECONDS is an optional argument for specifying the interval
of time that statistics are displayed. During the interval, statistics
are displayed once per second. Enter a value from 1 to 1000. The
default interval is 5 seconds.
16-19
Managing NAS Gateway System Health

The NAS Gateway supports gathering system health information, which is helpful
when troubleshooting the NAS Gateway. You can gather system health and
performance data and send that information to ONStor Customer Support without
having to allow an ONStor Technical Support Engineer to log in to your NAS
Gateway to gather information.
The system get commands enable you to gather either all pertinent information as a
batch, or individual pieces of the overall system health information. The following list
shows the new system get commands and what they support:
• system get all, which gathers all system information and related files. For more
information, see “Gathering All System Health Information” on page 16-21.
• system get config, which gathers system configuration information. For more
information, see “Getting System Configuration Information” on page 16-23.
• system get logs, which gathers all system log files. For more information, see
“Getting the Log Files” on page 16-25.
• system get stats, which gathers all system performance stats. For more
information, see “Getting the NAS Gateway Statistics” on page 16-26.
• system get tse, which gathers crash dump files and pertinent log files for
Technical Support Engineers (TSE) to use in diagnosing problems. For more
information, see “Gathering Technical Support Information” on page 16-29.
When the system get commands complete, they write the system health information
to a target location. By default, the output is sent to the root of the management
volume. However, through software, you can configure the output to be written to a
nondefault target directory anywhere in the file system.
Note - Create the directory where the system information will be written.
Otherwise, the system get commands cannot complete.
For example, assume the /tmp/onstor/support directory has been created. When
you run the system get commands, the output file is written to the target location in
the following format:
16-20
system_get_TYPE,HOST,DATE<.NUM>
The output file contains the following format:
• type is the type of information that the system get command retrieved. Valid
values are all, config, logs, stats, or tse. These values refer to the types of output
information.
• host is the host name.
• date is the year, month, and date when the system get command retrieved the
information.
• NUM is an optional format and a number that identifies individual copies of
information if multiple copies exist with the same date stamp. The NUM element is
appended only if more than one directory is output by the system get commands
on the same day.
Here are some examples of the output:
• system_get_all,ONStor0,05-03-18 indicates that the system get all
command gathered information from the NAS Gateway named ONStor0 on March
18, 2005.
• system_get_all,ONStor0,05-03-18.1 indicates that the system get all
command gathered a second iteration of information from the NAS Gateway
named ONStor0 on March 18, 2005.
• system_get_stats,ONStor0,05-03-19 indicates that the system get stats
commands gathered information from the NAS Gateway named ONStor0 on
March 19, 2005.
• system_get_config,ONStor0,05-03-20 indicates that the system get config
command gathered information from the NAS Gateway named ONStor0 on March
20, 2005.
The system get commands are supported on a per-NAS Gateway basis.
16-21
Gathering All System Health Information

You can gather all system information and log files into one file through the system
get all command. This command packs all the components of the system health
information into one file. The system information that is gathered includes:
• All log files
• Pertinent system statistics
• The cluster database
• Current system configuration information
This information is placed in a directory on the target location. By default, the target
location is the management volume, but you can specify any other volume in the file
system. The system health information can exist in the same directory as user data or
in a separate directory.
If multiple copies of the information exist for the same date, a number is appended to
the end of the new file name to prevent overwriting the existing file.
When the system get all command stops, a symlink is created to the most recent
system_get_all information. This symlink always points to the latest iteration of the
system_get_all information. Therefore, you can always find the most recent
information by following the symlink. The symlink takes the format of TYPE_FILER,
where TYPE is the type of system get command that was run, and FILER is the name
of the NAS Gateway on which the command was run.
16-22
To Get All System Health Information

system get all [-n NUMBER] [-i INTERVAL] [-a]
[-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY]
[-c CASENUM]
Options and
Description
Arguments
-n NUMBER An optional argument that specifies the number of iterations in which

the command must gather all system health information. By default
the current statistics are gathered into the sfinfo.xml file. You need the
NUMBER and INTERVAL arguments only if you want to gather
statistics at a certain interval over time. For gathering statistics at a
certain interval over time, set the NUMBER argument to at least 2.
-i INTERVAL An optional argument that specifies the interval, in number of minutes,

between statistics gathering iterations. The default value is 0 minutes,
which causes no wait between iterations. Enter a number greater than
0 to specify the interval.
-a An optional argument for gathering statistics for all volumes on the

current NAS Gateway.
Because additional processing is necessary to gather data from all
volumes, this option takes additional time for the command to
complete.
-V VSVRNAME An optional argument that specifies the name of the target virtual
server where the information is saved. By default, the information is
written to the management virtual server, but you can specify a
different virtual server.
The target virtual server must exist and be enabled. If the targeted
virtual server does not exist or is not enabled, the command fails.
16-23
Options and
Description
Arguments
-v VOLNAME An optional argument that specifies the name of the target volume
where the information is saved. By default, the information is written to
the management volume, but you can specify a different volume. If
you do not want the information written to the management volume,
enter the name of an existing volume.
Note - If the target volume does not exist or is offline, the command fails.
-d DIRECTORY An optional argument that specifies the name of the target directory
where the information is saved. The default directory is the root
directory ( / ), but you can specify a different directory. If you do not
want the information written to the root directory, enter the name of an
existing directory.
Note - If the target directory does not exist, the command fails.
-c CASENUM An optional argument that enables the collected information to be

uploaded to an ONStor server through SSL, under a specific case
number (CASENUM). To use this option, a Customer Support case
must already exist, and you will use the provided case number when
you specify this argument.
Getting System Configuration Information

You can gather system configuration information and basic operational statistics
through the system get config command. The output of this command is packaged
into an .XML file and sent to a directory on the target location, which can be either the
management volume or a location that you specify.
Note - Gathering configuration information from the NAS Gateway can take
some time.
You can keep multiple copies of the system get config output because the NAS
Gateway creates a unique name for each output. If multiple copies of the information
16-24
exist for the same date, a number is appended to the end of the new file name to
prevent overwriting of the existing file.
When the system get config command stops, a symlink is created to the most
recent system_get_config information. This symlink always points to the latest
iteration of configuration information, so you can always find the most recent
information by following the symlink. The symlink takes the format of TYPE_FILER,
where TYPE is the type of system get command that was run, and FILER is the name
of the NAS Gateway on which the command was run.
To Display the System Configuration Information
system get config [-s | [-V VSVRNAME] [-v VOLNAME]
[-d DIRECTORY] [-c CASENUM]
Options and
Description
Arguments
-s An optional argument that displays the output on the management

console. If you do not display the output on the management console,
the system configuration information is displayed on either the
management volume or the location specified by the VSVRNAME,
VOLNAME, and DIRECTORY arguments.
• If you send the output to the management console, the
configuration information scrolls up the management console’s
monitor as the output of system get config is being
processed.
• If you send the output to the target location, the configuration
information is available only after you mount the target location
through an NFS or CIFS share.
written to the management virtual server.
Note - The target virtual server must exist and be enabled. If the targeted
16-25
Options and
Description
Arguments
the management volume, but you can specify a different volume. If you
do not want the information written to the management volume, enter
the name of an existing volume.
where the information is saved. By default, the default directory is the
root directory ( / ).
Note - If the target directory does not exist, the command fails
-c CASENUM An optional argument that enables you to upload the collected

information to an ONStor server through SSL, under a case number. To
use this option, a Customer Support case must already exist.
Getting the Log Files

You can get the NAS Gateway’s log files by running the system get logs command
to check them for system messages or error messages to help analyze performance
issues or debugging problems. The log files are gathered in a target directory, which by
default is the management volume or volume that you specify.
You can keep multiple copies of the system get logs output because the NAS
prevent the existing file from being overwritten.
When the system get logs command stops, a symlink is created to the most recent
system_get_logs information. This symlink always points to the latest iteration of
logs, so you can always find the most recent information by following the symlink.
The symlink takes the format of TYPE_FILER, where TYPE is the type of system get
command that was run, and FILER is the name of the NAS Gateway on which the
command was run.
16-26

system get logs [-V VSVRNAME] [-v VOLNAME]
[-d DIRECTORY] [-c CASENMUM]
Options and
Description
Arguments
written to the management virtual server,
Note - The target virtual server must exist and be enabled. If the targeted
the management volume.
directory ( / ), but you can specify a different directory. If you do not
want the information written to the root directory, enter the name of an
existing directory.
-c CASENUM An optional argument that enable you to upload the collected

information to an ONStor server through SSL, under a case number.
To use this option, a Customer Support case must already exist.
Getting the NAS Gateway Statistics

You can gather and save important system and volume statistics by running the
system get stats command. This command gathers NAS Gateways statistics for
16-27
one or all volumes. The statistics are posted to a target directory, which by default is
the management volume or a volume that you specify in the file system.
You can keep multiple copies of the system get stats output because the NAS
prevent the existing file from being overwritten.
When the system get stats command stops, a symlink is created to the most recent
system_get_stats information. This symlink always points to the latest iteration of
statistics, so you can always find the most recent information by following the
symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of
system get command that was run, and FILER is the name of the NAS Gateway on
which the command was run.
You can stop statistics gathering intervals in either of the following ways:
• If the previously configured statistics gathering interval is in progress, it stops if
you run the system get stats command.
• If the current statistics gathering interval is in progress, you can stop it by using the
optional -k argument. This option is useful if you have started the statistics
gathering interval, but need to stop it before it completes.
system get stats [-k] [-n NUMBER] [-i INTERVAL]
[-a]
[-s | [-V VSVRNAME] [-v VOLNAME] [-d DIRECTORY] |
[-c CASENUM]]
Options and
Description
Arguments
-k An optional argument that kills any in process statistics gathering

operations.
16-28
Options and
Description
Arguments
-n NUMBER An optional argument that specifies the number of iterations in which

to gather the statistics information:
• If you want to gather statistics once, leave the NUMBER and
INTERVAL arguments blank.
• If you want to gather statistics repeatedly over time, set
NUMBER to at least 2.
-i INTERVAL An optional argument that specifies the interval, in number of
minutes, between statistics gathering iterations. The default value is
0 minutes, which causes no wait between iterations. Enter a number
greater than 0. For example, 60 for hourly statistics gathering or 1440
for daily statistics gathering.
-a An optional argument for gathering statistics for all volumes on the

current NAS Gateway.
Note - Because additional processing is necessary to gather data from all

volumes, this option takes additional time for the command to complete.
-s An optional argument that controls whether to display output on the

management console or on a target location.
• If you send the output to the management console, the statistics
scroll up the management console’s monitor as the output of
system get config is being processed.
• If you send the output to the target location, the information is
available only after you mount the target location through an NFS
or CIFS share.
written to the management virtual server, but you can specify a
different virtual server. If you do not want the information written to
the management virtual server, enter the name of an existing virtual
server.
Note - If the target virtual server does not exist or is not enabled, the
command fails.
16-29
Options and
Description
Arguments
where the information is saved. By default, the information is written
to the management volume
Note - If the target volume does not exist or is not online, the command
fails.
directory ( / ).

information to an ONStor server through SSL, under a case number.
To use this option, a Customer Support case must already exist.
Gathering Technical Support Information

The system get tse command enables you to gather a subset of technical support
information that ONStor Technical Support Engineering can use to perform
troubleshooting.
Note - This command is needed only if significant parts of the NAS Gateway
are not operating and you cannot run the system get config or system get
all commands.
The system get tse command obtains system information and places it in a
directory on the target location, which is by default the management volume default,
or a volume you specify in the file system.
You can keep multiple copies of the system get tse output because the creates a
unique name for each output. If multiple copies of the information exist for the same
16-30
date, a number is appended to the end of the new file name to prevent overwriting the
existing file.
When the system get tse command stops, a symlink is created to the most recent
system_get_tse information. This symlink always points to the latest iteration of the
TSE information, so you can always find the most recent information by following the
symlink. The symlink takes the format of TYPE_FILER, where TYPE is the type of
system get command that was run, and FILER is the name of the NAS Gateway on
which the command was run.
system get tse [-V VSVRNAME] [-v VOLNAME]
[-d DIRECTORY] | [-c CASENUM]
Options and
Description
Arguments
written to the management virtual server.
Note - If the targeted virtual server does not exist or is not enabled, the
command fails.
where the information is saved. By default, the information is written
to the management volume.
command fails.
16-31
Options and
Description
Arguments
where the information is saved. By default, the default directory is the
root directory ( / ).
command fails.

information to an ONStor server through SSL, under a case number
(CASENUM). To use this option, a Customer Support case must
already exist.
16-32
Working with the Read Ahead Cache

Read ahead cache allows the NAS Gateway to process user data blocks from
applications ahead of the actual read operation that places the blocks in NAS
Gateway’s data cache. Some applications have file access patterns that require read
ahead caching. The NAS Gateway supports enabling and disabling of read ahead
caching.
Enabling or Disabling Read Ahead Caching

By default, the NAS Gateway’s read ahead caching is disabled.
Note - You can determine whether read ahead caching needs to be enabled or
disabled by running the system show readahead performance command. If
an excessive amount of cache misses is occurring, you can try enabling read
ahead caching for more optimized use of the cache. If the amount of cache
misses is acceptable, read ahead caching can be left in its current state.
To Enable Read Ahead Caching

system enable readahead
When read cached is enabled, it can optimize the read ahead of data blocks into the
NAS Gateway data cache if the NAS Gateway is reading from an application that uses
sequential file reads. However, some applications perform random file reads, and if the
NAS Gateway’s read ahead caching is enabled, the result can be excessive data cache
thrashing.
To Disable Read Ahead Caching
system disable readahead
16-33
Displaying the State or Performance of Read Ahead Caching

You can display the state of read ahead caching at any time by running the system
show readahead command. By default, this feature is enabled.
To Display the Current State of Read Ahead Caching

system show readahead state
Read ahead cache performance statistics include:
• The number of read ahead requests the NAS Gateway has received
• The number of data blocks read
• The percentage of read ahead hits in the NAS Gateway’s data cache
• The percentage of read ahead misses in the NAS Gateway’s data cache
To Display System Read Ahead Cache Performance
system show readahead performance
16-34
Working with Core Dumps

A core dump is the entire memory core of the NAS Gateway and the cores from the
file processor (FP) element. This information is written to a file if the NAS Gateway
crashes. The core dump file is written to a core volume that you configure on the NAS
Gateway’s management virtual server.
The NAS Gateway supports an automatic core dumping feature that enables flushing
of the memory core and FP cores to disk whenever the NAS Gateway encounters a
system event that causes it to reset. The core dump file that is created during a core
dump is automatically compressed during the copy operation onto the core volume.
The .gz extension indicates the compressed core dump file.
Creating a Core Dump Volume

While the raw core dump is in the core volume, it cannot be accessed for debugging
purposes. When the NAS Gateway reboots, it copies the raw core dump as a core
dump file onto the management volume, and the core dump file is accessible. When
the copy is complete, the raw core dump remains in the core dump volume until the
next crash overwrites it, and the core dump file exists as a binary file on the
management volume on the management server. The analysis and interpretation of the
core dump file’s binary data can be performed only with the assistance of ONStor
personnel.
Note - When the core volume is created, it appears in the volume show
command’s output as Status NotMounted and Type Core.
Each NAS Gateway supports only one core dump volume.
Note - To support the core volume, a configured management virtual server

must exist, and a management volume must be configured in the management
virtual server.
16-35
To Create a Core Volume

• Run the following command from the management virtual server
context:
system create corevolume VOLNAME [LUN]
Options and
Description
Arguments
VOLNAME Specifies the name of the volume that you are creating as the NAS
Gateway’s core volume. The core volume cannot support a file system.
LUN An optional argument that enables you to configure the core volume on a
specific LUN. By default, the NAS Gateway takes the first “free” LUN
when you run this command. You can use only a “free” LUN for this
argument. To get a list of LUNs, you can run the lun show disk
command, and page through the display until you find a LUN whose state
is “free”.
Deleting the Core Dump Volume

When you delete the core volume, the following occurs:
• The core volume is destroyed and any LUN assigned to it is released and returns to
“free” state.
• Any raw core dumps that exist in the core volume are deleted.
• All future core dumps cannot be written to the core volume.
• The management volume is still assigned.
Note - There is no dependency between system delete corevolume and

system modify coredump off, so you do not need to disable the core dump
feature before deleting the core volume.
To Delete the NAS Gateway’s Core Volume

16-36
context:
system delete corevolume VOLNAME [force]
Options and
Description
Arguments
VOLNAME Specifies the name of the core dump volume that you are deleting. When
the core volume is deleted, all data within it is deleted.
force An optional argument that deletes the core dump volume regardless of
any checks or processes to take the core dump volume offline gracefully.
This option is immediate.
Enabling or Disabling Automatic Core Dumping

The NAS Gateway supports an automatic core dumping feature that enables flushing
of the memory core and FP cores to disk whenever the NAS Gateway encounters a
system event that causes it to reset.
Before you enable the core dump feature, the following conditions must be met:
• A management virtual server must be configured on the NAS Gateway where you
are enabling the core dump feature.
• A management volume must be configured within the management virtual server
on the NAS Gateway where you are enabling the core dump feature.
• A core volume must be configured within the management virtual server on the
NAS Gateway where you are enabling the core dump feature.
To Enable the Automatic Core Dump Feature
context:
system modify coredump on
If you disable core dumping, the NAS Gateway retains the core volume and any core
dumps that exist on the core dump volume. Any in-progress write operations to the
management volume are allowed to complete.
16-37
To Disable Automatic Core Dumping

context:
system modify coredump off
Displaying the State of Automatic Core Dumping

During run time, you can check the state of the automatic core dump feature. The
current state displays as either ON or OFF. By default, automatic core dump is ON.
To Display the State of the NAS Gateway’s Automatic Core Dumping
Feature
context:
system show coredump
Displaying Core Dump Files

To display a list of the core dump files, you can mount and display the management
volume. When the management volume is mounted, all NFS commands, such as ls and
cp are available. You can provide the core dump files to ONStor Technical Support for
analysis and interpretation through FTP or another standard file transfer protocol.
Only ONStor personnel can interpret the core dump files.
Setting the Maximum Number of Saved Core Dump Files

By default, the NAS Gateway saves one core dump file on the management volume.
However, you can set the maximum number of core dump files to be saved on the
management volume.
To Enable the Management Volume to Retain More Than One Core Dump
File
context:
system modify coredumpmaxsavedfiles MAX
MAX is the maximum number of files to be saved. Enter a number
16-38
between 0 and 99. The default is 8.
Configuring the Volume Exception Dump File

In addition to core dump files, the NAS Gateway also supports volume dump files.
These files are written to the management virtual server whenever a volume goes
offline due to a volume exception. The volume exception dump file contains
information related to the volume at the time it went offline. All volume dump files
have the same naming convention, which consists of the volume name and a numerical
identifier.
You can configure the contents of the volume exception dump file, and enable or
disable the volume exception dump feature by running the system modify
volumeexceptiondump command. As part of this command you can specify some of
the data structures that are captured and written to the volume exception dump file
when the volume goes offline. Table 16-13 lists the types of data that the NAS
Gateway can send to the volume exception dump file.
Table 16-13: Possible Data Types for Volume Exception Dump File
Data Type Summary
FS The file system structure.
SUPERBLOCK The in-core copy of the super block.
THREADSTACKS The stacks and registers of the threads currently running.
CONTEXTS Context structures of the running threads.
LOCKS The locks obtained by the running threads.
REQUESTS The file system requests executed by the running threads.
INODESMRU The most recently used Inodes. This includes the Inodes that have
been modified and have not been written to the disk yet
BUFFERSMRU The most recently used buffers. This includes the buffers that have
been modified and have not been written to the disk yet.
INODES 1 All Inodes that were cached at the time of the exception.
BUFFERS 1 All buffers that were cached at the time of the exception.
16-39
Table 16-13: Possible Data Types for Volume Exception Dump File (Continued)
Data Type Summary
1: These data types can significantly increase the size of the volume exception dump file.
By default, not all of the data types are stored in the volume exception dump file. The
default data types stored are:
• FS (file system)
• Superblock
• Threadstacks
• Contexts
• Locks
• Requests
To Configure the Volume Exception Dump File
system modify volumeexceptiondump [-m on|off]
[-a DATATYPE] [-d DATATYPE] [-r]
Options and
Description
Arguments
-m on|off Specifies the operating mode of the volume exception dump feature.
Use this argument to turn volume exception on or off. By default, the
feature is off.
-a DATATYPE An argument for adding a specified data type to the volume exception
dump.
-d DATATYPE An argument for deleting a specified data type from the volume
exception dump.
-r An argument for resetting the data types to the default.
16-40
Displaying the State of Volume Exception Dump Feature

Displays the automatic core dump's state of on or off. This command also displays the
name of the on-disk coredump volume, the maximum number of saved core dump
files, if the volume exception core dump is on or off, and the volume exception data
types.
To Display the Current State of the Volume Exception Dump Feature
context:
system show coredump
Index
Symbols displaying 8-16

/.snapshots 9-3 Audit Log file 8-2
Numerics auditing
1.0.NAS Gateway Overview and Access 1-1 file
circular file 8-15
A
displaying config 8-16
admin
displaying log 8-16
allow
enabling 8-9
deleting 2-7
fail flag 8-13
deny
file size 8-14
adding 2-4, 2-5
setting failure 8-11
admin privileges
setting mode 8-15
displaying 2-7
setting success 8-10
alias
file audit events 8-4
tape
autocreate
displaying 14-26
deleting
removing 14-26
virtual server 3-40
setting 14-25
setting
allow admin
virtual server 3-37
deleting 2-7, 2-8
autogrow
ARP 5-9
volume
adding entries 5-10
and quotas 10-2
displaying table 5-11
autogrowth
remove entries 5-11
mirror volumes 13-5
ARP Table 5-9, 5-10
autosupport 12-2
clearing 5-11
note 12-3
displaying 5-11
notification 12-3
asynchronous mirroring 13-5
vs. elog 12-2
Audit Log
1-2
autosupport config home

displaying 12-9 configuring 3-36, 3-37
autosupport statistics deleting 3-40
displaying 12-9 displaying options
B NFS shares 7-48
backup 14-3 domain
full 14-4 configuring
incremental 14-4 NIS domain
partial 14-4 adding 3-19
backup/restore E
NAS Gateway 14-6 element
backup/restore types 14-5 file processor 1-4
C FP 1-4
CIFS SP 1-5
auditing 8-3 storage processor 1-5
share deletion 7-55 elog
share information 7-52 vs. autosupport 12-2
client exclusions email
NFS shares 7-4 autosupport 12-2
command-line contents 1-16 enable mirror 13-19
configuration environment variables
NDMP NDMP
resetting 14-34 quotas 10-5, 10-6, 10-8
configuring mirrors 13-7 F
context fan tray
virtual server fans 1-6
changing 3-50 file auditing
clearing 3-52 audit events 8-4
D Audit Log
data services 14-6 displaying 8-16
deleting CIFS 8-2
NFS shares 7-51 circular mode 8-15
deleting mirrors 13-19 configuration
deny displaying 8-16
admin enabling 8-9
deleting 2-8 fail flag
deny admin setting 8-13
adding 2-4, 2-5 failure parameters
device path setting 8-11, 8-14
mapping 14-42, 14-43 file mode
directories setting 8-15
I-1-3
Log 8-2 interfaces

success parameters management 5-4
setting 8-10 interfaces displaying 5-4
understanding 8-2 IP
file extensions adding static routes 5-7
virus scan displaying interfaces
adding 15-38 IP Interfaces Table 5-4
listing 15-37 displaying IP Table 5-6
replacing 15-39 displaying Route Table 5-8
file processing overview 1-12 management interfaces 5-4
file processor element 1-4 removing routes 5-9
file system IP Table 5-6
quota L
and autogrow 10-2 label
and NDMP 10-4 LUN 4-13
enabling 10-17 local useraccounts 14-18
NDMP log
variables 10-5, 10-6, 10-8 virus scan
snapshots clear 15-34
quota show 15-33
snapshots logging in 1-16
snapshots LUN
quota labelling 4-13
considerati LUNs
ons 10-9 foreign 4-2
foreign LUNs 4-2 LUN discovery 4-1
FP element 1-4 M
free LUNs management interfaces 5-4
LUNs management virtual server 3-4
free 4-2 management volume
H NDMP 14-12
home directory share map
share ID
home directory 3-36, 3-37, 3-40 updating
quotas 7-72, 10-22
I
media changers
ICMP 5-2
alias
ping 5-2
displaying 14-26
traceroute 5-2
removing 14-26
ID map
setting 14-25
updating
listing 14-24
for quotas 7-72, 10-22
1-4
mirror tape 14-6

delete 13-19 NDMP sessions
enabling 13-19 displaying 14-36
schedule network connectivity 1-13
modifying 13-12 NFS
session shares
displaying 13-20 client exclusions 7-4
pausing 13-23 deleting 7-51
mirror show 13-20 showing options 7-48
mirroring note
asynchronous 13-5 autosupport 12-3
autogrowth 13-5 notification
configuration 13-7 autosupport 12-3
mirrors O
considerations 13-7 on-demand snapshots
modifying mirrors 13-12 creating 9-4, 9-5
module ONStor NAS Gateway
SSC 1-4 dimensions 1-5
mount options displaying configuration 16-4
displaying 7-48 displaying uptime 16-3
mover services 14-6 halting 16-4
N performing traceroute 16-5
NAS Gateway sending pings 16-5
backup/restore 14-6 setting NTP 16-7
NDMP setting time 16-6
configuration ONStor Volume Manager 1-13
displaying 14-35 overview 1-13
resetting 14-34 overview
disabling 14-28 ONStor Volume Manager 1-13
enabling 14-28 software 1-12
management volume 14-12 file processing 1-12
quota variables 10-5, 10-6, 10-8 system control 1-12
snapshot management extensions 14-5 P
tape parameters
block size 14-33 autosupport
set model 14-31 creating 12-9
NDMP service pausing mirrors 13-23
and quotas 10-4 physical device
NDMP services 14-3 mapping 14-42, 14-43
data 14-6 portmap
mover 14-6 RPC
SCSI 14-6
I-1-5
virus scanning 15-24 clear 15-33, 15-34

privileges outgoing 15-36
admin RPC portmap 15-24
displaying 2-7 server 15-27
Q show config 15-32
quota 7-72, 10-22 uninstalling 15-17
autogrow Windows service 15-25
interaction 10-2 schedule
enabling 10-17 mirror
NDMP modify 13-12
interaction 10-4 scsi
NDMP variables 10-5, 10-6, 10-8 release
quotas 10-1 tape 14-27
R SCSI services 14-6
remote backup 14-4 server
restore 14-3 management virtual 3-4
backup 14-4 virtual
incremental 14-4 changing 3-50
partial 14-4 clearing 3-52
Route Table deleting autocreate 3-40
displaying 5-8 deleting WINS 3-36
routes 5-8 enabling 3-44
removing 5-9 moving 3-54
static setting autocreate 3-37
static route state
adding 5-7 virtual server disabled 3-3
virtual server enabled 3-3
S
understanding 3-3
sample topology 1-11
virus scan
scanning
add 15-2
virus
delete 15-32
add server 15-2
services
config
NDMP
requirements 15-18
and quotas 10-4
config files 15-18
session
delete server 15-32
mirror
extensions
displaying 13-20
adding 15-38
pause 13-23
listing 15-37
shares
replacing 15-39
CIFS
incoming traffic 15-36
deleting 7-55
log
information 7-52
1-6
NFS set model

clients exclusion 7-4 NDMP 14-31
deleting 7-51 tape alias
showing options 7-48 clear 14-21
sharing read-only 6-24 displaying 14-21
snapshot schedules setting 14-20
creating 9-6 tape device
snapshots 9-2 releasing 14-27
directory 9-3 state
on-demand 9-2 displaying 14-23
scheduled 9-2 tape library
software overview 1-12 alias
file processing 1-12 displaying 14-26
network connectivity 1-13 removing 14-26
storage processing 1-13 setting 14-25
system control 1-12 displaying 14-24
SP element 1-5 tape services 14-6
SSC 1-4 topology
SSC module 1-4 sample 1-11
state traffic 15-36
NDMP U
displaying 14-35 Updating ID map 7-72, 10-22
tape user
displaying 14-23 allow admin
statistics deleting 2-7, 2-9
autosupport user interface
creating 12-9 accessing 1-16
storage ports useraccount
statistics deleting 2-13
displaying 4-6 displaying 2-12
storage processing 1-13 modifying 2-11
storage processor element 1-5 useraccounts 14-18
system control overview 1-12 V
System Switch and Controller 1-4 virtual server
T management server 3-4
Table state 3-3
ARP 5-10, 5-11 virtual servers
table changing 3-50
ARP 5-9 clearing 3-52
tape deleting autocreate 3-40
block size deleting WINS 3-36
NDMP 14-33
I-1-7
enabling 3-44 WINS

moving 3-54 deleting
protected mode 3-54 virtual server 3-36
setting autocreate 3-37
virus scan
components
server 15-27
config
requirements 15-18
show 15-32
config files 15-18
extensions
adding 15-38
listing 15-37
replacing 15-39
incoming
enable 15-36
log
clear 15-34
show 15-33
outgoing
disable 15-36
RPC portmap 15-24
server
add 15-2
delete 15-32
traffic
incoming 15-36
outgoing 15-36
virus scanning
uninstalling 15-17
Windows service 15-25
volume
autogrow
and quotas 10-2
creating volumes 6-5
deleting volumes 6-22
displaying volumes 6-14
modifying volumes 6-15
W
Windows domain
adding 3-19
1-8

Ons Doc Sag 2200 g1 - 3100sag2007 09

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ons Doc Sag 2200 g1 - 3100sag2007 09

Caricato da

Copyright:

Formati disponibili

ONStor Bobcat™ 2200 Series

Customer Order Number: ONS-DOC-SAG-2200, Rev G1

Chapter 1: NAS Gateway Overview and Access .....................................1-1

Chapter 3: Working with Virtual Servers..................................................3-1

Chapter 4: Managing Storage and Fibre Channel ...................................4-1

Chapter 5: Working with Network Interfaces...........................................5-1

Chapter 6: Managing Volumes and File Systems ...................................6-1

Chapter 7: Managing Shares.....................................................................7-1

Chapter 8: Managing File Auditing ...........................................................8-1

Chapter 9: Managing Snapshots ..............................................................9-1

Chapter 11: Monitoring the NAS Gateway .............................................11-1

Chapter 12: Autosupport and Event Monitoring ..................................12-1

Chapter 13: Working with ONStor Data Mirror ......................................13-1

Chapter 14: Managing Backup and Restore ..........................................14-1

Chapter 15: Managing Virus Scanning...................................................15-1

Chapter 16: Managing NAS Gateway System Settings ........................16-1

1 - “NAS Gateway Overview Provides an overview of the software, hardware, and

2 - “Managing Privileges” Explains the administrative privileges supported on the

7 - “Managing Shares” Explains the EverON™ software, how it operates with

Table 1 : Document Organization (Continued)

13 - “Working with ONStor Explains the NAS Gateway’s mirroring capabilities

Document Name Part Number Revision Level

ONStor Bobcat NAS Gateway ONS-DOC-CCG-2200 D1

ONStor Bobcat 2200 Series NAS ONS-DOC-CR-2200 E1

ONStor Bobcat 2200 Series NAS ONS-DOC-CMA B1

ONStor Bobcat 2200 Series ONS-DOC-SAG- A1 01/18/05

ONStor Bobcat 2200 Series ONS-DOC-SAG- B1 03/16/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- C2 05/08/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- D1 08/15/06

ONStor Bobcat 2200 Series ONS-DOC-SAG- E1 01/23/07

ONStor Bobcat 2200 Series ONS-DOC-SAG- F1 05/18/07

ONStor NAS Gateway System ONS-DOC-SAG- G1 09/30/07

Syntax Marker Means... Example

- (dash) You are specifying an option. -a

blank space You are delimiting words, arguments, arp show

bold text Command syntax. list

bold italic text A mandatory variable. You need to ipaddr

Introducing the ONStor NAS Gateway

System Switch and Controller

NAS Gateway Chassis

• FCC Class A, Part 15

Chassis Front Panel

10/100 Ethernet GE FC Port

Figure 1-1 ONStor NAS Gateway Front Panel

Table 1-1: Chassis Front Panel Elements

Panel Element Description

NAS Gateway status LEDs Indicator of whether the NAS Gateway is

Table 1-1: Chassis Front Panel Elements (Continued)

Panel Element Description

10/100 Ethernet ports, 2 Two ports for an Ethernet or Fast Ethernet

10/100 Ethernet port LEDs, 2 Indicator of whether the NAS Gateway

CompactFlash ejectors Ejects the CompactFlash cards. Each

Table 1-1: Chassis Front Panel Elements (Continued)

Panel Element Description

Do not remove the active (amber LED) card.

CompactFlash LEDs, 2 Indicator for the CompactFlash cards. A green

Do not remove the active CompactFlash card.

GE ports, 4 GE ports of the NAS Gateway. Each port

GE port LEDs, 4 Indicator of whether the NAS Gateway’s

FC ports, 2 FC ports for the NAS Gateway. Each port

Table 1-1: Chassis Front Panel Elements (Continued)

Panel Element Description