Clustered Data ONTAP 82 File Access and Protocols

Clustered Data ONTAP 8.
2
File Access and Protocols Management Guide
NetApp, Inc.
495 East Java Drive
Sunnyvale, CA 94089
U.S.
Telephone: +1(408) 822-6000

Fax: +1(408) 822-4501
Support telephone: +1 (888) 463-8277
Web: www.netapp.com
Feedback: doccomments@netapp.com
Part number: 215-07968_A0

May 2013
Table of Contents | 3
Contents
Considerations before configuring file access .......................................... 17
File protocols that Data ONTAP supports ................................................................ 17
How Data ONTAP controls access to files ............................................................... 17
Authentication-based restrictions .................................................................. 17
File-based restrictions ................................................................................... 18
LIF configuration requirements for file access management .................................... 18
How namespaces and volume junctions affect file access on Vservers with
FlexVol volumes ................................................................................................. 19
What namespaces in Vservers with FlexVol volumes are ............................ 19
What volume junctions are ............................................................................ 19
How volume junctions are used in CIFS and NFS server namespaces ......... 20
What the typical NAS namespace architectures are ...................................... 20
How security styles affect data access ...................................................................... 23
What the security styles and their effects are ................................................ 24
Where and when to set security styles .......................................................... 25
How to decide on what security style to use on Vservers with FlexVol
volumes .................................................................................................... 25
How security style inheritance works ........................................................... 25
How unified security style supports multiprotocol access to Infinite
Volumes ................................................................................................... 26
Comparison of unified and mixed security styles ......................................... 27
Preservation of UNIX permissions ............................................................... 31
How to manage UNIX permissions using the Windows Security tab .......... 31
NFS and CIFS file naming dependencies ................................................................. 32
Characters a file name can use ...................................................................... 32
Case-sensitivity of a file name ...................................................................... 32
How Data ONTAP creates file names ........................................................... 33
Use of hard mounts ................................................................................................... 33
How Data ONTAP supports file access using NFS ................................. 34

How Data ONTAP handles NFS client authentication ............................................. 34
CIFS file access from NFS clients ............................................................................ 34
Supported NFS versions and clients .......................................................................... 35
4 | File Access and Protocols Management Guide

NFSv4.0 functionality supported by Data ONTAP .................................................. 35
Limitations of Data ONTAP support for NFSv4 ...................................................... 35
Data ONTAP support for NFSv4.1 ........................................................................... 36
Data ONTAP support for parallel NFS ..................................................................... 36
Process for NFS access to UNIX security style data on Vservers with FlexVol
volumes ................................................................................................................ 37
Process for NFS access to NTFS security style data on Vservers with FlexVol
volumes ................................................................................................................ 37
Setting up file access using NFS ................................................................ 38

Creating and managing data volumes and the NAS namespace ............................... 38
Creating data volumes with specified junction points .................................. 38
Creating data volumes without specifying junction points ........................... 39
Mounting or unmounting existing volumes in the NAS namespace ............. 40
Displaying volume mount and junction point information ........................... 42
Configuring security styles ........................................................................................ 43
Configuring security styles on Vserver root volumes ................................... 43
Configuring security styles on FlexVol volumes .......................................... 44
Configuring security styles on qtrees ............................................................ 44
Modifying protocols for Vservers ............................................................................. 45
Enabling or disabling NFSv3 .................................................................................... 46
Enabling or disabling NFSv4.0 ................................................................................. 46
Enabling or disabling NFSv4.1 ................................................................................. 46
Enabling or disabling parallel NFS ........................................................................... 47
Creating an NFS server ............................................................................................. 47
Securing NFS access using export policies ............................................................... 48
How export policies control client access to volumes .................................. 48
Default export policy for a Vserver with FlexVol volume ........................... 49
How export rules work .................................................................................. 49
How to handle clients with an unlisted security type .................................... 51
How security types determine client access levels ........................................ 53
How to handle superuser access requests ...................................................... 55
Creating an export policy .............................................................................. 57
Adding a rule to an export policy .................................................................. 57
Setting an export rule's index number ........................................................... 60
Associating an export policy to a FlexVol volume ....................................... 61
Export policy restrictions and nested junctions for FlexVol volumes .......... 62
Using Kerberos with NFS for strong security ........................................................... 62
Group ID limitation for NFS RPCSEC_GSS ................................................ 63
Requirements for configuring Kerberos with NFS ....................................... 63
Specifying the user ID domain for NFSv4 .................................................... 66
Configuring a Vserver to use LDAP ............................................................. 67
Creating a Kerberos realm configuration ...................................................... 67
Creating an NFS Kerberos configuration ...................................................... 69
Creating a new LDAP client schema ............................................................ 69
Creating an LDAP client configuration ........................................................ 70
Enabling LDAP on a Vserver ........................................................................ 72
How name mappings are used ....................................................................... 73
Configuring local UNIX users and groups ................................................................ 77
Creating a local UNIX user ........................................................................... 77
Loading local UNIX users from a URI ......................................................... 78
Creating a local UNIX group ........................................................................ 79
Loading local UNIX groups from a URI ...................................................... 79
Adding a user to a local UNIX group ........................................................... 80
Loading netgroups into a Vserver ................................................................. 81
Creating a NIS domain configuration ....................................................................... 81
Support for NFS over IPv6 ........................................................................................ 82
Enabling IPv6 for NFS .................................................................................. 82
Managing file access using NFS ................................................................ 83

Controlling NFS requests from nonreserved ports .................................................... 83
Considerations for clients that mount NFS exports using a nonreserved port .......... 84
Commands for managing NFS servers ...................................................................... 84
Commands for managing name mappings ................................................................ 84
Commands for managing local UNIX users ............................................................. 85
Commands for managing local UNIX groups ........................................................... 85
Verifying the status of netgroup definitions .............................................................. 86
Commands for managing NIS domain configurations .............................................. 87
Commands for managing LDAP client configurations ............................................. 87
Commands for managing LDAP configurations ....................................................... 88
Commands for managing LDAP client schema templates ........................................ 88
How the access cache works ..................................................................................... 89
Displaying information about NFS Kerberos configurations ................................... 89
Modifying an NFS Kerberos configuration .............................................................. 90

Commands for managing Kerberos realm configurations ........................................ 91
Commands for managing export policies .................................................................. 91
Commands for managing export rules ...................................................................... 92
Managing file locks ................................................................................................... 92
About file locking between protocols ........................................................... 92
How Data ONTAP treats read-only bits ....................................................... 93
Displaying information about locks .............................................................. 93
Breaking locks ............................................................................................... 96
Modifying the NFSv4.1 server implementation ID .................................................. 97
Managing NFSv4 ACLs ............................................................................................ 98
Benefits of enabling NFSv4 ACLs ................................................................ 98
How NFSv4 ACLs work ............................................................................... 98
Enabling or disabling modification of NFSv4 ACLs .................................... 99
How Data ONTAP uses NFSv4 ACLs to determine whether it can
delete a file ............................................................................................ 100
Enabling or disabling NFSv4 ACLs ............................................................ 100
Managing NFSv4 file delegations ........................................................................... 101
How NFSv4 file delegations work .............................................................. 101
Enabling or disabling NFSv4 read file delegations ..................................... 102
Enabling or disabling NFSv4 write file delegations ................................... 103
Configuring NFSv4 file and record locking ............................................................ 104
About NFSv4 file and record locking ......................................................... 104
Specifying the NFSv4 locking lease period ................................................ 104
Specifying the NFSv4 locking grace period ............................................... 105
How NFSv4 referrals work ..................................................................................... 105
Enabling or disabling NFSv4 referrals .................................................................... 106
Displaying NFS statistics ........................................................................................ 107
Support for VMware vStorage over NFS ................................................................ 108
Enabling or disabling VMware vStorage over NFS ................................................ 108
Enabling or disabling rquota support ...................................................................... 109
NFSv3 performance improvement by modifying the TCP maximum read and
write size ............................................................................................................ 110
Modifying the NFSv3 TCP maximum read and write size ..................................... 111
SMB file access concepts .......................................................................... 113

SMB concepts ......................................................................................................... 113
How authentication provides SMB access security ................................................ 113
Kerberos authentication ............................................................................... 114
NTLM authentication .................................................................................. 114
Role authorization plays in securing file access over SMB connections ................ 114
Role export policies play with SMB access ............................................................ 115
How name mapping is used to secure SMB file access on Vservers with
FlexVol volumes ............................................................................................... 115
How name mapping works .......................................................................... 116
Preservation of UNIX permissions ......................................................................... 116
Very large CIFS configuration changes might take some time to finish ................ 116
Configuring CIFS servers ........................................................................ 118

Supported CIFS clients and domain controllers ...................................................... 118
Unsupported Windows features .............................................................................. 118
Setting up CIFS servers ........................................................................................... 119
Prerequisites for CIFS server setup ............................................................. 119
Setting up the CIFS server .......................................................................... 119
Setting up network access for the CIFS server ........................................... 130
Managing CIFS servers ........................................................................................... 137
Using options to customize CIFS servers ................................................... 137
Managing CIFS server security settings ...................................................... 140
Configuring SMB on your Vserver's CIFS server ...................................... 145
Using SMB signing to enhance network security ....................................... 150
Improving client performance with traditional and lease oplocks .............. 157
Using IPv6 with CIFS ................................................................................. 163
Applying Group Policy Objects to a CIFS server ....................................... 167
Managing domain controller connections ................................................... 173
Managing miscellaneous CIFS server tasks ................................................ 176
Setting up file access using SMB ............................................................. 181

Configuring security styles ...................................................................................... 181
Configuring security styles on Vserver root volumes ................................. 181
Configuring security styles on FlexVol volumes ........................................ 181
Configuring security styles on qtrees .......................................................... 182
Creating and managing data volumes and the NAS namespace ............................. 183
Creating data volumes with specified junction points ................................ 183
Creating data volumes without specifying junction points ......................... 184
Mounting or unmounting existing volumes in the NAS namespace ........... 185
Displaying volume mount and junction point information ......................... 186

Creating name mappings ......................................................................................... 187
Name mapping conversion rules ................................................................. 187
Creating a name mapping ............................................................................ 189
Commands for managing name mappings .................................................. 190
Creating and configuring SMB shares .................................................................... 190
Share naming considerations ....................................................................... 191
Non-Unicode clients not supported ............................................................. 191
Elimination of execute permission requirements on share paths ................ 192
Information you need when creating SMB shares ...................................... 192
Creating an SMB share on a CIFS server ................................................... 193
Adding or removing share properties on an existing share ......................... 197
Commands for managing CIFS shares ........................................................ 200
Securing file access by using SMB share ACLs ..................................................... 200
How Data ONTAP uses share-level ACLs ................................................. 200
Creating SMB share access control lists ..................................................... 201
Commands for managing SMB share access control lists .......................... 201
Securing file access by using file permissions ........................................................ 201
Configuring standard NTFS file permissions by using the Windows
Security tab ............................................................................................ 202
Configuring advanced NTFS file permissions using the Windows
Security tab ............................................................................................ 204
How to configure NTFS file permissions using the Data ONTAP CLI ...... 207
How UNIX file permissions provide access control when accessing files
over SMB ............................................................................................... 208
Securing SMB access using export policies ............................................................ 208
How export policies are used with SMB access ......................................... 209
Default export policy for a Vserver with FlexVol volume ......................... 210
What happens to existing SMB export policies when upgrading ............... 210
Enabling or disabling export policies for SMB access ............................... 211
Creating an export policy ............................................................................ 212
How export rules work ................................................................................ 212
How to handle clients with an unlisted security type .................................. 214
How security types determine client access levels ...................................... 216
How to handle superuser access requests .................................................... 218
Adding an SMB access rule to an export policy ......................................... 220
Setting an export rule's index number ......................................................... 224
Associating an export policy to a FlexVol volume ..................................... 224
Export policy restrictions and nested junctions for FlexVol volumes ........ 226
Commands for managing export policies .................................................... 226
Commands for managing export rules ........................................................ 226
Considerations when reverting export policies for SMB ............................ 227
Managing file access using SMB ............................................................. 228

Using local users and groups for authentication and authorization ........................ 228
How Data ONTAP uses local users and groups .......................................... 228
What local privileges are ............................................................................. 232
Requirements and considerations ................................................................ 233
List of BUILTIN groups and their default privileges ................................. 234
Enabling or disabling local users and groups functionality ........................ 236
Managing local user accounts ..................................................................... 238
Managing local groups ................................................................................ 245
Managing local privileges ........................................................................... 253
Displaying information about file security and audit policy on FlexVol volumes . 257
Displaying information about file security on NTFS security-style
FlexVol volumes ................................................................................... 258
Displaying information about file security on mixed security-style
FlexVol volumes ................................................................................... 262
Displaying information about file security on UNIX security-style
FlexVol volumes ................................................................................... 265
Displaying information about NTFS audit policies on FlexVol volumes
using the CLI ......................................................................................... 268
Displaying information about NFSv4 audit policies on FlexVol volumes . 271
Managing NTFS file security and audit policies on Vservers with FlexVol
volumes using the CLI ....................................................................................... 274
Use cases for using the CLI to set file and folder security .......................... 275
Limitations when using the CLI to set file and folder security ................... 275
How security descriptors are used to apply file and folder security ........... 275
Configuring and applying file security on NTFS files and folders ............. 276
Configuring and applying audit policies on NTFS files and folders ........... 290
Commands for managing NTFS security descriptors ................................. 302
Commands for managing NTFS DACL access control entries .................. 303
Commands for managing NTFS SACL access control entries ................... 303
Commands for managing security policies ................................................. 304

Commands for managing security policy tasks ........................................... 304
Commands for managing security policy jobs ............................................ 304
Using security tracing to verify or troubleshoot file and directory access .............. 305
How security tracing works ......................................................................... 305
Types of access checks security traces monitor .......................................... 306
Considerations when creating security traces ............................................. 306
Performing security traces ........................................................................... 307
How to interpret security trace results ......................................................... 315
Configuring the metadata cache for CIFS shares .................................................... 320
How CIFS metadata caching works ............................................................ 320
Enabling the CIFS metadata cache .............................................................. 320
Configuring the lifetime of CIFS metadata cache entries ........................... 321
Managing file locks ................................................................................................. 321
About file locking between protocols ......................................................... 322
How Data ONTAP treats read-only bits ..................................................... 322
How Data ONTAP differs from Windows on handling locks on share
path components .................................................................................... 323
Displaying information about locks ............................................................ 323
Breaking locks ............................................................................................. 325
Monitoring CIFS activity ........................................................................................ 326
Displaying CIFS session information ......................................................... 326
Displaying information about open CIFS files ........................................... 329
Determining which statistics objects and counters are available ................ 333
Displaying CIFS and audit statistics ........................................................... 335
Deploying CIFS client-based services ..................................................... 336

Using offline files to allow caching of files for offline use .................................... 336
Requirements for using offline files ............................................................ 337
Considerations when deploying offline files ............................................... 337
Configuring offline files support on SMB shares using the CLI ................ 338
Configuring offline files support on SMB shares by using the Computer
Management MMC ............................................................................... 340
Using roaming profiles to store user profiles centrally on a Vserver's CIFS
server ................................................................................................................. 341
Requirements for using roaming profiles .................................................... 341
Configuring roaming profiles ...................................................................... 342
Using folder redirection to store data on a Vserver's CIFS server .......................... 342
Requirements for using folder redirection .................................................. 343
Configuring folder redirection .................................................................... 343
How to access the ~snapshot directory from Windows clients using SMB 2.x ...... 344
Recovering files and folders using Previous Versions ............................................ 345
Requirements for using Microsoft Previous Versions ................................ 345
Using the Previous Versions tab to view and manage Snapshot copy
data ........................................................................................................ 346
Determining whether Snapshot copies are available for Previous
Versions use ........................................................................................... 347
Creating a Snapshot configuration to enable Previous Versions access ..... 348
Considerations when restoring directories that contain junctions ............... 349
Deploying CIFS server-based services ................................................... 350

Managing home directories ..................................................................................... 350
How Data ONTAP enables dynamic CIFS home directories ..................... 350
Adding a home directory share ................................................................... 352
Adding a home directory search path .......................................................... 353
Creating a home directory configuration using the %w and %d variables . 354
Configuring home directories using the %u variable .................................. 356
Additional home directory configurations .................................................. 359
Commands for managing search paths ........................................................ 360
Configuring SMB client access to UNIX symbolic links ....................................... 360
How Data ONTAP enables you to provide SMB client access to UNIX
symbolic links ........................................................................................ 361
Limits when configuring UNIX symbolic links for SMB access ............... 362
Configuring UNIX symbolic link support on SMB shares ......................... 362
Creating symbolic link mappings for SMB ................................................. 364
Commands for managing symbolic link mappings ..................................... 365
Using BranchCache to cache CIFS share content at a branch office ...................... 366
Requirements, considerations, and recommendations ................................ 366
Configuring BranchCache ........................................................................... 369
Configuring BranchCache-enabled SMB shares ......................................... 374
Managing and monitoring the BranchCache configuration ........................ 377
Disabling BranchCache on SMB shares ..................................................... 387
Disabling or enabling BranchCache on a Vserver ...................................... 389
Deleting the BranchCache configuration on a Vserver ............................... 391
What happens to BranchCache when reverting .......................................... 392

Improving Microsoft remote copy performance ..................................................... 393
How ODX works ......................................................................................... 393
Requirements for using ODX ...................................................................... 395
Considerations for using ODX .................................................................... 396
Use cases for ODX ...................................................................................... 397
Enabling or disabling ODX ......................................................................... 398
Improving client response time by providing SMB automatic node referrals
with Auto Location ............................................................................................ 399
Requirements and considerations when using automatic node referrals ..... 400
Support for automatic node referrals ........................................................... 401
Enabling or disabling SMB automatic node referrals ................................. 402
Using statistics to monitor automatic node referral activity ....................... 403
How to monitor client-side SMB automatic node referral information
using a Windows client ......................................................................... 405
Providing folder security on shares with access-based enumeration ...................... 405
Enabling or disabling access-based enumeration on SMB shares .............. 406
Enabling or disabling access-based enumeration from a Windows client . . 407
Configuring Data ONTAP for the Hyper-V over SMB solution .......... 408
What nondisruptive operations for Hyper-V over SMB means .............................. 408
What the protocols are that enable nondisruptive operations for Hyper-V . 409
Concepts to understand about NDOs for Hyper-V over SMB solutions .... 409
How SMB 3.0 functionality supports NDOs for Hyper-V over SMB ........ 411
What the Witness protocol does to enhance transparent failover ............... 411
Share-based backups of Hyper-V virtual machines with Remote VSS ...... 413
How ODX copy offload is used with Hyper-V over SMB ......................... 417
Configuration requirements, considerations, and recommendations ...................... 418
Configuration requirements ......................................................................... 419
Considerations and limits ............................................................................ 422
Recommendations when configuring Hyper-V over SMB ......................... 423
Planning the configuration ...................................................................................... 424
Completing the data LIF and network configuration worksheet ................. 425
Completing the volume configuration worksheet ....................................... 427
Completing the SMB share configuration worksheet ................................. 428
Creating Data ONTAP configurations for Hyper-V over SMB solutions .............. 430
Verifying that both Kerberos and NTLMv2 authentication are permitted .. 431
Verifying that the Hyper-V server's domain computer account maps to
the default UNIX user ........................................................................... 433
Verifying that the Vserver root volume uses NTFS security style ............. 435
Verifying that required CIFS options are configured .................................. 436
Verifying that automatic node referrals are disabled .................................. 437
Creating data LIFs for Hyper-V over SMB configurations (cluster
administrators only) ............................................................................... 438
Creating NTFS data volumes ...................................................................... 440
Creating continuously available SMB shares .............................................. 441
Configuring the VSS shadow copy directory depth .................................... 443
Considerations for reverting Hyper-V over SMB configurations ........................... 443
Managing Hyper-V over SMB configurations ........................................................ 444
Configuring existing shares for continuous availability ............................. 444
Enabling or disabling the VSS shadow copy feature .................................. 447
Using statistics to monitor Hyper-V over SMB activity ......................................... 448
Determining which statistics objects and counters are available ................ 448
Displaying SMB statistics ........................................................................... 450
Verifying that the configuration is capable of nondisruptive operations ................ 450
How to use health monitoring to determine whether NDO status is
healthy ................................................................................................... 451
Displaying NDO status by using system health monitoring ....................... 451
Verifying the continuously available configuration of Hyper-V SMB
shares ..................................................................................................... 453
Verifying LIF status .................................................................................... 455
Determining whether SMB sessions are continuously available ................ 456
File access to Infinite Volumes ................................................................ 465

Support for NFS on Infinite Volumes ..................................................................... 465
Support for CIFS on Infinite Volumes .................................................................... 466
Comparison of namespaces for Infinite Volumes and FlexVol volumes ................ 467
Where clients access Infinite Volumes ....................................................... 467
How access to an Infinite Volume is controlled ..................................................... 467
How export policies affect access to an Infinite Volume ............................ 468
How share ACLs affect SMB access to Infinite Volumes .......................... 469
How file permissions control access to Infinite Volumes ........................... 469
What the default permissions are on Infinite Volumes ........................................... 470
How unified security style supports multiprotocol access to Infinite Volumes ...... 470

How group mapping supports multiprotocol access to Infinite Volumes ... 472
Setting up client access to an Infinite Volume ........................................................ 473
Preparing an Infinite Volume for client access ........................................... 473
Configuring name services, user authentication, and user mapping on an
Infinite Volume ..................................................................................... 475
Setting up basic NFS access to an Infinite Volume .................................... 475
Setting up basic SMB access to an Infinite Volume ................................... 477
Configuring group mapping on an Infinite Volume .................................... 479
Controlling access to an Infinite Volume with IP-based export rules ......... 480
Controlling SMB access to an Infinite Volume share with share ACLs ..... 481
Controlling access to Infinite Volumes with file permissions .................... 482
Advanced Infinite Volume file access concepts ..................................................... 483
What happens when NFS clients set UNIX permissions on Infinite
Volumes ................................................................................................. 483
What happens when SMB clients set NTFS file permissions on Infinite
Volumes ................................................................................................. 484
What happens when NFS clients set NFSv4.1 ACLs on Infinite
Volumes ................................................................................................. 485
How SMB clients set permissions for UNIX users of Infinite Volumes .... 485
How file permissions on Infinite Volumes are displayed to clients ............ 485
How the mixed state of an Infinite Volume affects its availability ............. 487
Why an Infinite Volume's size appears smaller from a client ..................... 488
How locks work on Infinite Volumes ......................................................... 489
Comparison of unified and mixed security styles ....................................... 489
How storage classes affect client access to Infinite Volumes ..................... 494
Auditing NAS file access events on Vservers with FlexVol volumes ... 495
How auditing works ................................................................................................ 495
Basic auditing concepts ............................................................................... 495
How the Data ONTAP auditing process works .......................................... 496
When staging volumes are created on aggregates ....................................... 497
Auditing requirements and considerations .............................................................. 498
What the supported audit event log formats are ...................................................... 498
CIFS file and folder access events that can be audited ........................................... 499
NFS file and directory access events that can be audited ....................................... 500
How implementing auditing is a two-step process .................................................. 500
Planning the auditing configuration ........................................................................ 501
Completing the auditing configuration worksheet ...................................... 504
Creating a file and directory auditing configuration on a Vserver .......................... 504
Creating the auditing configuration ............................................................. 505
Enabling auditing on a Vserver ................................................................... 506
Verifying the auditing configuration ........................................................... 506
What to do if aggregates do not contain enough space for staging volumes .......... 507
Configuring audit policies on NTFS security-style files and directories ................ 507
Configuring NTFS Audit Policies using the Windows Security tab ........... 508
How to configure NTFS audit policies using the Data ONTAP CLI .......... 511
Configuring auditing for UNIX security style files and directories ........................ 511
Displaying information about audit policies applied to files and directories .......... 512
Displaying information about audit policies using the Windows Security
tab .......................................................................................................... 512
using the CLI ......................................................................................... 513
Managing auditing configurations .......................................................................... 516
Enabling and disabling auditing on a Vserver ............................................ 516
Displaying information about auditing configurations ............................... 517
Commands for modifying auditing configurations ..................................... 519
Deleting an auditing configuration .............................................................. 520
What the process is when reverting ............................................................. 520
Troubleshooting auditing and staging volume space issues .................................... 521
How to troubleshoot space issues related to the event log volumes ........... 521
How to troubleshoot space issues related to the staging volumes (cluster
administrators only) ............................................................................... 521
Using FPolicy for file monitoring and management on Vservers with

FlexVol volumes ................................................................................... 523
How FPolicy works ................................................................................................. 523
What the two parts of the FPolicy solution are ........................................... 523
What synchronous and asynchronous communications are ........................ 523
Roles that cluster components play with FPolicy ....................................... 524
How FPolicy on clustered Data ONTAP works with external FPolicy
servers .................................................................................................... 525
What the node-to-FPolicy server communication process is ...................... 527
How FPolicy services work across Vserver namespaces ............................ 528
FPolicy configuration types ........................................................................ 529

What the steps for setting up an FPolicy configuration are ........................ 530
Requirements, considerations, and best practices for configuring FPolicy ............ 531
Ways to configure FPolicy .......................................................................... 531
Requirements for setting up FPolicy ........................................................... 531
Best practices and recommendations when setting up FPolicy ................... 532
Important revert considerations ................................................................... 532
Planning the FPolicy configuration ......................................................................... 533
Planning the external engine configuration ................................................. 533
Planning the FPolicy event configuration ................................................... 539
Planning the FPolicy policy configuration .................................................. 545
Planning the FPolicy scope configuration ................................................... 548
Creating the FPolicy configuration ......................................................................... 551
Creating the FPolicy external engine .......................................................... 552
Creating the FPolicy policy event ............................................................... 552
Creating the FPolicy policy ......................................................................... 553
Creating the FPolicy policy scope ............................................................... 553
Enabling the FPolicy policy ........................................................................ 554
Modifying FPolicy configurations .......................................................................... 554
Commands for modifying FPolicy configurations ...................................... 554
Enabling or disabling FPolicy policies ........................................................ 555
Displaying information about FPolicy configurations ............................................ 555
How the show commands work .................................................................. 556
Commands for displaying information about FPolicy configurations ........ 556
Displaying information about FPolicy policy status ................................... 557
Displaying information about enabled policies ........................................... 558
Managing FPolicy server connections .................................................................... 559
Connecting to external FPolicy servers ....................................................... 559
Disconnecting from external FPolicy servers ............................................. 559
Displaying information about connections to external FPolicy servers ...... 560
Glossary ..................................................................................................... 563

Copyright information ............................................................................. 569
Trademark information ........................................................................... 570
How to send your comments .................................................................... 571
Index ........................................................................................................... 572
17
Considerations before configuring file access

Data ONTAP allows you to manage access to files by clients using different protocols. There are
certain concepts you should be familiar with before configuring file access.
File protocols that Data ONTAP supports

Data ONTAP supports file access using the NFS and CIFS protocols.
This means clients can access all files on a Vserver regardless of what protocol they are connecting
with or what type of authentication they require.
Related concepts
How Data ONTAP supports file access using NFS on page 34

SMB file access concepts on page 113
How Data ONTAP controls access to files

Data ONTAP controls access to files according to the authentication-based and file-based restrictions
that you specify.
When a client connects to the storage system to access files, Data ONTAP has to perform two tasks:
Authentication
Data ONTAP has to authenticate the client by verifying the identity with a trusted source. In
addition, the authentication type of the client is one method that can be used to determine whether
a client can access data when configuring export policies (optional for CIFS).
Authorization
Data ONTAP has to authorize the user by comparing the user's credentials with the permissions
configured on the file or directory and determining what type of access, if any, to provide.
To properly manage file access control, Data ONTAP must communicate with external services such
as NIS, LDAP, and Active Directory servers. Configuring a storage system for file access using CIFS
or NFS requires setting up the appropriate services depending on your environment in Data ONTAP.
Authentication-based restrictions
With authentication-based restrictions, you can specify which client machines and which users can
connect to the Vserver.
Data ONTAP supports Kerberos authentication from both UNIX and Windows servers.
File-based restrictions
With file-based restrictions, you can specify which users can access which files.
When a user creates a file, Data ONTAP generates a list of access permissions for the file. Although
the form of the permissions list varies with each protocol, it always includes common permissions,
such as reading and writing permissions.
When a user tries to access a file, Data ONTAP uses the permissions list to determine whether to
grant access. Data ONTAP grants or denies access according to the operation that the user is
performing, such as reading or writing, and the following factors:
User account
User groups or netgroups
Client protocol
File type
As part of the verification process, Data ONTAP maps host names to IP addresses using the lookup
service you specifyLightweight Directory Access Protocol (LDAP), Network Information Service
(NIS), Domain Name Service (DNS), or local storage system information.
LIF configuration requirements for file access management

To properly manage file access control, Data ONTAP must communicate with external services such
as NIS, LDAP, and Active Directory servers. The Vserver LIFs must be properly configured to allow
these communications.
The communication with external services usually happens over the data LIF of the Vserver.
Therefore, you must ensure that the Vserver has a data LIF properly configured to reach all required
external services on each node.
In addition, in some situations, communication over the data LIF might fail or must be made on a
node that does not host data LIFs for the Vserver. In this case, the storage system attempts to use
node-management and cluster-management LIFs instead. If your environment allows this, you should
also ensure that the node-management and cluster-management LIFs in the cluster can reach these
external services as well.
For more information about LIF configuration, see the Clustered Data ONTAP Network
Management Guide.
Considerations before configuring file access | 19
How namespaces and volume junctions affect file access on

Vservers with FlexVol volumes
You must understand what namespaces and volume junctions are and how they work to correctly
configure file access on Vservers in your storage environment.
What namespaces in Vservers with FlexVol volumes are

A namespace is a logical grouping of volumes that are joined together at junction points to create a
single, logical file system that derives from the Vserver root volume. Each Vserver has a namespace.
A Vserver's CIFS and NFS servers can store and access data across the namespace. Each client can
access the entire namespace by mounting an export or accessing a single CIFS share at the top of the
namespace.
Alternatively, Vserver administrators can create exports at each volume junction so that clients can
create mount points at intermediate locations in the namespace, or they can create CIFS shares that
point to any directory path in the namespace.
Volumes can be added at any time by mounting them to any location in the namespace. Clients can
immediately access the newly added volume, provided that the volume junction is under the point at
which they are accessing the namespace and provided that they have sufficient permissions.
What volume junctions are

Volume junctions are a way to join individual volumes together into a single, logical namespace.
Volume junctions are transparent to CIFS and NFS clients. When NAS clients access data by
traversing a junction, the junction appears to be an ordinary directory.
A junction is formed when a volume is mounted to a mount point below the root and is used to create
a file-system tree. The top of a file-system tree is always the root volume, which is represented by a
slash (/). A junction points from a directory in one volume to the root directory of another volume.
A volume must be mounted at a junction point in the namespace to allow NAS client access to
contained data:
Although specifying a junction point is optional when a volume is created, data in the volume
cannot be exported and a share cannot be created until the volume is mounted to a junction point
in the namespace.
A volume that was not mounted during volume creation can be mounted post-creation.
New volumes can be added to the namespace at any time by mounting them to a junction point.
Mounted volumes can be unmounted; however, unmounting a volume disrupts NAS client access
to all data in the volume and to all volumes mounted at child junction points beneath the
unmounted volume.
Junction points can be created directly below a parent volume junction, or they can be created on
a directory within a volume.

For example, a path to a volume junction for a volume named vol3 might be /vol1/vol2/
vol3, or it might be /vol1/dir2/vol3, or even /dir1/dir2/vol3.
How volume junctions are used in CIFS and NFS server namespaces
You can mount volumes at junction points anywhere within the namespace to create a single, logical
namespace. If you specify a junction point when the volume is created, the volume is created and
mounted for NAS access.
You can create CIFS shares and NFS exports on the mounted volume. If you do not specify a
junction point, the volume is online but is not mounted for NAS file access. You must mount a
volume to a junction point before it can be used for NAS file access.
What the typical NAS namespace architectures are

All Vserver name spaces derive from the root volume; however, there are several typical NAS
namespace architectures that you can use as you create your Vserver name space. You can choose the
namespace architecture that matches your business and workflow needs.
The top of the namespace is always the root volume, which is represented by a slash (/). The
namespace architecture under the root falls into three basic categories:
A single branched tree, with only a single junction to the root of the namespace
Multiple branched trees, with multiple junction points to the root of the namespace
Multiple stand-alone volumes, each with a separate junction point to the root of the name space
Namespace with single branched tree

An architecture with a single branched tree has a single insertion point to the root of the Vserver
namespace. The single insertion point can be either a junctioned volume or a directory beneath the
root. All other volumes are mounted at junction points beneath the single insertion point (which can
be a volume or a directory).
roo t
(/)
V se rve r roo t
A
A5
A4
A1
A2
A3
A 51
A3
A1
A 51 A 52 A 53
A 41 A 42
A2
A5
A 52
A 42
A4
A 53
A 41
For example, a typical volume junction configuration with the above namespace architecture might
look like the following configuration, where all volumes are junctioned below the single insertion
point, which is a directory named data:
Vserver
------vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
Volume
-----------corp1
corp2
data1
eng1
eng2
sales
vol1
vol2
vol3
vs1_root
Junction
Active
-------true
true
true
true
true
true
true
true
true
-
Junction Path
------------------/data/dir1/corp1
/data/dir1/corp2
/data/data1
/data/data1/eng1
/data/data1/eng2
/data/data1/sales
/data/vol1
/data/vol2
/data/vol3
/
Junction
Path Source
----------RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
-
Namespace with multiple branched trees

An architecture with multiple branched trees has multiple insertion points to the root of the Vserver
namespace. The insertion points can be either junctioned volumes or directories beneath the root. All
other volumes are mounted at junction points beneath the insertion points (which can be volumes or
directories).
roo t
A2
A3
B1
C1
A3
V se rve r roo t
(/)
A1
A2
C1
B2
C2
B2
C2 C 3 C3
C3
B1
look like the following configuration, where there are three insertion points to the root volume of the
Vserver. Two insertion points are directories named data and projects. One insertion point is a
junctioned volume named audit:
Vserver
------vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
vs1
Volume
-----------audit
audit_logs1
audit_logs2
audit_logs3
eng
mktg1
mktg2
project1
project2
vs1_root
Junction
Active
-------true
true
true
true
true
true
true
true
true
-
Junction Path
------------------/audit
/audit/logs1
/audit/logs2
/audit/logs3
/data/eng
/data/mktg1
/data/mktg2
/projects/project1
/projects/project2
/
Junction
Path Source
----------RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
-
Namespace with multiple stand-alone volumes

In an architecture with stand-alone volumes, every volume has an insertion point to the root of the
Vserver namespace; however, the volume is not junctioned below another volume. Each volume has
a unique path, and is either junctioned directly below the root or is junctioned under a directory
below the root.
V se rve r roo t
roo t (/)
look like the following configuration, where there are five insertion points to the root volume of the
Vserver, with each insertion point representing a path to one volume.
Vserver
------vs1
vs1
vs1
vs1
vs1
vs1
Volume
-----------eng
mktg
project1
project2
sales
vs1_root
Junction
Active
-------true
true
true
true
true
-
Junction Path
------------------/eng
/vol/mktg
/project1
/project2
/sales
/
Junction
Path Source
----------RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
-
How security styles affect data access

Each volume and qtree on the storage system has a security style. The security style determines what
type of permissions are used for data on volumes when authorizing users. You must understand what
the different security styles are, when and where they are set, how they impact permissions, how they
differ between volume types, and more.
Related concepts
Configuring security styles on page 43
What the security styles and their effects are

There are four different security styles: UNIX, NTFS, mixed, and unified. Each security style has a
different effect on how permissions are handled for data. You must understand the different effects to
ensure that you select the appropriate security style for your purposes.
It is important to understand that security styles do not determine what client types can or cannot
access data. Security styles only determine the type of permissions Data ONTAP uses to control data
access and what client type can modify these permissions.
For example, if a volume uses UNIX security style, CIFS clients can still access data (provided that
they properly authenticate and authorize) due to the multiprotocol nature of Data ONTAP. However,
Data ONTAP uses UNIX permissions that only UNIX clients can modify.
Security
style
Clients that
can modify
permissions
Permissions that
clients can use
Resulting effective
security style
Clients that can

access files
UNIX
NFS
NFSv3 mode bits
UNIX
NFS and CIFS
NFSv4.x ACLs
UNIX
NTFS
CIFS
NTFS ACLs
NTFS
Mixed
NFS or CIFS
NFSv3 mode bits
UNIX
NFSv4.x ACLs
UNIX
NTFS ACLs
NTFS
NFSv3 mode bits
UNIX
NFSv4.1 ACLs
UNIX
NTFS ACLs
NTFS
Unified
(only for
Infinite
Volumes)
NFS or CIFS
When the security style is mixed or unified, the effective permissions depend on the client type that
last modified the permissions because users set the security style on an individual basis. If the last
client that modified permissions was an NFSv3 client, the permissions are UNIX NFSv3 mode bits.
If the last client was an NFSv4 client, the permissions are NFSv4 ACLs. If the last client was a CIFS
client, the permissions are Windows NTFS ACLs.
Note: Data ONTAP initially sets some default file permissions. By default, the effective security
style on all data in UNIX, mixed, and unified security style volumes is UNIX and the effective
permissions type is UNIX mode bits (0755 unless specified otherwise) until configured by a client
as allowed by the default security style. By default, the effective security style on all data in NTFS
security style volumes is NTFS and has an ACL allowing full control to everybody.
Where and when to set security styles

Security styles can be set on FlexVol volumes (both root or data volumes) and qtrees. Security styles
can be set manually at the time of creation, inherited automatically, or changed at a later time.
Note: Infinite Volumes always use the unified security style. You cannot configure or change the
security style of an Infinite Volume.
How to decide on what security style to use on Vservers with FlexVol

volumes
To help you decide what security style to use on a volume, you should consider two factors. The
primary factor is the type of administrator that manages the file system. The secondary factor is the
type of user or service that accesses the data on the volume.
When you configure the security style on a volume, you should consider the needs of your
environment to ensure that you select the best security style and avoid issues with managing
permissions. The following considerations can help you decide:
Security style
Choose if...
UNIX
The file system is managed by a UNIX administrator.

The majority of users are NFS clients.
An application accessing the data uses a UNIX user as the service account.
NTFS
The file system is managed by a Windows administrator.

The majority of users are CIFS clients.
An application accessing the data uses a Windows user as the service
account.
Mixed
The file system is managed by both UNIX and Windows administrators and
users consist of both NFS and CIFS clients.
How security style inheritance works

If you do not specify the security style when creating a new FlexVol volume or qtree, it inherits its
security style.
Security styles are inherited in the following manner:
A FlexVol volume inherits the security style of the root volume of its containing Vserver.
A qtree inherits the security style of its containing FlexVol volume.
A file or directory inherits the security style of its containing FlexVol volume or qtree.
Infinite Volumes cannot inherit security styles. All files and directories in Infinite Volumes always
use the unified security style. The security style of an Infinite Volume and the files and directories it
contains cannot be changed.
How unified security style supports multiprotocol access to Infinite

Volumes
The unified security style used by all Infinite Volumes enables all users using NFSv3, NFSv4.1, and
SMB 1.0 to view and set file permissions, regardless of the file permissions that are currently in
effect on a given file or directory. In addition, unified security style supports UNIX principals in
NTFS file permissions.
How an Infinite Volume gets unified security style
Infinite Volumes always use unified security style. Unlike FlexVol volumes, Infinite Volumes do not
inherit security styles from the root volume of their containing Vservers. Unlike with FlexVol
volumes, you cannot, and do not need to, configure the security style of an Infinite Volumes or its
files and directories.
Setting permissions on all files
In unified security style, clients can set file permissions regardless of the file permissions that are
currently in effect, including the following multiprotocol situations:
NFS clients can set UNIX permissions bits on a file with NTFS file permissions.
SMB clients can set NTFS file permissions on a file with UNIX permissions or an NFSv4.1 ACL.
NFSv4.1 clients can set an NFSv4.1 ACL on a file with NTFS file permissions.
Displaying permissions on all files

In unified security style, clients can view file permissions of any file regardless of the file
permissions that are currently in effect, including the following multiprotocol situations:
NFS clients can display UNIX permissions of a file with NTFS file permissions.
SMB clients can view permissions of a file with UNIX permissions or an NFSv4.1 ACL.
NFSv4.1 clients can display an equivalent NFSv4.1 ACL for a file with NTFS file permissions.
Support for UNIX principals in NTFS file permissions

In unified security style, NTFS file permissions can contain UNIX principals, which facilitate
multiprotocol access in the following ways:
When a Windows or UNIX user uses any supported protocol to access a file that contains NTFS
file permissions, the user's UNIX credential is compared with any UNIX principals in the NTFS
file permissions.
When an SMB client views a file's permissions, any UNIX users in the permissions are displayed
without being converted to Windows users.
When an SMB client sets NTFS file permissions, the SMB client can specify permissions for
UNIX principals.
When an NFS client changes the UNIX permissions, owner, or group of a file that uses NTFS file
permissions, UNIX principals are used in the affected permissions while leaving the remaining
NTFS file permissions unchanged.
NTFS file permissions are unaffected as long as the v4 ACL Preserve parameter is enabled.
Comparison of unified and mixed security styles

Understanding the differences between unified and mixed security styles can help you understand
how file permissions behave differently on FlexVol volumes that use mixed security style and
Infinite Volumes, which use unified security style.
Access checks
When a client tries to access a file, unified security style handles the access check the same way
except that unified security style also supports UNIX principals in NTFS file permissions.
The following table identifies whether the outcome is the same for mixed and unified security styles
when clients try to access a file:
When...
Of a file where
UNIX
permissions are
effective
Of a file that uses NTFS file permissions Of a file that has

an NFSv4.1 ACL
An NFSv3 or
NFSv4.1
client tries to
access a file
The outcome is
the same: the
UNIX credentials
are compared to
the UNIX
permissions.
The outcome is the same: the user's

Windows credential (obtained by using
user mapping) is compared to the
Windows SIDs in the NTFS file
permissions.
In addition, under unified security style,
the user's UNIX credential is compared
against any UNIX principals in the NTFS
file permissions.
The outcome is
the same: the
UNIX credentials
are compared to
the NFSv4.1
ACL.
An SMB
client tries to
access a file
The outcome is
the same: the
user's UNIX
credentials
(obtained by
using user name
mapping) is
compared to the
UNIX
permissions.

Windows credential is compared to the
permissions.
the user's UNIX credential (obtained by
using name mapping) is compared against
any UNIX principals in the NTFS file
permissions.
The outcome is
the same: the
user's UNIX user
credential
(obtained by
using user name
mapping) is
compared to the
NFSv4.1 ACL.

Ability to set permissions
The ability to set permissions is similar under both security styles, but unified security style has the
following benefits:
When an NFS client sets UNIX permissions on a file that uses NTFS file permissions, the
changes are merged into the NTFS file permissions.
When an SMB client sets NTFS permissions on a file, the permissions can include UNIX
principals.
The following table identifies whether the outcome is the same under mixed and unified security
styles when clients set file permissions:
When...
Of a file where UNIX

permissions are
effective
Of a file that uses NTFS file

permissions
An NFSv3 or
NFSv4.1 client
sets UNIX
permissions by
changing
permissions
The outcome is the

same: the UNIX
permissions are
updated.
The outcome is different:
Of a file that has an

NFSv4.1 ACL
The outcome is the

same: ACEs for
Under mixed security style,
OWNER@,
the NTFS file permissions
GROUP@, and
are dropped and the UNIX
EVERYONE@ are
permissions become
modified or added in
effective.
the NFSv4.1 ACL.
Under unified security style,
(This occurs only if the
the
v4 ACL preserve
ACEs for OWNER@,
parameter is enabled.)
GROUP@, and
EVERYONE@ are
modified or added to the
(This occurs only if the v4
ACL preserve parameter is
enabled.)

When...

permissions are
effective

permissions

NFSv4.1 ACL
An NFSv3 or
NFSv4.1 client
sets UNIX
permissions by
changing the
owner or
group
The outcome is the

same: the owner and
the primary group of
the file are updated.
The outcome is the

same: the owner and

permissions become
effective.
the Owner SID and the
Group SID of the existing
NTFS permissions are
updated. (This occurs only
if the v4 ACL preserve
An SMB client The outcome is similar:

sets NTFS
NTFS file permissions
permissions
are set.
In addition, under
unified security style,
the NTFS file
permissions can
include UNIX users.
The outcome is similar: The

new NTFS file permissions
replace the existing NTFS file
permissions.
In addition, under unified
security style, the NTFS file
permissions can include UNIX
users.
The outcome is similar:

the NFSv4.1 ACL is
dropped and NTFS file
permissions are set.
In addition, under
the NTFS file
permissions can
include UNIX users.
An NFSv4.1
The outcome is the
client sets an
same: an NFSv4.1
NFSv4.1 ACL ACL is set.
The outcome is the same: the

NTFS file permissions are
dropped, and an NFSv4.1 ACL
is set.
The outcome is the

same: the NFSv4.1
ACL is dropped and a
new NFSv4.1 ACL is
set.
Viewing permissions
The ability of clients to view permissions is significantly better under unified security style in the
following ways:
An SMB client can show the permissions of a file that has an NFSv4.1 ACL.
An NFSv4.1 client can display an equivalent NFSv4.1 ACL for a file that has NTFS file
permissions.
When an SMB client shows permissions of a file that uses NTFS file permissions, UNIX
principals can appear in the permissions.

The following table identifies whether the outcome is the same or different under mixed and unified
security styles when clients show file permissions:
When...

permissions are effective
Of a file that uses NTFS

file permissions

NFSv4.1 ACL
An NFS
client shows
UNIX
permissions
The outcome is the same:

The UNIX permissions are
displayed.

The display UNIX
permissions (that are
calculated each time an ACL
is set) are displayed.
The outcome is the

same: The display
mode bits (that are
calculated each time
an ACL is set) are
displayed.
An SMB
client shows
permissions

permissions are displayed
for Owner, Group, and
Everyone. The sticky bit,
setuid flag, and setgid flag
are also displayed if they are
set.
effective permissions are
also displayed for current
user.
permissions for OWNER@,
GROUP@, and
EVERYONE@ appear as
UNIX names when
displayed in Windows
Explorer.
The outcome is generally the The outcome is

same: the NTFS permissions different:
are displayed.
Under mixed
security style,
security style, UNIX users
permissions are
and groups can appear in the
displayed for
permissions.
Owner, Group, and
Everyone, and
effective
permissions are
displayed for
current user. The
sticky bit, setuid
flag, and setgid
flag are also
displayed if they
are set.
Under unified
security style,
effective NTFS
file permissions
are displayed.
All of the users
and groups are
UNIX principals.

When...


file permissions

NFSv4.1 ACL
An NFSv4.1
client
displays an
NFSv4.1
ACL

An NFSv4.1 ACL is
displayed, containing ACEs
for OWNER@, GROUP@,
and EVERYONE@.
The outcome is the

same: The NFSv4.1
ACL is displayed.
Under mixed security

style, an NFSv4.1 ACL
is displayed, containing
ACEs for OWNER@,
GROUP@, and
EVERYONE@.
Under unified security
style, an NFSv4 ACL is
displayed, containing
users and groups that
have been mapped from
Windows to UNIX.
(User and group
mappings must be
configured.)
Preservation of UNIX permissions

Data ONTAP preserves UNIX permissions when files are edited and saved by Windows
applications.
When applications on Windows clients edit and save files, they read the security properties of the
file, create a new temporary file, apply those properties to the temporary file, and then give the
temporary file the original file name.
When Windows clients perform a query for the security properties, they receive a constructed ACL
that exactly represents the UNIX permissions. The sole purpose of this constructed ACL is to
preserve the file's UNIX permissions as files are updated by Windows applications to ensure that the
resulting files have the exact same UNIX permissions. Data ONTAP does not set any NTFS ACLs
using the constructed ACL.
How to manage UNIX permissions using the Windows Security tab

If you want to manipulate UNIX permissions of files or folders in UNIX or mixed security-style
qtrees or volumes on Vservers with FlexVol volumes, you can use the Security tab on Windows
clients. Alternatively, you can use applications that can query and set Windows ACLs.
Modifying UNIX permissions

You can use the Windows Security tab to view and change UNIX permissions for a UNIX
security-style volume or qtree. This is also true for a mixed security-style volume or qtree where
the files and folders have a UNIX effective security style.
If mode permissions are used, you can directly change the mode permissions for the listed UID,
GID, and others (everyone else with an account on the computer). For example, if the displayed
UID has r-x permissions, you can change the UID permissions to rwx.
Changing UNIX permissions to NTFS permissions
You can use the Windows Security tab to replace UNIX security objects with Windows security
objects on a mixed security-style volume or qtree where the files and folders have a UNIX
effective security style.
You must first remove the listed entries and then replace them with the desired Windows User
and Group objects. You can then configure NTFS-based ACLs on the Windows User and Group
objects. By removing UNIX security objects and adding Windows Users and Groups to a file or
folder in a mixed security-style volume or qtree, you change the effective security style on the file
or folder from UNIX to NTFS.
When changing permissions on a folder, the default Windows behavior is to propagate these
changes to all subfolders and files. Therefore, you must change the propagation choice to the
desired setting if you do not want to propagate a change in security style to all child folders,
subfolders, and files.
NFS and CIFS file naming dependencies

File naming conventions depend on both the network clients operating systems and the file-sharing
protocols.
The operating system and the file-sharing protocols determine the following:
Characters a file name can use

Case-sensitivity of a file name
Characters a file name can use

If you are sharing a file between clients on different operating systems, you should use characters
that are valid in both operating systems.
For example, if you use UNIX to create a file, do not use a colon (:) in the file name because the
colon is not allowed in MS-DOS file names. Because restrictions on valid characters vary from one
operating system to another, see the documentation for your client operating system for more
information about prohibited characters.
Case-sensitivity of a file name

File names are case-sensitive for NFS clients and case-insensitive but case-preserving for CIFS
clients.
For example, if a CIFS client creates Spec.txt, both CIFS and NFS clients display the file name as
Spec.txt. However, if a CIFS user later tries to create spec.txt, the name is not allowed because,
to the CIFS client, that name currently exists. If an NFS user later creates a file named spec.txt,
NFS and CIFS clients display the file name differently, as follows:
On NFS clients, you see both file names as they were created, Spec.txt and spec.txt, because
file names are case-sensitive.
On CIFS clients, you see Spec.txt and Spec~1.txt.
Data ONTAP creates the Spec~1.txt file name to differentiate the two files.
How Data ONTAP creates file names

Data ONTAP creates and maintains two file names for files in any directory that has access from a
CIFS client: the original long name and a file name in 8.3 format.
For file names that exceed the eight character name or the three character extension limit, Data
ONTAP generates an 8.3-format file name as follows:
It truncates the original file name to six characters, if the file name exceeds six characters.
It appends a tilde (~) and a number, one through five, to file names that are no longer unique after
being truncated.
If it runs out of numbers because there are more than five similar names, it creates a unique file
name that bears no relation to the original file name.
It truncates the file name extension to three characters.
For example, if an NFS client creates a file named specifications.html, the 8.3 format file
name created by Data ONTAP is specif~1.htm. If this name already exists, Data ONTAP uses a
different number at the end of the file name. For example, if an NFS client then creates another file
named specifications_new.html, the 8.3 format of specifications_new.html is
specif~2.htm.
Use of hard mounts

When troubleshooting mounting problems, you need to be sure that you are using the correct mount
type. NFS supports two mount types: soft mounts and hard mounts. You should use only hard
mounts for reliability reasons.
You should not use soft mounts, especially when there is a possibility of frequent NFS timeouts.
Race conditions can occur as a result of these timeouts, which can lead to data corruption.
How Data ONTAP supports file access using NFS

You can export and unexport file system paths on your storage system, making them available or
unavailable, respectively, for mounting by NFS clients.
How Data ONTAP handles NFS client authentication

NFS clients must be properly authenticated before they can access data on the Vserver. Data ONTAP
authenticates the clients by checking their UNIX credentials against name services you configure.
When an NFS client connects to the Vserver, Data ONTAP obtains the UNIX credentials for the user
by checking different name services, depending on the name services configuration of the Vserver.
Data ONTAP can check credentials for local UNIX accounts, NIS domains, and LDAP domains. At
least one of them must be configured so that Data ONTAP can successfully authenticate the user.
You can specify multiple name services and the order in which Data ONTAP searches them.
In a pure NFS environment with UNIX volume security styles, this configuration is sufficient to
authenticate and provide the proper file access for a user connecting from an NFS client.
If you are using mixed, NTFS, or unified volume security styles, Data ONTAP must obtain a CIFS
user name for the UNIX user for authentication with a Windows domain controller. This can happen
either by mapping individual users using local UNIX accounts or LDAP domains, or by using a
default CIFS user instead. You can specify which name services Data ONTAP searches in which
order, or specify a default CIFS user.
CIFS file access from NFS clients

Data ONTAP uses Windows NT File System (NTFS) security semantics to determine whether a
UNIX user, on an NFS client, has access to a file in a mixed or NTFS qtree.
Data ONTAP does this by converting the users UNIX User ID (UID) into a CIFS credential, then
using the CIFS credential to verify that the user has access rights to the file. A CIFS credential
consists of a primary Security Identifier (SID), usually the users Windows user name, and one or
more group SIDs that correspond to Windows groups of which the user is a member.
The time Data ONTAP takes converting the UNIX UID into a CIFS credential can be from tens of
milliseconds to hundreds of milliseconds because the process involves contacting a domain
controller. Data ONTAP maps the UID to the CIFS credential and enters the mapping in a credential
cache to reduce the verification time caused by the conversion.
How Data ONTAP supports file access using NFS | 35
Supported NFS versions and clients

Before you can use NFS in your network, you need to know which NFS versions and clients Data
ONTAP supports.
For the latest information about which NFS versions and clients Data ONTAP supports, see the
Interoperability Matrix at support.netapp.com/NOW/products/interoperability.
NFSv4.0 functionality supported by Data ONTAP

Data ONTAP supports all the mandatory functionality in NFSv4.0 except the SPKM3 and LIPKEY
security mechanisms.
The following NFSV4 functionality is supported:
COMPOUND Allows a client to request multiple file operations in a single remote procedure call
(RPC) request.
File delegation Allows the server to delegate file control to some types of clients for read and
write access.
Pseudo-fs
Used by NFSv4 servers to determine mount points on the storage system. There is
no mount protocol in NFSv4.
Locking
Lease-based. There are no separate Network Lock Manager (NLM) or Network

Status Monitor (NSM) protocols in NFSv4.
For more information about the NFSv4.0 protocol, see RFC 3530.
Related tasks
Enabling or disabling NFSv4.0 on page 46
Limitations of Data ONTAP support for NFSv4

You should be aware of several limitations of Data ONTAP support for NFSv4.
The SPKM3 and LIPKEY security mechanisms are not supported.

The delegation feature is not supported by every client type.
Names with non-ASCII characters on volumes other than UTF8 volumes are rejected by the
storage system.
All file handles are persistent; the server does not give volatile file handles.
Migration and replication are not supported.
NFSv4 clients are not supported with read-only load-sharing mirrors.
Data ONTAP routes NFSv4 clients to the source of the load-sharing mirror for direct read and
write access.
Named attributes are not supported.
All recommended attributes are supported, except for the following:
archive
hidden
homogeneous
mimetype
quota_avail_hard
quota_avail_soft
quota_used
system
time_backup
Note: Although it does not support the quota* attributes, Data ONTAP does support user and
group quotas through the RQUOTA side band protocol.
Data ONTAP support for NFSv4.1

Data ONTAP supports the NFSv4.1 protocol to allow access for NFSv4.1 clients.
By default NFSv4.1 is disabled. You can enable it by specifying the -v4.1 option and setting it to
enabled when creating an NFS server on a Vserver. You must also enable NFSv4.0 support to be
able to enable NFSv4.1 support.
Data ONTAP does not support NFSv4.1 directory and file level delegations.
Related tasks
Data ONTAP support for parallel NFS

Data ONTAP supports parallel NFS (pNFS). The pNFS protocol offers performance improvements
by giving clients direct access to the data of a set of files distributed across multiple nodes of a
cluster. It helps clients locate the optimal path to a volume.
Related tasks
Enabling or disabling parallel NFS on page 47
How Data ONTAP supports file access using NFS | 37
Process for NFS access to UNIX security style data on

Understanding the process used for NFS access to UNIX security style data is helpful when
designing a file access configuration that provides appropriate security settings.
When an NFS client connects to a storage system to access data with UNIX security style, Data
ONTAP goes through the following steps:
1. Obtain the UNIX credentials for the user.
Data ONTAP checks local UNIX accounts, NIS servers, and LDAP servers, depending on the
Vserver configuration.
2. Authorize the user.
Data ONTAP checks the CIFS credentials for the user against the NTFS permissions of the data
to determine what type of data access the user is allowed, if any.
In this scenario, name mapping is not performed because CIFS credentials are not required.
Process for NFS access to NTFS security style data on

Understanding the process used for NFS access to NTFS security style data is helpful when
designing a file access configuration that provides appropriate security settings.
When an NFS client connects to a storage system to access data with NTFS security style, Data
ONTAP goes through the following steps:
1. Obtain the UNIX credentials for the user.
Data ONTAP checks local UNIX accounts, NIS servers, and LDAP servers, depending on the
Vserver configuration.
2. Map the UNIX user to a CIFS name.
Data ONTAP checks local name mapping rules, LDAP mapping rules, and the default CIFS user,
depending on the Vserver configuration.
3. Establish a connection to a Windows domain controller.
Data ONTAP uses a cached connection, queries DNS servers, or uses a specified preferred
domain controller.
4. Authenticate the user.
Data ONTAP connects to the domain controller and performs pass-through authentication.
5. Authorize the user.
Data ONTAP checks the CIFS credentials for the user against the NTFS permissions of the data
to determine what type of data access the user is allowed, if any.
Setting up file access using NFS

You must complete a number of steps to allow clients access to files on a Vserver using NFS. There
are some additional steps that are optional depending on the current configuration of your
environment.
For clients to be able to access files on a Vserver using NFS, you must complete the following tasks:
1. Enable the desired NFS protocol versions on the Vserver.
You can specify the versions of NFS that clients can use to access files on the Vserver.
2. Create an NFS server on the Vserver.
An NFS server is a logical entity on a Vserver that enables the Vserver to serve files over NFS.
3. Configure the NFS server with the appropriate security, name mapping, and other settings
depending on the network and storage environment.
Note: The Vserver must exist before you can set up file access using NFS. For more information
about Vservers, see the Clustered Data ONTAP System Administration Guide for Vserver
Administrators
Creating and managing data volumes and the NAS

namespace
To manage file access in a NAS environment, you must manage data volumes and junction points on
your Vserver with FlexVol volumes. This includes planning your namespace architecture, creating
volumes with or without junction points, mounting or unmounting volumes, and displaying
information about data volumes and NFS server or CIFS server namespaces.
Related concepts
What namespaces in Vservers with FlexVol volumes are on page 19

What volume junctions are on page 19
How volume junctions are used in CIFS and NFS server namespaces on page 20
What the typical NAS namespace architectures are on page 20
Creating data volumes with specified junction points

You can specify the junction point when you create a data volume. The resultant volume is
automatically mounted at the junction point and is immediately available to configure for NAS
access.
Before you begin
The aggregate in which you want to create the volume must already exist.
Setting up file access using NFS | 39

Steps
1. Create the volume with a junction point by using the following command:
volume create -vserver vserver_name -volume volume_name -aggregate
aggregate_name -size {integer[KB|MB|GB|TB|PB]} -security-style {ntfs|
unix|mixed} -junction-path junction_path
The junction path must start with the root (/) and can contain both directories and junctioned
volumes. The junction path does not need to contain the name of the volume. Junction paths are
independent of the volume name.
Specifying a volume security style is optional. If you do not specify a security style, Data
ONTAP creates the volume with the same security style that is applied to the Vserver's root
volume. However, the root volume's security style might not be the security style you want
applied to the data volume you create. The recommendation is to specify the security style when
you create the volume to minimize difficult-to-troubleshoot file-access issues.
There are many optional parameters that you can use to customize a data volume. To learn more
about them, see the man pages for the volume create command.
2. Verify that the volume was created with the desired junction point:
volume show -vserver vserver_name -volume volume_name -junction
Example
The following example creates a volume named home4 located on Vserver vs1 that has a
junction path /eng/home:
cluster1::> volume create -vserver vs1 -volume home4 -aggregate aggr1 -size
1g -junction-path /eng/home
[Job 1642] Job succeeded: Successful
cluster1::> volume show -vserver vs1 -volume home4 -junction
Junction
Junction
Vserver
Volume Active
Junction Path
Path Source
--------- ------- -------- --------------- ----------vs1
home4
true
/eng/home
RW_volume
Creating data volumes without specifying junction points

You can create a data volume without specifying a junction point. The resultant volume is not
automatically mounted, and is not available to configure for NAS access. You must mount the
volume before you can configure SMB shares or NFS exports for that volume.
Before you begin

Steps
1. Create the volume without a junction point by using the following command:
unix|mixed}
applied to the data volume. The recommendation is to specify the security style when you create
the volume to minimize difficult-to-troubleshoot file-access issues.
2. Verify that the volume was created without a junction point:
Example
The following example creates a volume named sales located on Vserver vs1 that is not
mounted at a junction point:
cluster1::> volume create -vserver vs1 -volume sales -aggregate aggr3 -size
20GB
cluster1::> volume show -vserver vs1 -junction
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
true
/data
RW_volume
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
-
Mounting or unmounting existing volumes in the NAS namespace

A volume must be mounted on the NAS namespace before you can configure NAS client access to
data contained in the Vserver volumes. You can mount a volume to a junction point if it is not
currently mounted. You can also unmount volumes.
About this task
If you unmount a volume, all data within the junction point, including data in volumes with junction
points contained within the unmounted volume's namespace, are inaccessible to NAS clients. When
you unmount a volume, data within the volume is not lost. Additionally, existing volume export
policies and SMB shares created on the volume or on directories and junction points within the

unmounted volume are retained. If you remount the unmounted volume, NAS clients can access the
data contained within the volume using existing export policies and SMB shares.
Steps
1. Perform the desired action:

If you want to...
Enter the command...
Mount a volume
volume mount -vserver vserver_name -volume volume_name junction-path junction_path
Unmount a volume volume unmount -vserver vserver_name -volume volume_name
2. Verify that the volume is in the desired mount state:

Examples
The following example mounts a volume named sales located on Vserver vs1 to the junction
point /sales:
cluster1::> volume mount -vserver vs1 -volume sales -junction-path /sales
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
true
/data
RW_volume
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
true
/sales
RW_volume
The following example unmounts a volume named data located on Vserver vs1:
cluster1::> volume unmount -vserver vs1 -volume data
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
true
/sales
RW_volume
Displaying volume mount and junction point information

You can display information about a Vserver's mounted volumes and the junction points to which the
volumes are mounted. You can also determine which volumes are not mounted to a junction point.
You can use this information to understand and manage your Vserver namespace.
Step

If you want to display...
Summary information about mounted volume show -vserver vserver_name -junction

and unmounted volumes on a
Vserver
Detailed information about mounted
Vserver
volume show -vserver vserver_name -volume

volume_name -instance
Specific information about mounted

Vserver
a. If necessary, you can display valid fields for the -fields

parameter by using the following command:
volume show -fields ?
b. Display the desired information by using the -fields
parameter:
volume show -vserver vserver_name -fields
fieldname,...
Examples
The following example displays a summary of mounted and unmounted volumes on Vserver
vs1:
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
true
/data
RW_volume
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
true
/sales
RW_volume
The following example displays information about specified fields for volumes located on
Vserver vs2:
cluster1::> volume show -vserver vs2 -fields vserver,volume,aggregate,size,state,type,securitystyle,junction-path,junction-parent,node
vserver volume
aggregate size state type security-style junction-path junction-parent node
------- -------------- ---- ------ ---- -------------- ------------- --------------- ----vs2
data1
aggr3
2GB online RW
unix
node3
vs2
data2
aggr3
1GB online RW
ntfs
/data2
vs2_root
node3

vs2
vs2
vs2
vs2
vs2
vs2
data2_1
data2_2
pubs
images
logs
vs2_root
aggr3
aggr3
aggr1
aggr3
aggr1
aggr3
8GB
8GB
1GB
2TB
1GB
1GB
online
online
online
online
online
online
RW
RW
RW
RW
RW
RW
ntfs
ntfs
unix
ntfs
unix
ntfs
/data2/d2_1
/data2/d2_2
/publications
/images
/logs
/
data2
data2
vs2_root
vs2_root
vs2_root
-
node3
node3
node1
node3
node1
node3
Configuring security styles

You configure security styles on volumes and qtrees to determine the type of permissions Data
ONTAP uses to control access and what client type can modify these permissions.
Related concepts
How security styles affect data access on page 23
Configuring security styles on Vserver root volumes

You configure the Vserver root volume security style to determine the type of permissions used for
data on the root volume of a Vserver.
Steps
1. Perform one of the following actions:

Create the Vserver with the... Specify the security style by...
vserver setup command
Entering the desired root volume security style when prompted by the
CLI wizard.
vserver create command Including the -rootvolume-security-style parameter with the

desired security style.
The possible options for the root volume security style are unix, ntfs, or mixed. You cannot
use unified security style because it only applies to Infinite Volumes.
For more information about the vserver setup or vserver create commands, see the
Clustered Data ONTAP System Administration Guide for Cluster Administrators.
2. To display the configuration, including the security style of the Vserver you created, enter the
following command:
vserver show -vserver vserver_name
Configuring security styles on FlexVol volumes

You configure the FlexVol volume security style to determine the type of permissions used for data
on FlexVol volumes of a Vserver.
Steps

If the FlexVol volume... Use the command...
Does not yet exist
volume create and include the -security-style parameter to specify

the security style.
Already exists
volume modify and include the -security-style parameter to specify

the security style.
The possible options for the FlexVol volume security style are unix, ntfs, or mixed. You
cannot use unified security style because it only applies to Infinite Volumes.
If you do not specify a security style when creating a FlexVol volume, the default security style is
mixed.
For more information about the volume create or volume modifycommands, see the
Clustered Data ONTAP Logical Storage Management Guide.
2. To display the configuration, including the security style of the FlexVol volume you created,
enter the following command:
volume show -volume volume_name -instance
Configuring security styles on qtrees

You configure the qtree volume security style to determine the type of permissions used for data on
qtrees.
Steps

If the qtree...
Use the command...
Does not exist yet volume qtree create and include the -security-style parameter to
specify the security style.
Already exists
volume qtree modify and include the -security-style parameter to

The possible options for the qtree security style are unix, ntfs, or mixed. You cannot use
unified security style because it only applies to Infinite Volumes.
If you do not specify a security style when creating a qtree, the default security style is mixed.

For more information about the volume qtree create or volume qtree modify
commands, see the Clustered Data ONTAP Logical Storage Management Guide.
2. To display the configuration, including the security style of the qtree you created, enter the
following command:
volume qtree show -qtree qtree_name -instance
Modifying protocols for Vservers

Before you can configure and use NFS or CIFS on Vservers, you must enable the protocol. This is
typically done during Vserver setup, but if you did not enable the protocol during setup, you can
enable it later by using the vserver modify command.
Steps
1. Check which protocols are currently enabled for a Vserver by entering the following command:
vserver show -vserver vserver_name -fields allowed-protocols
2. Modify the list of enabled protocols for a Vserver by entering the following command:
vserver modify vserver vserver_name -allowed-protocols
protocol_name[,protocol_name,...]
You must enter the complete list of protocols you want to be enabled on the Vserver, including
the protocols that are already enabled. Any protocol not specified with the command is
automatically disabled and moved to the disallowed protocol list.
You can also use the Vserver setup wizard to modify protocols for Vservers by using the
vserver setup command.
See the man page for each command for more information.
3. Confirm that the allowed protocol list was updated correctly by entering the following command:
Examples
The following command displays which protocols are currently enabled on a Vserver named
vs1.
vs1::> vserver show -vserver vs1 -fields allowed-protocols
vserver allowed-protocols
------- ----------------vs1
nfs
The following command adds CIFS to the list of enabled protocols on a Vserver named vs1.
vs1::> vserver modify -vserver vs1 -allowed-protocols nfs,cifs
Enabling or disabling NFSv3

You can enable or disable NFSv3 by modifying the -v3 option. This allows file access for clients
using the NFSv3 protocol. By default, NFSv3 is enabled.
Step

If you want to...
Enable NFSv3
vserver nfs modify -vserver vserver_name -v3 enabled
Disable NFSv3
vserver nfs modify -vserver vserver_name -v3 disabled
Enabling or disabling NFSv4.0

You can enable or disable NFSv4.0 by modifying the -v4.0 option. This allows file access for
clients using the NFSv4.0 protocol. By default, NFSv4.0 is disabled.
About this task
NFSv4.0 is not supported for Vservers with Infinite Volume.

Step

If you want to...
Enter the following command...
Enable NFSv4.0
vserver nfs modify -vserver vserver_name -v4.0 enabled
Disable NFSv4.0
vserver nfs modify -vserver vserver_name -v4.0 disabled
Enabling or disabling NFSv4.1

You can enable or disable NFSv4.1 by modifying the -v4.1 option. This allows file access for
clients using the NFSv4.1 protocol. By default, NFSv4.1 is disabled.
Step

If you want to...
Enable NFSv4.1
vserver nfs modify -vserver vserver_name -v4.1 enabled
Disable NFSv4.1
vserver nfs modify -vserver vserver_name -v4.1 disabled
Enabling or disabling parallel NFS

To enable or disable parallel NFS (pNFS), you can modify the -v4.1-pnfs option. By default
pNFS is enabled.
Before you begin
NFSv4.1 support is required to be able to use pNFS.

If you want to enable parallel NFS, you must first disable NFS referrals. They cannot be both enabled
at the same time.
Step

If you want to... Enter the command...
Enable pNFS
vserver nfs modify -vserver vserver_name -v4.1-pnfs enabled
Disable pNFS
vserver nfs modify -vserver vserver_name -v4.1-pnfs

disabled
Related tasks

Enabling or disabling NFSv4 referrals on page 106
Creating an NFS server

The NFS server is necessary to provide NFS clients with access to a Vserver. You can use the
vserver nfs create command to create an NFS server.
Before you begin
The cluster administrator might also want to configure an NTP server for the Vserver. See the
Clustered Data ONTAP System Administration Guide for Vserver Administrators for more
information.

Before creating an NFS server, you might want to configure an NIS domain for the Vserver. If not,
the NFS server uses local-users and local-groups.
Step
1. Use the vserver nfs create command to create an NFS server.

Example
The following command creates an NFS server on a Vserver named vs1 with NFSv3 disabled,
NFSv4.0 enabled, and NFSv4.0 ACLs enabled.
vs1::> vserver nfs create -vserver vs1 -v3 disabled -v4.0 enabled v4.0-acl enabled
Related tasks
Creating a NIS domain configuration on page 81

Related references
Commands for managing NFS servers on page 84
Securing NFS access using export policies

You can use export policies to restrict NFS access to volumes to clients that match specific
parameters.
How export policies control client access to volumes

Export policies contain one or more export rules that process each client access request. The result of
the process determines whether the client is denied or granted access and what level of access. An
export policy with export rules must exist on a Vserver for clients to access data.
You associate exactly one export policy with each volume to configure client access to the volume. A
Vserver can contain multiple export policies. This enables you to do the following for Vservers with
multiple volumes:
Assign different export policies to each volume of a Vserver for individual client access control
to each volume in the Vserver.
Assign the same export policy to multiple volumes of a Vserver for identical client access control
without having to create a new export policy for each volume.
If a client makes an access request that is not permitted by the applicable export policy, the request
fails with a permission-denied message. If a client does not match any rule in the volume's export
policy, then access is denied. If an export policy is empty, then all accesses are implicitly denied.

You can modify an export policy dynamically on a system running Data ONTAP.
Default export policy for a Vserver with FlexVol volume

Each Vserver with FlexVol volume has a default export policy that contains no rules. An export
policy with rules must exist before clients can access data on the Vserver, and each FlexVol volume
contained in the Vserver must be associated with an export policy.
When you create a Vserver with FlexVol volume, the storage system automatically creates a default
export policy called default for the root volume of the Vserver. You must create one or more rules
for the default export policy before clients can access data on the Vserver. Alternatively, you can
create a custom export policy with rules. You can modify and rename the default export policy, but
you cannot delete the default export policy.
When you create a FlexVol volume in its containing Vserver with FlexVol volume, the storage
system creates the volume and associates the volume with the default export policy for the root
volume of the Vserver. By default, each volume created in the Vserver is associated with the default
export policy for the root volume. You can use the default export policy for all volumes contained in
the Vserver, or you can create a unique export policy for each volume. You can associate multiple
volumes with the same export policy.
How export rules work

Export rules are the functional elements of an export policy. Export rules match client access
requests to a volume against specific parameters you configure to determine how to handle the client
access requests.
An export policy must contain at least one export rule to allow access to clients. If an export policy
contains more than one rule, the rules are processed in the order in which they appear in the export
policy. The rule order is dictated by the rule index number. If a rule matches a client, the permissions
of that rule are used and no further rules are processed. If no rules match, the client is denied access.
You can configure export rules to determine client access permissions using the following criteria:
The file access protocol used by the client sending the request, for example, NFSv4 or SMB.
A client identifier, for example, host name or IP address.
The security type used by the client to authenticate, for example, Kerberos v5, NTLM, or
AUTH_SYS.
If a rule specifies multiple criteria, and the client does not match one or more of them, the rule does
not apply.
Example
The export policy contains an export rule with the following parameters:
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule any

The client access request is sent using the NFSv3 protocol and the client has the IP address
10.1.17.37.
Even though the client access protocol matches, the IP address of the client is in a different
subnet from the one specified in the export rule. Therefore, client matching fails and this rule
does not apply to this client.
Example
-protocol nfs
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule any
10.1.16.54.
The client access protocol matches and the IP address of the client is in the specified subnet.
Therefore, client matching is successful and this rule applies to this client. The client gets
read-write access regardless of its security type.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm
Client #1 has the IP address 10.1.16.207, sends an access request using the NFSv3 protocol,
and authenticated with Kerberos v5.
and authenticated with AUTH_SYS.
The client access protocol and IP address matches for both clients. The read-only parameter
allows read-only access to all clients regardless of the security type they authenticated with.
Therefore both clients get read-only access. However, only client #1 gets read-write access
because it used the approved security type Kerberos v5 to authenticate. Client #2 does not get
read-write access.
How to handle clients with an unlisted security type

When a client presents itself with a security type that is not listed in an access parameter of an export
rule, you have the choice of either denying access to the client or mapping it to the anonymous user
ID instead by using the option none in the access parameter.
A client might present itself with a security type that is not listed in an access parameter because it
was authenticated with a different security type or was not authenticated at all (security type
AUTH_NONE). By default, the client is automatically denied access to that level. However, you can
add the option none to the access parameter. As a result, clients with an unlisted security style are
mapped to the anonymous user ID instead. The -anon parameter determines what user ID is
assigned to those clients. The user ID specified for the -anon parameter must be a valid user that is
configured with permissions you deem appropriate for the anonymous user.
Valid values for the -anon parameter range from 0 to 65535.
User ID assigned to -anon
Resulting handling of client access requests
0 - 65533
The client access request is mapped to the anonymous user

ID and gets access depending on the permissions
configured for this user.
65534
The client access request is mapped to the user nobody and

gets access depending on the permissions configured for
this user. This is the default.
65535
The access request from any client is denied when mapped

to this ID and the client presents itself with security type
AUTH_NONE.
The access request from clients with user ID 0 is denied
when mapped to this ID and the client presents itself with
any other security type.
When using the option none, it is important to remember that the read-only parameter is processed
first. Consider the following guidelines when configuring export rules for clients with unlisted
security types:
Read-only
includes none
Read-write
includes none
Resulting access for clients with unlisted security types
No
No
Denied
No
Yes
Denied because read-only is processed first
Yes
No
Read-only as anonymous
Yes
Yes
Read-write as anonymous

Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule sys,none
-rwrule any
-anon 70
and did not authenticate (meaning security type AUTH_NONE).
The client access protocol and IP address matches for all three clients. The read-only
parameter allows read-only access to clients with their own user ID that authenticated with
AUTH_SYS. The read-only parameter allows read-only access as the anonymous user with
user ID 70 to clients that authenticated using any other security type. The read-write parameter
allows read-write access to any security type, but in this case only applies to clients already
filtered by the read-only rule.
Therefore, clients #1 and #3 get read-write access only as the anonymous user with user ID 70.
Client #2 gets read-write access with its own user ID.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule sys,none
-rwrule none
-anon 70

allows read-write access only as the anonymous user.
Therefore, client #1 and client #3 get read-write access only as the anonymous user with user
ID 70. Client #2 gets read-only access with its own user ID but is denied read-write access.
How security types determine client access levels

The security type that the client authenticated with plays a special role in export rules. You must
understand how the security type determines the levels of access the client gets to a volume.
The three possible access levels are as follows:
1. Read-only
2. Read-write
3. Superuser (for clients with user ID 0)
Because the access level by security type is evaluated in this order, you must observe the following
rules when constructing access level parameters in export rules:
For a client to get access
level...
These access parameters must match the client's security

type...
Normal user read-only
Read-only (-rorule)
Normal user read-write
Read-only (-rorule) and read-write (-rwrule)
Superuser read-only
Read-only (-rorule) and -superuser
Superuser read-write
Read-only (-rorule) and read-write (-rwrule) and -superuser
The following are valid security types for each of these three access parameters:
any
none
never
This security type is not valid for use with the -superuser parameter.
krb5
ntlm
sys
When matching a client's security type against each of the three access parameters, there are three
possible outcomes:

If the client's security type...
Then the client...
Matches one specified in the access parameter.
Gets access for that level with its own user ID.
Does not match one specified, but the access

parameter includes the option none.
Gets access for that level but as the anonymous

user with the user ID specified by the -anon
parameter.
Does not match one specified and the access

parameter does not include the option none.
Does not get any access for that level.

This does not apply to the -superuser
parameter because it always includes none even
when not specified.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule sys,krb5
-superuser krb5
Client #1 has the IP address 10.1.16.207, has user ID 0, sends an access request using the
NFSv3 protocol, and authenticated with Kerberos v5.
NFSv3 protocol, and authenticated with AUTH_SYS.
NFSv3 protocol, and did not authenticate (AUTH_NONE).
parameter allows read-only access to all clients regardless of security type. The read-write
parameter allows read-write access to clients with their own user ID that authenticated with
AUTH_SYS or Kerberos v5. The superuser parameter allows superuser access to clients with
user ID 0 that authenticated with Kerberos v5.
Therefore, client #1 gets superuser read-write access because it matches all three access
parameters. Client #2 gets read-write access but not superuser access. Client #3 gets read-only
access but not superuser access.
How to handle superuser access requests

When you configure export policies, you need to consider what you want to happen if the storage
system receives a client access request with user ID 0, meaning as a superuser, and set up your export
rules accordingly.
In the UNIX world, a user with the user ID 0 is known as the superuser, typically called root, who
has unlimited access rights on a system. Using superuser privileges can be dangerous for several
reasons, including breach of system and data security.
By default, Data ONTAP maps clients presenting with user ID 0 to the anonymous user. However,
you can specify the -superuser parameter in export rules to determine how to handle clients
presenting with user ID 0 depending on their security type. The following are valid options for the superuser parameter:
any
none
This is the default setting if you do not specify the -superuser parameter.
krb5
ntlm
sys
There are two different ways how clients presenting with user ID 0 are handled, depending on the superuser parameter configuration:
If the -superuser parameter and the client's Then the client...
security type...
Match
Gets superuser access with user ID 0.
Do not match
Gets access as the anonymous user with the user

ID specified by the -anon parameter and its
assigned permissions.
This is regardless of whether the read-only or
read-write parameter specifies the option none.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm
-anon 127

However, only client #1 gets read-write access because it used the approved security type
Kerberos v5 to authenticate.
Client #2 does not get superuser access. Instead, it gets mapped to anonymous because the superuser parameter is not specified. This means it defaults to none and automatically maps
user ID 0 to anonymous. Client #2 also only gets read-only access because its security type did
not match the read-write parameter.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm
-superuser krb5
-anon 0
Kerberos v5 to authenticate. Client #2 does not get read-write access.
The export rule allows superuser access for clients with user ID 0. Client #1 gets superuser
access because it matches the user ID and security type for the read-only and -superuser
parameters. Client #2 does not get read-write or superuser access because its security type
does not match the read-write parameter or the -superuser parameter. Instead, client #2 is
mapped to the anonymous user, which in this case has the user ID 0.
Creating an export policy

Before creating export rules, you must create an export policy to hold them. You can use the
vserver export-policy create command to create an export policy.
Steps
1. To create an export policy, enter the following command:

vserver export-policy create -vserver virtual_server_name -policyname
policy_name
-vserver virtual_server_name specifies the Vserver name.
-policyname policy_name specifies the name of the new export policy. The policy name can
be up to 256 characters long.

2. Use the volume modify command to assign the export policy to a volume.
Example
The following command creates an export policy named rs1 on a Vserver named vs1:
vs1::> vserver export-policy create -vserver vs1 -policyname rs1
Related references
Commands for managing export policies on page 91
Adding a rule to an export policy

You can use the vserver export-policy rule create command to create an export rule for
an export policy. This enables you to define client access to data.
Before you begin
The export policy you want to add the export rules to must already exist.
About this task
Step
1. To create an export rule, enter the following command:

vserver export-policy rule create -vserver virtual_server_name policyname policy_name -ruleindex integer -protocol {any|nfs3|nfs|cifs|
nfs4|flexcache},... -clientmatch text -rorule {any|none|never|krb5|ntlm|
sys},... -rwrule {any|none|never|krb5|ntlm|sys},... -anon user_ID -

superuser {any|none|krb5|ntlm|sys},... -allow-suid {true|false} -allowdev {true|false}
-policyname policy_name specifies the name of the existing export policy to add the rule to.
-ruleindex integer specifies the index number for the rule. Rules are evaluated according to
their order in the list of index numbers; rules with lower index numbers are evaluated first. For
example, the rule with index number 1 is evaluated before the rule with index number 2.
-protocol {any|nfs3|nfs|cifs|nfs4|flexcache} specifies the access protocols that the
export rule applies to. You can specify a comma-separated list of multiple access protocols for an
export rule. If you specify the protocol as any, do not specify any other protocols in the list. If
you do not specify an access protocol, the default value of any is used.
-clientmatch text specifies the client to which the rule applies. You can specify the match in
any of the following formats:

Client match format
Example
Domain name preceded by the "." character
.example.com
Host name
host1
IPv4 address
10.1.12.24
IPv4 address with a subnet mask expressed as

a number of bits
10.1.12.10/4
IPv4 address with a network mask
10.1.16.0/255.255.255.0
IPv6 address in dotted format
::1.2.3.4

a number of bits
ff::00/32
Netgroup with the netgroup name preceded by

the @ character
@netgroup1
Note: Entering an IP address range, such as 10.1.12.10-10.1.12.70, is not allowed. Entries in

this format are interpreted as a text string and treated as a host name. Entering an IPv6 address
with a network mask, such as ff::12/ff::00, is not allowed.
-rorule {any|none|never|krb5|ntlm|sys|} provides read-only access to clients that
authenticate with the specified security types.

-rwrule {any|none|never|krb5|ntlm|sys|} provides read-write access to clients that

Note: A client can only get read-write access for a specific security type if the export rule
allows read-only access for that security type as well. If the read-only parameter is more

restrictive for a security type than the read-write parameter, the client cannot get read-write
access.
You can specify a comma-separated list of multiple security types for a rule. If you specify the
security type as any or never, do not specify any other security types. Choose from the
following valid security types:
any
A matching client can access the volume regardless of security type.
none
If listed alone, clients with any security type are granted access as anonymous. If listed with
other security types, clients with a specified security type are granted access and clients with
any other security type are granted access as anonymous.
never
A matching client cannot access the volume regardless of security type.
krb5
A matching client can access the volume if it is authenticated by Kerberos 5.
ntlm
A matching client can access the volume if it is authenticated by CIFS NTLM.
sys
A matching client can access the volume if it is authenticated by NFS AUTH_SYS.

-anon user_ID specifies a UNIX user ID or user name that is mapped to client requests that
arrive with a user ID of 0 (zero), which is typically associated with the user name root. The
default value is 65534, which is typically associated with the user name nobody.
-superuser {any|none|krb5|ntlm|sys|} provides superuser access to clients that authenticate
with the specified security types.

Note: A client can only get superuser access for a specific security type if the export rule
restrictive for a security type than the superuser parameter, the client cannot get superuser
access.
-allow-suid {true|false} specifies whether to allow access to set user ID (suid) and set
group ID (sgid). The default is true.
-allow-dev {true|false} specifies whether to allow creation of devices. The default is true.
Example
The following command creates an export rule on a Vserver named vs1 in an export policy
named rs1. The rule has the index number 1. The rule matches all clients. The rule enables all
NFS access. It enables read-only access by all clients and requires Kerberos authentication for
read-write access. Clients with the UNIX user ID 0 (zero) are mapped to user ID 65534 (which
typically maps to the user name nobody). The rule enables suid and sgid access but does not
enable the creation of devices.

vs1::> vserver export-policy rule create -vserver vs1
-policyname rs1 -ruleindex 1 -protocol nfs -clientmatch 0.0.0.0/0
-rorule any -rwrule krb5 -anon 65534 -allow-suid true -allow-dev
false
Related tasks
Creating an export policy on page 57

Related references
Commands for managing export rules on page 92
Setting an export rule's index number

You can use the vserver export-policy rule setindex command to manually set an
existing export rule's index number. This enables you to rearrange the order in which Data ONTAP
processes export rules.
About this task
If the new index number is already in use, the command inserts the rule at the specified spot and
reorders the list accordingly.
Step
1. To modify the index number of a specified export rule, enter the following command:
vserver export-policy rule setindex -vserver virtual_server_name policyname policy_name -ruleindex integer -newruleindex integer
-policyname policy_name specifies the policy name.
-ruleindex integer specifies the current index number of the export rule.
-newruleindex integer specifies the new index number of the export rule.
Example
The following command changes the index number of an export rule at index number 3 to
index number 2 in an export policy named rs1 on a Vserver named vs1.
vs1::> vserver export-policy rule setindex -vserver vs1
-policyname rs1 -ruleindex 3 -newruleindex 2
Associating an export policy to a FlexVol volume

Each FlexVol volume contained in the Vserver with FlexVol must be associated with an export
policy that contains export rules for clients to access data in the volume.
About this task
When you create a Vserver, Data ONTAP creates a default export policy called default for the
Vserver. Data ONTAP assigns the default export policy to the Vserver's volumes. You can associate
another custom export policy that you create instead of the default policy to a volume. Before you
associate a custom export policy to a volume, you must create one or more export rules that allow the
desired access to data in the volume and assign those export rules to the export policy that you want
to associate with the volume.
You can associate an export policy to a volume when you create the volume or at any time after you
create the volume. You can associate one export policy to the volume.
Steps
1. Use either the volume create or volume modify command with the -policy option to
associate an export policy to the volume.
Example
cluster::> volume create -vserver vs1 -volume vol1
-aggregate aggr2 -state online -policy cifs_policy -security-style
ntfs
-junction-path /dept/marketing -size 250g -space-guarantee volume
For more information about the volume create and volume modify commands, see the man
pages.
2. Verify that the export policy associated with the volume has the desired access configuration
using the vserver export-policy rule show command with the -policyname option.
Example
cluster::> vserver export-policy rule show -policyname cifs_policy
Virtual
Policy
Rule
Access
Client
RO
Server
Name
Index
Protocol Match
Rule
------------ ------------------ ------ -------- ------------ -----vs1
cifs_policy
1
cifs
0.0.0.0/0
any
For more information about the vserver export-policy rule show command, see the man
pages.

The command displays a summary for that export policy, including a list rules applied to that
policy. Data ONTAP assigns each rule a rule index number. After you know the rule index
number, you can use it to display detailed information about the specified export rule.
3. Verify that the rules applied to the export policy are configured correctly by using the vserver
export-policy rule show command and specify the -policyname, -vserver, and ruleindex options.
Example
cluster::> vserver export-policy rule show -policyname cifs_policy vserver vs1 -ruleindex 1
Virtual Server: vs1
Policy Name: cifs_policy
Rule Index: 1
Access Protocol: cifs
Client Match Spec: 0.0.0.0/0
RO Access Rule: any
RW Access Rule: any
User ID To Which Anonymous Users Are Mapped: 0
Superuser Security Flavors: any
Honor SetUID Bits In SETATTR: true
Allow Creation of Devices: true
Export policy restrictions and nested junctions for FlexVol volumes

If you configured export policies to set a less restrictive policy on a nested junction but a more
restrictive policy on a higher level junction, access to the lower level junction might fail.
You should ensure that higher level junctions have less restrictive export policies than lower level
junctions.
Using Kerberos with NFS for strong security

You can use Kerberos to provide strong authentication between Vservers and NFS clients to ensure
secure NFS communication.
Beginning with version 3, NFS supports generic security services for RPC (RPCSEC_GSS), which
enables the use of Kerberos 5. Kerberos provides strong secure authentication for client/server
applications. Authentication provides verification of a user's or process's identity to a server. In the
Data ONTAP environment, Kerberos provides authentication between Vservers and NFS clients.
Group ID limitation for NFS RPCSEC_GSS

Although Data ONTAP supports generic security services for RPC (RPCSEC_GSS) for NFSv3 and
later, you should be aware of a limitation related to the number of group IDs for UNIX users.
Data ONTAP supports up to 32 group IDs when handling NFS user credentials using RPCSEC_GSS
authentication. If a user has more than 32 group IDs in their credentials, the remaining group IDs are
truncated.
To avoid authentication issues due to this limitation, ensure that users do not belong to more than 32
groups.
Requirements for configuring Kerberos with NFS

Before you configure Kerberos with NFS on the storage system, you must verify that certain items in
your network and storage environment are properly configured.
Note: The steps to configure your environment depend on what version and type of client
operating system, domain controller, Kerberos, DNS, etc., that you are using. Documenting all
these variables is beyond the scope of this document. For more information, see the respective
documentation for each component.
For a detailed example of how to set up clustered Data ONTAP and Kerberos 5 with NFSv3 and
NFSv4 in an environment using Windows Server 2008 R2 Active Directory and Linux hosts, see
technical report 4073.
The following items should be configured first:
Network environment requirements
Kerberos
You must have a working Kerberos setup with a key distribution center (KDC), such as Windows
Active Directory based Kerberos or MIT Kerberos.
NFS servers must use nfs as the primary component of their machine principal.
DES encryption
The domain controller must have DES encryption enabled if you are running Windows Active
Directory.
NTP
You must have a working time server running NTP. This is necessary to prevent Kerberos
authentication failure due to time skew.
Domain name resolution (DNS)
Each UNIX client and each Vserver LIF must have a proper service record (SRV) registered with
the KDC under forward and reverse lookup zones. All participants must be properly resolvable
via DNS.
User accounts
Each client must have a user account in the Kerberos realm. NFS servers must use nfs as the
primary component of their machine principal.

NFS client requirements
NFS
Each client must be properly configured to communicate over the network using NFSv3 or
NFSv4.
Clients must support RFC1964 and RFC2203. For more information, see the Interoperability
Matrix at support.netapp.com/NOW/products/interoperability.
Kerberos
Each client must be properly configured to use Kerberos authentication, including the following
details:
Encryption for TGS communication is enabled.

DES for Windows Active Directory based Kerberos or MIT Kerberos, or DES3 for MIT
Kerberos only.
The most secure encryption type for TGT communication is enabled.
The Kerberos realm and domain are configured correctly.
GSS is enabled.
DNS
Each client must be properly configured to use DNS for correct name resolution.
NTP
Each client must be synchronizing with the NTP server.
Host and domain information
Each client's /etc/hosts and /etc/resolv.conf files must contain the correct host name and
DNS information, respectively.
Keytab files
Each client must have a keytab file from the KDC. The realm must be in uppercase letters. The
encryption type must be DES-CBC-MD5 (for Windows Active Directory based Kerberos or MIT
Kerberos) or DES3-CBC-SHA1 (for MIT Kerberos only). For Windows, you must allow weak
cryptography to use DES.
Optional: For best performance, clients benefit from having at least two network interfaces: one
for communicating with the local area network and one for communicating with the storage
network.
Storage system requirements
IPv4
You must have IPv4 network connectivity configured. Kerberos is not supported over IPv6.
NFS license
The storage system must have a valid NFS license installed. For more information about
managing feature licenses, see the Clustered Data ONTAP System Administration Guide for
Cluster Administrators.
CIFS license
The CIFS license is optional. It is only required for checking Windows credentials when using
multiprotocol name mapping. It is not required in a strict UNIX-only environment. For more
information about managing feature licenses, see the Clustered Data ONTAP System
Administration Guide for Cluster Administrators.
Vserver
You must have at least one Vserver configured on the storage system. For more information
about configuring Vservers, see the Data ONTAP Software Setup Guide for Cluster-Mode.
DNS on the Vserver
You must have configured DNS on each Vserver. For more information about configuring DNS
on Vservers, see the Data ONTAP Software Setup Guide for Cluster-Mode.
NFS server
You must have configured NFS on the Vserver.
CIFS server
If you are running a multiprotocol environment, you must have configured CIFS on the Vserver.
The CIFS server is required for multiprotocol name mapping.
Volumes
You must have a root volume and at least one data volume configured for use by the Vserver. For
more information about configuring volumes, see the Clustered Data ONTAP Logical Storage
Management Guide.
Root volume
The root volume of the Vserver must have the following configuration:
Set the...
To...
Security style
UNIX
UID
root or ID 0
GID
root or ID 0
UNIX permissions
777
In contrast to the root volume, data volumes can have either security style.
UNIX groups
The Vserver must have the following UNIX groups configured:
Group name
Group ID
daemon
root
pcuser
65534 (created automatically by Data ONTAP when

you create a Vserver)
UNIX users
The Vserver must have the following UNIX users configured:
User
name
User ID
Primary
group ID
Comment
nfs
500
Required for GSS INIT phase

The first component of the server SPN is used as the
user.
pcuser
65534
65534
Required for NFS and CIFS multiprotocol use

Created and added to the pcuser group automatically
by Data ONTAP when you create a Vserver.
root
Required for mounting
The nfs user is not required if a Kerberos-UNIX name mapping exists for the SPN that is bound
to the data LIF.
Export policies and rules
You must have configured export policies with the necessary export rules for the root and data
volumes. If all volumes of the Vserver are accessed over Kerberos, you can set the export rule for
the root volume to anon=0, -rorule, -rwrule, -superuser, and -krb.
Kerberos-UNIX name mapping
The Vserver must have the Kerberos principal nfs/fqdn@REALM mapped to the UNIX user root.
Related concepts
Securing NFS access using export policies on page 48

Related tasks
Enabling or disabling NFSv3 on page 46

Creating a local UNIX user on page 77
Creating a local UNIX group on page 79
Related information
Technical Report: Kerberos Implementation with Data ONTAP 8.1 Cluster-Mode and Windows
Server 2008 R2 Active Directory: media.netapp.com/documents/tr-4073.pdf
Specifying the user ID domain for NFSv4

To specify the user ID domain, you can set the -v4-id-domain option.
About this task
By default, Data ONTAP uses the NIS domain for NFSv4 user ID mapping, if one is set. If an NIS
domain is not set, the DNS domain is used. You might need to set the user ID domain if, for

example, you have multiple user ID domains. The domain name must match the domain
configuration on the domain controller. It is not required for NFSv3.
Step
1. Enter the following command:

vserver nfs modify -vserver vserver_name -v4-id-domain NIS_domain_name
Configuring a Vserver to use LDAP

You can configure Vservers to use LDAP servers in your environment for obtaining network
information. You modify the -ns-switch parameter to configure the network information sources
and the -nm-switch parameter to configure the name mapping sources for Vservers.
Step

If you want to configure a Vserver to use
LDAP as a...
Network information source
vserver modify -vserver vserver_name ns-switch file,ldap
Network information source and for name

mapping.
vserver modify -vserver vserver_name ns-switch file,ldap -nm-switch

file,ldap
-ns-switch specifies the sources to search for network information and in what order.
-nm-switch specifies the sources to search for name mapping information and in what order. In
a UNIX-only environment, this switch is not necessary. Name mapping is only required in a
mixed environment using both UNIX and Windows.
See the man page for the command for more information.
Creating a Kerberos realm configuration

If you want to use Kerberos authentication for client access, you must first configure the Vserver to
use an existing Kerberos realm. You can use the vserver services kerberos-realm create
command to configure a Vserver to use a Kerberos realm.
Before you begin
The cluster administrator should have configured NTP on the storage system to avoid authentication
issues. Time differences between a client and server (clock skew) are a common cause of
authentication failures.

Step
1. Use the vserver services kerberos-realm create command to configure a Kerberos

realm.
Examples
The following command creates a Kerberos realm configuration that uses a Microsoft Active
Directory server as the KDC server. The Kerberos configuration is named AUTH. The
Kerberos realm is AUTH.EXAMPLE.COM. The Active Directory server is named ad-1 and
its IP address is 10.10.8.14. The permitted clock skew is 300 seconds (the default). The IP
address of the KDC server is 10.10.8.14, and its port number is 88 (the default). The
encryption type is Data Encryption Standard (DES). The comment is "Microsoft Kerberos
config".
vs1::> vserver services kerberos-realm create -configname AUTH
-realm AUTH.EXAMPLE.COM -adserver-name ad-1 -adserver-ip 10.10.8.14
-clock-skew 300 -kdc-ip 10.10.8.14 -kdc-port 88 -kdc-vendor
Microsoft -comment "Microsoft Kerberos config"
The following command creates a Kerberos realm configuration that uses an MIT KDC. The
Kerberos configuration is named SECURE. The Kerberos realm is
SECURITY.EXAMPLE.COM. The permitted clock skew is 15 seconds and the Active
Directory server and IP address are SUSAN and 10.10.3.1, respectively. The IP address of the
KDC server is 10.10.9.1, and its port number is 88. The KDC vendor is Other to indicate a
UNIX vendor. The IP address of the administrative server is 10.10.9.1, and its port number is
749 (the default). The IP address of the password server is 10.10.9.1, and its port number is
464 (the default). The encryption type is DES. The comment is "UNIX Kerberos config".
vs1::> vserver services kerberos-realm create -configname SECURE
-realm SECURITY.EXAMPLE.COM. -clock-skew 300 -adserver-name SUSAN adserver-ip 10.10.3.1
-kdc-ip 10.10.9.1 -kdc-port 88 -kdc-vendor Other -adminserver-ip
10.10.9.1 -adminserver-port 749
-passwordserver-ip 10.10.9.1 -passwordserver-port 464 -comment
"UNIX Kerberos config"
Related references
Commands for managing Kerberos realm configurations on page 91
Creating an NFS Kerberos configuration

You can use the vserver nfs kerberos-config modify command to enable Kerberos and
create a Kerberos configuration for a Vserver. This enables the Vserver to use Kerberos security
services for NFS.
About this task
For best performance, the Vserver should have at least two data LIFs. One for use by the SPN for
UNIX and CIFS related Kerberos traffic, and another one for non-Kerberos traffic.
If you are using Microsoft Active Directory Kerberos, the first 15 characters of any service principal
names (SPNs) used in the domain must be unique. Microsoft Active Directory (AD) has a limitation
for SPNs of 15 characters maximum and does not allow duplicate SPNs.
Step

vserver nfs kerberos-config modify -vserver vserver_name -lif
logical_interface -kerberos {enabled|disabled} -spn
service_principal_name -admin-username user_name
Related tasks
Displaying information about NFS Kerberos configurations on page 89

Modifying an NFS Kerberos configuration on page 90
Creating a new LDAP client schema

Data ONTAP provides three LDAP schemas: one for Active Directory Services for UNIX
compatibility, one for Active Directory Identity Management for UNIX compatibility, and one for
RFC-2307 LDAP compatibility. If the LDAP schema in your environment differs from these, you
must create a new LDAP client schema for Data ONTAP.
About this task
The default LDAP schemas provided by Data ONTAP cannot be modified. To create a new schema,
you create a copy and then modify the copy accordingly.
Steps
1. Display the existing LDAP client schema templates to identify the one you want to copy:
vserver services ldap client schema show
2. Set the privilege level to advanced:

set -privilege advanced

3. Make a copy of an existing LDAP client schema:
vserver services ldap client schema copy -vserver vserver_name -schema
existing_schema_name -new-schema-name new_schema_name
4. Use the vserver services ldap client schema modify command to modify the new
schema and customize it for your environment.
5. Return to the admin privilege level:
set -privilege admin
Related references
Commands for managing LDAP client schema templates on page 88
Creating an LDAP client configuration

You can use the vserver services ldap client create command to create an LDAP client
configuration. You must set up an LDAP client first to be able to use LDAP services.
Steps
1. To create an LDAP client configuration, enter the following command:

vserver services ldap client create -vserver vserver_name -client-config
client_config_name {-servers LDAP_server_list | -ad-domain ad_domain preferred-ad-servers preferred_ad_server_list -bind-as-cifs-server
{true|false}} -schema schema -port port -query-timeout integer -minbind-level {anonymous|simple|sasl} -bind-dn LDAP_DN -bind-password
password -base-dn LDAP_DN -base-scope {base|onelevel|subtree}
-vserver vserver_name specifies the name of the Vserver for which you want to create an
LDAP client configuration.

-client-config client_config_name specifies the name of the new LDAP client
configuration.
-servers LDAP_server_list specifies one or more LDAP servers by IP address in a comma-
delimited list.
-ad-domain ad_domain specifies the AD domain.
-preferred-ad-servers preferred_ad_server_list specifies one or more preferred
Active Directory servers by IP address in a comma-delimited list.
-bind-as-cifs-server {true|false} specifies whether to bind using the Vserver's CIFS
credentials. The default is false. If you want to set this parameter to true, you must first install
a CIFS license and create a CIFS Vserver.

-schema schema specifies the schema template to use. You can either use one of the provided
default schemas or create your own schema by copying a default schema (they are read-only) and
modifying the copy.
-port port specifies the LDAP server port. The default is 389.
-query-timeout integer specifies the query timeout in seconds. The allowed range is 0-10
seconds. The default is 3 seconds.

-min-bind-level {anonymous|simple|sasl} specifies the minimum bind authentication
level. The default is anonymous.
-bind-dn LDAP_DN specifies the Bind user. For Active Directory servers, specify the user in the
account (DOMAIN\user) or principal (user@domain.com) form. Otherwise, specify the user in

distinguished name (CN=user,DC=domain,DC=com) form.
-bind-password password specifies the Bind password.
-base-dn LDAP_DN specifies the base DN. The default is "" (root).
-base-scope {base|onelevel|subtree} specifies the base search scope. The default is
subtree.
2. Verify that the LDAP client configuration was created successfully:

vserver services ldap client show -client-config client_config_name
Examples
The following command creates a new LDAP client configuration named ldap1 to work
with an Active Directory server for LDAP:
cluster1::> vserver services ldap client create -vserver vs1 client-config ldapclient1 ad-domain addomain.example.com -bind-ascifs-server true -schema AD-SFU -port 389 -query-timeout 3 -minbind-level simple -base-dn DC=addomain,DC=example,DC=com -basescope subtree -preferred-ad-servers 172.17.32.100
The following command modifies the LDAP client configuration named ldap1 to work with
an Active Directory server for LDAP by specifying an Active Directory domain and to bind to
the server using the Vserver's CIFS credentials:
cluster1::> vserver services ldap client modify -vserver vs1 client-config ldap1 -bind-as-cifs-server true -ad-domain
addomain.example.com
The following command modifies the LDAP client configuration named ldap1 by specifying
the base DN:

cluster1::> vserver services ldap client modify -vserver vs1 client-config ldap1 -base-dn CN=Users,DC=addomain,DC=example,DC=com
Related references
Commands for managing LDAP client configurations on page 87
Enabling LDAP on a Vserver

You can use the vserver services ldap create command to enable LDAP on a Vserver and
configure it to use an LDAP client you created. This enables the Vserver to use LDAP for name
mapping.
Before you begin
An LDAP client configuration must exist on the Vserver.

Step
1. To enable LDAP on a Vserver, enter the following command:

vserver services ldap create -vserver virtual_server_name -client-config
client_config_name -client-enabled true
-client-config client_config_name specifies the client configuration name.
-client-enabled specifies whether the LDAP client is enabled. The default is true.
Example
The following command enables LDAP on a Vserver named vs1 and configures it to use the
LDAP client configuration named ldap1.
cluster1::> vserver services ldap create -vserver vs1 -clientconfig ldap1 -client-enabled true
Related tasks
Enabling LDAP on a Vserver on page 72

Related references
Commands for managing LDAP configurations on page 88
How name mappings are used

Data ONTAP uses name mapping to map CIFS identities to UNIX identities, Kerberos identities to
UNIX identities, and UNIX identities to CIFS identities. It needs this information to obtain user
credentials and provide proper file access regardless of whether they are connecting from an NFS
client or a CIFS client.
Name mapping is usually required due to the multiprotocol nature of Data ONTAP, which supports
CIFS and NFS client access to the same data. Data stored on Vservers with FlexVol volumes uses
either UNIX- or NTFS-style permissions. To authorize a client, the credentials must match the
security style. Consider the following scenarios:
If a CIFS client wants to access data with UNIX-style permissions, Data ONTAP cannot directly
authorize the client because it cannot use CIFS credentials with UNIX-style permissions. To properly
authorize the client request, Data ONTAP must first map the CIFS credentials to the appropriate
UNIX credentials so that it can then use the UNIX credentials to compare them to the UNIX-style
permissions.
If an NFS client wants to access data with NTFS-style permissions, Data ONTAP cannot directly
authorize the client because it cannot use UNIX credentials with NTFS-style permissions. To
properly authorize the client request, Data ONTAP must first map the UNIX credentials to the
appropriate NTFS credentials so that it can then use the NTFS credentials to compare them to the
NTFS-style permissions.
There are two exceptions where you do not have to use name mapping:
You configure a pure UNIX environment and do not plan to use CIFS access or NTFS security
style on volumes.
In this scenario, name mapping is not required because Data ONTAP can use the UNIX
credentials of the NFS clients to directly compare them to the UNIX-style permissions.
You configure the default user to be used instead.
In this scenario, name mapping is not required because instead of mapping every individual client
credential all client credentials are mapped to the same default user.
Note that you can use name mapping only for users, not for groups. It is not possible to map CIFS
users to a group ID (GID), or UNIX users to a group in the Active Directory (AD). Similarly, it is not
possible to map a GID to a group or a user in AD, or an AD group to a UNIX UID or GID.
However, you can map a group of individual users to a specific user. For example, you can map all
AD users that start or end with the word SALES to a specific UNIX user and to the users UID. As a
result, you can rename certain users in AD and use regular expressions to effectively emulate group
actions. This type of mapping also works in reverse.
How name mapping works

Data ONTAP goes through a number of steps when attempting to map user names. They include
checking the local name mapping database and LDAP, trying the user name, and using the default
user if configured.
When Data ONTAP has to map credentials for a user, it first checks the local name mapping
database and LDAP server for an existing mapping. Whether it checks one or both and in which
order is determined by the -nm-switch parameter of the Vserver configuration.
For Windows to UNIX mapping

If no mapping is found, Data ONTAP checks whether the lowercase Windows user name is a
valid user name in the UNIX domain. If this does not work, it uses the default UNIX user
provided it is configured. If the default UNIX user is not configured and it cannot obtain a
mapping this way either, mapping fails and an error is returned.
For UNIX to Windows mapping
If no mapping is found, Data ONTAP tries to find a Windows account that matches the UNIX
name in the CIFS domain. If this does not work, it uses the default CIFS user, provided it is
configured. If the default CIFS user is not configured and it cannot obtain a mapping this way
either, mapping fails and an error is returned.
Name mapping conversion rules

A Data ONTAP system keeps a set of conversion rules for each Vserver. Each rule consists of two
pieces: a pattern and a replacement. Conversions start at the beginning of the appropriate list and
perform a substitution based on the first matching rule. The pattern is a UNIX-style regular
expression. The replacement is a string containing escape sequences representing subexpressions
from the pattern, as in the UNIX sed program.
It is possible to allow NFS access to volumes with NTFS security style for users in a different
domain from the one that the storage system belongs to, provided that the proper name mapping rule
exists.
If a user matches a rule to map to a user in a different domain, the domain must be trusted. To ensure
successful mapping to users in other domains for both CIFS and NFS access, there must be a
bidirectional trust relationship between the domains.
If a user matches a rule but the user cannot authenticate in the other domain because it is untrusted,
the mapping fails. In addition, there is no further processing of other mapping rules subsequent to the
failed one. Therefore, it is important to arrange name mapping rules in the right order so that rules for
other domains are evaluated before the rules for the domain of the Vserver.
Regular expressions are not case-sensitive when mapping from Windows to UNIX. However, they
are case-sensitive for Kerberos-to-UNIX and UNIX-to-Windows mappings.
As an example, the following rule converts the CIFS user named jones in the domain named
ENG into the UNIX user named jones.

Pattern
Replacement
ENG\\jones
jones
Note that the backslash is a special character in regular expressions and must be escaped with another
backslash.
The caret (^), underscore (_), and ampersand (&) characters can be used as prefixes for digits in
replacement patterns. These characters specify uppercase, lowercase, and initial-case
transformations, respectively. For instance:
If the initial pattern is (.+) and the replacement pattern is \1, then the string jOe is mapped to jOe
(no change).
If the initial pattern is (.+) and the replacement pattern is \_1, then the string jOe is mapped to joe.
If the initial pattern is (.+) and the replacement pattern is \^1, then the string jOe is mapped to
JOE.
If the initial pattern is (.+) and the replacement pattern is \&1, then the string jOe is mapped to
Joe.
If the character following a backslash-underscore (\_), backslash-caret (\^), or backslash-ampersand

(\&) sequence is not a digit, then the character following the backslash is used verbatim.
The following example converts any Windows user in the CIFS domain named ENG into a UNIX
user with the same name in NIS.
Pattern
Replacement
ENG\$.+)
\1
The double backslash (\$ matches a single backslash. The parentheses denote a subexpression but do
not match any characters themselves. The period matches any single character. The asterisk matches
zero or more of the previous expression. In this example, you are matching ENG\ followed by one or
more of any character. In the replacement, \1 refers to whatever the first subexpression matched.
Assuming the CIFS user ENG\jones, the replacement evaluates to jones; that is, the portion of the
name following ENG\.
Note: If you are using the CLI, you must delimit all regular expressions with double quotation
marks ("). For instance, to enter the regular expression (.+) in the CLI, type "(.+)" at the command
prompt. Quotation marks are not required in the Web UI.
For further information about regular expressions, see your UNIX system administration
documentation, the online UNIX documentation for sed or regex, or Mastering Regular
Expressions, published by O'Reilly and Associates.
Creating a name mapping

You can use the vserver name-mapping create command to create a name mapping. You use
name mappings to enable Windows users to access UNIX security style volumes and the reverse.
About this task
For each Vserver, Data ONTAP supports up to 1,024 name mappings for each direction.
Step
1. To create a name mapping, enter the following command:

vserver name-mapping create -vserver virtual_server_name -direction
{krb-unix|win-unix|unix-win} -position integer -pattern text replacement text
-direction {krb-unix|win-unix|unix-win} specifies the mapping direction.
-position integer specifies the desired position in the priority list of a new mapping.
-pattern text specifies the pattern to be matched, up to 256 characters in length.
-replacement text specifies the replacement pattern, up to 256 characters in length.
When Windows-to-UNIX mappings are created, any CIFS clients that have open connections to
the Data ONTAP system at the time the new mappings are created must log out and log back in to
see the new mappings.
Examples
The following command creates a name mapping on a Vserver named vs1. The mapping is a
mapping from UNIX to Windows at position 1 in the priority list. The mapping maps the
UNIX user johnd to the Windows user ENG\John.
vs1::> vserver name-mapping create -vserver vs1 -direction unix-win
-position 1 -pattern johnd -replacement "ENG\\John"
The following command creates another name mapping on a Vserver named vs1. The mapping
is a mapping from Windows to UNIX at position 1 in the priority list. The mapping maps
every CIFS user in the domain ENG to users in the NIS domain associated with the Vserver.
vs1::> vserver name-mapping create -vserver vs1 -direction win-unix
-position 1 -pattern "ENG\\(.+)"
-replacement "\1"

Related references
Commands for managing name mappings on page 84

Configuring the default user
You can configure a default user to use if all other mapping attempts fail for a user, or if you do not
want to map individual users between UNIX and Windows. Alternatively, if you want authentication
of non-mapped users to fail, you should not configure a default user.
About this task
For CIFS authentication, if you do not want to map each Windows user to an individual UNIX user,
you can instead specify a default UNIX user.
For NFS authentication, if you do not want to map each UNIX user to an individual Windows user,
you can instead specify a default Windows user.
Step

If you want to...
Configure the default UNIX user
vserver cifs options modify -default-unix-user

user_name
Configure the default Windows user vserver nfs modify -default-win-user user_name
Configuring local UNIX users and groups

You can use local UNIX users and groups for authentication and name mappings.
Creating a local UNIX user

You can use the vserver services unix-user create command to create local UNIX users.
A local UNIX user is a UNIX user you create on a Vserver as a UNIX name services option and to
be used in the processing of name mappings.
Step
1. To create a local UNIX user, enter the following command:

vserver services unix-user create -vserver virtual_server_name -user
user_name -id integer -primary-gid integer -full-name full_name
-user user_name specifies the user name.
-id integer specifies the user ID.

-primary-gid integer specifies the primary group ID.
-full-name full_name specifies the full name of the user.
Example
The following command creates a local UNIX user named bettyb on a Vserver named vs1.
The user has the ID 123 and the primary group ID 100. The user's full name is "Elizabeth
Boop".
node::> vserver services unix-user create -vserver vs1 -user bettyb
-id 123
-primary-gid 100 -full-name "Elizabeth Boop"
Related references
Commands for managing local UNIX users on page 85
Loading local UNIX users from a URI

You can use the vserver services unix-user load-from-uri command to load one or more
local UNIX users into a Vserver from a uniform resource identifier (URI).
About this task
The URI must contain user information in the UNIX /etc/passwd format:
user_name: password: user_ID: group_ID: full_name
The command discards the value of the password field and of the fields after the full_name field
( home_directory and shell).
Step
1. To load one or more local UNIX users into a Vserver from a URI, enter the following command:
vserver services unix-user load-from-uri -vserver virtual_server_name uri {ftp|http}://uri -overwrite {true|false}
-uri {ftp|http}://uri specifies the URI to load from.
-overwrite {true|false} specifies whether to overwrite entries. The default is false.
Example
The following command loads user information from the URI ftp://ftp.example.com/
passwd into a Vserver named vs1. Existing users on the Vserver are not overwritten by
information from the URI.

node::> vserver services unix-user load-from-uri -vserver vs1
-uri ftp://ftp.example.com/passwd -overwrite false
Creating a local UNIX group

You can use the vserver services unix-group create command to create UNIX groups that
are local to a Vserver. Local UNIX groups are used with local UNIX users.
Step
1. To create a local UNIX group, enter the following command:

vserver services unix-group create -vserver virtual_server_name -name
group_name -id integer
-name group_name specifies the group name.
-id integer specifies the group ID.
Example
The following command creates a local group named eng on a Vserver named vs1. The group
has the ID 101.
vs1::> vserver services unix-group create -vserver vs1 -name eng id 101
Related references
Commands for managing local UNIX groups on page 85
Loading local UNIX groups from a URI

You can use the vserver services unix-group load-from-uri command to load one or
more local UNIX groups into a Vserver from a uniform resource identifier (URI).
About this task
The URI must contain user information in the UNIX /etc/group format:
group_name: password: group_ID: comma_separated_list_of_users
The command discards the value of the password field.
Step
1. To load one or more local UNIX groups into a Vserver from URI, enter the following command:

vserver services unix-group load-from-uri -vserver virtual_server_name uri {ftp|http}://uri -overwrite {true|false}
-uri {ftp|http}://uri specifies the URI to load from.
-overwrite {true|false} specifies whether to overwrite entries. The default is false.
Example
The following command loads group information from the URI ftp://ftp.example.com/
group into a Vserver named vs1. Existing groups on the Vserver are not overwritten by
information from the URI.
vs1::> vserver services unix-group load-from-uri -vserver vs1
-uri ftp://ftp.example.com/group -overwrite false
Adding a user to a local UNIX group

You can use the vserver services unix-group adduser command to add a user to a UNIX
group that is local to a Vserver.
Step
1. To add a user to a local UNIX group, enter the following command:

vserver services unix-group adduser -vserver virtual_server_name -name
group_name -username user_name
-name group_name specifies the name of the UNIX group to add the user to.
-username user_name specifies the user name of the user to add to the group.
Example
The following command adds a user named max to a local UNIX group named eng on a
Vserver named vs1.
vs1::> vserver services unix-group adduser -vserver vs1 -name eng
-username max
Loading netgroups into a Vserver

You can use the vserver services netgroup load command to load netgroups into a Vserver
from a uniform resource identifier (URI).
Step
1. To load netgroups into a Vserver from an FTP or HTTP URI, enter the following command:
vserver services netgroup load -vserver vserver_name -source {ftp|
http}://uri
-vserver vserver_name specifies the Vserver name.
-source {ftp|http}://uri specifies the URI to load from.
Example
The following command loads netgroup definitions into a Vserver named vs1 from the HTTP
URL http://intranet/downloads/corp-netgroup:
vs1::> vserver services netgroup load -vserver vs1
-source http://intranet/downloads/corp-netgroup
Related tasks
Verifying the status of netgroup definitions on page 86
Creating a NIS domain configuration

If you specified NIS as a name service option during Vserver setup, you must create a NIS domain
configuration for the Vserver. You can use the vserver services nis-domain create
command to create a NIS domain configuration.
About this task
You can create multiple NIS domains. However, you can only use one that is set to active.
Step
1. Use the vserver services nis-domain create command to create a NIS domain
configuration.

Example
The following command creates a NIS domain configuration for a NIS domain called
nisdomain on Vserver vs1 with a NIS server at IP address 192.0.2.180 and makes it active.
vs1::> vserver services nis-domain create -vserver vs1 -domain
nisdomain -active true -servers 192.0.2.180
Related references
Commands for managing NIS domain configurations on page 87
Support for NFS over IPv6

Starting with Data ONTAP 8.2, NFS clients can access files on your storage system over an IPv6
network.
Enabling IPv6 for NFS

If you want NFS clients to be able to access data on the storage system over an IPv6 network, Data
ONTAP requires several configuration changes.
Steps
1. Enable IPv6 on the cluster.

This step must be performed by a cluster administrator. For more information about enabling
IPv6 on the cluster, see the Clustered Data ONTAP Network Management Guide.
2. Configure data LIFs for IPv6.
This step must be performed by a cluster administrator. For more information about configuring
LIFs, see the Clustered Data ONTAP Network Management Guide.
3. Configure NFS export policies and rules for NFS client access.
If you want to match clients by IPv6 address, be sure to configure the export rules accordingly.
Related concepts
83
Managing file access using NFS

After you have enabled NFS on a Vserver and configured it, there are a number of tasks you might
want to perform to manage file access using NFS.
Controlling NFS requests from nonreserved ports

You can reject NFS mount requests from nonreserved ports by enabling the -mount-rootonly
option. To reject all NFS requests from nonreserved ports, you can enable the -nfs-rootonly
option.
About this task
By default, the option -mount-rootonly is enabled.

By default, the option -nfs-rootonly is disabled.
These options do not apply to the NULL procedure.
Step

If you want to...
Allow NFS mount requests from

nonreserved ports
vserver nfs modify -vserver vserver_name

-mount-rootonly disabled
Reject NFS mount requests from

nonreserved ports

-mount-rootonly enabled
Allow all NFS requests from nonreserved

ports

-nfs-rootonly disabled
Reject all NFS requests from nonreserved

ports

-nfs-rootonly enabled
Considerations for clients that mount NFS exports using a

nonreserved port
The -mount-rootonly option must be disabled on a storage system that must support clients that
mount NFS exports using a nonreserved port even when the user is logged in as root. Such clients
include Hummingbird clients and Solaris NFS/IPv6 clients.
If the -mount-rootonly option is enabled, Data ONTAP does not allow NFS clients that use
nonreserved ports, meaning ports with numbers higher than 1,023, to mount NFS exports.
Commands for managing NFS servers

There are specific Data ONTAP commands for managing NFS servers.
If you want to...
Use this command...
Create an NFS server
vserver nfs create
Display NFS servers
vserver nfs show
Modify an NFS server
vserver nfs modify
Delete an NFS server
vserver nfs delete
Related tasks
Creating an NFS server on page 47
Commands for managing name mappings

There are specific Data ONTAP commands for managing name mappings.
If you want to...
Use this command...
Create a name mapping
vserver name-mapping create
Insert a name mapping at a specific position
vserver name-mapping insert
Display name mappings
vserver name-mapping show
Exchange the position of two name mappings
vserver name-mapping swap
Modify a name mapping
vserver name-mapping modify
Managing file access using NFS | 85

If you want to...
Use this command...
Delete a name mapping
vserver name-mapping delete
Related concepts
How name mappings are used on page 73
Commands for managing local UNIX users

There are specific Data ONTAP commands for managing local UNIX users.
If you want to...
Use this command...
Create a local UNIX user
vserver services unix-user create
Display local UNIX users
vserver services unix-user show
Modify a local UNIX user
vserver services unix-user modify
Delete a local UNIX user
vserver services unix-user delete
Related tasks
Creating a local UNIX user on page 77
Commands for managing local UNIX groups

There are specific Data ONTAP commands for managing local UNIX groups.
If you want to...
Use this command...
Add a user to a local UNIX group
vserver services unix-group adduser
Create a local UNIX group
vserver services unix-group create
Display local UNIX groups
vserver services unix-group show
Modify a local UNIX group
vserver services unix-group modify
Delete a user from a local UNIX group
vserver services unix-group deluser
Delete a local UNIX group
vserver services unix-group delete

Related tasks
Creating a local UNIX group on page 79
Verifying the status of netgroup definitions

After loading netgroups into a Vserver, you can use the vserver services netgroup status
command to verify the status of netgroup definitions. This enables you to determine whether
netgroup definitions are consistent on all of the nodes that back a Vserver.
Steps

2. Verify the status of netgroup definitions:

vserver services netgroup status
The command displays the following information:
Vserver name
Node name
Load time for netgroup definitions
Hash value of the netgroup definitions
You can display additional information in a more detailed view. See the reference page for the
command for details.
Example
The following command displays netgroup status for all Vservers.
vs1::> set -privilege advanced
Warning: These advanced commands are potentially dangerous; use
them only when
directed to do so by technical support.
Do you wish to continue? (y or n): y
vs1::*> vserver services netgroup status
Virtual
Server
Node
Load Time
Hash Value
--------- --------------- --------------------------------------------------

vs1
node1
9/20/2006
e6cb38ec1396a280c0d2b77e3a84eda2
node2
9/20/2006
node3
9/20/2006
node4
9/20/2006
16:04:53
16:06:26
16:08:08
16:11:33
Related tasks
Loading netgroups into a Vserver on page 81
Commands for managing NIS domain configurations

There are specific Data ONTAP commands for managing NIS domain configurations.
If you want to...
Use this command...
Create a NIS domain configuration
vserver services nis-domain create
Display NIS domain configurations
vserver services nis-domain show
Modify a NIS domain configuration
vserver services nis-domain modify
Delete a NIS domain configuration
vserver services nis-domain delete
Related tasks
Commands for managing LDAP client configurations

There are specific Data ONTAP commands for managing LDAP client configurations.
If you want to...
Use this command...
Create an LDAP client configuration
vserver services ldap client create
Display LDAP client configurations
vserver services ldap client show
Modify an LDAP client configuration
vserver services ldap client modify
Delete an LDAP client configuration
vserver services ldap client delete

Note: A Vserver administrator cannot modify or delete an LDAP client configuration that was
created by a cluster administrator.
Related tasks
Creating an LDAP client configuration on page 70
Commands for managing LDAP configurations

There are specific Data ONTAP commands for managing LDAP configurations.
If you want to...
Use this command...
Create an LDAP configuration
vserver services ldap create
Display LDAP configurations
vserver services ldap show
Modify an LDAP configuration
vserver services ldap modify
Delete an LDAP configuration
vserver services ldap delete
Related tasks
Enabling LDAP on a Vserver on page 72
Commands for managing LDAP client schema templates

There are specific Data ONTAP commands for managing LDAP client schema templates.
Note: The vserver services ldap client schema copy, modify, and delete
commands are only available at the advanced privilege level and higher.
If you want to...
Use this command...
Copy an existing LDAP schema template
vserver services ldap client schema

copy
Display LDAP schema templates

show
Modify an LDAP schema template

modify

If you want to...
Use this command...
Delete an LDAP schema template

delete
Note: A Vserver administrator cannot modify or delete an LDAP client schema that was created
by a cluster administrator.
Related tasks
Creating a new LDAP client schema on page 69
How the access cache works

The Data ONTAP access cache reduces the likelihood of having to perform a reverse DNS lookup or
parse netgroups when granting or denying an NFS client access to a volume. This results in
performance improvements due to less time used for DNS lookups.
Whenever an NFS client attempts to access a volume, Data ONTAP must determine whether to grant
or deny access. Except in the most simple cases (for example, when a volume is exported with just
the ro or rw option), Data ONTAP grants or denies access according to a value in the access cache
that corresponds to the following things:
The volume
The NFS client's IP address, access type, and security type
This value might not exist in the access cache entry if Data ONTAP has not made a previous access
determination for this particular NFS client-volume combination. In this case, Data ONTAP grants or
denies access according to the result of a comparison between the following things:
The NFS clients IP address (or host name, if necessary), access type, and security type
The volume export rules
Data ONTAP then stores the result of this comparison in the access cache for five minutes.
Displaying information about NFS Kerberos configurations

You can use the vserver nfs kerberos-config show command to display information about
NFS Kerberos configurations. This enables you to determine how NFS Kerberos is configured.
Step
1. To display information about NFS Kerberos configurations, enter the following command:
vserver nfs kerberos-config show

The command displays the following information:
Virtual server name

Logical interface name
Logical interface IP address
Whether Kerberos is enabled or disabled
Kerberos SPN
Numeric ID of the configuration
You can display additional information in a more detailed view. See the reference page for the
command for details.
Example
The following command displays detailed information about an NFS Kerberos configuration:
vs1::> vserver nfs kerberos-config show -vserver vs1
-lif datalif1
Virtual Server:
Logical Interface:
Ip Address:
Kerberos Enabled:
Service Principal Name:
vs1
datalif1
172.19.4.1
Disabled
nfs/security.example.com@ENG.EXAMPLE.COM
Related tasks
Creating an NFS Kerberos configuration on page 69
Modifying an NFS Kerberos configuration

You can use the vserver nfs kerberos-config modify command to modify a Kerberos
configuration for NFS. This enables you to enable or disable the NFS-enabled Vserver to use
Kerberos authentication.
Step
1. Use the vserver nfs kerberos-config modify command to modify an NFS Kerberos
configuration
Examples
The following command enables an NFS Kerberos configuration on a Vserver named vs1 and
a logical interface named datalif1. The SPN is nfs/security.example.com@eng.example.com
and the keytab file to be loaded is at the URL ftp://ftp.example.com/keytab.

vs1::> vserver nfs kerberos-config modify -vserver vs1 -lif
datalif1 -kerberos enable -spn nfs/
security.example.com@ENG.EXAMPLE.COM -admin-username admin -keytaburi ftp://ftp.example.com/keytab
Data ONTAP then prompts the user for the password for the admin-user. The admin-user
should have permission on the KDC to add the principal to the principal's database.
The following command disables the NFS Kerberos configuration that was created in the
previous example.
vs1::> vserver nfs kerberos-config modify -vserver vs1 -lif
datalif1 -kerberos disable
Commands for managing Kerberos realm configurations

There are specific Data ONTAP commands for managing Kerberos realm configurations.
If you want to...
Use this command...
Create a Kerberos realm configuration
vserver services kerberos-realm

create
Display Kerberos realm configurations
vserver services kerberos-realm show
Modify Kerberos realm configurations

modify
Delete a Kerberos realm configuration

delete
Related tasks
Creating a Kerberos realm configuration on page 67
Commands for managing export policies

There are specific Data ONTAP commands for managing export policies.
If you want to...
Use this command...
Display information about export policies
vserver export-policy show

If you want to...
Use this command...
Rename an export policy
vserver export-policy rename
Copy an export policy
vserver export-policy copy
Delete an export policy
vserver export-policy delete
Related concepts
Commands for managing export rules

There are specific Data ONTAP commands for managing export rules.
If you want to...
Use this command...
Create an export rule
vserver export-policy rule create
Display information about export rules
vserver export-policy rule show
Modify an export rule
vserver export-policy rule modify
Delete an export rule
vserver export-policy rule delete
Related tasks
Adding a rule to an export policy on page 57
Managing file locks

You can display information about a Vserver's current locks as a first step to determining why a
client cannot access a volume or file. You can use this information if you need to break file locks.
About file locking between protocols

File locking is a method used by client applications to prevent a user from accessing a file previously
opened by another user. How Data ONTAP locks files depends on the protocol of the client.
If the client is an NFS client, locks are advisory; if the client is a CIFS client, locks are mandatory.
Because of differences between the NFS and CIFS file locks, an NFS client might fail to access a file
previously opened by a CIFS application.

The following occurs when an NFS client attempts to access a file locked by a CIFS application:
In mixed or NTFS volumes, file manipulation operations, such as rm, rmdir, and mv, can cause
the NFS application to fail.
NFS read and write operations are denied by CIFS deny-read and deny-write open modes,
respectively.
NFS write operations fail when the written range of the file is locked with an exclusive CIFS
bytelock.
How Data ONTAP treats read-only bits

The read-only bit is a binary digit, which holds a value of 0 or 1, that is set on a file-by-file basis to
reflect whether a file is writable (disabled) or read-only (enabled).
CIFS clients that use MS-DOS and Windows can set a per-file read-only bit. NFS clients do not set a
per-file read-only bit because NFS clients do not have any protocol operations that use a per-file
read-only bit.
Data ONTAP can set a read-only bit on a file when a CIFS client that uses MS-DOS or Windows
creates that file. Data ONTAP can also set a read-only bit when a file is shared between NFS clients
and CIFS clients. Some software, when used by NFS clients and CIFS clients, requires the read-only
bit to be enabled.
For Data ONTAP to keep the appropriate read and write permissions on a file shared between NFS
clients and CIFS clients, it treats the read-only bit according to the following rules:
NFS treats any file with the read-only bit enabled as if it has no write permission bits enabled.
If an NFS client disables all write permission bits and at least one of those bits had previously
been enabled, Data ONTAP enables the read-only bit for that file.
If an NFS client enables any write permission bit, Data ONTAP disables the read-only bit for that
file.
If the read-only bit for a file is enabled and an NFS client attempts to discover permissions for the
file, the permission bits for the file are not sent to the NFS client; instead, Data ONTAP sends the
permission bits to the NFS client with the write permission bits masked.
If the read-only bit for a file is enabled and a CIFS client disables the read-only bit, Data ONTAP
enables the owners write permission bit for the file.
Files with the read-only bit enabled are writable only by root.
Note: Changes to file permissions take effect immediately on CIFS clients, but might not take
effect immediately on NFS clients if the NFS client enables attribute caching.
Displaying information about locks

You can use the vserver locks show command to display information about the current file
locks, including what types of locks are held and what the lock state is, details about byte-range

locks, sharelock modes, delegation locks, and opportunistic locks, and whether locks are opened with
durable or persistent handles.
About this task
The client IP address cannot be displayed for locks established through NFSv4 or NFSv4.1.
By default, the command displays information about all locks. You can use command parameters to
display information about locks for a specific Vserver or to filter the command's output by other
criteria. If you do not specify any parameter, the command displays the following information:
Vserver name
Volume name of the FlexVol volume or the name of the namespace constituent for the Infinite
Volume
Path of the locked object
Protocol by which the lock was established
Type of lock
Client
The vserver locks show displays information about four types of locks:
Byte-range locks, which lock only a portion of a file.

Share locks, which lock open files.
Opportunistic locks, which control client-side caching over SMB.
Delegations, which control client-side caching over NFSv4.x.
By specifying optional parameters, you can determine important information about each of these lock
types including the following:
What the lock state is.

What the detailed byte-range lock information is.
What the oplock level is.
Whether lease oplocks are granted.
What the sharelock mode is.
Whether sharelocks are granted with durable handles, persistent handles, or no handles.
Whether delegation locks are granted with read or read-write caching.
Step
1. Display information about locks by using the vserver locks show command.

Examples
The following example displays summary information for an NFSv4 lock on a file with the
path /vol1/file1. The sharelock access mode is write-deny_none, and the lock was granted
with write delegation:
cluster1::> vserver locks show
Vserver: vs0
Volume Object Path
LIF
Protocol Lock Type
------- ------------------------- ----------- --------- ----------vol1
/vol1/file1
lif1
nfsv4
share-level
Sharelock Mode: write-deny_none
delegation
Delegation Type: write
Client
-------
The following example displays detailed oplock and sharelock information about the SMB
lock on a file with the path /data2/data2_2/intro.pptx. A durable handle is granted on
the file with a share lock access mode of write-deny_none to a client with an IP address of
10.3.1.3. A lease oplock is granted with a batch oplock level:
cluster1::> vserver locks show -instance -path /data2/data2_2/intro.pptx
Vserver: vs1
Volume: data2_2
Logical Interface: lif2
Object Path: /data2/data2_2/intro.pptx
Lock UUID: 553cf484-7030-4998-88d3-1125adbba0b7
Lock Protocol: cifs
Lock Type: share-level
Node Holding Lock State: node3
Lock State: granted
Bytelock Starting Offset: Number of Bytes Locked: Bytelock is Mandatory: Bytelock is Exclusive: Bytelock is Superlock: Bytelock is Soft: Oplock Level: Shared Lock Access Mode: write-deny_none
Shared Lock is Soft: false
Delegation Type: Client Address: 10.3.1.3
SMB Open Type: durable
SMB Connect State: connected
SMB Expiration Time (Secs): SMB Open Group ID:
78a90c59d45ae211998100059a3c7a00a007f70da0f8ffffcd445b0300000000
Vserver:
Volume:
Logical Interface:
Object Path:
Lock UUID:
Lock Protocol:
Lock Type:
Node Holding Lock State:
Lock State:
Bytelock Starting Offset:
Number of Bytes Locked:
Bytelock is Mandatory:
Bytelock is Exclusive:
Bytelock is Superlock:
Bytelock is Soft:
Oplock Level:
vs1
data2_2
lif2
/data2/data2_2/test.pptx
302fd7b1-f7bf-47ae-9981-f0dcb6a224f9
cifs
op-lock
node3
granted
batch

Shared Lock Access Mode: Shared Lock is Soft: Delegation Type: Client Address: 10.3.1.3
SMB Open Type: SMB Connect State: connected
Breaking locks
When file locks are preventing client access to files, you can display information about currently held
locks, and then break specific locks. Examples of scenarios in which you might need to break locks
include debugging applications or resolving networking problems.
About this task
The vserver locks break command is available only at the advanced privilege level and higher.
The man page for the command contains detailed information.
Steps
1. To find the information you need to break a lock, use the vserver locks show command.

If you want to break a lock by specifying...
The Vserver name, volume name, LIF name,

and file path
vserver locks break -vserver

vserver_name -volume volume_name -path
path -lif lif
The lock ID
vserver locks break -lockid UUID

-volume volume_name specifies the volume name of the FlexVol volume or the name of the
namespace constituent for the Infinite Volume.

-path path specifies the path.
-lif lif specifies the logical interface.
-lockid specifies the universally unique identifier for the lock.

Modifying the NFSv4.1 server implementation ID

The NFSv4.1 protocol includes a server implementation ID that documents the server domain, name,
and date. You can modify the server implementation ID default values. Changing the default values
can be useful, for example, when gathering usage statistics or troubleshooting interoperability issues.
For more information, see RFC 5661.
About this task
The default values for the three options are as follows:

Option
Option name
Default value
NFSv4.1 Implementation -v4.1-implementationID Domain

domain
netapp.com
NFSv4.1 Implementation -v4.1-implementation-name

ID Name
Cluster version name
NFSv4.1 Implementation -v4.1-implementation-date

ID Date
Cluster version date
Steps


If you want to modify the NFSv4.1
implementation ID...
Domain
vserver nfs modify -v4.1-implementationdomain domain
Name
vserver nfs modify -v4.1-implementation-name

name
Date
vserver nfs modify -v4.1-implementation-date

date

Managing NFSv4 ACLs

You can enable, disable, set, modify, and view NFSv4 access control lists (ACLs).
Benefits of enabling NFSv4 ACLs

There are many benefits to enabling NFSv4 ACLs.
The benefits of enabling NFSv4 ACLs include the following:
Finer-grained control of user access for files and directories

Better NFS security
Improved interoperability with CIFS
Removal of the NFS limitation of 16 groups per user
How NFSv4 ACLs work

A client using NFSv4 ACLs can set and view ACLs on files and directories on the system. When a
new file or subdirectory is created in a directory that has an ACL, the new file or subdirectory
inherits all ACL Entries (ACEs) in the ACL that have been tagged with the appropriate inheritance
flags.
For access checking, CIFS users are mapped to UNIX users. The mapped UNIX user and that users
group membership are checked against the ACL.
If a file or directory has an ACL, that ACL is used to control access no matter what protocol
NFSv3, NFSv4, or CIFSis used to access the file or directory and is used even if NFSv4 is no
longer enabled on the system.
Files and directories inherit ACEs from NFSv4 ACLs on parent directories (possibly with
appropriate modifications) as long as the ACEs have been tagged with the appropriate inheritance
flags.
The maximum number of ACEs for each ACL is 1,024, as defined by the -v4-acl-max-aces
parameter. The default for this parameter is 400. When the -v4-acl-preserve parameter is
enabled and an object has both UNIX mode bits and ACLs, the ACL requires three mandatory ACEs
to grant the proper permissions to OWNER, GROUP, and EVERYONE. These mandatory ACEs are
applied automatically by Data ONTAP when a user performs a chmod operation to set mode bits. If
you set an ACL that is missing any of the mandatory ACEs, Data ONTAP limits the number of
ACEs for that ACL to reserve space for any missing mandatory ACEs to ensure that they can be
added later should you decide to set mode bits as well.
When a file or directory is created as the result of an NFSv4 request, the ACL on the resulting file or
directory depends on whether the file creation request includes an ACL or only standard UNIX file
access permissions, and whether the parent directory has an ACL:
If the request includes an ACL, that ACL is used.
If the request includes only standard UNIX file access permissions but the parent directory has an
ACL, the ACEs in the parent directory's ACL are inherited by the new file or directory as long as
the ACEs have been tagged with the appropriate inheritance flags.
Note: A parent ACL is inherited even if -v4.0-acl is set to off.
If the request includes only standard UNIX file access permissions and the parent directory does
not have an ACL, the client file mode is used to set standard UNIX file access permissions.
If the request includes only standard UNIX file access permissions and the parent directory has a
non-inheritable ACL, the new object is created only with mode bits.
Enabling or disabling modification of NFSv4 ACLs

When Data ONTAP receives a chmod command for a file or directory with an ACL, by default the
ACL is retained and modified to reflect the mode bit change. You can disable the -v4-aclpreserve option to change the behavior if you want the ACL to be dropped instead.
About this task
This option is enabled by default.

Steps


If you want to...
Enter the following command
Enable retention and modification of existing

NFSv4 ACLs (default)
vserver nfs modify -vserver

vserver_name -v4-acl-preserve enabled
Disable retention and drop NFSv4 ACLs when vserver nfs modify -vserver
changing mode bits
vserver_name -v4-acl-preserve disabled

How Data ONTAP uses NFSv4 ACLs to determine whether it can delete a
file
To determine whether it can delete a file, Data ONTAP uses a combination of the file's DELETE bit,
and the containing directory's DELETE_CHILD bit. For more information, see the NFS 4.1 RFC
5661.
Enabling or disabling NFSv4 ACLs

To enable or disable NFSv4 ACLs, you can modify the -v4.0-acl and -v4.1-acl options. These
options are disabled by default.
About this task
The -v4.0-acl or -v4.1-acl option controls the setting and viewing of NFSv4 ACLs; it does not
control enforcement of these ACLs for access checking.
NFSv4.0 ACLs are not supported for Vservers with Infinite Volume.
Step

If you want to...
Then...
Enable NFSv4.0 ACLs Enter the following command:

vserver nfs modify -vserver vserver_name -v4.0-acl
enabled
Disable NFSv4.0 ACLs Enter the following command:
disabled
Enable NFSv4.1 ACLs Enter the following command:
enabled
Disable NFSv4.1 ACLs Enter the following command:
disabled
Modifying the maximum ACE limit for NFSv4 ACLs

You can modify the maximum number of allowed ACEs for each NFSv4 ACL by modifying the
parameter -v4-acl-max-aces. By default, the limit is set to 400 ACEs for each ACL. Increasing

this limit can help ensure successful migration of data with ACLs containing over 400 ACEs to
storage systems running Data ONTAP.
About this task
Increasing this limit might impact performance for clients accessing files with NFSv4 ACLs.
Steps

2. Modify the maximum ACE limit for NFSv4 ACLs by entering the following command:
vserver nfs modify -v4-acl-max-aces max_ace_limit
The valid range of max_ace_limit is 192 to 1024.

Managing NFSv4 file delegations

You can enable and disable NFSv4 file delegations and retrieve NFSv4 file delegation statistics.
How NFSv4 file delegations work

Data ONTAP supports read and write file delegations in accordance with RFC 3530.
As specified in RFC 3530, when an NFSv4 client opens a file, Data ONTAP can delegate further
handling of opening and writing requests to the opening client. There are two types of file
delegations: read and write. A read file delegation allows a client to handle requests to open a file for
reading that do not deny read access to others. A write file delegation allows the client to handle all
open requests.
Delegation works on files within any style of qtree, whether or not opportunistic locks (oplocks) have
been enabled.
Delegation of file operations to a client can be recalled when the lease expires, or when the storage
system receives the following requests from another client:
Write to file, open file for writing, or open file for deny read
Change file attributes
Rename file
Delete file
When a lease expires, the delegation state is revoked and all of the associated states are marked
soft. This means that if the storage system receives a conflicting lock request for this same file
from another client before the lease has been renewed by the client previously holding the delegation,
the conflicting lock is granted. If there is no conflicting lock and the client holding the delegation

renews the lease, the soft locks are changed to hard locks and are not removed in the case of a
conflicting access. However, the delegation is not granted again upon a lease renewal.
When the server reboots, the delegation state is lost. Clients can reclaim the delegation state upon
reconnection instead of going through the entire delegation request process again. When a client
holding a read delegation reboots, all delegation state information is flushed from the storage system
cache upon reconnection. The client must issue a delegation request to establish a new delegation.
Note: NFSv4 File delegations are not supported on Vservers with Infinite Volume.
Enabling or disabling NFSv4 read file delegations

To enable or disable NFSv4 read file delegations, you can modify the -v4.0-read-delegation or
-v4.1-read-delegation option. By enabling read file delegations, you can eliminate much of the
message overhead associated with the opening and closing of files.
About this task
By default, read file delegations are disabled.

The disadvantage of enabling read file delegations is that the server and its clients must recover
delegations after the server reboots or restarts, a client reboots or restarts, or a network partition
occurs.
NFSv4 file delegations are not supported on Vservers with Infinite Volume.
Step

If you want to...
Then...
Enable NFSv4 read file

delegations
Enter the following command:
Enable NFSv4.1 read file

delegations
Disable NFSv4 read file

delegations
Disable NFSv4.1 read file

delegations
vserver nfs modify -vserver vserver_name -v4.0read-delegation enabled
vserver nfs modify -vserver vserver_name -v4.1read-delegation enabled
vserver nfs modify -vserver vserver_name -v4.0read-delegation disabled
vserver nfs modify -vserver vserver_name -v4.1read-delegation disabled

Result
The file delegation options take effect as soon as they are changed. There is no need to reboot or
restart NFS.
Enabling or disabling NFSv4 write file delegations

To enable or disable write file delegations, you can modify the -v4.0-write-delegation or v4.1-write-delegation option. By enabling write file delegations, you can eliminate much of
the message overhead associated with file and record locking in addition to opening and closing of
files.
About this task
By default, write file delegations are disabled.

The disadvantage of enabling write file delegations is that the server and its clients must perform
additional tasks to recover delegations after the server reboots or restarts, a client reboots or restarts,
or a network partition occurs.
NFSv4 file delegations are not supported on Vservers with Infinite Volume.
Step

If you want to...
Then...
Enable NFSv4 write file

delegations
Enable NFSv4.1 write file

delegations
Disable NFSv4 write file

delegations
Disable NFSv4.1 write file

delegations
vserver nfs modify -vserver vserver_name -v4.0write-delegation enabled
vserver nfs modify -vserver vserver_name -v4.1write-delegation enabled
vserver nfs modify -vserver vserver_name -v4.0write-delegation disabled
vserver nfs modify -vserver vserver_name -v4.1write-delegation disabled
Result
The file delegation options take effect as soon as they are changed. There is no need to reboot or
restart NFS.
Configuring NFSv4 file and record locking

You can configure NFSv4 file and record locking by specifying the locking lease period and grace
period.
About NFSv4 file and record locking

For NFSv4 clients, Data ONTAP supports the NFSv4 file-locking mechanism, maintaining the state
of all file locks under a lease-based model.
In accordance with RFC 3530, Data ONTAP defines a single lease period for all state held by an
NFS client. If the client does not renew its lease within the defined period, all states associated with
the client's lease may be released by the server. The client can renew its lease explicitly or implicitly
by performing an operation, such as reading a file.
Furthermore, Data ONTAP defines a grace period, which is a period of special processing in which
clients attempt to reclaim their locking state during a server recovery.
Term
Definition (see RFC 3530)
Lease
The time period in which Data ONTAP irrevocably grants a lock to a

client.
Grace period
The time period in which clients attempt to reclaim their locking state
from Data ONTAP during server recovery.
Lock
Refers to both record (byte-range) locks as well as file (share) locks

unless specifically stated otherwise.
Specifying the NFSv4 locking lease period

To specify the NFSv4 locking lease period (that is, the time period in which Data ONTAP
irrevocably grants a lock to a client), you can modify the -v4-lease-seconds option. Shorter lease
periods speed up server recovery while longer lease periods are beneficial for servers handling a very
large amount of clients.
About this task
By default, this option is set to 30. The minimum value for this option is 10. The maximum value for
this option is the locking grace period, which you can set with the locking.lease_seconds
option.
Steps


vserver nfs modify -vserver vserver_name -v4-lease-seconds
number_of_seconds

Specifying the NFSv4 locking grace period

To specify the NFSv4 locking grace period (that is, the time period in which clients attempt to
reclaim their locking state from Data ONTAP during server recovery), you can modify the -v4grace-seconds option.
About this task
By default, this option is set to 45.

Steps


vserver nfs modify -vserver vserver_name -v4-grace-seconds
number_of_seconds

How NFSv4 referrals work

When you enable NFSv4 referrals, Data ONTAP provides intra-vserver referrals to NFSv4 clients.
Intra-vserver referral is when a cluster node receiving the NFSv4 request refers the NFSv4 client to
another LIF on the Vserver.
The NFSv4 client should access the path that received the referral at the target LIF from that point
onward. The original cluster node gives such a referral when it determines that there exists a LIF in
the Vserver that is resident on the cluster node on which the data volume resides, thereby allowing
the clients faster access to the data and avoiding extra cluster communication.
Support for NFSv4 referrals is not uniformly available in all NFSv4 clients. In an environment where
not all clients support this feature, you should not enable referrals. If the feature is enabled and a
client that does not support it receives a referral from the server, the client cannot access the volume
and experiences failures.
See RFC3530 for details about referrals.
Note: Referrals are not supported on Vservers with Infinite Volume.
Enabling or disabling NFSv4 referrals

You can enable NFSv4 referrals on Vservers with FlexVol volumes by enabling the options -v4fsid-change and -v4.0-referrals or -v4.1-referrals. Enabling NFSV4 referrals can result
in faster data access for NFSv4 clients that support this feature.
Before you begin
If you want to enable NFS referrals, you must first disable parallel NFS. They cannot be both enabled
at the same time.
Steps


If you want to...
Enable NFSv4 referrals
vserver nfs modify -vserver vserver_name -v4-fsidchange enabled

vserver nfs modify -vserver vserver_name -v4.0referrals enabled
Disable NFSv4 referrals
vserver nfs modify -vserver vserver_name -v4.0referrals disabled
Enable NFSv4.1 referrals vserver nfs modify -vserver vserver_name -v4-fsidchange enabled
vserver nfs modify -vserver vserver_name -v4.1referrals enabled
Disable NFSv4.1
referrals
vserver nfs modify -vserver vserver_name -v4.1referrals disabled

Related tasks
Enabling or disabling parallel NFS on page 47
Displaying NFS statistics

You can display NFS statistics for the storage system to monitor performance and diagnose issues.
Steps
1. Use the statistics catalog object show command to identify the NFS objects from
which you can view data.
Example
statistics catalog object show -object nfs*

For more information about the statistics commands, see the Clustered Data ONTAP System
2. Use the statistics start and optional statistics stop commands to collect a data
sample from one or more objects.
3. Use the statistics show command to view the sample data.
Example: Monitoring NFSv3 performance
The following example shows performance data for the NFSv3 protocol.
The following command starts data collection for a new sample:
vs1::> statistics start -object nfsv3 -sample-id nfs_sample
The following command shows data from the sample by specifying counters that show the
number of successful read and write requests versus the total number of read and write
requests:
vs1::> statistics show -sample-id nfs_sample -counter read_total|

write_total|read_success|write_success
Object: nfsv3
Instance: vs1
Start-time: 2/11/2013 15:38:29
End-time: 2/11/2013 15:38:41
Cluster: cluster1
Counter
Value
--------------------------- --------------------------read_success
40042
read_total
40042

write_success
write_total
1492052
1492052
Support for VMware vStorage over NFS

Data ONTAP supports certain VMware vStorage APIs for Array Integration (VAAI) features in an
NFS environment.
Supported features
The following features are supported:
copy offload
Enables an ESXi host to copy virtual machines or virtual machine disks (VMDKs) directly
between the source and destination data store location without involving the host. This conserves
ESXi host CPU cycles and network bandwidth. Copy offload preserves space efficiency if the
source volume is sparse.
space reservation
Guarantees storage space for a VMDK file by reserving space for it.
Limitations
VMware vStorage over NFS has the following limitations:
vStorage is not supported with FlexCache.

vStorage is not supported on Vservers with Infinite Volume.
vStorage is not supported over IPv6.
Copy offload operations can fail in the following scenarios:
While running wafliron on the source or destination volume because it temporarily takes the
volume offline
While moving either the source or destination volume
While moving either the source or destination LIF
While performing takeover or giveback operations
Enabling or disabling VMware vStorage over NFS

You can enable or disable support for VMware vStorage over NFS on Vservers with FlexVol
volumes by using the vserver nfs modify command.
About this task
By default, support for VMware vStorage over NFS is disabled.

Steps
1. Display the current vStorage support status for a Vserver by entering the following command:
vserver nfs show -vserver vserver_name -instance

If you want to...
Enable VMware vStorage support vserver nfs modify -vserver vserver_name vstorage enabled
Disable VMware vStorage support vserver nfs modify -vserver vserver_name vstorage disabled
After you finish
You must install the NFS Plug-in for VMware VAAI before you can use this functionality. For more
information, see Installing the NetApp NFS Plug-in for VMware VAAI.
Enabling or disabling rquota support

Data ONTAP supports the remote quota protocol version 1 (rquota v1). The rquota protocol enables
NFS clients to obtain quota information for users and groups from a remote machine. You can enable
rquota on Vservers with FlexVol volumes by using the vserver nfs modify command.
About this task
By default, rquota is disabled.

Step

If you want to...
Enable rquota support for a Vserver vserver nfs modify -vserver vserver_name rquota enable
Disable rquota support for a Vserver vserver nfs modify -vserver vserver_name rquota disable
For more information about quotas, see the Clustered Data ONTAP Logical Storage Management
Guide.
NFSv3 performance improvement by modifying the TCP

maximum read and write size
You might be able to improve the performance of NFSv3 clients connecting to storage systems over
a high-latency network by modifying the TCP maximum read and write size.
When clients access storage systems over a high-latency network, such as a wide area network
(WAN) or metro area network (MAN) with a latency over 10 milliseconds, you might be able to
improve the connection performance by modifying the TCP maximum read and write size. Clients
accessing storage systems in a low-latency network, such as a local area network (LAN), can expect
little to no benefit from modifying these parameters. If the throughput improvement does not
outweigh the latency impact, you should not use these parameters.
To determine whether your storage environment would benefit from modifying these parameters, you
should first conduct a comprehensive performance evaluation of a poorly performing NFS client.
Review whether the low performance is due to excessive round trip latency and small request on the
client. Under these conditions, the client and server cannot fully use the available bandwidth because
they spend the majority of their duty cycles waiting for small requests and responses to be
transmitted over the connection.
By increasing the NFSv3 request size, the client and server can use the available bandwidth more
effectively to move more data per unit time, therefore increasing the overall efficiency of the
connection.
Keep in mind that the configuration between the storage system and the client might vary. If you
configure the storage system to support 1 MB maximum read size but the client only supports 64 KB,
then the mount read size is limited to 64 KB or less.
Before modifying these parameters, you must be aware that it results in additional memory
consumption on the storage system for the period of time necessary to assemble and transmit a large
response. The more high-latency connections to the storage system, the higher the additional memory
consumption. Storage systems with high memory capacity might experience very little effect from
this change. Storage systems with low memory capacity might experience noticeable performance
degradation.
The successful use of these parameter relies on the ability to retrieve data from multiple nodes of a
cluster. The inherent latency of the cluster network might increase the overall latency of the response.
Overall latency tends to increase when using these parameters. As a result, latency sensitive
workloads might show negative impact.
Modifying the NFSv3 TCP maximum read and write size

You can modify the -v3-tcp-max-read-size and -v3-tcp-max-write-size options to
change the NFSv3 TCP maximum read and write size. Modifying these options can help improve
NFSv3 performance over TCP in some storage environments.
Before you begin
All nodes in the cluster must be running Data ONTAP 8.1 or later.
About this task
You can modify these options individually for each Vserver.

Steps


If you want to...
Modify the NFSv3 TCP

maximum read size
vserver nfs modify -vserver vserver_name -v3tcp-max-read-size integer_max_read_size
Modify the NFSv3 TCP

maximum write size
vserver nfs modify -vserver vserver_name -v3tcp-max-write-size integer_max_write_size
Option
Range
Default
-v3-tcp-max-read-size
8192 to 1048576 bytes
65536 bytes
-v3-tcp-max-write-size
8192 to 65536 bytes
65536 bytes
Note: The maximum read or write size you enter must be a multiple of 4 KB (4096 bytes).
Requests that are not properly aligned negatively affect performance.

4. Use the vserver nfs show command to verify the changes.

5. If any clients use static mounts, unmount and remount for the new parameter size to take effect.

Example
The following command sets the NFSv3 TCP maximum read size to 1048576 bytes on a
Vserver named vs1:
vs1::> vserver nfs modify -vserver vs1 -v3-tcp-max-read-size 1048576
113
SMB file access concepts

There are certain SMB file access concepts you should understand before you configure a CIFS
server and then configure SMB shares to let SMB clients access files on your cluster.
SMB concepts
Clients can access files on a Vserver using the SMB protocol, provided that Data ONTAP can
properly authenticate the user.
When an SMB client connects to a CIFS server, Data ONTAP authenticates the user with a Windows
domain controller. Data ONTAP uses two methods to obtain the domain controllers to use for
authentication:
It queries DNS servers in the domain that the CIFS server is configured to use for domain
controller information.
It queries a list of preferred domain controllers you can optionally specify.
Next, Data ONTAP must obtain UNIX credentials for the user. It does this by using mapping rules
on the Vserver or by using a default UNIX user instead. For a Vserver, you can specify which
mapping services to use, local files or LDAP, and the order in which mapping services are searched.
Additionally, you can specify the default UNIX user.
Data ONTAP then checks different name services for UNIX credentials for the user, depending on
the name services configuration of a Vserver. The options are local UNIX accounts, NIS domains,
and LDAP domains. You must configure at least one of them so that Data ONTAP can successfully
authorize the user. You can specify multiple name services and the order in which they are searched.
How authentication provides SMB access security

Authentication is the process of verifying the identity of an entity. Before users can create SMB
connections to access data contained on the Vserver, they must be authenticated by the domain to
which the CIFS server belongs.
The CIFS server supports two authentication methods, Kerberos and NTLM (NTLMv1 or NTLMv2).
Kerberos is the default method used to authenticate domain users.
Related concepts
Using local users and groups for authentication and authorization on page 228
Role authorization plays in securing file access over SMB connections on page 114
How name mapping is used to secure SMB file access on Vservers with FlexVol volumes on page
115

Related tasks
Modifying the CIFS server Kerberos security settings on page 140
Kerberos authentication
Data ONTAP supports Kerberos authentication when creating authenticated SMB sessions.
Kerberos is a protocol designed to provide strong authentication within a client/server environment.
The basis of the protocol is a shared secret key cryptology system that provides secure authentication
in a networked environment.
Kerberos is the primary authentication service for Active Directory. The Kerberos server, or
Kerberos Key Distribution Center (KDC) service, stores and retrieves information about security
principles in the Active Directory. Unlike the NTLM model, Active Directory clients who want to
establish a session with another computer, such the CIFS server, contact a KDC directly to obtain
their session credentials.
NTLM authentication
NTLM client authentication is done using a challenge response protocol based on shared knowledge
of a user-specific secret based on a password.
If a user is creates an SMB connection using a local Windows user account, authentication is done
locally by the CIFS server using NTLMv2.
Role authorization plays in securing file access over SMB

connections
Authorization is the process of determining what an authenticated entity can do. Authorization
includes share permissions as well as file permissions. Authorization as it relates to file access
determines what an entity can do to files and folders contained on the Vserver.
Share permissions and file permissions are both evaluated to determine effective permissions that
determine what file and folder access requests a user is authorized to perform.
Share permissions control what a user can do over a SMB connection.

File permissions control what a user can do on the files and folders to which the permissions are
applied.
File permissions are effective regardless of whether SMB or NFS is used to access the data.
Related concepts
Creating and configuring SMB shares on page 190

Securing file access by using SMB share ACLs on page 200
Securing file access by using file permissions on page 201
How authentication provides SMB access security on page 113
SMB file access concepts | 115
115
Role export policies play with SMB access

Export policies for SMB access are optional starting with Data ONTAP 8.2, and they are disabled by
default. Export policies for SMB can be enabled if desired to provide a third layer of SMB access
control, along with share and file permissions.
Related concepts
Securing SMB access using export policies on page 208
How name mapping is used to secure SMB file access on

User mapping between a Windows user and a UNIX user is a fundamental part of multiprotocol
access. Multiprotocol access over SMB depends on user mapping between a users Windows identity
and UNIX identity to evaluate the users rights to perform file and folder operations within volumes
and qtrees.
Data ONTAP always maps the users Windows identity to the users UNIX identity during the CIFS
authentication process. The information about the mapped UNIX user and the UNIX user's groups
are saved with the CIFS credential. Hence, a CIFS user credential also contains its mapping UNIX
credential.
Data ONTAP maps user names. It does not map groups. However, because group membership is
critically important when determining file access, as part of the mapping process the mapped UNIX
users group membership is retrieved and cached along with the user mapping information.
Related concepts
Creating name mappings on page 187

Related tasks
Configuring the default UNIX user on page 176
How name mapping works

Data ONTAP goes through a number of steps when attempting to map user names. They include
checking the local name mapping database and LDAP, trying the user name, and using the default
user if configured.
When Data ONTAP has to map credentials for a user, it first checks the local name mapping
database and LDAP server for an existing mapping. Whether it checks one or both and in which
order is determined by the -nm-switch parameter of the Vserver configuration.
For Windows to UNIX mapping

If no mapping is found, Data ONTAP checks whether the lowercase Windows user name is a
valid user name in the UNIX domain. If this does not work, it uses the default UNIX user
provided it is configured. If the default UNIX user is not configured and it cannot obtain a
mapping this way either, mapping fails and an error is returned.
For UNIX to Windows mapping
If no mapping is found, Data ONTAP tries to find a Windows account that matches the UNIX
name in the CIFS domain. If this does not work, it uses the default CIFS user, provided it is
configured. If the default CIFS user is not configured and it cannot obtain a mapping this way
either, mapping fails and an error is returned.
Preservation of UNIX permissions

Data ONTAP preserves UNIX permissions when files are edited and saved by Windows
applications.
When applications on Windows clients edit and save files, they read the security properties of the
file, create a new temporary file, apply those properties to the temporary file, and then give the
temporary file the original file name.
When Windows clients perform a query for the security properties, they receive a constructed ACL
that exactly represents the UNIX permissions. The sole purpose of this constructed ACL is to
preserve the file's UNIX permissions as files are updated by Windows applications to ensure that the
resulting files have the exact same UNIX permissions. Data ONTAP does not set any NTFS ACLs
using the constructed ACL.
Very large CIFS configuration changes might take some

time to finish
When you enter CLI commands on the storage system, they are typically executed instantaneously.
However, when the CLI command results in a large CIFS configuration change, it might take a while
SMB file access concepts | 117

for the configuration change to finish after you entered the CLI command and received confirmation
that it was successful.
The larger the change and the more objects are affected, the longer it can take to complete. Examples
for this delay are creating several thousand new shares or modifying several thousand share ACLs.
The following command areas are affected by this delay:
Servers
Home directories
Shares
Share ACLs
Superusers
Symlink path mapping
Server security
If you make such very large configuration changes, allow time for the changes to finish.
Configuring CIFS servers

You can enable and configure a CIFS server to let CIFS clients access files on your cluster. Each data
Vserver in the cluster can be bound to exactly one Active Directory domain; however, the data
Vservers do not need to be bound to the same domain. Each data Vserver can be bound to a unique
Active Directory domain.
Supported CIFS clients and domain controllers

Before you can use CIFS with your Vserver, you need to know which CIFS clients and domain
controllers Data ONTAP supports.
For the latest information about which CIFS clients and domain controllers Data ONTAP supports,
see the Interoperability Matrix at support.netapp.com/NOW/products/interoperability.
Unsupported Windows features

Before you use CIFS in your network, you need to be aware of certain Windows features that Data
ONTAP does not support.
Data ONTAP does not support the following Windows features:
Encrypted File System (EFS)

Logging of NT File System (NTFS) events in the change journal
Microsoft File Replication Service (FRS)
Microsoft Windows Indexing Service
Remote storage through Hierarchical Storage Management (HSM)
Quota management from Windows clients
Windows quota semantics
The LMHOSTS file
NTFS native compression
Configuring CIFS servers | 119
Setting up CIFS servers

You can enable and configure CIFS servers to let CIFS clients access files on your cluster. There are
a number of tasks to plan and to complete when setting up a CIFS server on a Vserver.
Prerequisites for CIFS server setup

CIFS licensing, time services, and network routing prerequisites must be met before you begin the
CIFS server setup process.
CIFS must be licensed on the cluster

Time services must be set up on the cluster
The cluster must be synchronized to a reliable time source to ensure that CIFS server creation
succeeds. During the CIFS server creation process, Data ONTAP must use Kerberos
authentication to authenticate with the domain that you want the CIFS server to join. Kerberos
authentication requires, by default, that the time configured on a requesting host match, within
five minutes, the time configured on the Kerberos server. If the cluster's time does not match to
within five minutes of the time configured on the domain controller, CIFS setup fails.
Prior to creating the CIFS server, there must be a route to an Active Directory domain controller
for the domain to which you want to join the CIFS server.
If there are no data LIFs present for a Vserver and the node management LIFs are on a segment
that does not route to the Active Directory server, CIFS setup fails. A route to the Active
Directory server can be provided by either of two ways:
By configuring the node management LIFs to be on a network segment that can route to an
Active Directory domain controller
By configuring at least one Vserver data LIF on the Vserver that can route to the Active
Directory domain controller prior to creating the CIFS server
Related concepts
Setting up the CIFS server on page 119

Setting up network access for the CIFS server on page 130
Managing CIFS servers on page 137
Setting up the CIFS server

Setting up the CIFS server involves completing the CIFS server configuration worksheet, creating
the Vserver with the proper setting for CIFS access, configuring DNS on the Vserver, creating the
CIFS server, and, if necessary, setting up UNIX user and group name services.
Before you set up your CIFS server, you must understand the choices you need to make when
performing the setup. You should make decisions regarding the Vserver, DNS, and CIFS server
configurations and record your choices in the planning worksheet prior to creating the configuration.
This can help you in successfully creating a CIFS server.

Creating a Vserver can only be completed by a cluster administrator.
Steps
1. Completing the CIFS server setup configuration worksheet on page 120

Use this worksheet to record the values that you need during the CIFS server setup process. As
part of completing the worksheet, you need to record the information you need to create a
Vserver, configure DNS services, and create the CIFS server.
2. Creating a Vserver with FlexVol volumes for the CIFS server (cluster administrators only) on
page 124
You must first create a Vserver with a configuration that is appropriate for hosting a CIFS server.
Before you create the Vserver, you must choose the aggregate that holds the root volume.
3. Configuring DNS on the Vserver on page 126
You must configure DNS on the Vserver before creating the CIFS server. Generally, the DNS
name servers are the Active Directory-integrated DNS servers for the domain that the CIFS server
will join.
4. Creating a CIFS server on page 127
A CIFS server is necessary to provide CIFS clients with access to a Vserver. After you have set up
DNS services on the Vserver you can create a CIFS server.
5. Configuring name services on the Vserver on page 129
With CIFS access, user mapping to a UNIX user is always performed, even if accessing data in an
NTFS security-style volume. If you map Windows users to corresponding UNIX users whose
information is stored in NIS or LDAP directory stores, you should configure these name services
during CIFS setup.
Related concepts
Prerequisites for CIFS server setup on page 119

Setting up network access for the CIFS server on page 130
Completing the CIFS server setup configuration worksheet
Use this worksheet to record the values that you need during the CIFS server setup process. As part
of completing the worksheet, you need to record the information you need to create a Vserver,
configure DNS services, and create the CIFS server.
Information for creating a Vserver with FlexVol volumes
Note: For information about creating a Vserver with Infinite Volume, see the Clustered Data
ONTAP Logical Storage Management Guide.

Types of information
Vserver name
The name you want to assign to the Vserver.
The Vserver name can contain alphanumeric characters and the following
special characters: ., -, and _. However, the name of a Vserver should not
start with a number or the following special characters: . and -. The
maximum number of characters allowed in a Vserver name is 47.
You must specify a Vserver name.
Name for Vserver root volume
You must specify the name you want to assign to the root volume.
The root volume's name must start with an alphabetic character (a to z or A to
Z) and be 203 or fewer characters in length.
Name of the aggregate that holds the Vserver root volume
You must specify an aggregate name. The aggregate must exist.
Security style for the Vserver root volume
You must specify a security style for the root volume.
Possible values are ntfs, unix, and mixed.
UNIX user and group name services for the Vserver
You must specify the sources that are searched for name service information
and the order in which they are searched. This parameter provides the
functionality of the /etc/nsswitch.conf file on UNIX systems.
Supported name services for storing local UNIX user and group information are
local files, NIS, and LDAP. You can configure one or more of the name
services. UNIX name services are important in an SMB environment, even one
that provides access using SMB connections only, with no NFS access. This is
because during the SMB session setup, Data ONTAP always performs
Windows to UNIX user mapping when constructing the CIFS credential.
You must specify which name services to use.
Your values

User mapping name services for the Vserver

You can optionally specify the sources (local files or LDAP) that are searched
for name mapping information and the order in which they are searched. The
default name service for user mapping is local files.
If you plan to configure the CIFS server to use the default UNIX user, or if you
plan to use local files to store user mapping information, it is not necessary to
specify a value for this parameter.
You should specify this parameter for the two following scenarios:
Use this parameter if you want to use LDAP for storing user mapping
information.
Use this parameter if you want to use both local files and LDAP for storing
user mapping information.
Vserver language setting

You can optionally specify the default language to use for the Vserver and its
volumes. If you do not specify a default language, the default Vserver language
is set to C.UTF-8.
The Vserver language setting determines the character set used to display file
names and data for all NAS volumes in the Vserver.
Note: The language of a Vserver with FlexVol volumes can be modified after
the Vserver is created.
For more information about setting the Vserver language, see the Clustered Data
ONTAP System Administration Guide for Cluster Administrators.
Snapshot policy
You can optionally specify the Snapshot policy to apply to the Vserver. If you
do not specify a Snapshot policy, the default cluster Snapshot policy is applied
to the Vserver. This policy is enabled by default. By default, the Snapshot
policy is inherited by the Vserver's volumes. You can change which Snapshot
policy is applied to the Vserver at any time.
See the Snapshot copy section of the Clustered Data ONTAP Logical Storage
Management Guide for more information about Snapshot policies.
Your values

Your values
Quota policy
You can optionally specify the quota policy to apply to the Vserver. If you do
not specify a quota policy, a blank quota policy named default is created and
applied to the Vserver. By default, the quota policy is inherited by the Vserver's
volumes. You can change which quota policy is applied to the Vserver at any
time.
This setting is supported only on Vservers with FlexVol volumes.
See the quota section of the Clustered Data ONTAP Logical Storage
Management Guide for more information about quotas.
Information for configuring DNS
IP addresses of the DNS servers

List of IP addresses for the DNS servers that will provide name resolution for
the CIFS server. The listed DNS servers must contain the service location DNS
records (SRV) needed to locate the Active Directory LDAP servers and domain
controllers for the domain that the CIFS server will join. The SRV record is
used to map the name of a service to the DNS computer name of a server that
offers that service. CIFS server creation fails if Data ONTAP cannot obtain the
service location records through local DNS queries.
The simplest way to ensure that Data ONTAP can locate the Active Directory
SRV records is to configure Active Directory-integrated DNS servers as the
Vserver DNS servers. However, you can use non-Active Directory-integrated
DNS servers provided that the DNS administrator has manually added the SRV
records to the DNS zone that contains information about the Active Directory
domain controllers.
For information about the Active Directory-integrated SRV records, see the
topic How DNS Support for Active Directory Works: Microsoft TechNet:
technet.microsoft.com/en-us/library/cc759550(WS.10).aspx on Microsoft
TechNet.
DNS domain name
List of domain names to append to a host name when doing host-to-IP name
resolution.List the local domain first, followed by the domain names for which
DNS queries are most often made.
Values

Information for creating a CIFS server on the Vserver
Values
Vserver name
The name of the Vserver you created to host the CIFS server.
You must specify a Vserver name.
CIFS server name
The name of the CIFS server. The CIFS server name can be the same as or
different from the Vserver name. The CIFS server name can be up to 15
characters. Characters that are not allowed include @, # , *, (, ),
=, +, [, ], |, ;, :, ", ,, <, >, \, /, and ?.
You must specify the CIFS server name.
Domain name
The FQDN of the Active Directory domain that you want the CIFS server to
join. A CIFS server appears as a member Windows server object in the Active
Directory store.
You must specify the domain name.
Organizational unit
The organizational unit within the Active Directory domain where you want the
CIFS server computer object placed. This is an optional setting. By default, the
CIFS server computer object storage location is CN=Computers.
Creating a Vserver with FlexVol volumes for the CIFS server (cluster administrators only)
You must first create a Vserver with a configuration that is appropriate for hosting a CIFS server.
Before you create the Vserver, you must choose the aggregate that holds the root volume.
Before you begin
The aggregate on which you want to create the Vserver root volume must exist.
You must know whether you are creating a Vserver with FlexVol volumes or a Vserver with
Infinite Volume.
You must know which security style the root volume will have.
If you plan to implement a Hyper-V over SMB solution on this Vserver, the recommendation is
to use NTFS security style for the root volume. Volumes that contain Hyper-V files must be set to
NTFS security at the time they are created. By setting the root volume security style to NTFS,
you ensure that you do not inadvertently create UNIX or mixed security-style volumes.
You must know which name services to configure.
About this task
This task can only be completed by a cluster administrator.

For information about creating a Vserver with Infinite Volume, see the Clustered Data ONTAP
Logical Storage Management Guide.
Steps
1. Determine which aggregates are candidates for containing the Vserver root volume by displaying
information about all the aggregates in the cluster except for the ones that are node root
aggregates:
storage aggregate show -has-mroot false
You must choose an aggregate that has at least 1 GB of free space to contain the root volume.
2. Record the name of the aggregate on which you want to create the Vserver's root volume.
3. If you plan on specifying a language when you create the Vserver and do not know the value to
use, identify and record the value of the language you want to specify:
vserver create -language ?
4. If you plan on specifying a Snapshot policy when you create the Vserver and do not know the
name of the policy, list the available policies and identify and record the name of the quota policy
you want to use:
volume snapshot policy show -vserver vserver_name
5. If you plan on specifying a quota policy when you create the Vserver and do not know the name
of the policy, list the available policies and identify and record the name of the quota policy you
want to use:
volume quota policy show -vserver vserver_name
6. Create the CIFS server:

vserver create -vserver vserver_name -aggregate aggregate_name rootvolume root_volume_name -rootvolume-security-style {unix|ntfs|mixed}
-ns-switch {nis|file|ldap},... [-nm-switch {file|ldap},...] [-language
language [-snapshot-policy snapshot_policy_name] [-quota-policy
quota_policy_name] -comment comment]
-ns-switch specifies which directory stores to use for UNIX user and group information and
the order in which they are searched.

-nm-switch specifies which directory store to use for name mapping information and the order
in which they are searched.

7. Verify that the Vserver configuration is correct by using the vserver cifs show command.
Example
The following command creates a Vserver named vs1. The root volume is named
vs1_root and is created on aggr3 with NTFS security style. Only local files name services is
configured for storing UNIX user and group information. Local files are used for name
mapping storage.

cluster1::> storage aggregate show -has-mroot false
Aggregate
Size Available Used% State
#Vols Nodes RAID Status
--------- -------- --------- ----- ------- ------ ------ -----------aggr1
239.0GB
229.8GB
4% online
4 node1 raid_dp,
normal
aggr2
239.0GB
235.9GB
1% online
2 node2 raid_dp,
normal
aggr3
478.1GB
465.2GB
3% online
1 node3 raid_dp,
normal
cluster1::> vserver create -vserver vs1 -aggregate aggr3 -rootvolume vs1_root -nsswitch file -rootvolume-security-style ntfs -language en_US
[Job 72] Job succeeded:
Vserver creation completed
cluster1::> vserver show -vserver vs1
Vserver:
Vserver Type:
Vserver UUID:
Root Volume:
Aggregate:
Name Service Switch:
Name Mapping Switch:
NIS Domain:
Root Volume Security Style:
LDAP Client:
Language:
Snapshot Policy:
Comment:
Antivirus On-Access Policy:
Quota Policy:
List of Aggregates Assigned:
Limit on Maximum Number of Volumes allowed:
Vserver Admin State:
Allowed Protocols:
Disallowed Protocols:
Is Vserver with Infinite Volume:
QoS Policy Group:
vs1
data
11111111-1111-1111-1111-111111111111
vs1_root
aggr3
file
file
ntfs
en_US
default
default
default
unlimited
running
nfs, cifs, ndmp
fcp, iscsi
false
-
Related tasks
Modifying protocols for Vservers on page 45

Configuring DNS on the Vserver
You must configure DNS on the Vserver before creating the CIFS server. Generally, the DNS name
servers are the Active Directory-integrated DNS servers for the domain that the CIFS server will
join.
About this task
Active Directory-integrated DNS servers contain the service location records (SRV) for the domain
LDAP and domain controller servers. If the Vserver cannot find the Active Directory LDAP servers
and domain controllers, CIFS server setup fails.
Steps
1. Configure DNS services:

vserver services dns create -vserver vserver_name -domains FQDN[,...] name-servers IP-address[,...]
The domain path is constructed from the values in the -domains parameter.
2. Verify that the DNS configuration is correct and that the service is enabled by using the vserver
services dns show command.
Example
The following example configures the DNS service on Vserver vs1:
cluster1::> vserver services dns create -vserver vs1 -domains
iepubs.local,example.com -name-servers 10.1.1.50,10.1.1.51
cluster1::> vserver services dns show -vserver vs1
Name
Vserver State
Domains
Servers
-------- --------- --------------------------- ------------vs1
enabled
iepubs.local, example.com
10.1.1.50,
10.1.1.51
Creating a CIFS server

A CIFS server is necessary to provide CIFS clients with access to a Vserver. After you have set up
DNS services on the Vserver you can create a CIFS server.
Before you begin
The node management LIFs must be on a network segment that can route to the Active Directory
domain controller of the domain to which you want to join the CIFS server. Alternatively, at least
one Vserver data LIF must exist on the Vserver that can route to the Active Directory domain
controller.
If there are no data LIFs present for a Vserver and the node management LIFs are on a segment
that does not route to the Active Directory server, CIFS setup fails.
The cluster time must be synchronized to within five minutes of the Active Directory domain
controller's time.
The recommendation is to configure cluster NTP services to use the same NTP servers for time
synchronization as the Active Directory domain uses.
About this task
You must keep the following in mind when creating the CIFS server:
The CIFS server name can be up to 15 characters in length.

Characters that are not allowed include @, # , *, (, ), =, +, [, ], |, ;, :,
", ,, <, >, \, /, and ?.
You must use the FQDN when specifying the domain.
The default is to add the CIFS server machine account to the Active Directory CN=Computer
object.
You can choose to add the CIFS server to a different organizational unit (OU) by using the -ou
option. When specifying the OU, you do not specify the domain portion of the distinguished
name, you only specify the OU or CN portion of the distinguished name. Data ONTAP appends
the value provided for the required -domain parameter onto the value provided for -ou
parameter to produce the Active Directory distinguished name, which is used when joining the
Active Directory domain.
The initial administrative status of the CIFS server is up.
Steps
1. Create the CIFS Vserver:

vserver cifs create -vserver vserver_name -domain FQDN [-ou
organizational_unit]
For more information about using the vserver cifs create command, see the man pages.
2. Verify the CIFS server configuration by using the vserver cifs show command.
Examples
The following command creates a CIFS server named CIFS1 on Vserver vs1 and joins the
CIFS Vserver to the example.com domain. The CIFS server computer object is placed in the
default CN=Computer container:
cluster1::> vserver cifs create -vserver vs1 -name CIFS1 -domain example.com
cluster1::> vserver cifs show -vserver vs1
Server
Status
Domain/Workgroup
Vserver
Name
Admin
Name
----------- --------- --------- ---------------vs1
CIFS1
up
EXAMPLE
Authentication
Style
-------------domain
The following command creates a CIFS server named CIFS1 on Vserver vs1 in the
example.com domain. The machine account is created in the
OU=eng,OU=corp,DC=example,DC=com container.
cluster1::> vserver cifs create -vserver vs1 cifs-server CIFS1 -domain
example.com ou OU=eng,OU=corp
The following command creates a CIFS server named CIFS2 on Vserver vs1 in the
example.com domain. The storage administrator wants to create the machine account in the
OU=eng,OU=corp,DC=example,DC=com container; however the distinguished name is
mistakenly used for the value of the -ou parameter. Doing so results in an error, because the
Vserver interprets the container location as
OU=eng,OU=corp,DC=example,DC=com,DC=example,DC=com instead of
OU=eng,OU=corp,DC=example,DC=com.

If the distinguished name is mistakenly used for the value of the -ou parameter, the command
fails with the error message shown in the example:
cluster1::> vserver cifs create -vserver vs1 cifs-server CIFS2 -domain
example.com ou OU=eng,OU=corp,DC=example,DC=com
Error: command failed: Failed to create CIFS server CIFS2. Reason: SecD
Error: ou not found
Related concepts
Using options to customize CIFS servers on page 137

Managing CIFS server security settings on page 140
Configuring SMB on your Vserver's CIFS server on page 145
Using SMB signing to enhance network security on page 150
Improving client performance with traditional and lease oplocks on page 157
Using IPv6 with CIFS on page 163
Applying Group Policy Objects to a CIFS server on page 167
Managing domain controller connections on page 173
Managing miscellaneous CIFS server tasks on page 176
Monitoring CIFS activity on page 326
Related tasks
Stopping or starting the CIFS server on a Vserver on page 177

Moving CIFS servers to different OUs on page 178
Changing or resetting the domain account password on page 178
Configuring name services on the Vserver
With CIFS access, user mapping to a UNIX user is always performed, even if accessing data in an
NTFS security-style volume. If you map Windows users to corresponding UNIX users whose
information is stored in NIS or LDAP directory stores, you should configure these name services
during CIFS setup.
About this task
You can configure the CIFS server to map all Windows users to the default UNIX user. In this case,
configuring NIS or LDAP UNIX user and group name services is optional for CIFS access.
For information about configuring NIS and LDAP name services, see the NFS documentation.

Steps
1. If UNIX users and group information is managed by NIS name services, configure NIS name
services by using the information located in the NFS section of the guide.
2. If UNIX users and group information is managed by LDAP name services, configure LDAP
name services by using the information located in the NFS section of the guide.
Setting up network access for the CIFS server

Before clients can access data stored on the CIFS server over SMB shares, you must complete the
network setup configuration worksheet, create data LIFs, configure default gateways, and add any
needed routing groups and static routes.
Before you set up network access for the CIFS server, you must understand the choices you need to
make when performing the setup. You should make decisions regarding data LIF configurations,
routing groups, default gateways, and static routes, and record your choices in the planning
worksheet prior to creating the configuration. This can help you in successfully enabling network
access to resources on the CIFS server.
Creating data LIFs, routing groups, and static routes can only be completed by a cluster
administrator.
Steps
1. Completing the network setup worksheet for the CIFS server on page 130
You should record the values that you need to set up the network for a CIFS server. As part of
completing the network setup worksheet, you need to enter information about the CIFS server
data LIFs. You also need to record information about the default gateways, and optionally, for
custom routing groups and static routes.
2. Creating data LIFs for the CIFS server (cluster administrators only) on page 133
Before you can provide SMB access to the CIFS server, you must create data LIFs.
3. Creating default gateways, static routes, and routing groups (cluster administrators only) on page
135
After you create the Vserver data LIFs, you add default routes to routing groups. You can add
additional static routes to the routing groups and can create additional routing groups and add
routes to your custom routing groups.
Related concepts
Prerequisites for CIFS server setup on page 119

Setting up the CIFS server on page 119
Managing CIFS servers on page 137
Completing the network setup worksheet for the CIFS server
You should record the values that you need to set up the network for a CIFS server. As part of
completing the network setup worksheet, you need to enter information about the CIFS server data

LIFs. You also need to record information about the default gateways, and optionally, for custom
routing groups and static routes.
Information for creating LIFs on the Vserver
Data LIF names

The name to give to the logical network interfaces that clients use
when accessing data from the CIFS server. You can assign multiple
data LIFs per node, and you can assign LIFs to any node in the
cluster, provided that the node has available data ports. To provide
redundancy, you should create at least two data LIFs for each data
subnet, and the LIFs assigned to a particular subnet should be
assigned home ports on different nodes.
You can provide descriptive names for the interfaces. For example,
you can name the data LIFs according to the node assigned as their
home node. For example, you can name a LIF whose home node is
node1 lif1, a LIF whose home node is node2 lif2, and so on.
Protocols allowed on the data LIFs
Protocols that can use the data LIFs (CIFS, NFS, FlexCache, iSCSI,
and FC). This is an optional setting. By default, CIFS, NFS, and
FlexCache are allowed.
Note: Protocols that can use the LIF cannot be modified after the
LIF is created.
Data LIF home node

The home node is the node to which the logical interface returns
when the LIF is reverted to its home port. Record a home node for
each data LIF.
Data LIF home port
The home port is the port to which the logical interface returns when
the LIF is reverted to its home port. Record a home port for each data
LIF.
Data LIF IP addresses
You can configure Vserver data LIFs that are on different subnets.
The recommendation is to have at least two data LIFs per subnet so
that there is no single point of failure for data access through a
subnet. Record an IP address for each data LIF.
Values

Values
Data LIF network mask

There might be more than one netmask, depending on whether data
LIF IP addresses are configured for more than one subnet.
Optional custom routing groups
Data ONTAP automatically creates a routing group that is
appropriate for the netmask that the cluster administrator provided
when creating the data LIF. If an appropriate routing group exists,
Data ONTAP assigns the existing routing group to the LIF. You can
optionally create your own custom routing group.
Data LIF default gateway IP address
There might be more than one default gateway, depending on
whether data LIF IP addresses are configured for more than one
subnet.
Optional static routes for the data LIF
You can configure optional static routes for the routing groups
assigned to the data LIFs.
Information for DNS entries on the DNS server for the data LIFs
After you configure your data LIFs, the DNS administrator must create DNS A and PTR records
for the IP addresses assigned to the data LIFs. To load balance client connections to the assigned data
IP addresses, you must create multiple A records that all point to the same host name. DNS load
balances connections that are made using the host name to the assigned IP addresses in a round-robin
fashion.
Note: If you assigned the CIFS server a name that is different from the Vserver name, you must
create DNS entries that point to the CIFS server name instead of the Vserver name. Clients must
use the CIFS server name when connecting to SMB shares, not the Vserver name.
For example, if you create a CIFS server named CIFS1 in the EXAMPLE.LOCAL domain that
is hosted on a Vserver named vs1 and assign the IP addresses 10.1.1.1, 10.1.1.2, 10.1.1.3, and
10.1.1.4 to the four data LIFs, your DNS A record entries are as follows:
10.1.1.1
10.1.1.2
10.1.1.3
10.1.1.4
A
A
A
A
CIFS1.EXAMPLE.COM CIFS1
CIFS.EXAMPLE.COM CIFS1
If an NFS server is also configured on the Vserver and clients access data over NFS using the
same data LIFs that are used to connect to SMB shares, you must also create a set of A and
PTR records that point to the Vserver name. NFS clients use the Vserver name when mounting
an export.

There is an alternative method for creating the data LIF DNS records and managing DNS load
balancing for the CIFS server. Data ONTAP supports onboard Vserver DNS load balancing using
DNS delegation. To learn more about Vserver DNS load balancing, see the section about balancing
network loads in the Clustered Data ONTAP Network Management Guide and the knowledge base
article How to set up DNS load balancing in Cluster-Mode at support.netapp.com.
Values
DNS A and PTR records for the CIFS server

You need to create A and PTR records for IP
addresses assigned to the Data LIFs. The host
name for these records is the CIFS server name.
Optional: DNS A and PTR record for a Vserver
providing access using the NFS, FlexCache, or
NDMP protocols
You need an additional set of A and PTR
records for the Vserver if the Vserver provides
access to NFS clients and the Vserver name and
the CIFS server name are different. The host
name for these records is the Vserver name.
Creating data LIFs for the CIFS server (cluster administrators only)
Before you can provide SMB access to the CIFS server, you must create data LIFs.
Before you begin
You must have the list of IP addresses to assign to the data LIFs.
About this task
You can associate data LIFs with ports that are assigned the data role.
You can configure Vserver data LIFs that are on different subnets.
To use host names to connect to the CIFS server data ports, you must create DNS A and PTR
record entries that assign the IP addresses to the FQDN of the CIFS server.
You should not configure data LIFs that carry CIFS traffic to automatically revert to their home
nodes.

Steps
1. Determine what data ports are available:

network port show -role data
2. For each node that contains aggregates on which you plan to create data volumes, create a data
LIF:

network interface create -vserver vserver_name -lif lif_name -role data
-home-node node_name -home-port port -address -netmask-length integer
There are a number of optional parameters that you might want to use to customize the
configuration. For example, you can designate which failover policy to use or create a custom
failover group. For more information about using optional parameters, see the Clustered Data
ONTAP Network Management Guide.
After the command executes, the following message is displayed: Info: Your interface
was created successfully; the routing group <routing_group_name> was
created. An associated routing group is automatically created when you create the first data LIF
in an IP subnet. A routing group is a container for Vserver routes, including the default route.
3. Record the name of the routing group.
You need the name of the routing group when you create the default route and other static routes
for the Vserver.
4. Verify that the LIF network configuration is correct by using the network interface show
command.
You can create customized data LIF solutions using VLANs or interface groups (a logical
grouping of interface ports). For more information, see the man pages for the network port
ifgrp and network port vlan command families. For more information about configuring
network solutions, see the Clustered Data ONTAP Network Management Guide.
5. Create the DNS A and PTR records for the data LIF IP addresses assigned to the CIFS server.
6. If the Vserver name and the CIFS server name are different and you plan on configuring NFS,
FlexCache, or NDMP access to data on the Vserver using the same data LIFs that provide CIFS
access, create DNS A and PTR records for the data LIF IP addresses that resolve to the Vserver
name.
Example
The following example creates data LIFs on node1 and node2, the two nodes that contain the
aggregates that will host data volumes for Vserver vs1. The CIFS server name is also named
vs1 and is a member of the IEPUB.LOCAL domain. A default route is added to the routing
group that was automatically created during LIF creation. The following DNS A records and
the corresponding PTR records are added to the DNS server:
10.1.1.128 A VS1.IEPUB.LOCAL VS1
cluster1::> network port show -role data -node node1
Auto-Negot Duplex
Speed (Mbps)
Node
Port
Role
Link
MTU Admin/Oper Admin/Oper Admin/Oper
------ ------ ------------ ---- ----- ----------- ---------- -----------node1
a0a
data
down 1500 true/auto/auto/e0c
data
up
1500 true/true full/full
auto/1000
e0d
data
up
auto/1000
e1b
data
up
auto/1000
e1c
data
down 1500 true/true full/half
auto/10
e1d
data
auto/10

cluster1::> network port show -role data -node node2
Auto-Negot Duplex
Speed (Mbps)
Node
Port
Role
Link
MTU Admin/Oper Admin/Oper Admin/Oper
------ ------ ------------ ---- ----- ----------- ---------- -----------node2
e0c
data
up
auto/1000
e0d
data
up
auto/1000
e1b
data
up
auto/1000
e1c
data
auto/10
e1d
data
auto/10
cluster1::> network interface create -vserver vs1 -lif lif1 -role data -home-node
node1 -home-port e1b -address 10.1.1.128 -netmask-length 24
Info: Your interface was created successfully; the routing group d10.1.1.0/24 was
created
cluster1::> network interface create -vserver vs1 -lif lif2 -role data -home-node
node2 -home-port e1b -address 10.1.1.129 -netmask-length 24
cluster1::> network interface show -vserver vs1
Logical
Status
Network
Vserver
Interface Admin/Oper Address/Mask
--------- ---------- ---------- --------------vs1
lif1
up/up
10.1.1.128/24
lif2
up/up
10.1.1.129/24
Current
Current Is
Node
Port
Home
--------- ------- ---node1
node2
e1b
e1b
true
true
Creating default gateways, static routes, and routing groups (cluster administrators only)
After you create the Vserver data LIFs, you add default routes to routing groups. You can add
additional static routes to the routing groups and can create additional routing groups and add routes
to your custom routing groups.
Before you begin
You must know the IP address of the default gateway for any default routes that you create.
About this task
Data ONTAP automatically creates an associated routing group on a Vserver when you create the
first data LIF in an IP subnet. A routing group is a container for static routes, including the default
route. A routing group scope is bound by the Vserver. Routing groups are not shared across Vservers.
You can configure Vserver data LIFs that are on different subnets and that have different gateways.
If you have Vserver data LIFs that are on different subnets, Data ONTAP creates routing groups for
each subnet. If you want the Vserver to have a default route, you must add a default route to the
routing groups. You can also add other static routes to a routing group.
Note: Under some circumstances, you might not want a default route configured for one or more
of the data LIF subnets on a Vserver. For example, you might want to permit file access to clients
only on particular subnets or permit access only to particular servers. In this case, you must add the
necessary static routes to the appropriate routing group before the Vserver can provide NAS access
to external NAS hosts.

Steps
1. Identify the name of the routing groups on the Vserver to which the data LIFs are associated:
network routing-groups show -vserver vserver_name
2. Create any custom routing groups that you want configured by using the network routinggroups create command.
See the man page on the network routing-groups create command for more information
about creating routing groups.
3. For each routing group on the Vserver for which you want a default route configured, create a
default route:
network routing-groups route create -vserver vserver_name -routing-group
routing_group_name -destination 0.0.0.0/0 -gateway gateway_IP_address
4. Add any custom static routes to the routing groups by using the network routing-groups
route create command.
See the man page on the network routing-groups route create command for more
information about creating static routes.
5. Verify that the route configuration is correct by using the network routing-groups route
show command.
You can choose to customize the Vserver network configuration by creating your own routing
groups, adding static routes to your custom routing groups, and associating data LIFs to the
routing groups that you created. For information about configuring customized network solutions,
see the Clustered Data ONTAP Network Management Guide.
Example
The following commands add a default route to the routing group that was automatically
created during data LIF creation for Vserver vs1:
cluster1::> network routing-groups show -vserver vs1
Routing
Vserver
Group
Subnet
Role
Metric
--------- --------- ------------- ------------ ------vs1
d10.1.1.0/24
10.1.1.0/24 data
20
cluster1::> network routing-groups route create -vserver vs1 -routing-group
d10.1.1.0/24 -destination 0.0.0.0/0 -gateway 10.1.1.1
cluster1::> network routing-groups route
Routing
Vserver
Group
Destination
--------- -----------------------vs1
d10.1.1.0/24
0.0.0.0/0
show -vserver vs1

Gateway
----------10.1.1.1
Metric
-----20
Managing CIFS servers

After you set up a CIFS server, you can perform management tasks. For example, you can configure
CIFS options, manage CIFS server security settings, configure SMB and SMB signing, manage CIFS
oplocks, configure IPv6 CIFS access, apply GPOs to CIFS servers, manage domain controller
connections, and manage the CIFS server service.
Related concepts
Using options to customize CIFS servers on page 137

Managing file locks on page 92
Using options to customize CIFS servers

You can use options to customize CIFS servers. For example, you can configure the default UNIX
user. At the advanced privilege level, you can also enable or disable local Windows users and groups
and local Windows user authentication, automatic node referrals and remote copy offload, export
policies for CIFS, and other options.
Available CIFS options
It is useful to know what CIFS options are available when considering how to customize the CIFS
server. Some CIFS options are for general use on the CIFS server. A number of the options are used
to enable and configure specific CIFS functionality.
The following list specifies the CIFS options available at admin-privilege level:
Default UNIX user

Starting with Data ONTAP 8.2 and later releases, this option has a default value. The value is set
to pcuser.
Note: Starting with Data ONTAP 8.2 and later releases, Data ONTAP automatically creates the
default user named pcuser (with a UID of 65534), the group named pcuser (with a GID of
65534), and adds the default user to the pcuser group. When you create a CIFS server, Data
ONTAP automatically configures pcuser as the default UNIX user.
Read grants execute for mode bits

You can use this option to allow CIFS clients to run executable files with UNIX mode bits to
which they have read access even when the UNIX executable bit is not set. This option is
disabled by default.
WINS server addresses
There is no default value.
Default UNIX group
There is no default value. This option is supported only on Vservers with Infinite Volume.

The following list specifies the CIFS options available at advanced-privilege level:
Enabling or disabling SMB 2.x

SMB 2.0 is the minimum SMB version that supports LIF failover. If you disable SMB 2.x, Data
ONTAP also automatically disables SMB 3.0.
This option is supported only on Vservers with FlexVol volumes. The option is enabled by
default on Vservers with FlexVol volumes, and disabled by default on Vservers with Infinite
Volume.
Enabling or disabling SMB 3.0
SMB 3.0 is the minimum SMB version that supports continuously available shares. Windows
Server 2012 and Windows 8 are the minimum Windows versions to support SMB 3.0.
Volume.
ODX copy offload
This option is enabled by default. ODX copy offload is used automatically by Windows clients
that support it.
Automatic node referrals
This option is disabled by default. With automatic node referrals, the CIFS server automatically
refers clients to a data LIF local to the node that hosts the data accessed through the requested
share. This option must be disabled on Hyper-V over SMB configurations.
Enabling or disabling export policies for SMB
The default is to disable export policies for SMB.
Enabling or disabling using junction points as reparse points
This option is only valid for SMB 2.x or SMB 3.0 connections.
Volume.
Maximum simultaneous operations per TCP connection
The default value is 255.
Enabling or disabling local Windows users and groups functionality
Enabling or disabling local Windows users authentication
Enabling or disabling VSS shadow copy functionality
Data ONTAP uses shadow copy functionality to perform remote backups of data stored using the
Hyper-V over SMB solution.
This option is supported only on Vservers with FlexVol volumes, and only for Hyper-V over
SMB configurations. The option is enabled by default on Vservers with FlexVol volumes, and
disabled by default on Vservers with Infinite Volume.
Shadow copy directory depth
This option is used with the shadow copy functionality and defines the maximum depth of
directories on which to create shadow copies.

This option is supported only on Vservers with FlexVol volumes, and only for Hyper-V over
SMB configurations. The option is enabled by default on Vservers with FlexVol volumes, and
disabled by default on Vservers with Infinite Volume.
For more information about configuring CIFS server options, see the man pages.
Related concepts
Configuring SMB on your Vserver's CIFS server on page 145

Improving Microsoft remote copy performance on page 393
Improving client response time by providing SMB automatic node referrals with Auto Location on
page 399
Configuring Data ONTAP for the Hyper-V over SMB solution on page 408
Share-based backups of Hyper-V virtual machines with Remote VSS on page 413
Related tasks

Configuring CIFS options on page 139
Configuring CIFS options
You can configure CIFS options at any time after you have created a CIFS server on a Vserver.
Step

If you want to configure CIFS
options...
At admin-privilege level
vserver cifs options modify -vserver

vserver_name options
At advanced-privilege level
a. set -privilege advanced

b. vserver cifs options modify -vserver
vserver_name options
c. set -privilege admin
options is a list of one or more CIFS server options.
For more information about configuring CIFS options, see the man page for the vserver cifs
options modify command.
Managing CIFS server security settings

You can manage your Vserver's CIFS server security settings by modifying the CIFS Kerberos
security settings, enabling or disabling required SMB signing for incoming SMB traffic, requiring or
not requiring password complexity for local users, and displaying information about current CIFS
server security settings.
Modifying the CIFS server Kerberos security settings
You can modify certain CIFS Kerberos security settings on Vservers with FlexVol volumes and
Vservers with Infinite Volumes, including the maximum allowed Kerberos clock slew time, the
Kerberos ticket lifetime, and the maximum number of ticket renewal days.
About this task
Modifying CIFS server Kerberos settings by using the vserver cifs security modify
command modifies the settings only on the single Vserver that you specify with the -vserver
parameter. You can centrally manage Kerberos security settings for all Vservers on the cluster
belonging to the same Active Directory domain by using Active Directory group policy objects
(GPOs).
Steps
1. Perform one or more of the following actions:

If you want to...
Enter...
Specify the maximum allowed

Kerberos clock skew time in
minutes
vserver cifs security modify -vserver

vserver_name -kerberos-clock-skew
integer_in_minutes
Note: The default setting is five minutes.
Specify the Kerberos ticket

lifetime in hours

vserver_name -kerberos-ticket-age
integer_in_hours
Note: The default setting is ten hours.
Specify the maximum number

of ticket renewal days

vserver_name -kerberos-renew-age integer_in_days
Note: The default setting is seven days.
2. Verify the Kerberos security settings:

vserver cifs security show -vserver vserver_name

Example
The following example makes the following changes to Kerberos security. The Kerberos clock
skew is set to three minutes and the Kerberos ticket lifetime is set to eight hours for Vserver
vs1:
cluster1::> vserver cifs security modify -vserver vs1 -kerberos-clock-skew
3 -kerberos-ticket-age 8
cluster1::> vserver cifs security show -vserver vs1
Vserver: vs1
Kerberos Clock Skew:
3 minutes
Kerberos Ticket Age:
8 hours
Kerberos Renewal Age:
7 days
Is Signing Required:
false
Is Password Complexity Required: true
Related concepts
Kerberos authentication on page 114

Supported GPOs on page 168
Related tasks
Displaying information about CIFS server security settings on page 144

Enabling or disabling required SMB signing for incoming SMB traffic
You can enforce the requirement for clients to sign SMB messages by enabling required SMB
signing. If enabled, Data ONTAP accepts SMB messages only if they have valid signatures. If you
want to permit SMB signing, but not require it, you can disable required SMB signing.
About this task
By default, required SMB signing is disabled. You can enable or disable required SMB signing at
any time.
Note: SMB signing is not disabled by default under the following circumstance:
1. Required SMB signing is enabled and the cluster is reverted to a version of Data ONTAP that
does not support SMB signing.
2. The cluster is subsequently upgraded to a version of Data ONTAP that supports SMB signing.
Under these circumstances, the SMB signing configuration originally configured on a
supported version of Data ONTAP is retained through reversion and subsequent upgrade.

Steps

If you want required SMB
signing to be...
Enabled

vserver_name -is-signing-required true
Disabled

vserver_name -is-signing-required false
2. Verify that required SMB signing is enabled or disabled by determining if the value in the Is
Signing Required field in the output from the following command is set to the desired value:
vserver cifs security show -vserver vserver_name -fields is-signingrequired
Example
The following example enables required SMB signing for Vserver vs1:
cluster1::> vserver cifs security modify -vserver vs1 -is-signing-required
true
cluster1::> vserver cifs security show -vserver vs1 -fields is-signingrequired
vserver is-signing-required
-------- ------------------vs1
true
Related concepts

Performance impact of SMB signing on page 152
Recommendations for configuring SMB signing on page 152
Related tasks

Monitoring SMB signed session statistics on page 155
Requiring password complexity for local CIFS users
To provide enhanced security for local users on your Vservers with FlexVol volumes and Vservers
with Infinite Volumes, you can enforce password complexity requirement for local CIFS users.

Required password complexity is enabled by default; you can enable or disable required password
complexity at any time.
Before you begin
Local users and groups and local user authentication must be enabled on the CIFS server.
Steps

If you want required password
complexity for local CIFS users to
be...
Enabled

vserver_name -is-password-complexity-required
true
Disabled

vserver_name -is-password-complexity-required
false
2. Verify the security setting for required password complexity:

vserver cifs security show -vserver vserver_name
Example
The following example enables required password complexity for local CIFS users for Vserver
vs1:
cluster1::> vserver cifs security modify -vserver vs1 -is-passwordcomplexity-required true
Vserver: vs1
5 minutes
10 hours
7 days
false
Related concepts
Requirements for local user passwords on page 234

Related tasks

Changing local user account passwords on page 241
Displaying information about CIFS server security settings
You can display information about CIFS server security settings on Vservers with FlexVol volumes
or on Vservers with Infinite Volumes. You can use this information to verify whether security
settings have been configured by using the CLI or have been centrally configured by using Active
Directory group policy objects (GPOs).
Step

If you want display information about...
All security settings on a specified Vserver
vserver cifs security show -vserver

vserver_name
A specific security setting or settings on a

Vserver
vserver cifs security show -vserver

vserver_name -fields [fieldname,...]
To further customize the output, you can specify one or more optional parameters. For more
information, see the man pages.
Examples
The following example display security settings for Vserver vs1:
Vserver: vs1
5 minutes
10 hours
7 days
false
The following example displays the Kerberos clock skew for Vserver vs1:
cluster1::> vserver cifs security show -vserver vs1 -fields kerberos-clockskew
vserver kerberos-clock-skew
------- ------------------vs1
5
Configuring SMB on your Vserver's CIFS server

Server Message Block (SMB) is a remote file-sharing protocol used by Microsoft Windows clients
and servers. You can configure and manage SMB on your Vserver's CIFS server as well as monitor
SMB statistics.
Supported SMB versions on your Vserver's CIFS server
Data ONTAP supports several versions of the Server Message Block (SMB) protocol on your
Vserver's CIFS server. Data ONTAP support for SMB for Vservers with FlexVol volumes and
Vservers with Infinite Volumes differ. You need to be aware of which versions are supported for
each type of Vserver.
Data ONTAP supports the following SMB versions for Vservers with FlexVol volumes and Vservers
with Infinite Volumes:
SMB version
Supported on Vservers with

FlexVol volumes?
Supported on Vservers with

Infinite Volumes?
SMB 1.0
Yes
Yes
SMB 2.0
Yes
No
SMB 2.1
Yes
No
SMB 3.0
Yes
No
Supported SMB 1.0 functionality

The CIFS (SMB 1.0) protocol was introduced by Microsoft for Windows clients. Data ONTAP
supports the SMB 1.0 protocol on all versions of clustered Data ONTAP and on Vservers with
FlexVol volumes and Vservers with Infinite Volumes.
Over the years, Microsoft has extended the original SMB 1.0 protocol with enhancements to security,
file, and disk-management features. Legacy Windows clients (pre-Windows XP) or non-Windows
clients that support only SMB 1.0 can access data on the Vserver using CIFS over SMB 1.0.
Clustered Data ONTAP 8.1 and later supports the SMB 2.0 protocol on Vservers with FlexVol
volumes. SMB 2.0 is a major redesign of the SMB protocol that provides performance enhancements
and added resiliency against network interruptions through the use of durable handles.
SMB 2.0 is enabled automatically when you create a CIFS server.
Data ONTAP supports the following SMB 2.0 functionality:
Durable handles
Enables clients to transparently reconnect to disconnected SMB sessions after short network
outages. For example, LIF failovers, LIF moves, and LIF migrations are transparent and
nondisruptive for SMB 2.0 connections.
Compounded operations
Provides a method for combining multiple SMB messages into a single network transmission
request for submission to the underlying transport.
Asynchronous operations
Certain SMB commands from the clients can take a longer time for the server to process. For
these commands, the CIFS server can send responses asynchronously.
Increased read and write buffer sizes
Allows for better throughput across faster networks, even those with high latency.
Increased scalability
SMB 2.0 has increased limits for number of CIFS sessions, open share connections, and open file
connections.
Increased SMB signing security
Support for stronger data integrity protection through the use of the HMAC-SHA256 hash
algorithm.
Data ONTAP does not support the following SMB 2.0 functionality:
Symbolic links
Credit system for flow control
If SMB 2.0 is disabled on the CIFS server, communication between the SMB 2.0 client and the CIFS
server falls back to the SMB 1.0 protocol (assuming that the SMB 2.0 client includes the SMB 1.0
dialect in its negotiate request).
For more information, see Technical Report TR-3740 or the SMB 2.0 protocol specification.
Related information
Technical Report: SMB 2Next-Generation CIFS Protocol in Data ONTAP: media.netapp.com/

documents/tr-3740.pdf
The SMB 2.1 protocol provides several enhancements to the SMB 2.0 protocol. Data ONTAP 8.1
and later supports SMB 2.1 on Vservers with FlexVol volumes. Support for SMB 2.1 is enabled
automatically when you enable the SMB 2.0 protocol on the CIFS server.
SMB 2.0 and SMB 2.1 are enabled automatically when you create a CIFS server. SMB 2.0 and SMB
2.1 are always enabled or disabled together. You cannot enable or disable SMB 2.0 and SMB 2.1
separately.
Lease oplocks
Data ONTAP uses SMB 2.1 lease oplocks, which is a new client oplock leasing model that
provides advantages over traditional oplocks. Lease oplocks offer more flexibility and levels in
controlling the client caching. This results in significant performance improvement in highlatency and erratic networks.
BranchCache version 1
BranchCache is a feature that delivers WAN bandwidth optimization and improved file access
performance using client-side caching at remote offices. SMB 2.1 has the functional extensions
needed to manage content hashes, which are used by BranchCache-enabled CIFS servers to
provide clients with information about cached content.
Large MTU
Resilient handles
For more information, see Technical Report TR-3740 or the SMB 2.1 protocol specification.
Related information
Technical Report: SMB 2Next-Generation CIFS Protocol in Data ONTAP: media.netapp.com/

documents/tr-3740.pdf
Clustered Data ONTAP 8.2 and later supports the SMB 3.0 protocol on Vservers with FlexVol
volumes. SMB 3.0 provides important enhancements, including enhancements that facilitate
transparent failover and giveback and other nondisruptive operations.
Support for SMB 3.0 is enabled automatically when you create a CIFS server.
Continuously available share property

A new share property that, along with persistent handles, allows SMB clients that are connected
to shares that are configured to use the continuously available share property to transparently
reconnect to a CIFS server following disruptive events such as failover and giveback operations.
Persistent handles
Enables clients to transparently reconnect to disconnected SMB sessions after certain disruptive
events. A persistent handle is preserved after a disconnection. Persistent handles block other file
opens while waiting for a reconnection. Along with the continuously available share property,
persistent handles provide support for certain nondisruptive operations.
Remote VSS for SMB shares
Remote VSS (Volume Shadow Copy Service) for SMB provides the functionality that allows
VSS-enabled backup services to create application-consistent volume shadow copies of VSSaware applications that access data stored over SMB 3.0 shares.
Witness
Enables a CIFS server providing SMB shares to Hyper-V servers to promptly notify the Hyper-V
servers about network failures.
ODX copy offload
ODX enables data transfers within or between ODX-enabled storage servers without transferring
the data through the Windows client.
BranchCache version 2
Provides enhanced functionality, including smaller, variable-sized content segments, which
increases the reuse of existing cached content.
SMB Multichannel
SMB Direct
SMB Directory Leasing
SMB Encryption
For more information, see the SMB 3.0 protocol specification.

Related concepts

What the Witness protocol does to enhance transparent failover on page 411
Share-based backups of Hyper-V virtual machines with Remote VSS on page 413
Related tasks
Enabling or disabling SMB 3.0 on page 149

Creating an SMB share on a CIFS server on page 193
Enabling or disabling SMB 2.x
SMB 2.x is enabled by default for CIFS servers on Vservers with FlexVol volumes. This allows
clients to connect to the CIFS server using SMB 2.x. You can enable or disable SMB 2.x at any time
by using a CIFS server option.
About this task
The -smb2-enabled option enables SMB 2.0 and SMB 2.1.

Steps


If you want SMB 2.x to be... Enter the command...
Enabled
vserver cifs options modify -vserver vserver_name

-smb2-enabled true
Disabled

-smb2-enabled false

Example
The following example enables SMB 2.x on Vserver vs1:
cluster1::> set -privilege advanced
Warning: These advanced commands are potentially dangerous; use them
only when directed to do so by technical support personnel.
cluster1::*> vserver cifs options modify -vserver vs1 -smb2-enabled true
cluster1::*> set -privilege admin
Related concepts
Supported SMB 2.0 functionality on page 145

Related tasks
Enabling or disabling SMB 3.0 on page 149

Enabling or disabling SMB 3.0
SMB 3.0 is enabled by default for CIFS servers on Vservers with FlexVol volumes. This allows
clients that support SMB 3.0 to connect to the CIFS server using SMB 3.0. You can enable or disable
SMB 3.0 at any time by using a CIFS server option.
About this task
This option must be enabled if you want to configure continuously available shares.
ODX copy offload requires that SMB 3.0 be enabled. If ODX copy offload is enabled and you
disable SMB 3.0, Data ONTAP automatically disables ODX copy offload. Similarly, if you enable
ODX copy offload, Data ONTAP will automatically enable SMB 3.0 if it is not already enabled.

Steps


If you want SMB 3.0 to be... Enter the command...
Enabled

-smb3-enabled true
Disabled

-smb3-enabled false

Example
The following example shows SMB 3.0 enabled on Vserver vs1:
cluster1::*> vserver cifs options modify -vserver vs1 -smb3-enabled true
Related concepts

Related tasks
Enabling or disabling SMB 2.x on page 148
Using SMB signing to enhance network security

SMB signing helps to ensure that network traffic between the CIFS server and the client is not
compromised; it does this by preventing replay attacks. By default, Data ONTAP supports SMB
signing when requested by the client. Optionally, the storage administrator can configure the CIFS
server to require SMB signing.
How SMB signing policies affect communication with a CIFS server

In addition to the CIFS server SMB signing security settings, there are two SMB signing policies on
Windows clients that control the digital signing of communications between clients and a Vserver's
CIFS server. You can configure the setting that meets your business requirements.
Client SMB policies are controlled through Windows local security policy settings, which are
configured by using the Microsoft Management Console (MMC) or Active Directory GPOs. For
more information about client SMB signing and security issues, see the Microsoft Windows
documentation.
Here are descriptions of the two SMB signing policies on Microsoft clients:
Microsoft network client: Digitally sign communications (if server

agrees)
This setting controls whether the clients SMB signing capability is enabled. It is enabled by
default. When this setting is disabled on the client, the client communicates normally with the
CIFS server without SMB signing, regardless of the SMB signing setting on the CIFS server.
Microsoft network client: Digitally sign communications (always)
This setting controls whether the client requires SMB signing to communicate with a server. It is
disabled by default. When this setting is disabled on the client, SMB signing behavior is based on
the policy setting for Microsoft network client: Digitally sign communications
(if server agrees) and the setting on the CIFS server.
Note: If your environment includes Windows clients configured to require SMB signing, you
must enable SMB signing on the CIFS server. If you do not, the CIFS server cannot serve data
to these systems.
The effective results of client and CIFS server SMB signing settings depends on whether the SMB
sessions uses SMB 1.0 or SMB 2.x and later.
The following table summarizes the effective SMB signing behavior if the session uses SMB 1.0:
Client
Data ONTAPsigning Data ONTAPsigning

not required
required
Signing disabled and not required
Not signed
Signed
Signing enabled and not required
Not signed
Signed
Signing disabled and required
Signed
Signed
Signing enabled and required
Signed
Signed
The following table summarizes the effective SMB signing behavior if the session uses SMB 2.x or
SMB 3.0:
Note: For SMB 2.x and SMB 3.0 clients, SMB signing is always enabled. It cannot be disabled.

Client
Data ONTAPsigning Data ONTAPsigning

not required
required
Signing not required
Not signed
Signed
Signing required
Signed
Signed
The following table summarizes the default Microsoft client and server SMB signing behavior:
Protocol
Hash
algorithm
Can
enable/
disable
Can
require/not
require
Client
default
Server
default
DC default
SMB 1.0
MD5
Yes
Yes
Enabled
(not
required)
Disabled
(not
required)
Required
SMB 2.x
HMAC
SHA-256
No
Yes
Not
required
Not
required
Required
SMB 3.0
AESCMAC.
No
Yes
Not
required
Not
required
Required
Performance impact of SMB signing

When SMB sessions use SMB signing, all SMB communications to and from Windows clients
experience a significant impact on performance, which affects both the clients and the server (that is,
the nodes on the cluster running the Vserver containing the CIFS server).
The performance degradation shows as increased CPU usage on both the clients and the server,
although the amount of network traffic does not change.
Depending on your network and Vserver implementation, the performance impact of SMB signing
can vary widely; you can verify it only through testing in your network environment.
Most Windows clients negotiate SMB signing by default if it is enabled on the server. If you require
SMB protection for some of your Windows clients, and if SMB signing is causing performance
issues, you can disable SMB signing on any of your Windows clients that do not require protection
against replay attacks. For information about disabling SMB signing on Windows clients, see the
Microsoft Windows documentation.
Recommendations for configuring SMB signing
You can configure SMB signing behavior between SMB clients and the CIFS server to meet your
security requirements. The settings you choose when configuring SMB signing on your CIFS server
are dependent on what your security requirements are.
You can configure SMB signing on either the client or the CIFS server. Consider the following
recommendations when configuring SMB signing:

If...
Recommendation...
You want to increase the security of the

Make SMB signing required at the client by
communication between the client and the server enabling the Require Option (Sign
always) security setting on the client.
You want all SMB traffic to a certain Vserver
signed
Make SMB signing required on the Vserver's

CIFS server by configuring the security settings
to require SMB signing.
See Microsoft documentation for more information on configuring Windows client security settings.
Related tasks
Enabling or disabling required SMB signing for incoming SMB traffic on page 141
Considerations when multiple data LIFS are configured
If you enable or disable required SMB signing on the CIFS sever, there are certain considerations
you should keep in mind when you have multiple data LIFS configured for a Vserver.
When you configure a CIFS server, there might be multiple data LIFs configured. If so, the DNS
server contains multiple A record entries for the CIFS server, all using the same CIFS server host
name, but each with a unique IP address. For example, a CIFS server that has two data LIFs
configured might have the following DNS A record entries:
The normal behavior is that upon changing the required SMB signing setting, only new connections
from clients are affected by the change in the SMB signing setting. However, there is an exception to
this behavior. There is a case where a client has an existing connection to a share, and the client
creates a new connection to the same share after the setting is changed, while maintaining the
original connection. In this case, both the new and the existing SMB connection adopt the new SMB
signing requirements.
Consider the following example:
1. Client1 connects to a share without required SMB signing using the path O:\.
2. The storage administrator modifies the CIFS server configuration to require SMB signing.
3. Client1 connects to the same share with required SMB signing using the path S:\ (while
maintaining the connection using the path O:\) .
4. The result is that SMB signing is used when accessing data over both the O:\ and S:\ drives.
Enabling or disabling required SMB signing for incoming SMB traffic

You can enforce the requirement for clients to sign SMB messages by enabling required SMB
signing. If enabled, Data ONTAP accepts SMB messages only if they have valid signatures. If you
want to permit SMB signing, but not require it, you can disable required SMB signing.
About this task
By default, required SMB signing is disabled. You can enable or disable required SMB signing at
any time.
Note: SMB signing is not disabled by default under the following circumstance:
1. Required SMB signing is enabled and the cluster is reverted to a version of Data ONTAP that
does not support SMB signing.
2. The cluster is subsequently upgraded to a version of Data ONTAP that supports SMB signing.
Under these circumstances, the SMB signing configuration originally configured on a
supported version of Data ONTAP is retained through reversion and subsequent upgrade.
Steps

If you want required SMB
signing to be...
Enabled

vserver_name -is-signing-required true
Disabled

vserver_name -is-signing-required false
2. Verify that required SMB signing is enabled or disabled by determining if the value in the Is
Signing Required field in the output from the following command is set to the desired value:
vserver cifs security show -vserver vserver_name -fields is-signingrequired
Example
The following example enables required SMB signing for Vserver vs1:
cluster1::> vserver cifs security modify -vserver vs1 -is-signing-required
true
cluster1::> vserver cifs security show -vserver vs1 -fields is-signingrequired
vserver is-signing-required
-------- ------------------vs1
true
Monitoring SMB signed session statistics

You can monitor SMB sessions statistics and determine which established sessions are signed and
which are not.
About this task
The statistics command provides the signed_sessions counter that you can use to monitor
the number of signed SMB sessions. The signed_sessions is available with the following
statistics objects:
cifs allows you to monitor SMB signing for all SMB sessions.
smb1 allows you to monitor SMB signing for SMB 1.0 sessions.
smb2 allows you to monitor SMB signing for SMB 2.x and SMB 3.0 sessions.
Note: SMB 3.0 statistics are included in the output for the smb2 object.
If you want to compare the number of signed session to the total number of sessions, you can
compare output for the signed_sessions counter with the output for the
established_sessions counter.
You must start a statistics sample collection before you can view the resultant data. You can view
data from the sample if you do not stop data collection. Stopping data collection gives you a fixed
sample. Not stopping data collection gives you the ability to get updated data that you can use to
compare against previous queries. The comparison can help you identify trends.
For more information about using the statistics command, see the Clustered Data ONTAP
System Administration Guide for Cluster Administrators.
Steps
1. Start a data collection:

statistics start -object {cifs|smb1|smb2} -instance instance -sample-id
sample_ID [-node node_name]
If you do not specify the -sample-id parameter, the command generates a sample identifier for
you and defines this sample as the default sample for the CLI session. The value for -sample-id
is a text string. If you run this command during the same CLI session and do not specify the sample-id parameter, the command overwrites the previous default sample.
You can optionally specify the node on which you want to collect statistics. If you do not specify
the node, the sample collects statistics for all nodes in the cluster.
2. Optional: Use the statistics stop command to stop collecting data for the sample.
3. View SMB signing statistics:

If you want to view
information for...
Enter this command...
Signed sessions
show -sample-id sample_ID -counter

signed_sessions|node_name [-node node_name]
Signed sessions and established

sessions
show -sample-id sample_ID -counter

signed_sessions|established_sessions|node_name
[-node node_name]
If you want to display information for only a single node, specify the optional -node parameter.
Examples
The following example shows how you can monitor SMB 2.x and SMB 3.0 signing statistics
on Vserver vs1.
The following command starts data collection for a new sample:
cluster1::> statistics start -object smb2 -sample-id
smbsigning_sample -vserver vs1
Statistics collection is being started for Sample-id:
smbsigning_sample
The following command stops the data collection for the sample:
cluster1::> statistics stop -sample-id smbsigning_sample
Statistics collection is being stopped for Sample-id:
smbsigning_sample
The following command shows signed SMB sessions and established SMB sessions by node
from the sample:
cluster1::> statistics show -sample-id smbsigning_sample -counter
signed_sessions|established_sessions|node_name
Object: smb2
Instance: vs1
Start-time: 2/6/2013 01:00:00
End-time: 2/6/2013 01:03:04
Cluster: cluster1
Counter
Value
-------------------------------- ------------------------established_sessions
0
node_name
node1
signed_sessions
0
established_sessions
1
node_name
node2
signed_sessions
1
0
node_name
node3
signed_sessions
0
0

node_name
signed_sessions
node4
0
The following command shows signed SMB sessions for node2 from the sample:
cluster1::> statistics show -sample-id smbsigning_sample -counter
signed_sessions|node_name -node node2
Object: smb2
Instance: vs1
Start-time: 2/6/2013 01:00:00
End-time: 2/6/2013 01:22:43
Cluster: cluster1
Counter
Value
-------------------------------- ------------------------node_name
node2
signed_sessions
1
Related tasks
Enabling or disabling required SMB signing for incoming SMB traffic on page 141
Improving client performance with traditional and lease oplocks

Traditional oplocks (opportunistic locks) and lease oplocks enable a CIFS client in certain filesharing scenarios to perform client-side caching of read-ahead, write-behind, and lock information. A
client can then read from or write to a file without regularly reminding the server that it needs access
to the file in question. This improves performance by reducing network traffic.
Lease oplocks are an enhanced form of oplocks available with the SMB 2.1 protocol and later. Lease
oplocks allow a client to obtain and preserve client caching state across multiple SMB opens
originating from itself.
Lease oplocks are not supported on Vservers with Infinite Volumes.
Write cache data-loss considerations when using oplocks
Under some circumstances, if a process has an exclusive oplock on a file and a second process
attempts to open the file, the first process must invalidate cached data and flush writes and locks. The
client must then relinquish the oplock and access to the file. If there is a network failure during this
flush, cached write data might be lost.
Data-loss possibilities
Any application that has write-cached data can lose that data under the following set of
circumstances:
The connection is made using SMB 1.0.

It has an exclusive oplock on the file.
It is told to either break that oplock or close the file.
During the process of flushing the write cache, the network or target system generates an
error.
Error handling and write completion
The cache itself does not have any error handlingthe applications do. When the application
makes a write to the cache, the write is always completed. If the cache, in turn, makes a write to
the target system over a network, it must assume that the write is completed because if it does not,
the data is lost.
Enabling or disabling oplocks when creating CIFS shares

Oplocks allow clients to lock files and cache content locally, which can increase performance for file
operations. Oplocks are enabled on CIFS shares residing on Vservers with FlexVol volumes by
default. In some circumstances, you might want to disable oplocks. You can enable or disable
oplocks on a share-by-share basis.
About this task
If oplocks are enabled on the volume containing a share but the oplock share property for that share
is disabled, oplocks are disabled for that share. Disabling oplocks on a share takes precedence over
the volume oplock setting. Disabling oplocks on the share disables both opportunistic and lease
oplocks.
You can specify other share properties in addition to specifying the oplock share property by using a
comma-delimited list. You can also specify other share parameters.
Step
1. Perform the applicable action:

If you want
to...
Then...
Enable oplocks Enter the following command:

on a share
vserver cifs share create -vserver vserver_name -share-name
during share
share_name -path path_to_share -share-properties
creation
[oplocks,...]
Note: If you want the share to have only the default share properties, which are
oplocks, browsable, and changenotify enabled, you do not have to specify
the -share-properties parameter when creating a CIFS share. If you want any
combination of share properties other than the default, then you must specify the share-properties parameter with the list of share properties to use for that
share.

If you want
to...
Then...
Disable
oplocks on a
share during
share creation

vserver cifs share create -vserver vserver_name -share-name
share_name -path path_to_share -share-properties
[other_share_property,...]
Note: When disabling oplocks, you must specify a list of share properties when
creating the share, but you should not specify the oplocks property.
Related tasks
Enabling or disabling oplocks on existing CIFS shares on page 159

Monitoring oplock status on page 161
Enabling or disabling oplocks on existing CIFS shares
Oplocks are enabled on CIFS shares on Vservers with FlexVol volumes by default. Under some
circumstances, you might want to disable oplocks; alternatively, if you have previously disabled
oplocks on a share, you might want to reenable oplocks.
About this task
If oplocks are enabled on the volume containing a share, but the oplock share property for that share
is disabled, oplocks are disabled for that share. Disabling oplocks on a share takes precedence over
enabling oplocks on the volume. Disabling oplocks on the share, disables both opportunistic and
lease oplocks. You can enable or disable oplocks on existing shares at any time.
Step
1. Perform the applicable action:

If you want to...
Then...
Enable oplocks on a
share by modifying an
existing share

vserver share properties add -vserver vserver_name share-name share_name -share-properties oplocks
Note: You can specify additional share properties to add by using a commadelimited list.
Newly added properties are appended to the existing list of share properties. Any
share properties that you have previously specified remain in effect.

If you want to...
Then...
Disable oplocks on a
share by modifying an
existing share

vserver share properties remove -vserver vserver_name
-share-name share_name -share-properties oplocks
Note: You can specify additional share properties to remove by using a
comma-delimited list.
Share properties that you remove are deleted from the existing list of share
properties; however, previously configured share properties that you do not
remove remain in effect.
Examples
The following example shows oplocks enabled for the share named Engineering on Vserver
vs1:
cluster1::> vserver cifs share properties add -vserver vs1 -share-name
Engineering -share-properties oplocks
cluster1::> vserver cifs share properties show
Vserver
Share
Properties
---------------- ---------------- ----------------vs1
Engineering
oplocks
browsable
changenotify
showsnapshot
The following example shows oplocks disabled for the share named Engineering on Vserver
vs1:
cluster1::> vserver cifs share properties remove -vserver vs1 -share-name
Engineering -share-properties oplocks
cluster1::> vserver cifs share properties show
Vserver
Share
Properties
---------------- ---------------- ----------------vs1
Engineering
browsable
changenotify
showsnapshot
Related tasks
Enabling or disabling oplocks when creating CIFS shares on page 158

Adding or removing share properties on an existing share on page 197
Commands for enabling or disabling oplocks on volumes and qtrees

You need to know the commands for enabling or disabling oplocks on volumes or qtrees.
Oplocks allow clients to lock files and cache content locally, which can increase performance for file
operations.
Oplocks are enabled on volumes for Vservers with FlexVol volumes and Vservers with Infinite
Volume by default. You cannot disable oplocks when you create a volume, but you can enable or
disable oplocks on existing volumes for Vservers with FlexVol volumes at any time. You cannot
disable oplocks on volumes for Vservers with Infinite Volume.
You can enable oplocks on qtrees for Vservers with FlexVol volumes. If you do not specify an
oplock setting when creating a qtree, the qtree inherits the oplock setting of the parent volume.
However, if you do specify an oplock setting on the qtree, it takes precedence over the oplock setting
on the volume.
If you want to...
Use this command...
Enable oplocks on volumes or

qtrees
set to enable
Disable oplocks on volumes or

qtrees
set to disable
volume qtree oplocks with the -oplock-mode parameter
volume qtree oplocks with the -oplock-mode parameter
Related tasks

Monitoring oplock status
You can monitor and display information about oplock status. You can use this information to
determine which files have oplocks, what the oplock level and oplock state level are, and whether
oplock leasing is used. You can also determine information about locks that you might need to break
manually.
About this task
You can display a summary about all oplocks, or you can use optional parameters to display
information about a smaller subset of existing locks. You can limit the output to oplocks held by one
or more of the following objects:
On a specified Vserver
On a specified node
On a specified volume
Established on a specified LIF
At the specified path
Established through the SMB, NFSv3, NFSv4, or NFSv4.1 protocol

You can display the following information about traditional and lease oplocks:
Vserver, node, volume, and LIF on which the oplock is established

IP address of the client with the oplock
Path at which the oplock is established
Lock protocol (CIFS) and type (oplock)
Lock state
A lock can be in one of the following states:
granted, which means that the lock is established.
gwaiting, which means that the lock is waiting to be granted because it conflicts with
another lock.
revoking, which means that the server is currently coordinating with the client to change the
state of the lock.
Oplock level
A lock can have the following oplock levels:
batch, which permits the client to cache all operations on the file.
exclusive, which permits the client to cache reads and writes on the file.
read-batch, which permits the client to cache reads and opens on the file.
level2, which permits the client to cache reads on the file.
null, which disallows the client from caching any operations on the file.
Connection state and SMB expiration time
Open Group ID if a lease oplock is granted
Step
1. Display oplock status by using the vserver locks show command.

Examples
The following command displays default information about all locks. The oplock on the
displayed file is granted with a read-batch oplock level:
Vserver:
Volume
-------vol1
vs0
Object Path
LIF
Protocol Lock Type
------------------ ----------- --------- ----------/vol1/notes.txt
node1_data1
cifs
share-level
Sharelock Mode: read_write-deny_delete
op-lock
Oplock Level: read-batch
Client
---------192.168.1.5
192.168.1.5
The following example displays more detailed information about the lock on a file with the
path /data2/data2_2/intro.pptx. A lease oplock is granted on the file with a batch
oplock level to a client with an IP address of 10.3.1.3:

Note: When displaying detailed information, the command provides separate output for
oplock and sharelock information. This example only shows the output from the oplock
section.
cluster1::> vserver lock show -instance -path /data2/data2_2/intro.pptx
Vserver: vs1
Volume: data2_2
Object Path: /data2/data2_2/intro.pptx
Lock UUID: ff1cbf29-bfef-4d91-ae06-062bf69212c3
Lock Protocol: cifs
Lock Type: op-lock
Lock State: granted
Bytelock Starting Offset: Number of Bytes Locked: Bytelock is Mandatory: Bytelock is Exclusive: Bytelock is Superlock: Bytelock is Soft: Oplock Level: batch
Related tasks
Enabling or disabling oplocks when creating CIFS shares on page 158

Enabling or disabling oplocks on existing CIFS shares on page 159
Related references
Commands for enabling or disabling oplocks on volumes and qtrees on page 161
Using IPv6 with CIFS

Starting with Data ONTAP 8.2, CIFS clients can access files on your Vserver over an IPv6 network.
After you enable IPv6 on the cluster and properly configure data LIFs, CIFS over IPv6 works
immediately. You do not have to enable any other Vserver or CIFS server specific options.
Requirements for using IPv6
Before you can use IPv6 on your CIFS server, you need to know which versions of Data ONTAP and
SMB support it and what the license requirements are.
Data ONTAP version and license requirements
Data ONTAP 8.2 and later supports IPv6.
Commands used to configure CIFS servers, SMB access, and CIFS services and features that
support IPv6 can use either IPv4 or IPv6 addresses whenever an IP address is a supported
command parameter. Similarly, commands supported with IPv6 that display information about IP
addresses display both IPv4 and IPv6 addresses.
No special license is required for IPv6; however, CIFS must be licensed, and a CIFS server must
exist on the Vserver to user IPv6 with SMB access and CIFS services.
SMB protocol version requirements
For Vservers with FlexVol volumes, Data ONTAP supports IPv6 on all versions of the SMB
protocol, including SMB 1.0, SMB 2.x, and SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports IPv6 on SMB 1.0.
This is because SMB 2.x and SMB 3.0 are not supported on Vservers with Infinite Volume.
Note: NetBIOS name service (NBNS) over IPv6 is not supported.
Support for IPv6 with CIFS

If you want to use IPv6 on your CIFS server, you need to be aware of how Data ONTAP supports
IPv6 with CIFS.
Windows client and server support
Data ONTAP provides support for Windows servers and clients that support IPv6. The following
describes Microsoft Windows client and server IPv6 support:
Windows XP and Windows 2003 support IPv6 for SMB file sharing.
These versions provide limited support for IPv6.
Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2012 and later
support IPv6 for both SMB file sharing and Active Directory services, including DNS, LDAP,
CLDAP, and Kerberos services.
If IPv6 addresses are configured, Windows 7 and Windows Server 2008 and later releases use
IPv6 by default for Active Directory services. Both NTLM and Kerberos authentication over IPv6
connections are supported.
All Windows clients supported by Data ONTAP can connect to SMB shares by using IPv6
addresses.
For the latest information about which Windows clients Data ONTAP supports, see the
Note: NT domains are not supported for IPv6.
Additional CIFS services support

In addition to IPv6 support for SMB file shares and Active Directory services, Data ONTAP
provides IPv6 support for the following:
Client-side services, including offline folders, roaming profiles, folder redirection, Previous
Versions
Server-side services, including Dynamic home directories (Home Directory feature), symlinks
and Widelinks, BranchCache, ODX copy offload, automatic node referrals, and Previous
Versions
File access management services, including the use of Windows local users and groups for access
control and rights management, setting file permissions and audit policies using the CLI, security
tracing, file locks management, and monitoring CIFS activity
NAS multiprotocol auditing
FPolicy
Continuously available shares, Witness protocol, and Remote VSS (used with Hyper-V over
SMB configurations)
Name service and authentication service support

Communication with the following name services are supported with IPv6:
Domain controllers
DNS servers
LDAP servers
KDC servers
NIS servers
How CIFS servers use IPv6 to connect to external servers

To create a CIFS configuration that meets your requirements, you must be aware of how CIFS
servers use IPv6 when making connections to external servers.
Source address selection

If an attempt is made to connect to an external server, the source address selected must be of the
same type as the destination address. For example, if connecting to an IPv6 address, the Vserver
hosting the CIFS server must have a data LIF or management LIF that has an IPv6 address to use
as the source address. Similarly, if connecting to an IPv4 address, the Vserver must have a data
LIF or management LIF that has an IPv4 address to use as the source address.
For servers dynamically discovered using DNS, server discovery is performed as follows:
If IPv6 is disabled on the cluster, only IPv4 servers addresses are discovered.
If IPv6 is enabled on the cluster, both IPv4 and IPv6 server addresses are discovered. Either
type might be used depending upon the suitability of the server to which the address belongs
and the availability of IPv6 or IPv4 data or management LIFs.
Dynamic server discovery is used for discovering Domain Controllers and their associated
services, such as LSA, NETLOGON, Kerberos, and LDAP.
DNS server connectivity
Whether the Vserver uses IPv6 when connecting to a DNS server depends on the DNS name
services configuration. If DNS services are configured to use IPv6 addresses, connections are
made by using IPv6. If desired, the DNS name services configuration can use IPv4 addresses so
that connections to DNS servers continue to use IPv4 addresses. Combinations of IPv4 and IPv6
addresses can be specified when configuring DNS name services.
LDAP server connectivity
Whether the Vserver uses IPv6 when connecting to an LDAP server depends on the LDAP client
configuration. If the LDAP client is configured to use IPv6 addresses, connections are made by
using IPv6. If desired, the LDAP client configuration can use IPv4 addresses so that connections
to LDAP servers continue to use IPv4 addresses. Combinations of IPv4 and IPv6 addresses can
be specified when configuring the LDAP client configuration.
Note: The LDAP client configuration is used when configuring LDAP for UNIX user, group,
and netgroup name services.
NIS server connectivity

Whether the Vserver uses IPv6 when connecting to a NIS server depends on the NIS name
services configuration. If NIS services are configured to use IPv6 addresses, connections are
made by using IPv6. If desired, the NIS name services configuration can use IPv4 addresses so
that connections to NIS servers continue to use IPv4 addresses. Combinations of IPv4 and IPv6
addresses can be specified when configuring NIS name services.
Note: NIS name services are used for storing and managing UNIX user, group, netgroup, and
host name objects.

Related tasks
Enabling IPv6 for CIFS (cluster administrators only) on page 166

Monitoring and displaying information about IPv6 CIFS sessions on page 167
Enabling IPv6 for CIFS (cluster administrators only)
IPv6 networks are not enabled during cluster setup. A cluster administrator must enable IPv6 after
cluster setup is complete. When the cluster administrator enables IPv6, it is enabled for the entire
cluster.
Step
1. Enable IPv6:
network options ipv6 modify -enabled true
For more information about enabling IPv6 on the cluster and configuring IPv6 LIFs, see the
Clustered Data ONTAP Network Management Guide.
IPv6 is enabled. IPv6 data LIFs for CIFS access can be configured.
Related tasks
Monitoring and displaying information about IPv6 CIFS sessions on page 167
How to disable IPv6 for CIFS

Even though IPv6 is enabled on the cluster using a network option, you cannot disable IPv6 by using
the same command. Instead, Data ONTAP disables IPv6 when the cluster administrator disables the
last IPv6-enabled interface on the cluster. You should communicate with the cluster administrator
about management of your IPv6 enabled interfaces.
For more information about disabling IPv6 on the cluster, see the Clustered Data ONTAP Network
Management Guide.
Monitoring and displaying information about IPv6 CIFS sessions
You can monitor and display information about CIFS sessions that are connected using IPv6
networks. This information is useful in determining which clients are connecting using IPv6 as well
as other useful information about IPv6 CIFS sessions.
Step

If you want to determine whether...
CIFS sessions to a Vserver are connected

using IPv6
vserver cifs session show -vserver

vserver_name -instance
IPv6 is used for CIFS sessions through a

specified LIF address
vserver cifs session show -vserver

vserver_name -lif-address LIF_IP_address
-instance
LIF_IP_address is the data LIF's IPv6 address.
Applying Group Policy Objects to a CIFS server

Your Vserver's CIFS server supports Group Policy Objects (GPOs), a set of rules known as group
policy attributes that apply to computers in an Active Directory environment.
When CIFS and GPOs are enabled on your CIFS server, Data ONTAP sends LDAP queries to the
Active Directory server requesting GPO information. If there are GPO definitions that are applicable
to your CIFS server, the Active Directory server returns the following GPO information:
GPO name
Current GPO version
Location of the GPO definition
Lists of UUIDs (universally unique identifiers) for GPO policy sets
Supported GPOs
Although not all Group Policy Objects (GPOs) are applicable to your CIFS-enabled Vserver, the
Vserver can recognize and process the relevant set of GPOs.
The following GPOs are currently supported on Vservers for FlexVol volumes:
Registry settings:
Group Policy refresh interval for CIFS-enabled Vserver

Group Policy refresh random offset
Hash publication for BranchCache
The Hash Publication for BranchCache GPO corresponds to the BranchCache operating
mode. The three supported operating modes are per-share, all shares, and disabled.
Hash version support for BranchCache
The three supported settings are support for BranchCache version 1, support for BranchCache
version 2, and support for both versions 1 and 2.
Kerberos security settings:
Maximum clock skew

Maximum ticket age
Maximum ticket renew age
The following GPOs are currently supported on Vservers for Infinite Volume:
Registry settings:
Group Policy refresh interval for CIFS-enabled Vserver

Group Policy refresh random offset
Kerberos security settings:
Maximum clock skew

Maximum ticket age
Maximum ticket renew age
Related concepts
Using BranchCache to cache CIFS share content at a branch office on page 366
Kerberos authentication on page 114
Related tasks
Modifying the CIFS server Kerberos security settings on page 140

Enabling or disabling GPO support on a CIFS server on page 169
Requirements for using GPOs with your CIFS server

To use Group Policy Objects (GPOs) with your CIFS server, your system must meet several
requirements.
CIFS must be licensed on the cluster.

A CIFS server must be configured and joined to a Windows Active Directory domain.
GPOs must be configured and applied to the Windows Active Directory Organizational Unit
(OU) containing the CIFS server computer object.
GPO support must be enabled on the CIFS server.
Enabling or disabling GPO support on a CIFS server

You can enable or disable Group Policy Object (GPO) support on the CIFS server. If you enable
GPO support on the CIFS server, applicable GPOs that are defined on the group policy (in this case,
the policy applied to the OU containing the CIFS server computer object) are applied to the CIFS
server.
Steps

If you want to... Enter the command...
Enable GPOs
vserver cifs group-policy modify -vserver vserver_name status enabled
Disable GPOs
vserver cifs group-policy modify -vserver vserver_name status disabled
2. Verify that GPO support is in the desired state by using the following command:
vserver cifs group-policy show -vserver vserver_name
Example
The following example enables GPO support on Vserver vs1:
cluster1::> vserver cifs group-policy modify -vserver vs1 -status enabled
cluster1::> vserver cifs group-policy show -vserver vs1
Virtual Server
GPO Status
----------------------vs1
enabled
Related concepts
Supported GPOs on page 168

Related tasks
Displaying information about GPO configurations on page 171

How GPOs are updated on the CIFS server
Data ONTAP retrieves and applies Group Policy Object (GPO) changes every 90 minutes and
refreshes security settings every 16 hours. If you want to update GPOs to apply new GPO policy
settings before Data ONTAP automatically updates them, you can trigger a manual update on a CIFS
server with a Data ONTAP command.
All GPOs are verified and updated as needed every 90 minutes.

By default, Data ONTAP queries Active Directory for changes to GPOs. If the GPO version
numbers recorded in Active Directory are higher than those on the CIFS server, Data ONTAP
retrieves and applies the new GPOs. If the version numbers are the same, GPOs on the CIFS
server are not updated.
Security Settings GPOs are refreshed every 16 hours.
Data ONTAP retrieves and applies Security Settings GPOs every 16 hours, whether or not these
GPOs have changed.
Note: The 16-hour default value cannot be changed in the current Data ONTAP version. It is a
Windows client default setting.
All GPOs can be updated manually with a Data ONTAP command.

This command simulates the Windows gpupdate.exe /force command.
Manually updating GPO settings on the CIFS server

If you want to update Group Policy Object (GPO) settings on your CIFS server immediately, you can
manually force a GPO update.
Steps
1. Update GPO settings manually by entering the following command:

vserver cifs group-policy update -vserver vserver_name
2. Verify that the update succeeded by entering the following command:

vserver cifs group-policy show-applied -vserver vserver_name
Example
The following example updates the GPOs on a Vserver with FlexVol volumes named vs1:
cluster1::> vserver cifs group-policy update -vserver vs1
cluster1::> vserver cifs group-policy show-applied
Vserver: vs1
----------------------------GPO Name: Default Domain Policy
Level: Domain

Status: enabled
Registry Settings:
Refresh Time Interval: 22
Refresh Random Offset: 8
Hash Publication for BranchCache: per-share
Hash Version Support for BranchCache: all-versions
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
GPO Name: Resultant Set of Policy
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Displaying information about GPO configurations

You can display information about Group Policy Object (GPO) configurations that are defined in
Active Directory and about GPO configurations applied to the CIFS server.
About this task
You can display information about all GPO configurations defined in the Active Directory of the
domain to which the CIFS server belongs, or you can display information only about GPO
configurations applied to a CIFs server.
Step

If you want to...
Display information about all Group Policy

configurations defined in Active Directory
vserver cifs group-policy showdefined -vserver vserver_name
Display information about all Group Policy

configurations applied to a CIFS server
vserver cifs group-policy showapplied -vserver vserver_name
Example
The following example displays the GPO configurations defined in the Active Directory to
which the CIFS-enabled Vserver with FlexVol volumes named vs1 belongs and the GPO
configurations applied to Vserver vs1:

cluster1::> vserver cifs group-policy show-defined -vserver vs1
Vserver: vs1
Level: Domain
Status: enabled
Registry Settings:
Hash Version Support for BranchCache : all-versions
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Status: disabled
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
cluster1::> vserver cifs group-policy show-applied -vserver vs1
Vserver: vs1
Level: Domain
Status: enabled
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7

Related tasks
Managing domain controller connections

You can manage domain controller connections by displaying information about currently discovered
LDAP and domain controller servers, resetting and rediscovering LDAP and domain controller
servers, managing the preferred domain controller list, and displaying information about currently
configured preferred domain controllers.
Displaying information about discovered servers
You can display information related to discovered LDAP servers and domain controllers on your
CIFS-enabled Vserver.
Step
1. To display all or a subset of the information related to discovered servers, enter the following
command:
vserver cifs domain discovered-servers show
By default, the command displays the following information about discovered servers:
Node name
Vserver name
CIFS domain name
Server type
Preference
Domain controller name
Domain controller address
Status
You can display additional information in a detailed view. See the man page for the vserver
cifs domain discovered-servers show command for details.
Example
The following example shows discovered servers for Vserver vs1:
cluster1::> vserver cifs domain discovered-servers show
Node: node1
Vserver: vs1
Domain Name
--------------example.com
example.com
Type
-------MS-LDAP
MS-LDAP
Preference
---------adequate
adequate
DC-Name
----------DC-1
DC-2
DC-Address
------------1.1.3.4
1.1.3.5
Status
------OK
OK

example.com
example.com
MS-DC
MS-DC
adequate
adequate
DC-1
DC-2
1.1.3.4
1.1.3.5
OK
OK
Related tasks
Resetting and rediscovering servers on page 174

Resetting and rediscovering servers
Resetting and rediscovering servers on your CIFS server allows the CIFS server to discard stored
information about LDAP servers and domain controllers. After discarding server information, the
CIFS server reacquires current information about these external servers. This can be useful when the
connected servers are not responding appropriately.
Steps

vserver cifs domain discovered-servers reset-servers -vserver
vserver_name
2. Display information about the newly rediscovered servers:

vserver cifs domain discovered-servers show -vserver vserver_name
Example
The following example resets and rediscovers servers for Vserver vs1:
cluster1::> vserver cifs domain discovered-servers reset-servers vserver vs1
cluster1::> vserver cifs domain discovered-servers show
Node: node1
Vserver: vs1
Domain Name
--------------------example.com
example.com
example.com
example.com
Type
Preference DC-Name
DC-Address
Status
-------- ---------- ----------- ------------MS-LDAP
MS-LDAP
MS-DC
MS-DC
adequate
adequate
adequate
adequate
DC-1
DC-2
DC-1
DC-2
Related tasks
Displaying information about discovered servers on page 173
1.1.3.4
1.1.3.5
1.1.3.4
1.1.3.5
OK
OK
OK
OK

Adding preferred domain controllers
Data ONTAP automatically discovers domain controllers through DNS. Optionally, you can add one
or more domain controllers to the list of preferred domain controllers for a specific domain.
Step
1. To add to the list of preferred domain controllers, enter the following command:
vserver cifs domain preferred-dc add -vserver virtual_server_name domain domain_name -preferred-dc IP_address, ...
-domain domain_name specifies the fully qualified Active Directory name of the CIFS domain.
-preferred-dc IP_address,... specifies one or more IP addresses of the preferred domain
controllers, as a comma-delimited list, in order of preference.

Example
The following command adds domain controllers 172.17.102.25 and 172.17.102.24 to the list
of preferred domain controllers that the CIFS server on Vserver vs1 uses to manage external
access to the cifs.lab.example.com domain.
cluster1::> vserver cifs domain preferred-dc add -vserver vs1 -domain
cifs.lab.example.com -preferred-dc 172.17.102.25,172.17.102.24
Related references
Commands for managing preferred domain controllers on page 175

Commands for managing preferred domain controllers
You need to know the commands for adding, displaying, and removing preferred domain controllers.
If you want to...
Use this command...
Add a preferred domain controller
vserver cifs domain preferred-dc add
Display preferred domain controllers
vserver cifs domain preferred-dc

show
Remove a preferred domain controller
vserver cifs domain preferred-dc

remove
Managing miscellaneous CIFS server tasks

You can manage miscellaneous CIFS server tasks, including terminating or restarting CIFS access to
CIFS servers, changing or resetting the domain account password, moving the CIFS server to a
different OU, displaying information about NetBIOS over TCP connections, modifying or displaying
information about CIFS servers, or deleting CIFS servers.
You can also configure the default UNIX user.
Configuring the default UNIX user
You can configure the default UNIX user to use if all other mapping attempts fail for a user, or if you
do not want to map individual users between UNIX and Windows. Alternatively, if you want
authentication of non-mapped users to fail, you should not configure the default user.
Step
1. Configure the default UNIX user:

vserver cifs options modify -default-unix-user user_name
Related concepts

115
Modifying protocols for Vservers
Before you can configure and use NFS or CIFS on Vservers, you must enable the protocol. This is
typically done during Vserver setup, but if you did not enable the protocol during setup, you can
enable it later by using the vserver modify command.
Steps
1. Check which protocols are currently enabled for a Vserver by entering the following command:
2. Modify the list of enabled protocols for a Vserver by entering the following command:
vserver modify vserver vserver_name -allowed-protocols
protocol_name[,protocol_name,...]
You must enter the complete list of protocols you want to be enabled on the Vserver, including
the protocols that are already enabled. Any protocol not specified with the command is
automatically disabled and moved to the disallowed protocol list.
You can also use the Vserver setup wizard to modify protocols for Vservers by using the
vserver setup command.

3. Confirm that the allowed protocol list was updated correctly by entering the following command:
Examples
The following command displays which protocols are currently enabled on a Vserver named
vs1.
vs1::> vserver show -vserver vs1 -fields allowed-protocols
vserver allowed-protocols
------- ----------------vs1
nfs
The following command adds CIFS to the list of enabled protocols on a Vserver named vs1.
vs1::> vserver modify -vserver vs1 -allowed-protocols nfs,cifs
Stopping or starting the CIFS server on a Vserver

You can stop the CIFS server, which can be useful when performing tasks while users are not
accessing data over SMB shares. You can restart SMB access by starting the CIFS server. By
stopping the CIFS server, you can also modify the protocols allowed on the Vserver to disallow SMB
access if desired.
About this task
Note: If you stop the CIFS server, established sessions are terminated and their open files are
closed. Workstations with cached data will not be able to save those changes, which could result in
data loss.
Steps

If you want to...
Stop the CIFS server vserver cifs stop -vserver vserver_name [-foreground
{true|false}]
Start the CIFS server vserver cifs start -vserver vserver_name [-foreground
{true|false}]
-foreground specifies whether the command should execute in the foreground or background.
If you do not enter this parameter, it is set to true, and the command is executed in the
foreground.

2. Verify that the CIFS server administrative status is correct by using the vserver cifs show
command.
Example
The following commands start the CIFS server on Vserver vs1:
cluster1::> vserver start -vserver vs1
cluster1::> vserver cifs show -vserver vs1
Vserver:
CIFS Server NetBIOS Name:
NetBIOS Domain/Workgroup Name:
Fully Qualified Domain Name:
Default Site Used by LIFs Without Site Membership:
Authentication Style:
CIFS Server Administrative Status:
vs1
VS1
DOMAIN
DOMAIN.LOCAL
domain
up
Related tasks
Displaying information about discovered servers on page 173

Resetting and rediscovering servers on page 174
Changing or resetting the domain account password
The CIFS server on a Vserver has an Active Directory domain account. You can change the
password for this account for good security practices, or reset it if the password is lost.
Step

If you...
Use the command...
Know the password and want to change it
vserver cifs password-change
Do not know the password and want to reset it
vserver cifs password-reset
Moving CIFS servers to different OUs
The CIFS server create-process uses the default organizational unit (OU) CN=Computers during
setup unless you specify a different OU. You can move CIFS servers to different OUs after setup.
Steps
1. On the Windows server, open the Active Directory Users and Computers tree.
2. Locate the Vservers Active Directory object.

3. Right-click the object and select Move.
4. Select the OU that you want to associate with the Vserver.
Result
The Vserver object is placed in the selected OU.

Displaying information about NetBIOS over TCP connections
You can display information about NetBIOS over TCP (NBT) connections. This can be useful when
troubleshooting NetBIOS-related issues.
Step
1. Use the vserver cifs nbtstat command to display information about NetBIOS over TCP
connections.
Note: NetBIOS name service (NBNS) over IPv6 is not supported.
Example
The following example shows the NetBIOS name service information displayed for
cluster1:
cluster1::> vserver cifs nbtstat
Vserver: vs1
Node:
cluster1-01
Interfaces:
10.10.10.32
10.10.10.33
Servers:
17.17.1.2 (active
NBT Scope:
[ ]
NBT Mode:
[h]
NBT Name
NetBIOS Suffix
----------- --------------CLUSTER_1
00
CLUSTER_1
20
Vserver: vs1
Node:
cluster1-02
Interfaces:
10.10.10.35
Servers:
17.17.1.2 (active
CLUSTER_1
00
CLUSTER_1
20
4 entries were displayed.
State
------wins
wins
Time Left
--------57
57
Type
-----
)
wins
wins
58
58
Commands for managing CIFS servers

You need to know the commands for creating, displaying, modifying, and deleting CIFS servers.
If you want to...
Use this command...
Create a CIFS server
vserver cifs create
Display information about a CIFS server
vserver cifs show
Modify a CIFS server
vserver cifs modify
Delete a CIFS server
vserver cifs delete
Related concepts
What happens to local users and groups when deleting CIFS servers on page 231
181
Setting up file access using SMB

You must complete a number of steps to allow clients access to files using SMB on a Vserver.
Configuring security styles

You configure security styles on volumes and qtrees to determine the type of permissions Data
ONTAP uses to control access and what client type can modify these permissions.
Configuring security styles on Vserver root volumes

You configure the Vserver root volume security style to determine the type of permissions used for
data on the root volume of a Vserver.
Steps

Create the Vserver with the... Specify the security style by...
vserver setup command
Entering the desired root volume security style when prompted by the
CLI wizard.
vserver create command Including the -rootvolume-security-style parameter with the

desired security style.
The possible options for the root volume security style are unix, ntfs, or mixed. You cannot
use unified security style because it only applies to Infinite Volumes.
For more information about the vserver setup or vserver create commands, see the
2. To display the configuration, including the security style of the Vserver you created, enter the
following command:
vserver show -vserver vserver_name
Configuring security styles on FlexVol volumes

You configure the FlexVol volume security style to determine the type of permissions used for data
on FlexVol volumes of a Vserver.
Steps

If the FlexVol volume... Use the command...
Does not yet exist
volume create and include the -security-style parameter to specify

the security style.
Already exists
volume modify and include the -security-style parameter to specify

the security style.
The possible options for the FlexVol volume security style are unix, ntfs, or mixed. You
cannot use unified security style because it only applies to Infinite Volumes.
If you do not specify a security style when creating a FlexVol volume, the default security style is
mixed.
For more information about the volume create or volume modifycommands, see the
2. To display the configuration, including the security style of the FlexVol volume you created,
enter the following command:
volume show -volume volume_name -instance
Configuring security styles on qtrees

You configure the qtree volume security style to determine the type of permissions used for data on
qtrees.
Steps

If the qtree...
Use the command...
Does not exist yet volume qtree create and include the -security-style parameter to
Already exists
volume qtree modify and include the -security-style parameter to

The possible options for the qtree security style are unix, ntfs, or mixed. You cannot use
unified security style because it only applies to Infinite Volumes.
If you do not specify a security style when creating a qtree, the default security style is mixed.
For more information about the volume qtree create or volume qtree modify
commands, see the Clustered Data ONTAP Logical Storage Management Guide.
2. To display the configuration, including the security style of the qtree you created, enter the
following command:
volume qtree show -qtree qtree_name -instance
Setting up file access using SMB | 183
Creating and managing data volumes and the NAS

namespace
To manage file access in a NAS environment, you must manage data volumes and junction points on
your Vserver with FlexVol volumes. This includes planning your namespace architecture, creating
volumes with or without junction points, mounting or unmounting volumes, and displaying
information about data volumes and NFS server or CIFS server namespaces.
Creating data volumes with specified junction points

You can specify the junction point when you create a data volume. The resultant volume is
automatically mounted at the junction point and is immediately available to configure for NAS
access.
Before you begin
Steps
1. Create the volume with a junction point by using the following command:
unix|mixed} -junction-path junction_path
The junction path must start with the root (/) and can contain both directories and junctioned
volumes. The junction path does not need to contain the name of the volume. Junction paths are
independent of the volume name.
applied to the data volume you create. The recommendation is to specify the security style when
you create the volume to minimize difficult-to-troubleshoot file-access issues.
2. Verify that the volume was created with the desired junction point:
Example
The following example creates a volume named home4 located on Vserver vs1 that has a
junction path /eng/home:

cluster1::> volume create -vserver vs1 -volume home4 -aggregate aggr1 -size
1g -junction-path /eng/home
cluster1::> volume show -vserver vs1 -volume home4 -junction
Junction
Junction
Vserver
Volume Active
Junction Path
Path Source
--------- ------- -------- --------------- ----------vs1
home4
true
/eng/home
RW_volume
Creating data volumes without specifying junction points

You can create a data volume without specifying a junction point. The resultant volume is not
automatically mounted, and is not available to configure for NAS access. You must mount the
volume before you can configure SMB shares or NFS exports for that volume.
Before you begin
Steps
1. Create the volume without a junction point by using the following command:
unix|mixed}
applied to the data volume. The recommendation is to specify the security style when you create
the volume to minimize difficult-to-troubleshoot file-access issues.
2. Verify that the volume was created without a junction point:
Example
The following example creates a volume named sales located on Vserver vs1 that is not
mounted at a junction point:
cluster1::> volume create -vserver vs1 -volume sales -aggregate aggr3 -size
20GB
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source

--------vs1
vs1
vs1
vs1
---------data
home4
vs1_root
sales
-------true
true
-
--------------/data
/eng/home
/
-
----------RW_volume
RW_volume
-
Mounting or unmounting existing volumes in the NAS namespace

A volume must be mounted on the NAS namespace before you can configure NAS client access to
data contained in the Vserver volumes. You can mount a volume to a junction point if it is not
currently mounted. You can also unmount volumes.
About this task
If you unmount a volume, all data within the junction point, including data in volumes with junction
points contained within the unmounted volume's namespace, are inaccessible to NAS clients. When
you unmount a volume, data within the volume is not lost. Additionally, existing volume export
policies and SMB shares created on the volume or on directories and junction points within the
unmounted volume are retained. If you remount the unmounted volume, NAS clients can access the
data contained within the volume using existing export policies and SMB shares.
Steps

If you want to...
Mount a volume
volume mount -vserver vserver_name -volume volume_name junction-path junction_path
Unmount a volume volume unmount -vserver vserver_name -volume volume_name
2. Verify that the volume is in the desired mount state:

Examples
The following example mounts a volume named sales located on Vserver vs1 to the junction
point /sales:
cluster1::> volume mount -vserver vs1 -volume sales -junction-path /sales
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
true
/data
RW_volume
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
true
/sales
RW_volume

The following example unmounts a volume named data located on Vserver vs1:
cluster1::> volume unmount -vserver vs1 -volume data
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source
--------- ---------- -------- --------------- ----------vs1
data
vs1
home4
true
/eng/home
RW_volume
vs1
vs1_root
/
vs1
sales
true
/sales
RW_volume
Displaying volume mount and junction point information

You can display information about a Vserver's mounted volumes and the junction points to which the
volumes are mounted. You can also determine which volumes are not mounted to a junction point.
You can use this information to understand and manage your Vserver namespace.
Step

Summary information about mounted volume show -vserver vserver_name -junction

Vserver
Detailed information about mounted
Vserver
volume show -vserver vserver_name -volume

volume_name -instance
Specific information about mounted

Vserver
a. If necessary, you can display valid fields for the -fields

parameter by using the following command:
volume show -fields ?
b. Display the desired information by using the -fields
parameter:
volume show -vserver vserver_name -fields
fieldname,...
Examples
The following example displays a summary of mounted and unmounted volumes on Vserver
vs1:
Junction
Junction
Vserver
Volume
Active
Junction Path
Path Source

--------vs1
vs1
vs1
vs1
---------data
home4
vs1_root
sales
-------true
true
true
--------------/data
/eng/home
/
/sales
----------RW_volume
RW_volume
RW_volume
The following example displays information about specified fields for volumes located on
Vserver vs2:
cluster1::> volume show -vserver vs2 -fields vserver,volume,aggregate,size,state,type,securitystyle,junction-path,junction-parent,node
vserver volume
aggregate size state type security-style junction-path junction-parent node
------- -------------- ---- ------ ---- -------------- ------------- --------------- ----vs2
data1
aggr3
2GB online RW
unix
node3
vs2
data2
aggr3
1GB online RW
ntfs
/data2
vs2_root
node3
vs2
data2_1 aggr3
8GB online RW
ntfs
/data2/d2_1
data2
node3
vs2
data2_2 aggr3
8GB online RW
ntfs
/data2/d2_2
data2
node3
vs2
pubs
aggr1
1GB online RW
unix
/publications vs2_root
node1
vs2
images
aggr3
2TB online RW
ntfs
/images
vs2_root
node3
vs2
logs
aggr1
1GB online RW
unix
/logs
vs2_root
node1
vs2
vs2_root aggr3
1GB online RW
ntfs
/
node3
Creating name mappings

Data ONTAP uses name mapping to map CIFS identities to UNIX identities when accessing data
contained on a Vserver using SMB connections. It needs this information to obtain user credentials
and provide proper file access regardless of whether the data is of NTFS security style, UNIX
security style, or unified security style.
Name mapping is usually required due to allow multiprotocol access over SMB and NFS to the same
files, regardless of the effective-security style applied to the requested files.
You do not have to use name mapping if you configure the default UNIX user to be used instead.
Related concepts
115
Related tasks
Name mapping conversion rules

A Data ONTAP system keeps a set of conversion rules for each Vserver. Each rule consists of two
pieces: a pattern and a replacement. Conversions start at the beginning of the appropriate list and
perform a substitution based on the first matching rule. The pattern is a UNIX-style regular
expression. The replacement is a string containing escape sequences representing subexpressions
from the pattern, as in the UNIX sed program.

It is possible to allow NFS access to volumes with NTFS security style for users in a different
domain from the one that the storage system belongs to, provided that the proper name mapping rule
exists.
If a user matches a rule to map to a user in a different domain, the domain must be trusted. To ensure
successful mapping to users in other domains for both CIFS and NFS access, there must be a
bidirectional trust relationship between the domains.
If a user matches a rule but the user cannot authenticate in the other domain because it is untrusted,
the mapping fails. In addition, there is no further processing of other mapping rules subsequent to the
failed one. Therefore, it is important to arrange name mapping rules in the right order so that rules for
other domains are evaluated before the rules for the domain of the Vserver.
Regular expressions are not case-sensitive when mapping from Windows to UNIX. However, they
are case-sensitive for Kerberos-to-UNIX and UNIX-to-Windows mappings.
As an example, the following rule converts the CIFS user named jones in the domain named
ENG into the UNIX user named jones.
Pattern
Replacement
ENG\\jones
jones
Note that the backslash is a special character in regular expressions and must be escaped with another
backslash.
The caret (^), underscore (_), and ampersand (&) characters can be used as prefixes for digits in
replacement patterns. These characters specify uppercase, lowercase, and initial-case
transformations, respectively. For instance:
If the initial pattern is (.+) and the replacement pattern is \1, then the string jOe is mapped to jOe
(no change).
If the initial pattern is (.+) and the replacement pattern is \_1, then the string jOe is mapped to joe.
If the initial pattern is (.+) and the replacement pattern is \^1, then the string jOe is mapped to
JOE.
If the initial pattern is (.+) and the replacement pattern is \&1, then the string jOe is mapped to
Joe.
If the character following a backslash-underscore (\_), backslash-caret (\^), or backslash-ampersand

(\&) sequence is not a digit, then the character following the backslash is used verbatim.
The following example converts any Windows user in the CIFS domain named ENG into a UNIX
user with the same name in NIS.
Pattern
Replacement
ENG\$.+)
\1
The double backslash (\$ matches a single backslash. The parentheses denote a subexpression but do
not match any characters themselves. The period matches any single character. The asterisk matches

zero or more of the previous expression. In this example, you are matching ENG\ followed by one or
more of any character. In the replacement, \1 refers to whatever the first subexpression matched.
Assuming the CIFS user ENG\jones, the replacement evaluates to jones; that is, the portion of the
name following ENG\.
Note: If you are using the CLI, you must delimit all regular expressions with double quotation
marks ("). For instance, to enter the regular expression (.+) in the CLI, type "(.+)" at the command
prompt. Quotation marks are not required in the Web UI.
For further information about regular expressions, see your UNIX system administration
documentation, the online UNIX documentation for sed or regex, or Mastering Regular
Expressions, published by O'Reilly and Associates.
Creating a name mapping

You can use the vserver name-mapping create command to create a name mapping. You use
name mappings to enable Windows users to access UNIX security style volumes and the reverse.
About this task
For each Vserver, Data ONTAP supports up to 1,024 name mappings for each direction.
Step
1. To create a name mapping, enter the following command:

vserver name-mapping create -vserver virtual_server_name -direction
{krb-unix|win-unix|unix-win} -position integer -pattern text replacement text
-direction {krb-unix|win-unix|unix-win} specifies the mapping direction.
-position integer specifies the desired position in the priority list of a new mapping.
-pattern text specifies the pattern to be matched, up to 256 characters in length.
-replacement text specifies the replacement pattern, up to 256 characters in length.
When Windows-to-UNIX mappings are created, any CIFS clients that have open connections to
the Data ONTAP system at the time the new mappings are created must log out and log back in to
see the new mappings.
Examples
The following command creates a name mapping on a Vserver named vs1. The mapping is a
mapping from UNIX to Windows at position 1 in the priority list. The mapping maps the
UNIX user johnd to the Windows user ENG\John.

vs1::> vserver name-mapping create -vserver vs1 -direction unix-win
-position 1 -pattern johnd -replacement "ENG\\John"
The following command creates another name mapping on a Vserver named vs1. The mapping
is a mapping from Windows to UNIX at position 1 in the priority list. The mapping maps
every CIFS user in the domain ENG to users in the NIS domain associated with the Vserver.
vs1::> vserver name-mapping create -vserver vs1 -direction win-unix
-position 1 -pattern "ENG\\(.+)"
-replacement "\1"
Commands for managing name mappings

There are specific Data ONTAP commands for managing name mappings.
If you want to...
Use this command...
Create a name mapping
vserver name-mapping create
Insert a name mapping at a specific position
vserver name-mapping insert
Display name mappings
vserver name-mapping show
Exchange the position of two name mappings
vserver name-mapping swap
Modify a name mapping
vserver name-mapping modify
Delete a name mapping
vserver name-mapping delete
Creating and configuring SMB shares

Before users and applications can access data on the CIFS server over SMB, you must create and
configure SMB shares, which is a named access point in a volume. When you create a share, you can
customize the share by specifying share properties. If you want to change an existing share's
properties, you can modify share properties at any time.
When you create an SMB share, Data ONTAP creates a default ACL for the share with Full Control
permissions for Everyone.
SMB shares are tied to the Vserver's CIFS server. SMB shares are deleted if either the Vserver is
deleted or the CIFS server with which it is associated is deleted from the Vserver. If you re-create the
CIFS server on the Vserver, you must re-create the CIFS shares.

Related concepts
Managing file access using SMB on page 228

Share naming considerations

You should keep Data ONTAP share naming considerations in mind when creating shares on your
CIFS Vserver.
Share naming conventions for Data ONTAP are the same as for Windows. Keep the following in
mind when naming shares:
The name of each share must be unique for the Vserver.

Share names are not case-sensitive.
The maximum share name length is 80 characters.
Unicode share names are supported.
Share names ending with the $ character are hidden shares.
The ADMIN$ and IPC$ administrative shares are automatically created on every CIFS Vserver
and are reserved share names.
You cannot use the share name ONTAP_ADMIN$ when creating a share.
Share names containing spaces are supported:
You cannot use a space as the first character or as the last character in a share name.
You must enclose share names containing a space in quotation marks.
Note: Single quotation marks are considered part of the share name and cannot be used in
place of quotation marks.
The following characters are supported when you name CIFS shares: !, @ #, $, %,
&, ', _, -, ., ~, (, ), {, }.
The following characters are not supported when you name CIFS shares: +, [ ], ", /,
\, :, ;, |, <, >, ,, ?, *, =.
Related concepts
Information you need when creating SMB shares on page 192
Non-Unicode clients not supported

Clustered Data ONTAP only supports Unicode clients when accessing data using CIFS.
Note: Because of a limitation, older Macintosh clients running versions Tiger (Mac OS X 10.4.11)
and Leopard (Mac OS X 10.5.8) do not fully support Unicode in SMB requests; therefore, they are
not supported with Data ONTAP 8.2 or later. To use Macintosh clients when mounting shares with
SMB, they must be upgraded to Snow Leopard (Mac OS X 10.6) or later.
Elimination of execute permission requirements on share paths

For versions of Data ONTAP earlier than 8.1.2, if the root of the name space and any contained path
components, including junction points, does not allow execute access for a user accessing a folder
through a CIFS share, access might be denied. Starting with Data ONTAP 8.1.2 and later releases,
this restriction is eliminated.
Data ONTAP supports a unified namespace for NAS. A NAS namespace consists of the root of the
Vserver namespace and FlexVol volumes that are joined together with junctions that present as a
hierarchy of subdirectories below the root. This namespace hierarchy presents to the clients as a
single CIFS share. In essence, junctions stitch together volumes to create a single large file structure.
CIFS clients can access the namespace by mapping to the root of the namespace, thus providing
access to all the volumes beneath it through the Vserver's data LIFs. Alternatively, clients can also
access contained flexible volumes by mounting or mapping at the volume junction points or by
mapping using a path to a directory within the namespace, which provides alternative routes to
access data contained within the junctioned volumes.
In versions earlier than Data ONTAP 8.1.2, CIFS access issues might occur where the root of the
namespace or any component in the path to the folder being accessed has an effective UNIX security
style (a UNIX security-style volume or a mixed security-style volume with a UNIX effective
security). Access issues can occur because of the requirement that the mapped UNIX user must have
execute permissions on the namespace root and on any path component that is of UNIX security style
(either through the owner, group, or other mode bits or through NFSv4 ACLs). This is a requirement,
irrespective of the share location within the namespace hierarchy. This requirement does not apply if
all volumes including the root of the namespace and all LS mirrors are of NTFS security style.
For example, consider the path /unix1/dir1/dir2/ntfs1/, in which unix1 is a UNIX securitystyle volume, ntfs1 is an NTFS security-style volume, and dir1 and dir2 are regular directories.
In versions of Data ONTAP earlier than 8.1.2, a user must have execute permissions on unix1,
dir1, and dir2 to map a share that points to the path.
Starting with Data ONTAP 8.1.2 and later, this restriction is eliminated. Execute permissions are not
required for the mapped UNIX user to access data over CIFS shares. This is true regardless of
security style for the namespace root, any directory component within the path, or any junctioned
volumes.
Be aware that after upgrading to Data ONTAP 8.1.2 or later from a version of Data ONTAP earlier
than 8.1.2, effective access permissions might change as a result of eliminating this requirement. If
you are using the execute permission requirement as a way to restrict CIFS access, you might need to
adjust your share or file permissions to apply the desired access restrictions.
Information you need when creating SMB shares

You should be aware of what information you need before creating SMB shares. There are certain
required parameters that you must supply when you create SMB shares and certain choices about
share parameters and share properties that you must make.
When you create a share, you must provide all of the following information:
The name of the Vserver on which to create the share

The complete path in a volume to the SMB share, beginning with the junction path to the volume
The name of the share entered by users when they connect to the share
When you create a share, you can optionally specify a description for the share. The share description
appears in the Comment field when you browse the shares on the network.
You can specify the following optional share parameters:
Whether support for symlinks and widelinks in the share is allowed

Whether a custom UNIX umask is configured for new files configured on the share
Whether a custom UNIX umask is configured for new directories configured on the share
Whether a custom attribute cache lifetime is configured for the attribute cache
This share setting is useful only if the attribute cache share property is set.
Whether to configure offline files, and if so, which offline file setting to specify
You can specify the following optional share properties:
Whether the share is a home directory share

Whether the share supports opportunistic locks
Whether the share is browsable
Whether the share shows Snapshot copies
Whether the share supports change notification
Whether metadata caching is enabled for the share
Whether the share is a continuously available share
Whether the share allows clients to request BranchCache hashes on the files within the share
Whether the share supports access-based enumeration
Related concepts
Share naming considerations on page 191
Creating an SMB share on a CIFS server

You must create an SMB share before you can share data on a CIFS server with SMB clients. When
you create a share, you can customize the share by configuring optional settings such as specifying
how symlinks are presented to clients. You can also set share properties when creating the share.
Steps
1. If necessary, create the directory path structure for the share.

You must create the directory path structure specified by the -path option in the vserver cifs
share create command before creating your share. The vserver cifs share create
command checks the path specified in the -path option during share creation. If the specified
path does not exist, the command fails.
2. Create a SMB share on a Vserver's CIFS server by entering the following command:

vserver cifs share create -vserver vserver_name -share-name share_name
path path [-share-properties share_properties,...] [-symlink-properties
{enable|hide|read_only},...] [-file-umask octal_integer] [-dir-umask
octal_integer] [-comment text] [-attribute-cache-ttl [integerh]|
[integerm]|[integers]] [-offline-files {none|manual|documents|programs}]
-vserver vserver_name specifies the CIFS-enabled Vserver on which to create the share.
-share-name share_name specifies the name of the new SMB share.
-path path specifies the directory path to the SMB share.
This path must exist. A directory path name can be up to 255 characters long. If there is a space in
the path name, the entire string must be quoted (for example, "/new volume/mount here"). If this
is a home directory share as specified by the value of home directory on the -shareproperties parameter, you can make the share name dynamic by specifying the %w (Windows
user name), %u (UNIX user name), %d (domain name) variables, or any of their combinations as a
part of the value of this parameter.
-share-properties share_properties specifies an optional list of properties for the share.
The default initial property for all shares on FlexVol volumes are oplocks, changenotify, and
browsable. It is optional to specify them when you create a share. For a Vserver with Infinite
Volume, the default initial properties are oplocks and browsable.
The list of share properties can include one or more of the following:
homedirectory
The Data ONTAP CIFS home directory feature enables you to configure a share that maps to
different directories based on the user that connects to it and a set of variables. Instead of
having to create separate shares for each user, you can configure a single share with a few
home directory parameters to define a user's relationship between an entry point (the share)
and their home directory (a directory on the Vserver).
Note: This property cannot be added or removed after share creation.
oplocks
This specifies that the share uses opportunistic locks, also known as client-side caching.
Oplocks are enabled on shares by default; however, some applications do not work well when
oplocks are enabled. In particular, database applications such as Microsoft Access are
vulnerable to corruption when oplocks are enabled. An advantage of shares is that a single
path can be shared multiple times, with each share having different properties. For instance, if
a path named /dept/finance contains both a database and other types of files, you can
create two shares to it, one with oplocks disabled for safe database access and one with
oplocks enabled for client-side caching.
browsable
This specifies that the share can be browsed by Windows clients.
showsnapshot
This specifies that Snapshot copies can be viewed and traversed by clients.
changenotify

This specifies that the share supports Change Notify requests. For shares on a Vserver with
FlexVol volumes, this is a default initial property. For shares on a Vserver with Infinite
Volume, the changenotify property is not set by default, and setting it requires the
advanced privilege level. When the changenotify property is set for a share on a Vserver
with Infinite Volume, change notifications are not sent for changes to file attributes and time
stamps.
attributecache
This specifies that file attribute caching on the SMB share is enabled to provide faster access
of attributes.
continuously-available
This specifies that SMB 3.0 and later clients that support it are permitted to open files in a
persistent manner. Files opened this way are protected from disruptive events, such as failover
and giveback. This option is not supported for Vservers with Infinite Volume.
branchcache
This specifies that the share allows clients to request BranchCache hashes on the files within
this share. This option is effective only if you specify per-share as the operating mode in
the CIFS BranchCache configuration, and also specify oplocks in the list of share properties.
This option is not supported for Vservers with Infinite Volume.
access-based-enumeration
This specifies that Access Based Enumeration is enabled on this share. ABE-filtered shared
folders are visible to a user based on that individual user's access rights, preventing the display
of folders or other shared resources that the user does not have rights to access.
-symlink-properties share_symlink_property specifies how UNIX symbolic links
(symlinks) are presented to SMB clients. You can specify one of the following values:
enabled
This setting specifies that symlinks are enabled for read-write access
read_only
This setting specifies that symlinks are enabled for read-only access
hide
This setting specifies that SMB clients are prevented from seeing symlinks
Note: To disable symlinks, specify the value as "" or "-".
-file-umask octal_integer specifies the default UNIX umask for new files created on the
share. If not specified, the umask defaults to 022.

-dir-umask octal_integer specifies the default UNIX umask for new directories created on
the share. If not specified, the umask defaults to 000.

Note: Accessing an existing directory or file through multiple SMB shares that have different
values for the -file-umask and -dir-umask parameters returns consistent permissions and
access rights. For instance, assume you have a share named share1 that has a file umask of
000 and a share named share2 that has a file umask of 022, and that these shares overlap
(that is, can access the same directories). If you create a file named \\server\share1\abc,

the umask for that file is 000. If you create a file named \\server\share2\123, the umask
for that file is 022.
-comment text specifies a text description of the share. The description can be up to 255
characters long. If there is a space in the description, the entire string must be quoted (for
example, "This is engineering's share.").
-attribute-cache-ttl time_interval specifies the lifetime for the attribute cache share
property. Specifying this option is useful only if you specify attributecache as a value of the
-share-properties parameter.
-offline-files specifies the caching behavior of Windows clients when accessing data from
the share. The value can be one of following:
none
This setting disallows Windows clients from caching any files on this share
manual
This setting allows users on Windows clients to manually select files to be cached
documents
This setting allows Windows clients to cache user documents that are used by the user for
offline access
programs
This setting allows Windows clients to cache programs that are used by the user for offline
access. A user can use those files in an offline mode even if the share is available.
Examples
The following command creates a SMB share named SHARE1 on Vserver vs1. Its
directory path is /u/eng. Oplocks and browsability are specified on the share, and the UNIX
umask is explicitly set as 022 on files and 000 on directories.
cluster1::> vserver cifs share create -vserver vs1 -share-name
SHARE1 -path /u/eng -share-properties browsable,oplocks -file-umask
022 -dir-umask 000
The following command creates a SMB share named DOCUMENTS on a Vserver vs1.
The path to the share is /documents. The share uses opportunistic locks (client-side caching),
a notification is generated when a change occurs, and the share allows clients to cache user
documents on this share.
cluster1::> vserver cifs share create -vserver vs1 -share-name
DOCUMENTS -path /documents -share-properties changenotify,oplocks offline-files documents

Related concepts
Share naming considerations on page 191

Related tasks
Displaying CIFS session information on page 326

Displaying information about open CIFS files on page 329
Adding or removing share properties on an existing share

You can customize an existing share by adding or removing share properties. This can be useful if
you want to change the share configuration to meet changing requirements in your environment.
Before you begin
The share whose properties you want to modify must exist.

About this task
You need to keep the following in mind when adding share properties:
You can add one or more share properties by using a comma-delimited list.
Any share properties that you have previously specified remain in effect.
Newly added properties are appended to the existing list of share properties.
If you specify a new value for share properties that are already applied to the share, the newly
specified value replaces the original value.
You cannot remove share properties by using the vserver cifs share properties add
command.
You can use the vserver cifs share properties remove command to remove share
properties.
You need to keep the following in mind when removing share properties:
You can remove one or more share properties by using a comma-delimited list.
Any share properties that you have previously specified but do not remove, remain in effect.
Steps
1. Enter the appropriate command:

If you want to...
Add share properties
vserver cifs share properties add -vserver

vserver_name -share-name share_name -share-properties
properties,...
Remove share properties vserver cifs share properties remove -vserver

vserver_name -share-name share_name -share-properties
properties,...
vserver_name specifies the name of the Vserver that contains the share whose properties you
want to modify.
share_name is the name of the share whose properties you want to modify.
properties is the list of share properties you want to add or remove. The available share
properties are as follows:

Share properties
Description
oplocks
This property specifies that the share uses opportunistic locks, also
known as client-side caching.
browsable
This property allows Windows clients to browse the share.
showsnapshot
This property specifies that Snapshot copies can be viewed and

traversed by clients.
changenotify
This property specifies that the share supports Change Notify

requests. For shares on a Vserver with FlexVol volumes, this is a
default initial property. For shares on a Vserver with Infinite
Volume, the changenotify property is not set by default, and
setting it requires the advanced privilege level. When the
changenotify property is set for a share on a Vserver with Infinite
Volume, change notifications are not sent for changes to file
attributes and time stamps.
attributecache
This property enables the file attribute caching on the CIFS share to
provide faster access of attributes.
continuouslyavailable
This property permits SMB clients that support it to open files in a

persistent manner. Files opened this way are protected from
disruptive events, such as failover and giveback.
branchcache
This property specifies that the share allows clients to request

BranchCache hashes on the files within this share. This option is
useful only if you specify per-share as the operating mode in the
CIFS BranchCache configuration, and also specify the oplocks
share property.

Share properties
Description
access-basedenumeration
This specifies that Access Based Enumeration is enabled on this

share. ABE-filtered shared folders are visible to a user based on that
individual user's access rights, preventing the display of folders or
other shared resources that the user does not have rights to access.
See the vserver cifs share properties add and vserver cifs share properties
remove man pages for more information.
2. Verify the share property settings:
vserver cifs share show -vserver vserver_name -share-name share_name
Examples
The following example adds the showsnapshot share property to a share named share1 on
Vserver vs1:
share1 -share-properties showsnapshot
cluster1::> vserver cifs share show -vserver vs1 -share-name share1
Vserver
Share
Path
Properties
Comment
ACL
--------- ------ -------- --------------------------vs1
share1 /share1
oplocks
Everyone /
browsable
Full
changenotify
Control
showsnapshot
The following example removes the browsable share property from a share named share2
on Vserver vs1:
share2 -share-properties browsable
cluster1::> vserver cifs share show -vserver vs1 -share-name share2
Vserver
Share
Path
Properties
Comment
ACL
--------- ------ -------- --------------------------vs1
share2 /share2
oplocks
Everyone /
changenotify
Full
Control
Related tasks

Related references
Commands for managing CIFS shares on page 200
Commands for managing CIFS shares

You use the vserver cifs share commands to manage CIFS shares.
If you want to...
Use this command...
Create a CIFS share
vserver cifs share create
Display CIFS shares
vserver cifs share show
Modify a CIFS share
vserver cifs share modify
Delete a CIFS share
vserver cifs share delete
Note: You cannot modify the homedirectory share property on the admin$ administrative share.
You cannot modify any of the share properties on the ipc$ administrative share.
Securing file access by using SMB share ACLs

You can secure access to files and folders over a network by configuring share access control lists
(ACLs) on SMB shares. Share-level ACLs are used in combination with file-level permissions and,
optionally, export policies to determine effective access rights.
You can use either domain or local users or groups when configuring ACLs.
Related concepts
Displaying information about file security and audit policy on FlexVol volumes on page 257
Related tasks
Creating SMB share access control lists on page 201

Performing security traces on page 307
How Data ONTAP uses share-level ACLs

When an SMB user tries to access a share, Data ONTAP always checks the share-level ACL (access
control list) to determine whether access should be granted, regardless of the security style of the
volume or qtree containing the share.
A share-level ACL consists of a list of access control entries (ACEs). Each ACE contains a user or
group name and a set of permissions that determines user or group access to the share.

A share-level ACL only restricts access to files in the share; it never grants more access than the filelevel ACLs.
Creating SMB share access control lists

Creating access control lists for SMB shares enables you to control the level of access to a share for
users and groups.
Steps
1. Use the vserver cifs share access-control create command to create an access
control list for a SMB share.
2. Verify that the ACL applied to the share are correct by using the vserver cifs share
access-control show command.
The following command gives Change permissions to the group named salesteam for the
share sales on a Vserver named vs1:
cluster1::> vserver cifs share access-control create -vserver vs1 -share
sales -user-or-group salesteam -permission Change
cluster1::> vserver cifs share access-control show
Share
User/Group
Vserver
Name
Name
-------------- ----------- --------------------------vs1
sales
salesteam
Access
Permission
----------Change
Commands for managing SMB share access control lists

You need to know the commands for managing SMB access control lists (ACLs), which includes
creating, displaying, modifying, and deleting them.
If you want to...
Use this command...
Create a new ACL
vserver cifs share access-control create
Display ACLs
vserver cifs share access-control show
Modify an ACL
vserver cifs share access-control modify
Delete an ACL
vserver cifs share access-control delete
Securing file access by using file permissions

You can secure access by configuring file permissions on files and folders contained within the share
through which SMB clients access data on the Vserver. File-level permissions are used in

combination with share-level ACLs and, optionally, export policies to determine effective access
rights. Files and folders might be secured with NTFS permissions or UNIX permissions.
If files and folders are secured with UNIX file permissions, then the mapped UNIX user and the
UNIX user's groups are used to evaluate file permissions.
Related concepts

Configuring standard NTFS file permissions by using the Windows

Security tab
You can configure standard NTFS file permissions on files and directories by using the Windows
Security tab in the Windows Properties window. This is the same method used when configuring
standard file permissions on data residing on a Windows client.
Before you begin
The administrator performing this task must have sufficient NTFS permissions to change permissions
on the selected objects.
About this task
Configuring NTFS file permissions is done by adding entries to NTFS discretionary access control
lists (DACLs) that are associated with an NTFS security descriptor. The security descriptor is then
applied to NTFS files and directories. These tasks are automatically handled by the Windows GUI.
The security descriptor can contain DACLs for applying file and folder access permissions, security
access control lists (SACLs) for file and folder auditing, or both SACLs and DACLs.
You can set standard NTFS file permissions for file and folder access by completing the following
steps on a Windows host:
Steps
1. From the Tools menu in Windows Explorer, select Map network drive.
2. Complete the Map Network Drive box:
a) Select a Drive letter.
b) In the Folder box, type the IP address or CIFS server name of the Vserver containing the
share that contains the data you want to audit and the name of the share.
Example
If your CIFS server name is CIFS_SERVER and your share is named share1, you would
enter \\CIFS_SERVER\share1.

Note: You can specify the IP address of the data interface for the CIFS server instead of the
CIFS server name.

c) Click Finish.
The drive you selected is mounted and ready with the Windows Explorer window displaying files
and folders contained within the share.
3. Select the file or directory for which you want to set NTFS file permissions.
4. Right-click the file or directory, and then select Properties.
5. Select the Security tab.
The Security tab displays the list of users and groups for which NTFS permission are set. The
Permissions for <Object> box displays a list of Allow and Deny permissions in effect for the
selected user or group.
6. Click Edit.
The Permissions for <Object> box opens.
7. Perform the desired actions:
If you want to....
Do the following...
Set standard NTFS permissions

for a new user or group
a. Click Add.
The Select User, Computers, Service Accounts, or Groups
window opens.
b. In the Enter the object names to select box, type the name of the
user or group on which you want to add NTFS permission.
c. Click OK.
Change or remove standard NTFS In the Group or user names box, select the user or group that you
permissions from a user or group want to change or remove.

If you want to...
Do the following
Set standard NTFS permissions for a new In the Permissions for <Object> box, select the Allow or
or existing user or group
Deny boxes for the type of access that you want to allow or not
allow for the selected user or group.
Remove a user or group
Click Remove.
Standard permissions are compilations of the more granular advanced access rights. You can set
the following types of standard permissions:
Full control
Modify
Read & Execute
List folder contents
Read
Write
Note: If some or all of the standard permission boxes are not selectable, it is because the
permissions are inherited from the parent object. The Special permissions box is not
selectable. If it is selected, it means that one or more of the granular advanced rights has been
set for the selected user or group.
9. After you finish adding, removing, or editing NTFS permissions on that object, click OK.
For more information about how to set standard NTFS permissions, see your Windows
documentation.
Related concepts
Managing NTFS file security and audit policies on Vservers with FlexVol volumes using the CLI
on page 274
Related tasks
Configuring advanced NTFS file permissions using the Windows Security

tab
You can configure standard NTFS file permissions on files and directories by using the Windows
Security tab in the Windows Properties window.
Before you begin
The administrator performing this task must have sufficient NTFS permissions to change permissions
on the selected objects.
About this task
Configuring NTFS file permissions is done on a Windows host by adding entries to NTFS
discretionary access control lists (DACLs) that are associated with an NTFS security descriptor. The
security descriptor is then applied to NTFS files and directories. These tasks are automatically
handled by the Windows GUI.
Steps
2. Complete the Map Network Drive dialog box:
b) In the Folder box, type the CIFS server name containing the share that contains the data you
want to audit and the name of the share.

Example
If your CIFS server name is CIFS_SERVER and your share is named share1, you should
type \\CIFS_SERVER\share1.
CIFS server name.
c) Click Finish.
3. Select the file or directory for which you want to set NTFS file permissions.
4. Right-click the file or directory, and then select Properties.
The Security tab displays the list of users and groups for which NTFS permission are set. The
Permissions for box displays a list of Allow and Deny permissions in effect for each user or
group selected.
6. Click Advanced.
The Windows Properties window displays information about existing file permissions assigned to
users and groups.
7. Click Change Permissions.
The Permissions window opens.
If you want to...
Do the following...
Set up advanced NTFS permissions a. Click Add.

for a new user or group
b. In the Enter the object name to select box, type the name of the
user or group that you want to add.
c. Click OK.
Change advanced NTFS
permissions from a user or group
a. In the Permissions entries: box, select the user or group whose

advanced permissions you want to change.
b. Click Edit.
Remove advanced NTFS

permissions for a user or group
a. In the Permissions entries: box, select the user or group that

you want to remove.
b. Click Remove.
c. Skip to Step 13.

If you are adding advanced NTFS permissions on a new user or group or changing NTFS
advanced permissions on an existing user or group, the Permission Entry for <Object> box opens.
9. In the Apply to box, select how you want to apply this NTFS file permission entry.
You can select one of the following:
This folder, subfolders and files

This folder and subfolders
This folder only
This folder and files
Subfolders and files only
Subfolders only
Files only
If you are setting up NTFS file permissions on a single file, the Apply to box is not active. The
Apply to setting defaults to This object only.
10. In the Permissions box, select the Allow or Deny boxes for the advanced permissions that you
want to set on this object.
To allow the specified access, select the Allow box.

To not allow the specified access, select the Deny box.
You can set permissions on the following advanced rights:
Full control
If you choose this advanced right, all other advanced rights are automatically chosen (either
Allow or Deny rights).
Traverse folder / execute file
List folder / read data
Read attributes
Read extended attributes
Create files / write data
Create folders / append data
Write attributes
Write extended attributes
Delete subfolders and files
Delete
Read permissions
Change permissions
Take ownership
Note: If any of the advanced permission boxes are not selectable, it is because the permissions
are inherited from the parent object.

11. If you want subfolders and files of this object to inherit these permissions, select the Apply these
permissions to objects and/or containers within this container only box.

12. Click OK.
13. After you finish adding, removing, or editing NTFS permissions, specify the inheritance setting
for this object:
Select the Include inheritable permissions from this object's parent box.
This is the default.
Select the Replace all child object permissions with inheritable permissions from this
object box.
This setting is not present in the Permissions box if you are setting NTFS file permissions on a
single file.
Note: Be cautious when selecting this setting. This setting removes all existing permissions
on all child objects and replaces them with this object's permission settings. You could
inadvertently remove permissions that you did not want removed. It is especially important
when setting permissions in a mixed security-style volume or qtree. If child objects have a
UNIX-effective security style, propagating NTFS permissions to those child objects results
in Data ONTAP changing these objects from UNIX security style to NTFS security style,
and all UNIX permissions on those child objects are replaced with NTFS permissions.
Select both boxes.

Select neither box.
14. Click OK to close the Permissions box.

15. Click OK to close the Advanced Security settings for <Object> box.
For more information about how to set advanced NTFS permissions, see your Windows
documentation.
Related concepts
on page 274
How to configure NTFS file permissions using the Data ONTAP CLI
You can configure NTFS file permissions on files and directories using the Data ONTAP CLI. This
enables you to configure NTFS file permissions without needing to connect to the data using an SMB
share on a Windows Client.
You can configure NTFS file permissions by adding entries to NTFS discretionary access control
lists (DACLs) that are associated with an NTFS security descriptor. The security descriptor is then
applied to NTFS files and directories.
You can only configure NTFS file permissions using the command line. You cannot configure
NFSv4 ACLs by using the CLI.

Related concepts
on page 274
How UNIX file permissions provide access control when accessing files
over SMB
A FlexVol volume can have one of three types of security style: NTFS, UNIX, or mixed. You can
access data over SMB regardless of security style; however, appropriate UNIX file permissions are
needed to access data with UNIX effective security.
When data is accessed over SMB, there are several access controls used when determining whether a
user is authorized to perform a requested action:
Export permissions
Configuring export permissions for SMB access is optional in Data ONTAP 8.2 and later
releases.
Share permissions
File permissions
The following types of file permissions might be applied to the data on which the user wants to
perform an action:
NTFS
UNIX NFSv4 ACLs
UNIX mode bits
For data with NFSv4 ACLs or UNIX mode bits set, UNIX style permissions are used to determine
file permissions. The Vserver administrator needs to set the appropriate file permission to ensure that
users have the rights to perform the desired action.
Note: Data in a mixed security-style volume might have either NTFS or UNIX effective security
style. If the data has UNIX effective security style, then NFSv4 permissions or UNIX mode bits
are used when determining file access rights to the data.
Securing SMB access using export policies

You can optionally use export policies to restrict SMB access to files and folders on the Vserver's
volumes to specific clients. You can use export policies in combination with share-level ACLs and
file-level permissions to determine effective access rights.
Related concepts
Role export policies play with SMB access on page 115

How export policies are used with SMB access

If export policies for SMB access is enabled on the CIFS server, export policies are used when
controlling access to Vserver volumes by SMB clients. To access data in a Vserver using SMB, you
can create an export policy that allows SMB access and then associate the policy with the volumes
containing SMB shares.
An export policy has one or more rules applied to it that specifies which clients are allowed access to
the data and what authentication protocols are supported for read-only and read-write access. You
can configure export policies to allow access over SMB to all clients, a subnet of clients, or a specific
client and to allow authentication using Kerberos authentication, NTLM authentication, or both
Kerberos and NTLM authentication when determining read-only and read-write access to data.
After processing all export rules applied to the export policy, Data ONTAP can determine whether
the client is granted access and what level of access is granted. Export rules apply to client machines,
not to Windows users and groups. Export rules do not replace Windows user and group-based
authentication and authorization. Export rules provide another layer of access security in addition to
share and file-access permissions.
You associate exactly one export policy with each volume to configure client access to the volume. A
Vserver can contain multiple export policies. This enables you to do the following for Vservers with
multiple volumes:
Assign different export policies to each volume of a Vserver for individual client access control
to each volume in the Vserver.
Assign the same export policy to multiple volumes of a Vserver for identical client access control
without having to create a new export policy for each volume.
Each Vserver has at least one export policy called default, which contains no rules. You cannot
delete this export policy, but you can rename or modify it. Each volume on a Vserver by default is
associated with the default export policy. If export policies for SMB access is disabled on the
Vserver, the default export policy has no effect on SMB access.
You can configure rules that provide access to both NFS and SMB hosts and associate that rule with
an export policy, which can then be associated with the volume that contains data to which both NFS
and SMB hosts need access. Alternatively, if there are some volumes where only SMB clients require
access, you can configure an export policy with rules that only allow access using the SMB protocol
and that uses only Kerberos or NTLM (or both) for authentication for read-only and write access.
The export policy is then associated to the volumes where only SMB access is desired.
If export policies for SMB is enabled and a client makes an access request that is not permitted by the
applicable export policy, the request fails with a permission-denied message. If a client does not
match any rule in the volume's export policy, then access is denied. If an export policy is empty, then
all accesses are implicitly denied. This is true even if the share and file permissions would otherwise
permit access. This means that you must configure your export policy to minimally allow the
following on volumes containing SMB shares:
Allow access to all clients or the appropriate subset of clients

Allow access over SMB
Allow appropriate read-only and write access by using Kerberos or NTLM authentication (or
both)
Related concepts
What happens to existing SMB export policies when upgrading on page 210
Related tasks
Enabling or disabling export policies for SMB access on page 211

Adding an SMB access rule to an export policy on page 220
Default export policy for a Vserver with FlexVol volume

Each Vserver with FlexVol volume has a default export policy that contains no rules. An export
policy with rules must exist before clients can access data on the Vserver, and each FlexVol volume
contained in the Vserver must be associated with an export policy.
When you create a Vserver with FlexVol volume, the storage system automatically creates a default
export policy called default for the root volume of the Vserver. You must create one or more rules
for the default export policy before clients can access data on the Vserver. Alternatively, you can
create a custom export policy with rules. You can modify and rename the default export policy, but
you cannot delete the default export policy.
When you create a FlexVol volume in its containing Vserver with FlexVol volume, the storage
system creates the volume and associates the volume with the default export policy for the root
volume of the Vserver. By default, each volume created in the Vserver is associated with the default
export policy for the root volume. You can use the default export policy for all volumes contained in
the Vserver, or you can create a unique export policy for each volume. You can associate multiple
volumes with the same export policy.
What happens to existing SMB export policies when upgrading

For releases earlier than Data ONTAP 8.2, SMB export policies are mandatory. Starting with Data
ONTAP 8.2, export policies for SMB access are optional and are disabled by default. You need to be
aware of what happens when upgrading from releases where export policies are mandatory.
If you upgrade from a version of Data ONTAP where configured export policies were mandatory for
SMB access and the cluster contains Vservers with CIFS servers, support for export policies is
enabled for those Vservers after the upgrade. You do not need to reconfigure SMB access for
existing CIFS servers when upgrading.
If you create a new Vserver and CIFS server on the upgraded cluster, export policies for the new
CIFS server are disabled by default. You can enable and configure export policies on the new CIFS
servers if desired.
Enabling or disabling export policies for SMB access

You can enable or disable export policies for SMB access on Vservers with FlexVol volumes and
Vservers with Infinite Volumes. Using export policies to control SMB access to resources is optional
for Data ONTAP 8.2 and later.
About this task
Starting with Data ONTAP 8.2, a new option controls whether export policies are enabled for SMB
access. When setting up a new CIFS server on your Vserver, the usage of export policies for SMB
access is disabled by default. You can enable export policies for SMB access if you want to control
access based on authentication protocol or on client IP addresses or host names. You can enable or
disable export policies for SMB access at any time.
When upgrading a cluster from versions of Data ONTAP earlier than 8.2, this option is automatically
enabled on CIFS servers in the cluster that are using export policies to control SMB access. There is
no unexpected change to configured access controls when you upgrade to a version of Data ONTAP
where export policies for SMB access is optional.
Steps


If you want export policies
to be...
Enabled

-is-exportpolicy-enabled true
Disabled

-is-exportpolicy-enabled false

Example
The following example enables the usage of export policies to control SMB client access to
resources on Vserver vs1:
cluster1::*> vserver cifs options modify -vserver vs1 -is-exportpolicyenabled true
Related tasks
Adding an SMB access rule to an export policy on page 220
Creating an export policy

Before creating export rules, you must create an export policy to hold them. You can use the
vserver export-policy create command to create an export policy.
Steps
1. To create an export policy, enter the following command:

vserver export-policy create -vserver virtual_server_name -policyname
policy_name
-policyname policy_name specifies the name of the new export policy. The policy name can
be up to 256 characters long.

2. Use the volume modify command to assign the export policy to a volume.
Example
The following command creates an export policy named rs1 on a Vserver named vs1:
vs1::> vserver export-policy create -vserver vs1 -policyname rs1
How export rules work

Export rules are the functional elements of an export policy. Export rules match client access
requests to a volume against specific parameters you configure to determine how to handle the client
access requests.
An export policy must contain at least one export rule to allow access to clients. If an export policy
contains more than one rule, the rules are processed in the order in which they appear in the export
policy. The rule order is dictated by the rule index number. If a rule matches a client, the permissions
of that rule are used and no further rules are processed. If no rules match, the client is denied access.
You can configure export rules to determine client access permissions using the following criteria:
The file access protocol used by the client sending the request, for example, NFSv4 or SMB.
A client identifier, for example, host name or IP address.
The security type used by the client to authenticate, for example, Kerberos v5, NTLM, or
AUTH_SYS.

If a rule specifies multiple criteria, and the client does not match one or more of them, the rule does
not apply.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule any
10.1.17.37.
Even though the client access protocol matches, the IP address of the client is in a different
subnet from the one specified in the export rule. Therefore, client matching fails and this rule
does not apply to this client.
Example
-protocol nfs
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule any
10.1.16.54.
The client access protocol matches and the IP address of the client is in the specified subnet.
Therefore, client matching is successful and this rule applies to this client. The client gets
read-write access regardless of its security type.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm

Therefore both clients get read-only access. However, only client #1 gets read-write access
because it used the approved security type Kerberos v5 to authenticate. Client #2 does not get
read-write access.
How to handle clients with an unlisted security type

When a client presents itself with a security type that is not listed in an access parameter of an export
rule, you have the choice of either denying access to the client or mapping it to the anonymous user
ID instead by using the option none in the access parameter.
A client might present itself with a security type that is not listed in an access parameter because it
was authenticated with a different security type or was not authenticated at all (security type
AUTH_NONE). By default, the client is automatically denied access to that level. However, you can
add the option none to the access parameter. As a result, clients with an unlisted security style are
mapped to the anonymous user ID instead. The -anon parameter determines what user ID is
assigned to those clients. The user ID specified for the -anon parameter must be a valid user that is
configured with permissions you deem appropriate for the anonymous user.
Valid values for the -anon parameter range from 0 to 65535.
User ID assigned to -anon
Resulting handling of client access requests
0 - 65533
The client access request is mapped to the anonymous user

ID and gets access depending on the permissions
configured for this user.
65534
The client access request is mapped to the user nobody and

gets access depending on the permissions configured for
this user. This is the default.
65535
The access request from any client is denied when mapped

to this ID and the client presents itself with security type
AUTH_NONE.
The access request from clients with user ID 0 is denied
when mapped to this ID and the client presents itself with
any other security type.
When using the option none, it is important to remember that the read-only parameter is processed
first. Consider the following guidelines when configuring export rules for clients with unlisted
security types:

Read-only
includes none
Read-write
includes none
Resulting access for clients with unlisted security types
No
No
Denied
No
Yes
Denied because read-only is processed first
Yes
No
Read-only as anonymous
Yes
Yes
Read-write as anonymous
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule sys,none
-rwrule any
-anon 70
allows read-write access to any security type, but in this case only applies to clients already
filtered by the read-only rule.
Therefore, clients #1 and #3 get read-write access only as the anonymous user with user ID 70.
Client #2 gets read-write access with its own user ID.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule sys,none
-rwrule none
-anon 70
allows read-write access only as the anonymous user.
Therefore, client #1 and client #3 get read-write access only as the anonymous user with user
ID 70. Client #2 gets read-only access with its own user ID but is denied read-write access.
How security types determine client access levels

The security type that the client authenticated with plays a special role in export rules. You must
understand how the security type determines the levels of access the client gets to a volume.
The three possible access levels are as follows:
1. Read-only
2. Read-write
3. Superuser (for clients with user ID 0)
Because the access level by security type is evaluated in this order, you must observe the following
rules when constructing access level parameters in export rules:
For a client to get access
level...
These access parameters must match the client's security

type...
Normal user read-only
Read-only (-rorule)
Normal user read-write
Read-only (-rorule) and read-write (-rwrule)
Superuser read-only
Read-only (-rorule) and -superuser
Superuser read-write
Read-only (-rorule) and read-write (-rwrule) and -superuser
The following are valid security types for each of these three access parameters:
any
none
never

This security type is not valid for use with the -superuser parameter.
krb5
ntlm
sys
When matching a client's security type against each of the three access parameters, there are three
possible outcomes:
If the client's security type...
Then the client...
Matches one specified in the access parameter.
Gets access for that level with its own user ID.
Does not match one specified, but the access

parameter includes the option none.
Gets access for that level but as the anonymous

user with the user ID specified by the -anon
parameter.
Does not match one specified and the access

parameter does not include the option none.
Does not get any access for that level.

This does not apply to the -superuser
parameter because it always includes none even
when not specified.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule sys,krb5
-superuser krb5
NFSv3 protocol, and did not authenticate (AUTH_NONE).
parameter allows read-only access to all clients regardless of security type. The read-write
parameter allows read-write access to clients with their own user ID that authenticated with
AUTH_SYS or Kerberos v5. The superuser parameter allows superuser access to clients with
user ID 0 that authenticated with Kerberos v5.

Therefore, client #1 gets superuser read-write access because it matches all three access
parameters. Client #2 gets read-write access but not superuser access. Client #3 gets read-only
access but not superuser access.
How to handle superuser access requests

When you configure export policies, you need to consider what you want to happen if the storage
system receives a client access request with user ID 0, meaning as a superuser, and set up your export
rules accordingly.
In the UNIX world, a user with the user ID 0 is known as the superuser, typically called root, who
has unlimited access rights on a system. Using superuser privileges can be dangerous for several
reasons, including breach of system and data security.
By default, Data ONTAP maps clients presenting with user ID 0 to the anonymous user. However,
you can specify the -superuser parameter in export rules to determine how to handle clients
presenting with user ID 0 depending on their security type. The following are valid options for the superuser parameter:
any
none
This is the default setting if you do not specify the -superuser parameter.
krb5
ntlm
sys
There are two different ways how clients presenting with user ID 0 are handled, depending on the superuser parameter configuration:
If the -superuser parameter and the client's Then the client...
security type...
Match
Gets superuser access with user ID 0.
Do not match
Gets access as the anonymous user with the user

ID specified by the -anon parameter and its
assigned permissions.
This is regardless of whether the read-only or
read-write parameter specifies the option none.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm
-anon 127
Kerberos v5 to authenticate.
Client #2 does not get superuser access. Instead, it gets mapped to anonymous because the superuser parameter is not specified. This means it defaults to none and automatically maps
user ID 0 to anonymous. Client #2 also only gets read-only access because its security type did
not match the read-write parameter.
Example
-protocol nfs3
-clientmatch 10.1.16.0/255.255.255.0
-rorule any
-rwrule krb5,ntlm
-superuser krb5
-anon 0
Kerberos v5 to authenticate. Client #2 does not get read-write access.
The export rule allows superuser access for clients with user ID 0. Client #1 gets superuser
access because it matches the user ID and security type for the read-only and -superuser
parameters. Client #2 does not get read-write or superuser access because its security type
does not match the read-write parameter or the -superuser parameter. Instead, client #2 is
mapped to the anonymous user, which in this case has the user ID 0.
Adding an SMB access rule to an export policy

You can create an SMB access export rule for an export policy. This enables you to define client
access to data using the SMB protocol.
Before you begin
The export policy to which you want to add rules must already exist.
Steps
1. Create an export rule by entering the following command:

vserver export-policy rule create -vserver vserver_name -policyname
policy_name -ruleindex integer -protocol {any|nfs3|nfs|cifs|nfs4|
flexcache},... -clientmatch text -rorule {any|none|never|krb5|ntlm|
sys},... -rwrule {any|none|never|krb5|ntlm|sys},... -anon user_ID superuser {any|none|never|krb5|ntlm|sys},... -anon user_ID -superuser
{any|none|krb5|ntlm|sys},... -allow-suid {true|false} -allow-dev {true|
false}
-policyname policy_name specifies the name of the existing export policy to add the rule to.
-ruleindex integer specifies the index number for the rule. Rules are evaluated according to
their order in the list of index numbers; rules with lower index numbers are evaluated first. For
example, the rule with index number 1 is evaluated before the rule with index number 2.
-protocol {any | nfs3 | nfs | cifs | nfs4 | flexcache} specifies the access protocol to
which the rule applies. You can specify a comma-separated list of multiple access protocols for
an export rule. If you specify the protocol as any, do not specify any other protocols in the list. If
you do not specify an access protocol, the default value of any is used.
-clientmatch text specifies the client to which the rule applies. You can specify the match in
any of the following formats:

Client match format
Example
Domain name preceded by the "." character
.example.com
Host name
host1
IPv4 address
10.1.12.24

a number of bits
10.1.12.10/4
IPv4 address with a network mask
10.1.16.0/255.255.255.0
IPv6 address in dotted format
::1.2.3.4

Client match format
Example

a number of bits
ff::00/32
Netgroup with the netgroup name preceded by

the @ character
@netgroup1
Note: Entering an IP address range, such as 10.1.12.10-10.1.12.70, is not allowed. Entries in

this format are interpreted as a text string and treated as a host name. Entering an IPv6 address
with a network mask, such as ff::12/ff::00, is not allowed.
-rorule {any | none | never | krb5 | ntlm | sys} provides read-only access to clients that

-rwrule {any | none | never | krb5 | ntlm | sys} provides read-write access to clients that

Note: A client can only get read-write access for a specific security type if the export rule
restrictive for a security type than the read-write parameter, the client cannot get read-write
access.
You can specify a comma-separated list of multiple security types for a rule. If you specify the
security type as any or never, do not specify any other security types. Choose from the
following valid security types:
any
none
A matching client can access the volume regardless of security type.

If listed alone, clients with any security type are granted access as anonymous. If listed with
other security types, clients with a specified security type are granted access and clients with
any other security type are granted access as anonymous.
never
A matching client cannot access the volume regardless of security type.
krb5
A matching client can access the volume if it is authenticated by Kerberos 5. The krb5 option
refers to either SMB or NFS Kerberos authentication.
ntlm
A matching clients can access the volume if it is authenticated by SMB NTLM.
sys
A matching client can access the volume if it is authenticated by NFS AUTH_SYS.

-anon user_ID specifies a UNIX user ID or user name that is mapped to client requests that
arrive with a user ID of 0 (zero), which is typically associated with the user name root. The
default value is 65534, which is typically associated with the user name nobody. The following
notes apply to the use of this parameter:
To disable access by any client with a user ID of 0, you must specify a value of 65535.
To provide a client with a user ID of 0 with normal user access to files and directories owned
by the user ID 0, but not with superuser access to files and directories not owned by the user
ID 0, specify the anonymous user as 0 and superuser access as none.
-superuser {any | none | krb5 | ntlm | sys} provides superuser access to clients that

Note: A client can only get superuser access for a specific security type if the export rule
restrictive for a security type than the superuser parameter, the client cannot get superuser
access.
-allow-suid {true | false} specifies whether to allow access to set user ID (suid) and set
group ID (sgid). The default is true.
-allow-dev {true | false} specifies whether to allow creation of devices. The default is
true.
2. Verify that your export rules are correct by using the vserver export-policy rule show
command.
Example
cluster1::> vserver export-policy
Virtual
Policy
Rule
Server
Name
Index
------------ ------------ -----vs1
cifsonly
1
vs1
nfsonly
2
rule show
Access
Client
Protocol Match
-------- -----------cifs
192.168.1.0/24
nfs
0.0.0.0/0
RO
Rule
-----kerberos
any
Examples
Example 1: The following command creates an export rule on a Vserver named vs1 that has
the following configuration:
Policy name: cifs1

Index number: 1
Client match: Matches only clients on the 192.168.1.0/24 network
Protocol: Only enables SMB access
Read-only access: To clients using NTLM or Kerberos authentication
Read-write access: To clients using Kerberos authentication
cluster1::> vserver export-policy rule create -vserver vs1 policyname cifs1 -ruleindex 1 -protocol cifs -clientmatch
192.168.1.0/255.255.255.0 -rorule krb5,ntlm -rwrule krb5
Policy name: cifsnfs1

Index number: 2
Client match: Matches all clients
Protocol: SMB and NFS access
Read-only access: To all clients
Read-write access: To clients using Kerberos (NFS and SMB) or NTLM authentication
(SMB)
Mapping for UNIX user ID 0 (zero): Mapped to user ID 65534 (which typically maps to
the user name nobody)
Suid and sgid access: Allows
cluster1::> vserver export-policy rule create -vserver vs1 policyname cifsnfs1 -ruleindex 2 -protocol cifs,nfs -clientmatch
0.0.0.0/0 -rorule any -rwrule krb5,ntlm -anon 65534 -allow-suid true
Policy name: ntlm1

Index number: 1
Client match: Matches all clients
Protocol: Only enables SMB access
Read-only access: Only to clients using NTLM
Read-write access: Only to clients using NTLM
Note: If you configure the -rorule option or the -rwrule option for NTLM only access,
you must use IP address-based entries in the -clientmatch option. Otherwise, you receive
access denied errors. This is because Data ONTAP uses Kerberos Service Principal
Names (SPN) when using a host name to check on the client's access rights and NTLM
authentication does not support SPN names.
cluster1::> vserver export-policy rule create -vserver vs1 policyname ntlm1 -ruleindex 1 -protocol cifs -clientmatch 0.0.0.0/0
-rorule ntlm -rwrule ntlm
Setting an export rule's index number

You can use the vserver export-policy rule setindex command to manually set an
existing export rule's index number. This enables you to rearrange the order in which Data ONTAP
processes export rules.
About this task
If the new index number is already in use, the command inserts the rule at the specified spot and
reorders the list accordingly.
Step
1. To modify the index number of a specified export rule, enter the following command:
vserver export-policy rule setindex -vserver virtual_server_name policyname policy_name -ruleindex integer -newruleindex integer
-policyname policy_name specifies the policy name.
-ruleindex integer specifies the current index number of the export rule.
-newruleindex integer specifies the new index number of the export rule.
Example
The following command changes the index number of an export rule at index number 3 to
index number 2 in an export policy named rs1 on a Vserver named vs1.
vs1::> vserver export-policy rule setindex -vserver vs1
-policyname rs1 -ruleindex 3 -newruleindex 2
Associating an export policy to a FlexVol volume

Each FlexVol volume contained in the Vserver with FlexVol must be associated with an export
policy that contains export rules for clients to access data in the volume.
About this task
When you create a Vserver, Data ONTAP creates a default export policy called default for the
Vserver. Data ONTAP assigns the default export policy to the Vserver's volumes. You can associate
another custom export policy that you create instead of the default policy to a volume. Before you
associate a custom export policy to a volume, you must create one or more export rules that allow the
desired access to data in the volume and assign those export rules to the export policy that you want
to associate with the volume.

You can associate an export policy to a volume when you create the volume or at any time after you
create the volume. You can associate one export policy to the volume.
Steps
1. Use either the volume create or volume modify command with the -policy option to
associate an export policy to the volume.
Example
cluster::> volume create -vserver vs1 -volume vol1
-aggregate aggr2 -state online -policy cifs_policy -security-style
ntfs
-junction-path /dept/marketing -size 250g -space-guarantee volume
For more information about the volume create and volume modify commands, see the man
pages.
2. Verify that the export policy associated with the volume has the desired access configuration
using the vserver export-policy rule show command with the -policyname option.
Example
cluster::> vserver export-policy rule show -policyname cifs_policy
Virtual
Policy
Rule
Access
Client
RO
Server
Name
Index
Protocol Match
Rule
------------ ------------------ ------ -------- ------------ -----vs1
cifs_policy
1
cifs
0.0.0.0/0
any
For more information about the vserver export-policy rule show command, see the man
pages.
The command displays a summary for that export policy, including a list rules applied to that
policy. Data ONTAP assigns each rule a rule index number. After you know the rule index
number, you can use it to display detailed information about the specified export rule.
3. Verify that the rules applied to the export policy are configured correctly by using the vserver
export-policy rule show command and specify the -policyname, -vserver, and ruleindex options.
Example
cluster::> vserver export-policy rule show -policyname cifs_policy vserver vs1 -ruleindex 1
Virtual Server: vs1
Policy Name: cifs_policy
Rule Index: 1
Access Protocol: cifs
Client Match Spec: 0.0.0.0/0

RO Access Rule:
RW Access Rule:
User ID To Which Anonymous Users Are Mapped:
Superuser Security Flavors:
Honor SetUID Bits In SETATTR:
Allow Creation of Devices:
any
any
0
any
true
true
Export policy restrictions and nested junctions for FlexVol volumes

If you configured export policies to set a less restrictive policy on a nested junction but a more
restrictive policy on a higher level junction, access to the lower level junction might fail.
You should ensure that higher level junctions have less restrictive export policies than lower level
junctions.
Commands for managing export policies

There are specific Data ONTAP commands for managing export policies.
If you want to...
Use this command...
Display information about export policies
vserver export-policy show
Rename an export policy
vserver export-policy rename
Copy an export policy
vserver export-policy copy
Delete an export policy
vserver export-policy delete
Commands for managing export rules

There are specific Data ONTAP commands for managing export rules.
If you want to...
Use this command...
Create an export rule
vserver export-policy rule create
Display information about export rules
vserver export-policy rule show
Modify an export rule
vserver export-policy rule modify
Delete an export rule
vserver export-policy rule delete
Considerations when reverting export policies for SMB

For releases earlier than Data ONTAP 8.2, SMB export policies are mandatory. Starting with Data
ONTAP 8.2, export policies for SMB access are optional and are disabled by default. There are
certain considerations when reverting to a release where export policies are mandatory.
There are two scenarios where export policies for SMB access are a consideration when reverting to
a version of Data ONTAP where export policies for SMB are mandatory:
You have a cluster with an installed version of Data ONTAP where the use of export policies for
SMB is optional and export policies are disabled on all Vservers.
In this case, the Vservers and contained volumes do not have export policies that allow SMB
access. If you revert to a version of Data ONTAP where export policies are mandatory, export
policies are turned on and required for SMB access. This results in denial of access to SMB
clients.
The recommendation is that you configure export policies for SMB on all Vservers before you
revert so that there are no hard-to-resolve SMB client access issues after the revert.
You have a cluster with an installed version of Data ONTAP where the use of export policies for
SMB access is optional and export policies for SMB are enabled on some but not all of the
Vservers.
If you revert to a version of Data ONTAP where export policies are mandatory, export policies
are turned on and required for SMB access for all Vservers. This results in denial of access to
SMB clients on Vservers where export policies were not previously enabled.
The recommendation is that you configure export policies for SMB on all Vservers before you
revert so that there are no hard-to-resolve SMB client access issues after the revert.
Note: If you upgraded from a version of Data ONTAP where export policies are mandatory,
export policies for SMB were automatically enabled on existing Vservers. Even if you
subsequently disabled export policies for SMB on those existing Vservers, the export policies
remain in place. Upon a revert back to a version of Data ONTAP where export policies are
mandatory, the existing export policies are used to determine SMB access. However, before
reverting, you should create export policies for SMB access on any new Vservers created after the
initial upgrade.
Managing file access using SMB

After you create and configure a CIFS server on a Vserver, there are a number of tasks you might
want to perform to manage file access using SMB.
Using local users and groups for authentication and

authorization
You can create local users and groups on the Vserver. The CIFS server can use local users for CIFS
authentication and can use both local users and groups for authorization when determining both share
and file and directory access rights.
Local group members can be local users, domain users and groups, and domain machine accounts.
Local users and groups can also be assigned privileges. Privileges control access to Vserver resources
and can override the permissions that are set on objects. A user or member of a group that is assigned
a privilege is granted the specific rights that the privilege allows.
Note: Privileges do not provide clustered Data ONTAP general administrative capabilities.
How Data ONTAP uses local users and groups

When configuring and using local users and groups, you must understand what they are and how they
are used. For example, you can use local users and groups to provide share and file-access security to
data residing on the Vserver. You can also assign user management rights to users through the use of
local users and groups.
Local users and groups concepts
You should know what local users and groups are, and some basic information about them, before
determining whether to configure and use local users and groups in your environment.
Local user
A user account with a unique security identifier (SID) that has visibility only on
the Vserver on which it is created. Local user accounts have a set of attributes,
including user name and SID. A local user account authenticates locally on the
CIFS server using NTLM authentication.
User accounts have several uses:
Local group
Used to grant User Rights Management privileges to a user.

Used to control share-level and file-level access to file and folder resources
that the Vserver owns.
A group with a unique SID has visibility only on the Vserver on which it is
created. Groups contain a set of members. Members can be local users, domain
Managing file access using SMB | 229

users, domain groups, and domain machine accounts. Groups can be created,
modified, or deleted.
Groups have several uses:
Local domain
Used to grant User Rights Management privileges to its members.

Used to control share-level and file-level access to file and folder resources
that the Vserver owns.
A domain that has local scope, which is bounded by the Vserver. The local
domain's name is the CIFS server name. Local users and groups are contained
within the local domain.
A SID is a variable-length numeric value that identifies Windows-style security

Security
identifier (SID) principals. For example, a typical SID takes the following form:
S-1-5-21-3139654847-1303905135-2517279418-123456.
NTLM
authentication
A Microsoft Windows security method used to authenticate users on a CIFS

server.
A replicated database with an instance on each node in a cluster. Local user and
Cluster
group
objects are stored in the RDB.
replicated
database (RDB)
Reasons for creating local users and groups
There are several reasons for creating local users and groups on your Vserver. For example, you can
access the CIFS server using a local user account if the domain controllers are unavailable, or you
may want to use local groups to assign privileges.
You can create one or more local user accounts for the following reasons:
You want the ability to authenticate and log in to the CIFS server if domain controllers are
unavailable.
Local users can authenticate with the CIFS server using NTLM authentication when the domain
controller is down or when network problems prevent your CIFS server from contacting the
domain controller.
You want to assign a local user User Rights Management privileges.
User Rights Management is the ability for a CIFS server administrator to control what rights
users and groups have on the Vserver. You can assign privileges to a user by assigning the
privileges to the user's account or by making the user a member of a local group that has those
privileges.
Note: Although a local user can authenticate locally, the CIFS server is not operating in
Workgroup mode. Workgroup mode is not supported in this version of Data ONTAP. The CIFS
server must still be part of an Active Directory domain. The Vserver's CIFS server is operating as
a member server in an Active Directory domain.
You might want to create one or more local groups for the following reasons:
You want to control access to file and folder resources by using local groups for share and fileaccess control.
You want to create local groups with customized User Rights Management privileges.
There are certain built-in user groups with predefined privileges. To assign a customized set of
privileges, you can create a local group and assign that group the necessary privileges. You can
then add local users, domain users, and domain groups to the local group.
Related concepts
How local user authentication works on page 230

What local privileges are on page 232
How local user authentication works
Before a local user can access data on a CIFS server, the user must create an authenticated session.
Because SMB is session-based, the identity of the user can be determined just once, when the session
is first set up. The CIFS server uses NTLM-based authentication when authenticating local users.
Both NTLMv1 and NTLMv2 are supported.
Data ONTAP uses local authentication under three use cases. Each use case depends on whether the
domain portion of the user name (with the DOMAIN\user format) matches the CIFS server's local
domain name (the CIFS server name):
The domain portion matches

Users who provide local user credentials when requesting access to data are authenticated locally
on the CIFS server.
The domain portion does not match
Data ONTAP attempts to use NTLM authentication with a domain controller in the domain to
which the CIFS server belongs. If authentication succeeds, the login is complete. If it does not
succeed, what happens next depends on why authentication did not succeed.
For example, if the user exists in Active Directory but the password is invalid or expired, Data
ONTAP does not attempt to use the corresponding local user account on the CIFS server. Instead,
authentication fails. There are other cases where Data ONTAP uses the corresponding local
account on the CIFS server, if it exists, for authenticationeven though the NetBIOS domain
names do not match. For example, if a matching domain account exists but it is disabled, Data
ONTAP uses the corresponding local account on the CIFS server for authentication.
The domain portion is not specified
Data ONTAP first attempts authentication as a local user. If authentication as a local user fails,
then Data ONTAP authenticates the user with a domain controller in the domain to which the
CIFS server belongs.
After local or domain user authentication is completed successfully, Data ONTAP constructs a
complete user access token, which takes into account local group membership and privileges.
For more information about NTLM authentication for local users, see the Microsoft Windows
documentation.
How user access tokens are constructed

When a user maps a share, an authenticated SMB session is established and a user access token is
constructed that contains information about the user, the user's group membership and cumulative
privileges, and the mapped UNIX user.
Unless the functionality is disabled, local user and group information is also added to the user access
token. The way access tokens are constructed depends on whether the login is for a local user or an
Active Directory domain user:
Local user login

Although local users can be members of different local groups, local groups cannot be members
of other local groups. The local user access token is composed of a union of all privileges
assigned to groups to which a particular local user is a member.
Domain user login
When a domain user logs in, Data ONTAP obtains a user access token that contains the user SID
and SIDs for all the domain groups to which the user is a member. Data ONTAP uses the union
of the domain user access token with the access token provided by local memberships of the
user's domain groups (if any), as well as any direct privileges assigned to the domain user or any
of its domain group memberships.
For both local and domain user login, the Primary Group RID is also set for the user access token.
The default RID is Domain Users (RID 513). This default RID cannot be changed in this version
of Data ONTAP.
The Windows-to-UNIX and UNIX-to-Windows name mapping process follows the same rules for
both local and domain accounts.
Note: There is no implied, automatic mapping from a UNIX user to a local account. If this is
required, an explicit mapping rule must be specified using the existing name mapping commands.
Considerations when using SnapMirror on Vservers that contain local groups

There are certain considerations you should keep in mind if you configure SnapMirror on volumes
owned by a Vserver that contains local groups.
You cannot use local groups in ACEs applied to files, directories, or shares that are replicated by
SnapMirror to another Vserver. If you use the SnapMirror feature to create a DR mirror to a volume
on another Vserver and the volume has an ACE for a local group, the ACE is not valid on the mirror.
If data is replicated to a different Vserver, the data is effectively crossing into a different local
domain. The permissions granted to local users and groups are valid only within the scope of the
Vserver on which they were originally created.
What happens to local users and groups when deleting CIFS servers
The default set of local users and groups is created when a CIFS server is created, and they are
associated with the Vserver hosting the CIFS server. Vserver administrators can create local users

and groups at any time. You need to be aware of what happens to local users and groups when you
delete the CIFS server.
Local users and groups are associated with Vservers; therefore, they are not deleted when CIFS
servers are deleted due to security considerations. Although local users and groups are not deleted
when the CIFS server is deleted, they are hidden. You cannot view or manage local users and groups
until you re-create a CIFS server on the Vserver.
Note: The CIFS server administrative status does not affect visibility of local users or groups.
How you can use Microsoft Management Console with local users and groups
You can view information about local users and groups from the Microsoft Management Console.
With this release of Data ONTAP, you cannot perform other management tasks for local users and
groups from the Microsoft Management Console.
Considerations when reverting
If you plan to revert the cluster to a Data ONTAP release that does not support local users and groups
and local users and groups are being used to manage file access or user rights, you must be aware of
certain considerations.
Due to security reasons, information about configured local users, groups, and privileges are not
deleted when Data ONTAP is reverted to a version that does not support local users and groups
functionality.
Upon a revert to a prior major version of Data ONTAP, Data ONTAP does not use local users
and groups during authentication and credential creation.
Local users and groups are not removed from file and folder ACLs.
File access requests that depend on access being granted because of permissions granted to local
users or groups are denied.
To allow access, you must reconfigure file permissions to allow access based on domain objects
instead of local user and group objects.
What local privileges are

Privileges are well-known rights that can be granted to local and domain users and groups to perform
User Rights Management tasks on the CIFS server. You cannot create privileges. You can only add
or remove existing privileges.
List of supported privileges
Data ONTAP has a predefined set of supported privileges. Certain predefined local groups have
some of these privileges added to them by default. You can also add or remove privileges from the
predefined groups or create new local groups and add privileges to the groups that you created.
The following table lists the supported privileges on the Vserver and provides a list of BUILTIN
groups with assigned privileges:

Privilege name
Default security setting
Description
SeTcbPrivilege
None
Act as part of the

operating system
SeBackupPrivilege
BUILTIN\Administrators,
BUILTIN\Backup Operators
Back up files and

directories, overriding an
ACLs
SeRestorePrivilege
BUILTIN\Administrators,
Restore files and

directories, overriding
any ACLs
SeTakeOwnershipPrivilege
BUILTIN\Administrators
Take ownership of files

or other objects
SeSecurityPrivilege
Manage auditing
This includes viewing,
dumping, and clearing
the security log.
How to assign privileges

You can assign privileges directly to local users or domain users. Alternatively, you can assign users
to local groups whose assigned privileges match the capabilities that you want those users to have.
You can assign a set of privileges to a group that you create.

You then add a user to the group that has the privileges that you want that user to have.
You can also assign local users and domain users to predefined groups whose default privileges
match the privileges that you want to grant to those users.
Requirements and considerations

Before you create and configure local users and groups on your CIFS server, you need to be aware of
certain requirements and considerations.
Considerations when using BUILTIN groups and the local administrator account
There are certain considerations you should keep in mind when you use BUILTIN groups and the
local administrator account. For example, you should know that you can rename the local
administrator account, but you cannot delete this account.
The Administrator account can be renamed but cannot be deleted.

The Administrator account cannot be removed from the BUILTIN\Administrators group.
BUILTIN groups can be renamed but cannot be deleted.
After the BUILTIN group is renamed, another local object can be created with the well-known
name; however, the object is assigned a new RID.
There is no local Guest account.

Related references
List of BUILTIN groups and their default privileges on page 234

Requirements for local user passwords
By default, local user passwords must meet complexity requirements. The password complexity
requirements are similar to the requirements defined in the Microsoft Windows Local security policy.
The password must meet the following criteria:
Must be at least six characters in length

Must not contain the user account name
Must contain characters from at least three of the following four categories:
English uppercase characters (A through Z)

English lowercase characters (a through z)
Base 10 digits (0 through 9)
Special characters: ~, !, @, #, 0, ^, &, *, _, -, +, =, `, \, |, (, ), [, ], :, ;, ", ', <, >, ,, ., ?, /
Related tasks
Requiring password complexity for local CIFS users on page 142

Changing local user account passwords on page 241
List of BUILTIN groups and their default privileges

You can assign membership of a local user or domain user to a predefined set of BUILTIN groups
provided by Data ONTAP. Predefined groups have predefined privileges assigned.
The following table describes the predefined groups:
Predefined BUILTIN group
Default privileges
RID 544
When first created, the local Administrator
account, with a RID of 500, is automatically made

a member of this group. When the Vserver is
joined to a domain, the domain\Domain
Admins group is added to the group. If the
Vserver leaves the domain, the domain\Domain
Admins group is removed from the group.
SeBackupPrivilege
SeRestorePrivilege
SeSecurityPrivilege

Predefined BUILTIN group
Default privileges
BUILTIN\Power Users
none
RID 547
When first created, this group does not have any
members. Members of this group:
Can create and manage local users and groups.

Cannot add themselves or any other object to
the BUILTIN\Administrators group.
RID 551
members. Members of this group can override
read and write permissions on files or folders if
they are opened with backup intent.
BUILTIN\Users
SeBackupPrivilege
SeRestorePrivilege
none
RID 545
members (besides the implied Authenticated
Users) special group. When the Vserver is joined
to a domain, the domain\Domain Users group
is added to this group. If the Vserver leaves the
domain, the domain\Domain Users group is
removed from this group.
Everyone
none
SID S-1-1-0
This group includes all users, including guests
(but not anonymous users). This is an implied
group with an implied membership.
Related concepts
Considerations when using BUILTIN groups and the local administrator account on page 233
Enabling or disabling local users and groups functionality

Before you can use local users and groups for access control of NTFS security-style data, local user
and group functionality must be enabled. Additionally, if you want to use local users for SMB
authentication, the local user authentication functionality must be enabled.
Local users and groups functionality and local user authentication are enabled by default. If they are
not enabled, you must enable them before you can configure and use local users and groups. You can
disable local users and groups functionality at any time.
In addition to explicitly disabling local user and group functionality, Data ONTAP disables local user
and group functionality if any node in the cluster is reverted to a Data ONTAP release that does not
support the functionality. Local user and group functionality is not enabled until all nodes in the
cluster are running a version of Data ONTAP that supports it.
Related concepts
Managing local user accounts on page 238

Managing local groups on page 245
Managing local privileges on page 253
Enabling or disabling local users and groups
You can enable or disable local users and groups for SMB access on Vservers with FlexVol volumes
and Vservers with Infinite Volumes. Local users and groups functionality is enabled by default.
About this task
You can use local users and groups when configuring share and NTFS file permissions and can
optionally use local users for authentication when creating an SMB connection. To use local users for
authentication, you must also enable the local users and groups authentication option.
Steps


If you want local users and
groups to be...
Enabled

-is-local-users-and-groups-enabled true
Disabled

-is-local-users-and-groups-enabled false

Example
The following example enables local users and groups functionality on Vserver vs1:
cluster1::*> vserver cifs options modify -vserver vs1 -is-local-users-andgroups-enabled true
Enabling or disabling local user authentication

You can enable or disable local user authentication for SMB access on Vservers with FlexVol
volumes and Vservers with Infinite Volumes. The default is to allow local user authentication, which
is useful when the Vserver cannot contact a domain controller or if you choose not to use domainlevel access controls.
Before you begin
Local users and groups functionality must be enabled on the CIFS server.
About this task
You can enable or disable local user authentication at any time. If you want to use local users for
authentication when creating an SMB connection, you must also enable the CIFS server's local users
and groups option.
Steps


If you want local
authentication to be...
Enabled

vserver_name -is-local-auth-enabled true
Disabled

vserver_name -is-local-auth-enabled false

Example
The following example enables local user authentication on Vserver vs1:
cluster1::>set -privilege advanced
cluster1::*> vserver cifs options modify -vserver vs1 -is-local-authenabled true
Managing local user accounts

You can manage local user accounts by creating, modifying, and deleting them, and by displaying
information about user accounts and group membership. You can also perform other management
tasks, such as enabling, disabling, and renaming user accounts, setting the password for an account,
and managing local account password complexity.
Related concepts
Local users and groups concepts on page 228

Enabling or disabling local users and groups functionality on page 236
Creating local user accounts
You can create a local user account that can be used to authorize access to data contained in the
Vserver over an SMB connection. You can also use local user accounts for authentication when
creating an SMB session.
Before you begin
Local users and groups functionality must be enabled.

About this task
When you create a local user account, you must specify a user name and you must specify the
Vserver with which to associate the account. The user name must meet the following requirements:
Must not exceed 20 characters

Cannot be terminated by a period
Cannot include commas
Cannot include any of the following printable characters: ", /, \, [, ], :, |, <, >, +, =, ;, ?, *, @
Cannot include characters in the ASCII range 1-31, which are non-printable
You can optionally specify the following parameters:
-full-name user_name specifies the user's full name.

If the full name contains a space, it must be enclosed within quotation marks.
-description text specifies a description for the local user.
If the description contains a space, it must be enclosed within quotation marks.
-is account-disabled {true|false} specifies if the user account is enabled or disabled.
By default, the user account is enabled.
Steps
1. Create the local user by entering the following command:

vserver cifs users-and-groups local-user create -vserver vserver_name
user-name user_name optional_parameters
The command prompts for the local user's password.

2. Enter a password for the local user and confirm the password.
The password must meet the following requirements:


3. Verify that the user has been successfully created:

vserver cifs users-and-groups local-user show -vserver vserver_name
Example
The following example creates a local user CIFS_SERVER\sue associated with Vserver
vs1:
cluster1::> vserver cifs users-and-groups local-user create -vserver vs1 user-name
CIFS_SERVER\sue
Enter the password:
Confirm the password:
cluster1::> vserver cifs users-and-groups local-user show
Vserver User Name
Full Name Description
-------- -------------------------- ---------- ------------vs1
CIFS_SERVER\Administrator
Built-in administrator account
vs1
CIFS_SERVER\sue
Modifying local user accounts

You can modify a local user account if you want to change an existing user's full name or
description, and if you want to enable or disable the user account. You can also rename a local user
account if the user's name is compromised or if a name change is needed for administrative purposes.
If you want to...
Modify the local user's full name vserver cifs users-and-groups local-user modify
-vserver vserver_name -user-name user_name
full-name text
If the full name contains a space, then it must be enclosed within

double quotation marks.
Modify the local user's
description
vserver cifs users-and-groups local-user modify

-vserver vserver_name -user-name user_name
description text
If the description contains a space, then it must be enclosed

within double quotation marks.
Enable or disable the local user
account
vserver cifs users-and-groups local-user modify

-vserver vserver_name -user-name user_name -isaccount-disabled {true|false}
Rename the local user account
vserver cifs users-and-groups local-user rename

-vserver vserver_name -user-name user_name -newuser-name new_user_name
The new user name must meet the following criteria:

Cannot include any of the following printable characters: ", /,
\, [, ], :, |, <, >, +, =, ;, ?, *, @
Cannot include characters in the ASCII range 1-31, which
are non-printable
When renaming a local user, the new user name must remain
associated with the same CIFS server as the old user name.
See the man page on the vserver cifs users-and-groups local-user modify and
vserver cifs users-and-groups local-user rename commands for more information.

Example
The following example renames the local user CIFS_SERVER\sue to CIFS_SERVER
\sue_new on Vserver vs1:
cluster1::> vserver cifs users-and-groups local-user rename -user-name
CIFS_SERVER\sue -new-user-name CIFS_SERVER\sue_new -vserver vs1
Enabling or disabling local user accounts

You enable a local user account if you want the user to be able to access data contained in the
Vserver over an SMB connection. You can also disable a local user account if you do not want that
user to access Vserver data over SMB.
About this task
You enable a local user by modifying the user account.

Step
1. Perform the appropriate action:

If you want to...
Enable the user account vserver cifs users-and-groups local-user modify

vserver vserver_name -user-name user_name -isaccount-disabled false
Disable the user account vserver cifs users-and-groups local-user modify
vserver vserver_name -user-name user_name -isaccount-disabled true
Changing local user account passwords

You can change a local user's account password. This can be useful if the user's password is
compromised or if the user has forgotten the password.
Step
1. Change the password by performing the appropriate action:

vserver cifs users-and-groups local-user set-password -vserver
vserver_name -user-name user_name
The password must meet the following criteria:


Example
The following example sets the password for the local user CIFS_SERVER\sue associated
with Vserver vs1:
cluster1::> vserver cifs users-and-groups local-user set-password -username CIFS_SERVER\sue -vserver vs1
Enter the new password:
Confirm the new password:
Related tasks
Requiring password complexity for local CIFS users on page 142

Displaying information about local users
You can display a list of all local users in a summary form. If you want to determine which account
settings are configured for a specific user, you can display detailed account information for that user
as well as the account information for multiple users. This information can help you determine if you
need to modify a user's settings, and also to troubleshoot authentication or file access issues.
About this task
Information about a user's password is never displayed.

Step

If you want to...
Display information about all users on a vserver cifs users-and-groups local-user

Vserver
show -vserver vserver_name
Display detailed account information for vserver cifs users-and-groups local-user
a user
show -instance -vserver vserver_name -username user_name
There are other optional parameters that you can choose when you run the vserver cifs
users-and-groups local-user show command. See the man page on this command for
more information.

Example
The following example displays information about all local users on Vserver vs1:
cluster1::> vserver cifs users-and-groups local-user show -vserver vs1
Vserver User Name
Full Name
Description
-------- --------------------------- ------------- ------------vs1
James Smith
vs1
CIFS_SERVER\sue
Sue
Jones
Displaying information about group memberships for local users

You can display information about which local groups that a local user belongs to. You can use this
information to determine what access the user should have to files and folders. This information can
be useful in determining what access rights the user should have to files and folders or when
troubleshooting file access issues.
About this task
You can customize the command to display only the information that you want to see.
Step

If you want to...
Display local user membership information for a

specified local user
vserver cifs users-and-groups localuser show-membership -user-name

user_name
Display local user membership information for

the local group of which this local user is a
member
vserver cifs users-and-groups localuser show-membership -membership

group_name
Display user membership information for local

users that are associated with a specified Vserver
vserver cifs users-and-groups localuser show-membership -vserver

vserver_name
Display detailed information for all local users on vserver cifs users-and-groups locala Vserver
user show-membership -instance
vserver vserver_name
Example
The following example displays the membership information for all local users on Vserver
vs1; user CIFS_SERVER\Administrator is a member of the BUILTIN\Administrators
group, and CIFS_SERVER\sue is a member of CIFS_SERVER\g1 group:

cluster1::> vserver cifs users-and-groups local-user show-membership vserver vs1
Vserver
User Name
Membership
---------- ---------------------------- -----------------------vs1
CIFS_SERVER\sue
CIFS_SERVER\g1
Deleting local user accounts

You can delete local user accounts from a Vserver if they are no longer needed for local SMB
authentication to a Vserver's CIFS server or for determining access rights to data contained on a
Vserver.
About this task
Keep the following in mind when deleting local users:
The file system is not altered.

Windows Security Descriptors on files and directories that refer to this user are not adjusted.
All references to local users are removed from the membership and privileges databases.
Standard, well-known users such as Administrator cannot be deleted.
Steps
1. Determine the name of the local user account that you want to delete:
2. Delete the local user:

vserver cifs users-and-groups local-user delete -vserver vserver_name
user-name username_name
3. Verify that the user account is deleted:

Example
The following example deletes the local user CIFS_SERVER\sue associated with Vserver
vs1:
Vserver User Name
Full Name
Description
-------- --------------------------- -------------- ------------vs1
James Smith
vs1
CIFS_SERVER\sue
Sue
Jones
cluster1::> vserver cifs users-and-groups local-user delete -vserver vs1 -user-name
CIFS_SERVER\sue
Vserver
User Name
Full Name
Description

-------- --------------------------- -------------- ------------vs1
James Smith
Managing local groups

You can manage local groups by creating or modifying groups, displaying information about groups
and group membership, and by deleting unneeded groups. You can also perform other management
tasks, such as renaming groups and adding or removing both local and domain users from the local
groups.
Related concepts
Local users and groups concepts on page 228

Creating local groups
You can create local groups that can be used for authorizing access to data associated with the
Vserver over an SMB connection. You can also assign privileges that define what user rights or
capabilities a member of the group has.
Before you begin
The local users and groups functionality is enabled.

About this task
Keep the following in mind when creating local groups:
You can specify a group name with or without the local domain name.
The local domain is the Vserver's CIFS server name. For example, if the Vserver's CIFS server
name is CIFS_SERVER and you want to create the engineering group, you can specify the
group name as engineering or CIFS_SERVER\engineering.
The following rules apply when using a local domain as part of the group name:
You can only specify the local domain name for the Vserver to which the group is applied.
For example, if the local CIFS server name is CIFS_SERVER, you cannot specify the
following local group name: CORP_SERVER\group1.
You cannot use the BUILTIN term as a local domain in the group name.
For example, you cannot create a group named BUILTIN\group1.
You cannot specify a group name that already exists.
When you create a local group, you must specify a name for the group and you must specify the
Vserver with which to associate the group. You can optionally specify a description for the local
group. The group name must meet the following requirements:

Cannot include any of the following printable characters: ", /, \, [, ], :, |, <, >, +, =, ;, ?, *, @
Cannot include characters in the ASCII range 1-31, which are non-printable
Steps
1. Create the local group by entering the following command:

vserver cifs users-and-groups local-group create -vserver vserver_name group-name group_name
2. Verify that the group is successfully created:

vserver cifs users-and-groups local-group show -vserver vserver_name
Example
The following example creates a local group CIFS_SERVER\engineering associated with
Vserver vs1:
cluster1::> vserver cifs users-and-groups local-group create -vserver vs1 -group-name
CIFS_SERVER\engineering
cluster1::> vserver cifs users-and-groups local-group show -vserver vs1
Vserver
Group Name
Description
-------------- ---------------------------- ---------------------------vs1
Built-in Administrators group
vs1
Backup Operators group
vs1
BUILTIN\Power Users
Restricted administrative privileges
vs1
BUILTIN\Users
All users
vs1
vs1
CIFS_SERVER\sales
Modifying local groups

You can modify existing local groups by changing the description for an existing local group or by
renaming the group.
If you want to...
Use the command...
Modify the local

group description
vserver cifs users-and-groups local-group modify -vserver

vserver_name -group-name group_name -description text
If the description contains a space, then it must be enclosed within double

quotation marks.

If you want to...
Use the command...
Rename the local

group
vserver cifs users-and-groups local-group rename -vserver

vserver_name -group-name group_name -new-group-name
new_group_name
The new group name must meet the following criteria:

Cannot include any of the following printable characters: ", /, \, [, ], :, |, <,
>, +, =, ;, ?, *, @
Cannot include characters in the ASCII range 1-31, which are nonprintable
See the man page for the vserver cifs users-and-groups local-group modify and
vserver cifs users-and-groups local-group rename commands for more information.
Examples
The following example renames the local group CIFS_SERVER\engineering to
CIFS_SERVER\engineering_new:
cluster1::> vserver cifs users-and-groups local-group rename -vserver vs1 group-name CIFS_SERVER\engineering -new-group-name CIFS_SERVER
\engineering_new
The following example modifies the description of the local group CIFS_SERVER
\engineering:
cluster1::> vserver cifs users-and-groups local-group modify -vserver vs1 group-name CIFS_SERVER\engineering -description "New Description"
Displaying information about local groups

You can display a list of all local groups configured on the cluster or on a specified Vserver. This
information can be useful when troubleshooting file-access issues to data contained on a Vserver or
user-rights (privilege) issues on a Vserver.
Step

If you want information about... Enter the command...
All local groups on the cluster
vserver cifs users-and-groups local-group show
All local groups on the Vserver
vserver cifs users-and-groups local-group show

-vserver vserver_name
users-and-groups local-group show command. See the man page on this command for
more information.
Example
The following example displays information about all local groups on Vserver vs1:
Vserver Group Name
Description
-------- --------------------------- ---------------------------vs1
vs1
vs1
BUILTIN\Power Users
vs1
BUILTIN\Users
All users
vs1
vs1
CIFS_SERVER\sales
Managing local group membership

You can manage local group membership by adding and removing local or domain users, or adding
and removing domain groups. This is useful if you want to control access to data based on access
controls placed on the group or if you want users to have privileges associated with that group.
If you no longer want a local user, domain user, or domain group to have access rights or privileges
based on membership in a group, you can remove the member from the group.
You must keep the following in mind when adding members to a local group:
You cannot add users to the special Everyone group.

The local group must exist before you can add a user to it.
The user must exist before you can add the user to a local group.
You cannot add a local group to another local group.
To add a domain user or group to a local group, Data ONTAP must be able to resolve the name to
a SID.
You must keep the following in mind when removing members from a local group:
You cannot remove members from the special Everyone group.

The group from which you want to remove a member must exist.
Data ONTAP must be able to resolve the names of members that you want to remove from the
group to a corresponding SID.

If you want to...
Use the command...
Add a member to a
group
vserver cifs users-and-groups local-group add-members

vserver vserver_name -group-name group_name membernames name[,...]
You can specify a comma-delimited list of local users, domain users, or

domain groups to add to the specified local group.
Remove a member
from a group
vserver cifs users-and-groups local-group remove-members

-vserver vserver_name -group-name group_name membernames name[,...]
You can specify a comma-delimited list of local users, domain users, or

domain groups to remove from the specified local group.
Examples
The following example adds a local user CIFS_SERVER\sue and a domain group
AD_DOM\dom_eng to the local group CIFS_SERVER\engineering on Vserver vs1:
cluster1::> vserver cifs users-and-groups local-group add-members -vserver
vs1 -group-name CIFS_SERVER\engineering -member-names CIFS_SERVER
\sue,AD_DOMAIN\dom_eng
The following example removes the local users CIFS_SERVER\sue and CIFS_SERVER
\james from the local group CIFS_SERVER\engineering on Vserver vs1:
cluster1::> vserver cifs users-and-groups local-group remove-members vserver vs1 -group-name CIFS_SERVER\engineering -member-names CIFS_SERVER
\sue,CIFS_SERVER\james
Related tasks
Displaying information about members of local groups on page 249

Displaying information about members of local groups
You can display a list of all members of local groups configured on the cluster or on a specified
Vserver. This information can be useful when troubleshooting file-access issues or user-rights
(privilege) issues.
Step

If you want to display information about... Enter the command...
Members of all local groups on the cluster
vserver cifs users-and-groups localgroup show-members
Members of all local groups on the Vserver
vserver cifs users-and-groups localgroup show-members -vserver vserver_name
users-and-groups local-group show-members command. See the man page on this
command for more information.
Example
The following example displays information about members of all local groups on Vserver
vs1:
cluster1::> vserver cifs users-and-groups local-group show-members -vserver
vs1
Vserver
Group Name
Members
--------- ---------------------------- -----------------------vs1
AD_DOMAIN\Domain Admins
AD_DOMAIN\dom_grp1
BUILTIN\Users
AD_DOMAIN\Domain Users
AD_DOMAIN\dom_usr1
CIFS_SERVER\james
Deleting a local group

You can delete a local group from a Vserver if it is no longer needed for determining access rights to
data associated with that Vserver or if it is no longer needed for assigning Vserver user rights
(privileges) to group members.
About this task
Keep the following in mind when deleting local groups:
The file system is not altered.

Windows Security Descriptors on files and directories that refer to this group are not adjusted.
If the group does not exist, an error is returned.
The special Everyone group cannot be deleted.
Built-in groups such as BUILTIN\Administrators BUILTIN\Users cannot be deleted.
Steps
1. Determine the name of the local group that you want to delete by displaying the list of local
groups on the Vserver:

vserver cifs users-and-groups local-group show -vserver vserver_name
2. Delete the local group:

vserver cifs users-and-groups local-group delete -vserver vserver_name
group-name group_name
3. Verify that the group is deleted:

Example
The following example deletes the local group CIFS_SERVER\sales associated with
Vserver vs1:
Vserver
Group Name
Description
--------- ---------------------------- ---------------------------vs1
vs1
vs1
BUILTIN\Power Users
vs1
BUILTIN\Users
All users
vs1
vs1
CIFS_SERVER\sales
cluster1::> vserver cifs users-and-groups local-group delete -vserver vs1 -group-name
CIFS_SERVER\sales
Vserver
Group Name
Description
--------- ---------------------------- ---------------------------vs1
vs1
vs1
BUILTIN\Power Users
vs1
BUILTIN\Users
All users
vs1
Updating domain user and group names in local databases

You can add domain users and groups to a CIFS server's local groups. These domain objects are
registered in local databases on the cluster. If a domain object is renamed, the local databases must be
manually updated.
About this task
You must specify the name of the Vserver on which you want to update domain names.
Steps


If you want to update domain users and
groups and...
Use this command...
Display domain users and groups that

vserver cifs users-and-groups updatesuccessfully updated and that failed to update names -vserver vserver_name
Display domain users and groups that
successfully updated
vserver cifs users-and-groups updatenames -vserver vserver_name -displayfailed-only false
Display only the domain users and groups

that fail to update
vserver cifs users-and-groups updatenames -vserver vserver_name -displayfailed-only true
Suppress all status information about updates
vserver cifs users-and-groups updatenames -vserver vserver_name -suppressall-output true
For more information, see the man pages on the vserver cifs users-and-groups
update-names command.
Example
The following example updates the names of domain users and groups associated with Vserver
vs1. For the last update, there is a dependent chain of names that needs to be updated:
cluster1::*> vserver cifs users-and-groups update-names -vserver vs1
Vserver:
SID:
Domain:
Out-of-date Name:
Updated Name:
Status:
vs1
S-1-5-21-123456789-234565432-987654321-12345
EXAMPLE1
dom_user1
dom_user2
Successfully updated
Vserver:
SID:
Domain:
Out-of-date Name:
Updated Name:
Status:
vs1
S-1-5-21-123456789-234565432-987654322-23456
EXAMPLE2
dom_user1
dom_user2
Successfully updated
Vserver:
SID:
Domain:
Out-of-date Name:
Updated Name:
vs1
S-1-5-21-123456789-234565432-987654321-123456
EXAMPLE1
dom_user3
dom_user4

Status:
Successfully updated; also updated SID
"S-1-5-21-123456789-234565432-987654321-123457"
to name "dom_user5"; also updated SID
"S-1-5-21-123456789-234565432-987654321-123458"
"S-1-5-21-123456789-234565432-987654321-123459"
"S-1-5-21-123456789-234565432-987654321-123460"
to name "dom_user8"
The command completed successfully. 7 Active Directory objects have been
updated.
Managing local privileges

You can manage local privileges by adding, removing, or resetting privileges for local and domain
user accounts and groups. You can also display information about privileges assigned to local and
domain user accounts and groups.
Related concepts
What local privileges are on page 232

Adding privileges to local or domain users or groups
You can manage user rights for local or domain users or groups by adding privileges. The added
privileges override the default privileges assigned to any of these objects. This provides enhanced
security by allowing you to customize what privileges a user or group has.
Before you begin
The local or domain user or group to which privileges will be added must already exist.
About this task
Adding a privilege to an object overrides the default privileges for that user or group. Adding a
privilege does not remove previously added privileges.
You must keep the following in mind when adding privileges to local or domain users or groups:
You can add one or more privileges.

When adding privileges to a domain user or group, Data ONTAP might validate the domain user
or group by contacting the domain controller.
The command might fail if Data ONTAP is unable to contact the domain controller.

Steps
1. Add one or more privileges to a local or domain user or group:

vserver cifs users-and-groups privilege add-privilege -vserver
vserver_name -user-or-group-name name -privileges privilege[,...]
The value for the -user-or-group-name parameter is a local user or group, or a domain user or
group.
-privileges privilege[,...] is a comma-delimited list of one or more privileges.
2. Verify that the desired privileges are applied to the object:

vserver cifs users-and-groups privilege show -vserver vserver_name useror-group-name name
Example
The following example adds the privileges SeTcbPrivilege and
SeTakeOwnershipPrivilege to the user CIFS_SERVER\sue on Vserver vs1:
cluster1::> vserver cifs users-and-groups privilege add-privilege -vserver
vs1 -user-or-group-name CIFS_SERVER\sue -privileges
SeTcbPrivilege,SeTakeOwnershipPrivilege
cluster1::> vserver cifs users-and-groups privilege show -vserver vs1
Vserver
User or Group Name
Privileges
--------- --------------------- --------------vs1
CIFS_SERVER\sue
SeTcbPrivilege
Removing privileges from local or domain users or groups

You can manage user rights for local or domain users or groups by removing privileges. This
provides enhanced security by allowing you to customize the maximum privileges that users and
groups have.
Before you begin
The local or domain user or group from which privileges will be removed must already exist.
About this task
You must keep the following in mind when removing privileges from local or domain users or
groups:
You can remove one or more privileges.

When removing privileges from a domain user or group, Data ONTAP might validate the domain
user or group by contacting the domain controller.
The command might fail if Data ONTAP is unable to contact the domain controller.

Steps
1. Remove one or more privileges from a local or domain user or group:

vserver cifs users-and-groups privilege remove-privilege -vserver
vserver_name -user-or-group-name name -privileges privilege[,...]
The value for the -user-or-group-name parameter is a local user or group or a domain user or
group.
-privileges privilege[,...] is a comma-delimited list of one or more privileges.
2. Verify that the desired privileges have been removed from the object:
Example
The following example removes the privileges SeTcbPrivilege and
SeTakeOwnershipPrivilege from the user CIFS_SERVER\sue on Vserver vs1:
Vserver
User or Group Name
Privileges
--------- --------------------- --------------vs1
CIFS_SERVER\sue
SeTcbPrivilege
cluster1::> vserver cifs users-and-groups privilege remove-privilege vserver vs1 -user-or-group-name CIFS_SERVER\sue -privileges
SeTcbPrivilege,SeTakeOwnershipPrivilege
Vserver
User or Group Name
Privileges
--------- --------------------- ------------------vs1
CIFS_SERVER\sue
-
Resetting privileges for local or domain users and groups

You can reset privileges for local or domain users and groups. This can be useful when you have
made modifications to privileges for a local or domain user or group and those modifications are no
longer wanted or needed.
About this task
Resetting privileges for a local or domain user or group removes any privilege entries for that object.
Steps
1. Reset the privileges on a local or domain user or group:

vserver cifs users-and-groups privilege reset-privilege -vserver
vserver_name -user-or-group-name name

The value for the -user-or-group-name parameter is a local or domain user or group.
2. Verify that the privileges are reset on the object:
Examples
The following example resets the privileges on the user CIFS_SERVER\sue on Vserver vs1.
By default, normal users do not have privileges associated with their accounts:
cluster1::> vserver cifs users-and-groups privilege show
Vserver
User or Group Name
Privileges
--------- --------------------- --------------vs1
CIFS_SERVER\sue
SeTcbPrivilege
cluster1::> vserver cifs users-and-groups privilege reset-privilege vserver vs1 -user-or-group-name CIFS_SERVER\sue
This table is currently empty.
The following example resets the privileges for the group BUILTIN\Administrators,
effectively removing the privilege entry:
Vserver
User or Group Name
Privileges
--------- ------------------------ ------------------vs1
SeRestorePrivilege
SeSecurityPrivilege
cluster1::> vserver cifs users-and-groups privilege reset-privilege vserver vs1 -user-or-group-name BUILTIN\Administrators
This table is currently empty.
Displaying information about privilege overrides

You can display information about custom privileges assigned to domain or local user accounts or
groups. This information helps you determine whether the desired user rights are applied.
Step

If you want to display information about...
Custom privileges for all domain and local users and vserver cifs users-and-groups
groups on a Vserver
privilege show -vserver
vserver_name
Custom privileges for a specific domain or local
user and group on a Vserver
vserver cifs users-and-groups

privilege show -vserver
vserver_name -user-or-group-name
name
users-and-groups privilege show command. See the man page for this command for
more information.
Example
The following command displays all privileges explicitly associated with local or domain
users and groups for Vserver vs1:
Vserver
User or Group Name
Privileges
--------- ----------------------------------vs1
BUILTIN\Administrators SeTakeOwnershipPrivilege
SeRestorePrivilege
vs1
CIFS_SERVER\sue
SeTcbPrivilege
Displaying information about file security and audit policy

on FlexVol volumes
You can display information about file security on files and directories on FlexVol volumes. You can
also display information about applied audit policies.
You can display information about file security and audit polices applied to data contained within
volumes and qtrees with the following security styles:
NTFS
UNIX
Mixed
You can display information about audit policies for auditing access events over the following NAS
protocols:
SMB (all versions)

NFSv4.x

Related concepts
on page 274
Related tasks
Displaying information about file security on NTFS security-style FlexVol

volumes
You can display information about file and directory security on NTFS security-style FlexVol
volumes, including what the security style and effective security styles are, what permissions are
applied, and information about DOS attributes. You can use the results to validate your security
configuration or to troubleshoot file access issues.
About this task
You must supply the name of the Vserver that contains the data and the path to the data whose file or
directory security information you want to display. If you want to customize the output, you can use
the following optional parameters to display information only about file and directory security
settings that match the specified parameters:
Optional parameter
Description
-fields
fieldsname,...
You can use this parameter to display information on the fields you
specify. You can use this parameter either alone or in combination with
other optional parameters.
-instance
Displays detailed information about all entries.
-volume-name
volume_name
Displays information where the specified path is relative to the specified

volume. If this parameter is not specified, the Vserver root volume is
taken as default.
-share-name
share_name
Displays information where the specified path is relative to the root of the
specified share. If this parameter is not specified, the Vserver root volume
is taken as default.
-lookup-names
{true|false}
If set to true, the command displays information about file and

directory security for files and directories where the information about
owner and group are stored as names.
If set to false, the command displays information about file and
directory security for files and directories where the information for
owner and group are stored as SIDs.

Optional parameter
Description
-expand-mask
{true|false}

directory security for files and directories where the hexadecimal bit
mask entries are store in expanded form.
mask entries are store in collapsed form.
Note: By default, if the value of -expand-mask is set to false, the
value displayed for the

Expanded Dos Attributes
output field is -. You must set the value of this option to true if you
want to display the expanded DOS attributes.
-security-style
{unix|ntfs|mixed|
unified}
Displays information for files and directories with paths in volumes of the
specified security style. This command is not supported for Vservers with
Infinite Volumes; therefore, the unified value is not valid for this
release.
This is the associated security type of the volume or qtree.
-effective-style
{unix|ntfs|mixed|
unified}
Displays information for files and directories with the specified effective
security style on the path. This command is not supported for Vservers
with Infinite Volumes; therefore, the unified value is not valid for this
release.
This is the security scheme in effect for a given file or directory. A file or
directory can have one of two security styles, either NTFS or UNIX. The
effective security style is important with mixed security-style volumes
and qtrees since a file or directory can have either NTFS-effective or
UNIX-effective security (but not both).
-dos-attributes
hex_integer
Displays information only for files and directories with the specified DOS
attributes.
-text-dos-attr
text
Displays information only for files and directories with the specified text
DOS attributes.
-expanded-dosattr text
Displays information only for files and directories with the specified
extended DOS attributes.
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.

Optional parameter
Description
-mode-bits
octal_permissions
UNIX mode bits in Octal form.
-text-mode-bits
text
UNIX mode bits in text form.
-acls
security_acls
ACLs. You can enter the following information:
Type of ACL, which can be NTFS or NFSv4

For NTFS security-style volumes and qtrees, the ACL type must be
NTFS.
Control bits in the security descriptors
Owner, which applies only in the case of NTFS security descriptors
Group, which applies only in the case of NTFS security descriptors
Access Control Entries (ACEs), which includes both discretionary
access control list (DACL) and system access control list (SACL)
access control entries (ACEs) in the ACL
Note: UNIX-related output fields contain display-only UNIX file permission information. NTFS
security-style volumes and qtrees use only NTFS file permissions and Windows users and groups
when determining file access rights.
Step
1. Display file and directory security settings:

vserver security file-directory show -vserver vserver_name -path path
optional_parameters
Examples
The following example displays the security information about the path /vol4 in Vserver vs1:
cluster::> vserver security file-directory show -vserver vs1 -path /vol4
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
DOS Attributes in Text:
Expanded Dos Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
Unix Mode Bits in Text:
ACLs:
vs1
/vol4
ntfs
ntfs
10
----D--0
0
777
rwxrwxrwx
NTFS Security Descriptor
Control:0x8004
Owner:BUILTIN\Administrators
Group:BUILTIN\Administrators
DACL - ACEs

ALLOW-Everyone-0x1f01ff
ALLOW-Everyone-0x10000000-OI|CI|IO
The following example displays the security information with expanded masks about the
path /data/engineering in Vserver vs1:
cluster::> vserver security file-directory show -vserver vs1 -path -path /data/
engineering -expand-mask true
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
...0 .... .... ....
.... ..0. .... ....
.... .... 0... ....
.... .... ..0. ....
.... .... ...1 ....
.... .... .... .0..
.... .... .... ..0.
.... .... .... ...0
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/data/engineering
ntfs
ntfs
10
----D--0x10
= Offline
= Sparse
= Normal
= Archive
= Directory
= System
= Hidden
= Read Only
0
0
777
rwxrwxrwx
Control:0x8004
1...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.1..
..0.
...0
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Self Relative
RM Control Valid
SACL Protected
DACL Protected
SACL Inherited
DACL Inherited
SACL Inherit Required
DACL Inherit Required
SACL Defaulted
SACL Present
DACL Defaulted
DACL Present
Group Defaulted
Owner Defaulted
DACL - ACEs
0... .... .... .... ....
.0.. .... .... .... ....
..0. .... .... .... ....
...0 .... .... .... ....
.... ...0 .... .... ....
.... .... ...1 .... ....
.... .... .... 1... ....
.... .... .... .1.. ....
.... .... .... ..1. ....
.... .... .... ...1 ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
....
....
....
....
....
....
....
....
....
....
...1
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
1...
.1..
..1.
...1
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Generic Read
Generic Write
Generic Execute
Generic All
System Security
Synchronize
Write Owner
Write DAC
Read Control
Delete
Write Attributes
Read Attributes
Delete Child
Execute
Write EA
Read EA
Append
Write
Read

0...
.0..
..0.
...1
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Generic Read
Generic Write
Generic Execute
Generic All
System Security
Synchronize
Write Owner
Write DAC
Read Control
Delete
Write Attributes
Read Attributes
Delete Child
Execute
Write EA
Read EA
Append
Write
Read
Displaying information about file security on mixed security-style FlexVol

volumes
You can display information about file and directory security on mixed security-style FlexVol
volumes, including what the security style and effective security styles are, what permissions are
applied, and information about UNIX owners and groups. You can use the results to validate your
security configuration or to troubleshoot file access issues.
About this task
the following optional parameters to display information only about file and directory security
settings that match the specified parameters:
Optional parameter
Description
-fields
fieldsname, ...
-instance
-volume-name
volume_name

taken as default.
-share-name
share_name

Optional parameter
Description
-lookup-names
{true|false}
If set to true, the command displays information about file and directory
security for files and directories where the information about owner and
group are stored as names. If set to false, the command displays
information about file and directory security for files and directories
where the information for owner and group are stored as SIDs.
-expand-mask
{true|false}

mask entries are store in expanded form.
mask entries are store in collapsed form.
Note: By default, if the value of -expand-mask is set to false, the
value displayed for the
Expanded Dos Attributes
output field is -. You must set the value of this option to true if you
want to display the expanded DOS attributes.
-security-style
{unix|ntfs|mixed|
unified}
release.
-effective-style
{unix|ntfs|mixed|
unified}
security-style on the path. This command is not supported for Vservers
release.
effective security style is important with mixed security-style volumes and
qtrees since a file or directory can have either NTFS or UNIX effective
security (but not both).
-dos-attributes
hex_integer
attributes.
-text-dos-attr
text
DOS attributes.

Optional parameter
Description
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.
-mode-bits
octal_permissions
-text-mode-bits
text
-acls
security_acls

For NTFS security-style volumes and qtrees, the ACL type must be
NTFS.
Note: This field is empty for files and directories using UNIX security
that have only mode bit permissions applied (no NFSv4 ACLs).
Note: Mixed security-style volumes and qtrees can contain some files and directories that use
UNIX file permissions, either mode bits or NFSv4 ACLs, and some files and directories that use
Step

optional_parameters
Examples
The following example displays the security information about the path /projects in
Vserver vs1 in expanded-mask form. This mixed security-style path has a UNIX-effective
security style:
cluster1::> vserver security file-directory show -vserver vs1 -path /projects -expandmask true

Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
...0 .... .... ....
.... ..0. .... ....
.... .... 0... ....
.... .... ..0. ....
.... .... ...1 ....
.... .... .... .0..
.... .... .... ..0.
.... .... .... ...0
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/projects
mixed
unix
10
----D--0x10
= Offline
= Sparse
= Normal
= Archive
= Directory
= System
= Hidden
= Read Only
0
1
700
rwx------
The following example displays the security information about the path /data in Vserver vs1.
This mixed security-style path has an NTFS-effective security style:
cluster1::> vserver security file-directory show -vserver vs1 -path /
data
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/data
mixed
ntfs
10
----D--0
0
777
rwxrwxrwx
Control:0x8004
DACL - ACEs
Displaying information about file security on UNIX security-style FlexVol

volumes
You can display information about file and directory security on UNIX security-style FlexVol
volumes, including what the security styles and effective security styles are, what permissions are
applied, and information about UNIX owners and groups. You can use the results to validate your
security configuration or to troubleshoot file access issues.
About this task

the following optional parameters to display information only about file and directory security that
matches the specified parameters:
Optional parameter
Description
-fields
fieldsname, ...
-instance
-volume-name
volume_name

volume. If this parameter is not specified, the Vserver root volume is taken
as default.
-share-name
share_name
-lookup-names
{true|false}
Although you can specify a value for the -lookup-names parameter, this
parameter does not apply for UNIX security-style volumes. In NFSv4
ACLs, ACE's are displayed in SID format; therefore, lookup name are not
stored as a name. The name is stored as SID and that is what is returned
even if this value is set to true.
-expand-mask
{true|false}
Displays information where the hexadecimal bit mask entry is set to one of
the following:
true displays information where the bit mask entries are store in
expanded form.
false displays information where the bit mask entries are store in
collapsed form.
-security-style
{unix|ntfs|mixed|
unified}
release.
-effective-style
{unix|ntfs|mixed|
unified}
release.
security (but not both).

Optional parameter
Description
-dos-attributes
hex_integer
attributes.
-text-dos-attr
text
DOS attributes.
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.
-mode-bits
octal_permissions UNIX mode bits in Octal form.
-text-mode-bits
text
-acls system_acls

For UNIX security-style volumes and qtrees, the ACL type must be
NFSv4.
This does not apply for UNIX security-style volumes and qtrees.
Note: This field is empty for UNIX-security style files and directories
that have only mode bit permissions applied (no NFSv4 ACLs).
Note: UNIX security-style volumes and qtrees use only UNIX file permissions, either mode bits or
NFSv4 ACLs when determining file access rights.
Step

optional_parameters
Examples
The following example displays the security information about the path /home in Vserver vs1:
cluster1::> vserver security file-directory show -vserver vs1 -path /home
Vserver: vs1
File Path: /home
Security Style: unix
Effective Style: unix
DOS Attributes: 10
DOS Attributes in Text: ----D--Expanded Dos Attributes: Unix User Id: 0
Unix Group Id: 1
Unix Mode Bits: 700
Unix Mode Bits in Text: rwx-----ACLs: -
The following example displays the security information about the path /home in Vserver vs1
in expanded-mask form:
cluster1::> vserver security file-directory show -vserver vs1 -path /home -expand-mask
true
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
...0 .... .... ....
.... ..0. .... ....
.... .... 0... ....
.... .... ..0. ....
.... .... ...1 ....
.... .... .... .0..
.... .... .... ..0.
.... .... .... ...0
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/home
unix
unix
10
----D--0x10
= Offline
= Sparse
= Normal
= Archive
= Directory
= System
= Hidden
= Read Only
0
1
700
rwx------

using the CLI
You can display information about NTFS audit policies on FlexVol volumes, including what the
security styles and effective-security styles are, what permissions are applied, and information about

system access control lists. You can use the results to validate your security configuration or to
troubleshoot auditing issues.
About this task
You must supply the name of the Vserver that contains the path to the files or directories whose audit
information you want to display. If you want to customize the output, you can use the following
optional parameters to display information only about file and directory security that matches the
specified parameters:
Optional parameter
Description
-fields
fieldsname, ...
-instance
-volume-name
volume_name

taken as default.
-share-name
share_name
-lookup-names
{true|false}
Displays information where the information about owner and group is set
to one of the following:
-expand-mask
{true|false}
-security-style
{unix|ntfs|mixed|
unified}
true displays information where the lookup name is stored as a name.

false displays information where the lookup name is stored as a SID.
Displays information where the hexadecimal bit mask entry is set to one
of the following:
expanded form.
collapsed form.
release.

Optional parameter
Description
-effective-style
{unix|ntfs|mixed|
unified}
release.
-dos-attributes
hex_integer
attributes.
-text-dos-attr
text
DOS attributes.
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.
-mode-bits
octal_permissions
-text-mode-bits
text
-acls system_acls

Owner, which applies only in the case of NTFS security descriptors.
Group, which applies only in the case of NTFS security descriptors.
Access Control Entries (ACEs) which includes both discretionary
access control entries (ACEs) in the ACL.
Note: NTFS security-style volumes and qtrees use only NTFS system access control lists for audit
policies. Mixed security-style volumes and qtrees can contain some files and directories that are of
NTFS security style, which can have NTFS audit policies applied to them.

Step
1. Display audit policy settings:

optional_parameters
Example
The following example displays the audit policy information about the path /corp in Vserver
vs1. This NTFS-security-style path has a NTFS-effective security style. The NTFS security
descriptor contains both a SUCCESS and a SUCCESS/FAIL SACL entry:
vserver security file-directory show -vserver vs1 -path /corp
Vserver: vs1
File Path:
Security Style:
Effective Style:
DOS Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
/corp
ntfs
ntfs
10
----D--0
0
777
rwxrwxrwx
Control:0x8014
Owner:DOMAIN\Administrator
SACL - ACEs
ALL-DOMAIN\Administrator-0x100081-OI|CI|SA|FA
SUCCESSFUL-DOMAIN\user1-0x100116-OI|CI|SA
DACL - ACEs
ALLOW-BUILTIN\Administrators-0x1f01ff-OI|CI
ALLOW-BUILTIN\Users-0x1f01ff-OI|CI
ALLOW-CREATOR OWNER-0x1f01ff-OI|CI
ALLOW-NT AUTHORITY\SYSTEM-0x1f01ff-OI|CI
Displaying information about NFSv4 audit policies on FlexVol volumes

You can display information about NFSv4 audit policies on FlexVol volumes, including what the
security styles and effective security styles are, what permissions are applied, and information about
About this task
optional parameters to display information only about the audit policies that match the specified
parameters:

Optional parameter
Description
-fields
fieldsname, ...
-instance
-volume-name
volume_name

volume. If this parameter is not specified, the Vserver root volume is taken
as default.
-share-name
share_name
-lookup-names
{true|false}
-expand-mask
{true|false}

Displays information where the hexadecimal bit mask entry is set to one of
the following:
expanded form.
collapsed form.
-security-style
{unix|ntfs|mixed|
unified}
release.
-effective-style
{unix|ntfs|mixed|
unified}
release.
security (but not both). You can apply NFSv4 system access control lists
to files and directories with UNIX-effective security style.

Optional parameter
Description
-dos-attributes
hex_integer
attributes.
-text-dos-attr
text
DOS attributes.
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.
-mode-bits
octal_permissions UNIX mode bits in Octal form.
-text-mode-bits
text
-acls system_acls

For UNIX security-style volumes and qtrees, the ACL type must be
NFSv4.
Note: This field is empty for files and directories that are using UNIX
security with only mode bit permissions applied (no NFSv4 ACLs).
Note: Mixed security-style volumes and qtrees can contain some files and directories that use
UNIX file permissions, either mode bits or NFSv4 ACLs, as well as some files and directories that
use NTFS file permissions. Each file or directory can be one of the two security styles, but not
both. You can apply NFSv4 audit policies to file and directories with UNIX security style.

Step

optional_parameters
Examples
The following example displays the security information about the path /lab in Vserver vs1.
This UNIX security-style path has an NFSv4 ACL with a system access control list:
cluster::> vserver security file-directory show -vserver vs1 -path /lab
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/lab
unix
unix
11
----D--R
0
0
0
--------NFSV4 Security Descriptor
Control:0x8014
SACL - ACEs
SUCCESSFUL-S-1-520-0-0xf01ff-SA
FAILED-S-1-520-0-0xf01ff-FA
DACL - ACEs
ALLOW-S-1-520-1-0xf01ff
Managing NTFS file security and audit policies on Vservers

with FlexVol volumes using the CLI
You can manage NTFS file security and audit policies on Vservers with FlexVol volumes by using
the CLI. This removes the need to use a remote client to manage file security. Using the CLI can
significantly reduce the time it takes to apply security on many files and folders using a single
command.
You can use the vserver security file-directory command family to implement file
security and audit policies on files and folders that have NTFS effective security:
All files and folders contained within NTFS security-style volumes and qtrees have NTFS
effective security.
Mixed security-style volumes and qtrees can contain some files and folders that have UNIX
effective security and use UNIX file permissions, either mode bits or NFSv4 ACLs and NFSv4
audit policies, and some files and folders that have NTFS effective security and use NTFS file
permissions and audit policies.
You can use the CLI to apply file permissions and audit policies to files and folders of NTFS and
UNIX effective security-style in the mixed volume or qtree.

Note: All files and folders contained within UNIX security-style volumes and qtrees have UNIX
effective security. The CLI cannot be used to manage UNIX file security and audit policies on
UNIX security-style volumes and qtrees.
Related concepts
Related tasks
Configuring and applying file security on NTFS files and folders on page 276
Configuring and applying audit policies on NTFS files and folders on page 290
Use cases for using the CLI to set file and folder security
Because you can apply and manage file and folder security locally without involvement from a
remote client, you can significantly reduce the time it takes to set bulk security on a large number of
files or folders.
You can benefit from using the CLI to set file and folder security in the following use cases:
Storage of files in large enterprise environments, such as file storage in home directories
Migration of data
Change of Windows domain
Standardization of file security and audit policies across NTFS file systems
Limitations when using the CLI to set file and folder security
You need to be aware of certain limitations when using the CLI to set file and folder security.
The vserver security file-directory command family does not support setting NFSv4
ACLs.
You can only apply NTFS security descriptors to NTFS files and folders.
The vserver security file-directory command family does not support setting file
security (NTFS or NFSv4) on Vservers with Infinite Volumes.
How security descriptors are used to apply file and folder security
Security descriptors contain the access control lists that determine what actions a user can perform on
files and folders, and what is audited when a user accesses files and folders.
Permissions
Permissions are allowed or denied by an object's owner and determine what

actions an object (users, groups, or computer objects) can perform on
specified files or folders.
Security
descriptors
Security descriptors are data structures that contain security information that
define permissions associated with a file or folder.

Access control lists Access control lists are the lists contained within a security descriptor that
contain information on what actions users, groups, or computer objects can
(ACLs)
perform on the file or folder to which the security descriptor is applied. The
security descriptor can contain the following two types of ACLs:
Discretionary access control lists (DACLs)

System access control lists (SACLs)
DACLs contain the list of SIDS for the users, groups, and computer objects
Discretionary
access control lists who are allowed or denied access to perform actions on files or folders.
DACLs contain zero or more access control entries (ACEs).
(DACLs)
System access
control lists
(SACLs)
SACLs contain the list of SIDS for the users, groups, and computer objects
for which successful or failed auditing events are logged. SACLs contain zero
or more access control entries (ACEs).
Access Control
Entries (ACEs)
ACEs are individual entries in either DACLs or SACLs:
Permission
inheritance
A DACL access control entry specifies the access rights that are allowed
or denied for particular users, groups, or computer objects.
A SACL access control entry specifies the success or failure events to log
when auditing specified actions performed by particular users, groups, or
computer objects.
Permission inheritance describes how permissions defined in security

descriptors are propagated to an object from a parent object. Only inheritable
permissions are inherited by child objects. When setting permissions on the
parent object, you can decide whether folders, sub-folders, and files can
inherit them with Apply to this-folder, sub-folders, and files.
Related tasks
Configuring standard NTFS file permissions by using the Windows Security tab on page 202
Configuring advanced NTFS file permissions using the Windows Security tab on page 204
Configuring and applying file security on NTFS files and folders

There are several steps you must perform to apply NTFS file security. First, you create an NTFS
security descriptor and add DACLs to the security descriptor. Next you create a security policy and
add policy tasks. You then apply the security policy to a Vserver with FlexVol volumes.
About this task
After applying the security policy, you can monitor the security policy job and then verify the
settings on the applied file security.

Steps
1. Creating an NTFS security descriptor on page 278

Creating an NTFS security descriptor is the first step in configuring and applying NTFS access
control lists (ACLs) to files and folders residing within Vservers with FlexVol volumes. Later,
you will associate the security descriptor to the file or folder path in a policy task.
2. Adding NTFS DACL access control entries to the NTFS security descriptor on page 280
Adding DACL access control entries to the NTFS security descriptor is the second step in
configuring and applying NTFS ACLs to a file or folder. Each entry identifies which object is
allowed or denied access, and defines what the object can or cannot do to the files or folders
defined in the ACE.
3. Creating a security policy on page 283
Creating a security policy for a Vserver with FlexVol volumes is the third step in configuring and
applying ACLs to a file or folder. A policy acts as a container for various tasks where each task is
a single entry that can be applied to files or folders. You later add tasks to the security policy.
4. Adding a task to the security policy on page 284
Creating and adding a policy task to a security policy is the fourth step in configuring and
applying ACLs to files or folders in Vservers with FlexVol volumes. When you create the policy
task, you associate the task with a security policy. You can add one or more task entries to a
security policy.
5. Applying security policies on page 287
Applying a security policy to a Vserver with FlexVol volumes is the last step to creating and
applying NTFS ACLs to files or folders.
6. Monitoring the security policy job on page 288
When applying the security policy to a Vserver with FlexVol volumes, you can monitor the
progress of the task by monitoring the security policy job. This is helpful if you want to ascertain
that the application of the security policy succeeded. This is also helpful if you have a longrunning job where you are applying bulk security to a large number of files and folders.
7. Verifying the applied file security on page 288
You can verify the file security settings to confirm that the files or folders on the Vserver with
FlexVol volumes to which you applied the security policy have the desired settings.
Related concepts
Limitations when using the CLI to set file and folder security on page 275
How security descriptors are used to apply file and folder security on page 275
Configuring audit policies on NTFS security-style files and directories on page 507
Related tasks
Configuring standard NTFS file permissions by using the Windows Security tab on page 202
Configuring advanced NTFS file permissions using the Windows Security tab on page 204
Creating an NTFS security descriptor

control lists (ACLs) to files and folders residing within Vservers with FlexVol volumes. Later, you
will associate the security descriptor to the file or folder path in a policy task.
About this task
You can create NTFS security descriptors for files and folders residing within NTFS security-style
volumes, or for files and folders residing on mixed-security-style volumes.
By default, when a security descriptor is created, four discretionary access control list ACEs are
added to that security descriptor. The four default ACEs are as follows:
Object
Access
type
Access rights
Where to apply the permissions
Allow
Full Control
this-folder, sub-folders, files
BUILTIN\Users
Allow
Full Control
CREATOR OWNER
Allow
Full Control
NT AUTHORITY
\SYSTEM
Allow
Full Control
When creating the security descriptor, you must specify the following two parameters:
Required parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which you
want to apply the security descriptor.
-ntfs-sd SD_name
Security descriptor
The name to assign to the security descriptor.
You can customize the security descriptor configuration by using the following optional parameters:

Optional parameter
Description
-owner name_or_SID
Owner of the security descriptor

The owner of the security descriptor can modify the permissions on the
file (or folder) or files (or folders) to which the security descriptor is
applied and can give other users the right to take ownership of the object
or objects to which the security descriptor is applied. You can use any of
the following formats when specifying the value for this parameter:
SID
DOMAIN\user-name
user-name@DOMAIN
user-name@FQDN
If you specify any of the three name formats for the value of -owner,
keep in mind that the value is case insensitive.
-group name_or_SID
Primary Group of the Owner

Specifies the owner group of the security descriptor. You can specify the
owner group using either a group name or SID. You can use any of the
following formats when specifying the value for this parameter:
SID
DOMAIN\group-name
group-name@DOMAIN
group-name@FQDN
If you specify any of the three name formats for the value of -group,
Note: Before you can use this parameter, you must change to advanced
privilege level by using the set privilege command.
-control-flagsraw Hex_integer
Raw control flags

Specifies the control flags in the security descriptor. Available in
advanced mode only.
privilege level by using the following command:
Steps
1. If you want to use advanced parameters, set the privilege level to advanced:
2. Create a security descriptor:

vserver security file-directory ntfs create -vserver vserver_name -ntfssd SD_name optional_parameters
Example
vserver security file-directory ntfs create -ntfs-sd sd1 -vserver vs1 owner domain\joe
3. Verify that security descriptor configuration is correct:

vserver security file-directory ntfs show -vserver vserver_name -ntfs-sd
SD_name
Example
vserver security file-directory ntfs show -vserver vs1 -ntfs-sd sd1
Vserver: vs1
Security Descriptor Name: sd1
Owner of the Security Descriptor: DOMAIN\joe
4. If you are in advanced privilege level, return to the admin privilege level:
Adding NTFS DACL access control entries to the NTFS security descriptor
Adding DACL access control entries to the NTFS security descriptor is the second step in
configuring and applying NTFS ACLs to a file or folder. Each entry identifies which object is
allowed or denied access, and defines what the object can or cannot do to the files or folders defined
in the ACE.
About this task
You can add one or more ACEs (access control entries) to the security descriptor's DACL
(discretionary access control list).
If the security descriptor contains a DACL that has existing ACEs, the command adds the new ACE
to the DACL. If the security descriptor does not contain a DACL, the command creates the DACL
and adds the new ACE to it.
When adding an ACE to the DACL, you must provide information for the following four required
parameters:
Required parameters Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which the
security descriptor is applied.

-ntfs-sd SD_name
Security descriptor
The name of the security descriptor to which you want to add DACL
entries.
-access-type
{deny|allow}
Access type
Specifies whether the discretionary access control entry is an Allow or
Deny type of access control.
-account
name_or_SID
Account
The account to which you want to apply the discretionary access control
entry. You can specify the account by using a user name or SID. You can
use any of the following formats when specifying the value for this
parameter:
SID
DOMAIN\user-name
user-name@DOMAIN
user-name@FQDN
If you specify any of the three name formats for the value of -account,
keep in mind that the value is not case-sensitive.
You can optionally customize DACL entries by specifying what rights you want to allow or deny for
the account specified in the -account parameter. There are three mutually exclusive methods for
specifying rights:
Rights
Advanced rights
Raw rights (advanced-privilege)
Optional rights
parameters
Description
-rights {noaccess|fullcontrol|modify|
read-and-execute|
read|write}
Rights
You can choose only one of the parameter values.

Optional rights
parameters
Description
-advanced-rights
advanced_access_
right
Advanced rights
You can specify one or more of the following advanced-right values by
using a comma-delimited list:
-raw-rights
Hex_integer
read-data
write-data
append-data
read-ea
write-ea
execute-file
delete-child
read-attr
write-attr
delete
read-perm
write-perm
write-owner
full control
Raw rights
You can specify raw rights as a Hex integer. Available in advanced mode
only.
Note: This is an advanced privilege level parameter. Before you can use
this parameter, you must change to advanced-privilege level by using
the following command:
Note: If you do not specify rights for the DACL entry, the default is to set the rights to Full
Control.
You can optionally customize DACL entries by specifying how to apply inheritance.
Optional apply to
parameter
Description
-apply-to {thisApply DACL entry to

folder|sub-folder| You can choose one or more of the parameter values by entering a
files}

Note: If you do not specify this parameter, the default is to apply this DACL entry to this folder,
Steps
1. Add a DACL entry to a security descriptor:

vserver security file-directory ntfs dacl add -vserver vserver_name ntfs-sd SD_name -access-type {allow|deny} -account name_or_SID
optional_parameters
Example
vserver security file-directory ntfs dacl add -ntfs-sd sd1 -access-type
deny -account domain\joe -rights full-control -apply-to this-folder vserver vs1
2. Verify that the DACL entry is correct:

vserver security file-directory ntfs dacl show -vserver vserver_name ntfs-sd SD_name -access-type {allow|deny} -account name_or_SID
Example
vserver security file-directory ntfs dacl show -vserver vs1 -ntfs-sd sd1
-access-type deny -account domain\joe
Vserver: vs1
Security Descriptor Name:
Allow or Deny:
Account Name or SID:
Access Rights:
Advanced Access Rights:
Apply To:
Access Rights:
sd1
deny
DOMAIN\joe
full-control
this-folder
full-control
Creating a security policy

applying ACLs to a file or folder. A policy acts as a container for various tasks where each task is a
single entry that can be applied to files or folders. You later add tasks to the security policy.
About this task
The tasks that you add to the security policy contain associations between NTFS security descriptor
and file or folder paths; therefore, you should associate the policy with a Vserver with FlexVol
volumes (containing NTFS or mixed security-style volumes).
There are only two parameters for this command, and both are required.

Required
parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders with which you
want to associate the policy.
-policy-name
policy_name
policy_name
The name of the security policy.
Steps
1. Create a security policy:

vserver security file-directory policy create -vserver vserver_name policy-name policy_name
Example
vserver security file-directory policy create -policy-name policy1 vserver vs1
2. Verify the security policy:

vserver security file-directory policy show
Example
Vserver
Policy Name
------------------------vs1
policy1
Adding a task to the security policy

Creating and adding a policy task to a security policy is the fourth step in configuring and applying
ACLs to files or folders in Vservers with FlexVol volumes. When you create the policy task, you
associate the task with a security policy. You can add one or more task entries to a security policy.
About this task
The security policy is a container for a task. The task contains definitions for the security
configuration of a file (or folder) or set of files (or folders).
A task refers to a single operation that can be done by a security policy to files or folders with
NTFS or mixed security.
A task associates file or folder paths to the security descriptor that needs to be set on the files or
folders, and also defines the rules of inheritance.
Every task in a policy is uniquely identified by the file or folder path.

A policy cannot have duplicate task entries. There can be only one task per path.
There can be a maximum of 10,000 tasks entries per policy.
By associating a task with a security policy, you are associating the policy's assigned security
descriptor to the file or folder path in the policy task.
When adding tasks to security policies, you must specify the following four required parameters:
Required
parameters
Description
-vserver
vserver_name
Vserver
Name of the Vserver that contains the files and folders to which you want to
apply the security descriptor.
-policy-name
policy_name
Policy name
Name of the security policy to which you want to add the task.
-path path
Path
Path of the files or folders on which to apply the security descriptor
associated with this task.
-ntfs-sd
SD_name
Security descriptor
The name of the security descriptor that you want to associate with the file or
folder path in the task.
Because it is required parameter, it is recommended that you create the
security descriptor and add DACL ACEs (access control entries) and SACL
ACEs (if desired) prior to creating the task, then associate the security
descriptor with the file or folder path in the task, and finally add the task to
the security policy.
A security descriptor can contain multiple ACEs, both DACL ACEs and
SACL ACEs.
Optional
parameter
Description
-security-type
{ntfs| nfsv4}
Security type
Whether the security descriptor associated with this task is an NTFS or a
NFSv4 security descriptor type. If you do not specify a value for this optional
parameter, the default is ntfs.
Note: The nfsv4 security descriptor type is not supported in this release.
If you specify this optional parameter, you must enter ntfs for the value
of the -security-type parameter.

Optional
parameter
Description
-ntfs-mode
{propagate|
ignore| replace}
Propagation mode
Specifies how to propagate security settings to child subfolders and files.
This setting determines how child files and folders contained within a parent
folder inherit access control and audit information from the parent folder.
The three parameters correspond to three types of propagation modes:
Propagate The Propagate mode propagates inheritable permissions to all
subfolders and files. Existing permissions are not replaced.
Replace
The Replace mode replaces existing permissions on all

subfolders and files with inheritable permissions.
Ignore
The Ignore mode does not allow permissions on this file or

folder to be replaced.
If this parameter is not specified, the default value is propagate.

-index-number
integer
Index position
Specifies the index number of a task. Tasks are applied in order. A task with
a larger index number is applied after a task with a lower index number. If
you do not specify this optional parameter, new tasks are applied to the end
of the index list.
The range of supported values is 1 through 9999. If there is a gap between
the highest existing index number and the value entered for this parameter,
the task with this number is considered to be the last task in the policy and is
treated as having an index number of the previous highest index plus one.
Note: If you specify an index number that is already assigned to an
existing task, the task is added with that index number and the existing
task index number is auto arranged to the next number in the table.
Steps
1. Add a task with an associated security descriptor to the security policy:

vserver security file-directory policy-task add -vserver vserver_name policy-name policy_name -path path -ntfs-sd SD_name optional_parameters
Example
vserver security file-directory policy task add -vserver vs1 -policyname policy1 -path /home -security-type ntfs -ntfs-mode propagate -ntfssd sd1 -index-num 1
2. Verify the policy task configuration:

vserver security file-directory policy-task show -vserver vserver_name policy-name policy_name -path path
Example
vserver security file-directory policy task show
Vserver: vs1
Policy: policy1
Index
File/Folder
Path
-----------1
/home
Security
Type
-------ntfs
NTFS
Mode
-----propagate
NTFS Security
Descriptor Name
----------------sd1
Applying security policies

About this task
You use the vserver security file-directory apply command to apply security settings
defined in the security policy to files and folders residing within FlexVol volumes (NTFS or mixed
security style).
There are only two parameters for this command and both are required:
Required
parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which you want
to apply the policy with its associated task.
-policy-name
policy_name
Policy_name
The name of the security policy to apply.
Step
1. Apply a security policy:

vserver security file-directory policy apply -vserver vserver_name
policy-name policy_name
Example
vserver security file-directory apply -vserver vs1 -policy-name policy1
The policy apply job is scheduled.
Monitoring the security policy job

When applying the security policy to a Vserver with FlexVol volumes, you can monitor the progress
of the task by monitoring the security policy job. This is helpful if you want to ascertain that the
application of the security policy succeeded. This is also helpful if you have a long-running job
where you are applying bulk security to a large number of files and folders.
About this task
To display detailed information about a security policy job, use the -instance parameter.
Step
1. Monitor the security policy job:

vserver security file-directory job show -vserver vserver_name
Example
vserver security file-directory job show -vserver vs1
Job ID Name
Vserver
Node
State
------ -------------------- ---------- -------------- ---------53322 Fsecurity Apply
vs1
node1
Success
Description: File Directory Security Apply Job
Verifying the applied file security

You can verify the file security settings to confirm that the files or folders on the Vserver with
FlexVol volumes to which you applied the security policy have the desired settings.
About this task
You must supply the name of the Vserver that contains the data and the path to the file and folders on
which you want to verify security settings. You can use the optional -expand-mask parameter to
display detailed information about the security settings.
Step
1. Display file and folder security settings:

vserver security file-directory show -vserver vserver_name -path path [expand-mask true]
Example
vserver security file-directory show -vserver vs1 -path /data/
engineering -expand-mask true

Vserver: vs1
File Path:
Security Style:
Effective Style:
DOS Attributes:
...0 .... .... ....
.... ..0. .... ....
.... .... 0... ....
.... .... ..0. ....
.... .... ...1 ....
.... .... .... .0..
.... .... .... ..0.
.... .... .... ...0
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
/data/engineering
ntfs
ntfs
10
----D--0x10
= Offline
= Sparse
= Normal
= Archive
= Directory
= System
= Hidden
= Read Only
0
0
777
rwxrwxrwx
Control:0x8004
1...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
..0.
...0
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.1..
..0.
...0
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Self Relative
RM Control Valid
SACL Protected
DACL Protected
SACL Inherited
DACL Inherited
SACL Inherit Required
DACL Inherit Required
SACL Defaulted
SACL Present
DACL Defaulted
DACL Present
Group Defaulted
Owner Defaulted
DACL - ACEs
0... .... .... .... ....
.0.. .... .... .... ....
..0. .... .... .... ....
...0 .... .... .... ....
.... ...0 .... .... ....
.... .... ...1 .... ....
.... .... .... 1... ....
.... .... .... .1.. ....
.... .... .... ..1. ....
.... .... .... ...1 ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
.... .... .... .... ....
....
....
....
....
....
....
....
....
....
....
...1
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
1...
.1..
..1.
...1
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
1...
.1..
..1.
...1
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Generic Read
Generic Write
Generic Execute
Generic All
System Security
Synchronize
Write Owner
Write DAC
Read Control
Delete
Write Attributes
Read Attributes
Delete Child
Execute
Write EA
Read EA
Append
Write
Read
0... .... .... .... .... .... ....
.0.. .... .... .... .... .... ....
..0. .... .... .... .... .... ....
...1 .... .... .... .... .... ....
.... ...0 .... .... .... .... ....
.... .... ...0 .... .... .... ....
.... .... .... 0... .... .... ....
.... .... .... .0.. .... .... ....
.... .... .... ..0. .... .... ....
.... .... .... ...0 .... .... ....
.... .... .... .... .... ...0 ....
....
....
....
....
....
....
....
....
....
....
....
=
=
=
=
=
=
=
=
=
=
=
Generic Read
Generic Write
Generic Execute
Generic All
System Security
Synchronize
Write Owner
Write DAC
Read Control
Delete
Write Attributes

....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
....
....
....
....
....
....
....
....
0...
.0..
..0.
...0
=
=
=
=
=
=
=
=
Read Attributes
Delete Child
Execute
Write EA
Read EA
Append
Write
Read
Configuring and applying audit policies on NTFS files and folders

There are several steps you must perform to apply audit policies to NTFS files and folders. First, you
create an NTFS security descriptor and add SACLs to the security descriptor. Next you create a
security policy and add policy tasks. You then apply the security policy to a Vserver with FlexVol
volumes.
About this task
After applying the security policy, you can monitor the security policy job and then verify the
settings on the applied audit policy.
Steps
1. Creating an NTFS security descriptor on page 291

control lists (ACLs) to files and folders residing within Vservers with FlexVol volumes. Later,
you will associate the security descriptor to the file or folder path in a policy task.
2. Adding NTFS SACL access control entries to the NTFS security descriptor on page 293
Adding SACL access control entries to the NTFS security descriptor is the second step in creating
NTFS audit policies for files or folders in Vservers with FlexVol volumes. Each entry identifies
the user or group that you want to audit. The SACL entry defines whether you want to audit
successful or failed access attempts.
3. Creating a security policy on page 296
applying ACLs to a file or folder. A policy acts as a container for various tasks where each task is
a single entry that can be applied to files or folders. You later add tasks to the security policy.
4. Adding a task to the security policy on page 297
Creating and adding a policy task to a security policy is the fourth step in configuring and
applying ACLs to files or folders in Vservers with FlexVol volumes. When you create the policy
task, you associate the task with a security policy. You can add one or more task entries to a
security policy.
5. Applying security policies on page 300
6. Monitoring the security policy job on page 301
When applying the security policy to a Vserver with FlexVol volumes, you can monitor the
progress of the task by monitoring the security policy job. This is helpful if you want to ascertain

that the application of the security policy succeeded. This is also helpful if you have a longrunning job where you are applying bulk security to a large number of files and folders.
7. Verifying the applied audit policy on page 301
You can verify the audit policy to confirm that the files or folders on the Vserver with FlexVol
volumes to which you applied the security policy have the desired audit security settings.
Creating an NTFS security descriptor
control lists (ACLs) to files and folders residing within Vservers with FlexVol volumes. Later, you
will associate the security descriptor to the file or folder path in a policy task.
About this task
You can create NTFS security descriptors for files and folders residing within NTFS security-style
volumes, or for files and folders residing on mixed-security-style volumes.
By default, when a security descriptor is created, four discretionary access control list ACEs are
added to that security descriptor. The four default ACEs are as follows:
Object
Access
type
Access rights
Where to apply the permissions
Allow
Full Control
BUILTIN\Users
Allow
Full Control
CREATOR OWNER
Allow
Full Control
NT AUTHORITY
\SYSTEM
Allow
Full Control
When creating the security descriptor, you must specify the following two parameters:
Required parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which you
want to apply the security descriptor.
-ntfs-sd SD_name
Security descriptor
The name to assign to the security descriptor.

Optional parameter
Description
-owner name_or_SID
Owner of the security descriptor

The owner of the security descriptor can modify the permissions on the
file (or folder) or files (or folders) to which the security descriptor is
applied and can give other users the right to take ownership of the object
or objects to which the security descriptor is applied. You can use any of
SID
DOMAIN\user-name
user-name@DOMAIN
user-name@FQDN
If you specify any of the three name formats for the value of -owner,
-group name_or_SID
Primary Group of the Owner

Specifies the owner group of the security descriptor. You can specify the
owner group using either a group name or SID. You can use any of the
following formats when specifying the value for this parameter:
SID
DOMAIN\group-name
group-name@DOMAIN
group-name@FQDN
If you specify any of the three name formats for the value of -group,
privilege level by using the set privilege command.
-control-flagsraw Hex_integer
Raw control flags

Specifies the control flags in the security descriptor. Available in
advanced mode only.
privilege level by using the following command:
Steps
1. If you want to use advanced parameters, set the privilege level to advanced:
2. Create a security descriptor:

vserver security file-directory ntfs create -vserver vserver_name -ntfssd SD_name optional_parameters
Example
vserver security file-directory ntfs create -ntfs-sd sd1 -vserver vs1 owner domain\joe
3. Verify that security descriptor configuration is correct:

vserver security file-directory ntfs show -vserver vserver_name -ntfs-sd
SD_name
Example
vserver security file-directory ntfs show -vserver vs1 -ntfs-sd sd1
Vserver: vs1
Security Descriptor Name: sd1
Owner of the Security Descriptor: DOMAIN\joe
4. If you are in advanced privilege level, return to the admin privilege level:
Adding NTFS SACL access control entries to the NTFS security descriptor
Adding SACL access control entries to the NTFS security descriptor is the second step in creating
NTFS audit policies for files or folders in Vservers with FlexVol volumes. Each entry identifies the
user or group that you want to audit. The SACL entry defines whether you want to audit successful
or failed access attempts.
About this task
You can add one or more ACEs (access control entries) to the security descriptor's SACL (system
access control list).
If the security descriptor contains a SACL that has existing ACEs, the command adds the new ACE
to the SACL. If the security descriptor does not contain a SACL, the command creates the SACL and
adds the new ACE to it.
When adding an ACE to the SACL, you must provide information for the following four required
parameters:
Required parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which the
security descriptor is applied.

Required parameters
Description
-ntfs-sd SD_name
Security descriptor
The name of the security descriptor to which you want to add SACL
entries.
-access-type
{failure|success}
Access type
Specifies whether the system access control entry is a Success or Failure
audit type.
-account
name_or_SID
Account
The account on which to apply the system access control entry. You can
specify the account by using a user name or a SID. You can use any of
SID
DOMAIN\user-name
user-name@DOMAIN
user-name@FQDN
If you specify any of the three name formats for the value of -account,
keep in mind that the value is not case-sensitive.
You can configure SACL entries by specifying what rights you want to audit for success or failure
events for the account specified in the -account parameter. There are three mutually exclusive
methods for specifying rights:
Rights
Advanced rights
Raw rights (advanced-privilege)
To audit events, configure one of the three rights parameters:

Optional rights
parameters
Description
-rights {noaccess|fullcontrol|modify|
read-and-execute|
read|write}
Rights
You can choose only one of the parameter values.

Optional rights
parameters
Description
-advanced-rights
advanced_access_r
ight
Advanced rights
You can specify one or more of the following advanced-right values by
using a comma-delimited list:
-raw-rights
Hex_integer
read-data
write-data
append-data
read-ea
write-ea
execute-file
delete-child
read-attr
write-attr
delete
read-perm
write-perm
write-owner
full control
Raw rights
You can specify raw rights as a Hex integer. Available in advanced mode
only.
Note: This is an advanced-privilege-level parameter. Before you can
use this parameter, you must change to advanced privilege level by
using the following command:
Note: If you do not specify rights for the SACL entry, the default setting is Full Control.
You can optionally customize SACL entries by specifying how to apply inheritance.
Optional apply to
parameter
Description
-apply-to {thisfolder|sub-folder|
files}
Apply SACL entry to

You can choose one or more of the parameter values by entering a
Note: If you do not specify this parameter, the default is to apply this SACL entry to this folder,

Steps
1. Add a SACL entry to a security descriptor:

vserver security file-directory ntfs sacl add -vserver vserver_name ntfs-sd SD_name -access-type {failure|success} -account name_or_SID
optional_parameters
Example
vserver security file-directory ntfs sacl add -ntfs-sd sd1 -access-type
failure -account domain\joe -rights full-control -apply-to this-folder vserver vs1
2. Verify that the SACL entry is correct:

vserver security file-directory ntfs sacl show -vserver vserver_name ntfs-sd SD_name -access-type {failure|success} -account name_or_SID
Example
vserver security file-directory ntfs sacl show -vserver vs1 -ntfs-sd sd1
-access-type deny -account domain\joe
Vserver: vs1
Security Descriptor Name:
Access type for Specified Access Rights:
Account Name or SID:
Access Rights:
Advanced Access Rights:
Apply To:
Access Rights:
sd1
failure
DOMAIN\joe
full-control
this-folder
full-control
Creating a security policy

applying ACLs to a file or folder. A policy acts as a container for various tasks where each task is a
single entry that can be applied to files or folders. You later add tasks to the security policy.
About this task
The tasks that you add to the security policy contain associations between NTFS security descriptor
and file or folder paths; therefore, you should associate the policy with a Vserver with FlexVol
volumes (containing NTFS or mixed security-style volumes).
There are only two parameters for this command, and both are required.

Required
parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders with which you
want to associate the policy.
-policy-name
policy_name
policy_name
The name of the security policy.
Steps
1. Create a security policy:

vserver security file-directory policy create -vserver vserver_name policy-name policy_name
Example
vserver security file-directory policy create -policy-name policy1 vserver vs1
2. Verify the security policy:

Example
Vserver
Policy Name
------------------------vs1
policy1
Adding a task to the security policy

Creating and adding a policy task to a security policy is the fourth step in configuring and applying
ACLs to files or folders in Vservers with FlexVol volumes. When you create the policy task, you
associate the task with a security policy. You can add one or more task entries to a security policy.
About this task
The security policy is a container for a task. The task contains definitions for the security
configuration of a file (or folder) or set of files (or folders).
A task refers to a single operation that can be done by a security policy to files or folders with
NTFS or mixed security.
A task associates file or folder paths to the security descriptor that needs to be set on the files or
folders, and also defines the rules of inheritance.
Every task in a policy is uniquely identified by the file or folder path.

A policy cannot have duplicate task entries. There can be only one task per path.
There can be a maximum of 10,000 tasks entries per policy.
By associating a task with a security policy, you are associating the policy's assigned security
descriptor to the file or folder path in the policy task.
When adding tasks to security policies, you must specify the following four required parameters:
Required
parameters
Description
-vserver
vserver_name
Vserver
Name of the Vserver that contains the files and folders to which you want to
apply the security descriptor.
-policy-name
policy_name
Policy name
Name of the security policy to which you want to add the task.
-path path
Path
Path of the files or folders on which to apply the security descriptor
associated with this task.
-ntfs-sd
SD_name
Security descriptor
The name of the security descriptor that you want to associate with the file or
folder path in the task.
Because it is required parameter, it is recommended that you create the
security descriptor and add DACL ACEs (access control entries) and SACL
ACEs (if desired) prior to creating the task, then associate the security
descriptor with the file or folder path in the task, and finally add the task to
the security policy.
A security descriptor can contain multiple ACEs, both DACL ACEs and
SACL ACEs.
Optional
parameter
Description
-security-type
{ntfs| nfsv4}
Security type
Whether the security descriptor associated with this task is an NTFS or a
NFSv4 security descriptor type. If you do not specify a value for this optional
parameter, the default is ntfs.
Note: The nfsv4 security descriptor type is not supported in this release.
If you specify this optional parameter, you must enter ntfs for the value
of the -security-type parameter.

Optional
parameter
Description
-ntfs-mode
{propagate|
ignore| replace}
Propagation mode
Specifies how to propagate security settings to child subfolders and files.
This setting determines how child files and folders contained within a parent
folder inherit access control and audit information from the parent folder.
The three parameters correspond to three types of propagation modes:
Propagate The Propagate mode propagates inheritable permissions to all
subfolders and files. Existing permissions are not replaced.
Replace
The Replace mode replaces existing permissions on all

subfolders and files with inheritable permissions.
Ignore
The Ignore mode does not allow permissions on this file or

folder to be replaced.
If this parameter is not specified, the default value is propagate.

-index-number
integer
Index position
Specifies the index number of a task. Tasks are applied in order. A task with
a larger index number is applied after a task with a lower index number. If
you do not specify this optional parameter, new tasks are applied to the end
of the index list.
The range of supported values is 1 through 9999. If there is a gap between
the highest existing index number and the value entered for this parameter,
the task with this number is considered to be the last task in the policy and is
treated as having an index number of the previous highest index plus one.
Note: If you specify an index number that is already assigned to an
existing task, the task is added with that index number and the existing
task index number is auto arranged to the next number in the table.
Steps
1. Add a task with an associated security descriptor to the security policy:

vserver security file-directory policy-task add -vserver vserver_name policy-name policy_name -path path -ntfs-sd SD_name optional_parameters
Example
vserver security file-directory policy task add -vserver vs1 -policyname policy1 -path /home -security-type ntfs -ntfs-mode propagate -ntfssd sd1 -index-num 1
2. Verify the policy task configuration:

vserver security file-directory policy-task show -vserver vserver_name policy-name policy_name -path path
Example
vserver security file-directory policy task show
Vserver: vs1
Policy: policy1
Index
File/Folder
Path
-----------1
/home
Security
Type
-------ntfs
NTFS
Mode
-----propagate
NTFS Security
Descriptor Name
----------------sd1
Applying security policies

About this task
You use the vserver security file-directory apply command to apply security settings
defined in the security policy to files and folders residing within FlexVol volumes (NTFS or mixed
security style).
There are only two parameters for this command and both are required:
Required
parameters
Description
-vserver
vserver_name
Vserver
The name of the Vserver that contains the files and folders to which you want
to apply the policy with its associated task.
-policy-name
policy_name
Policy_name
The name of the security policy to apply.
Step
1. Apply a security policy:

vserver security file-directory policy apply -vserver vserver_name
policy-name policy_name
Example
vserver security file-directory apply -vserver vs1 -policy-name policy1
The policy apply job is scheduled.
Monitoring the security policy job

When applying the security policy to a Vserver with FlexVol volumes, you can monitor the progress
of the task by monitoring the security policy job. This is helpful if you want to ascertain that the
application of the security policy succeeded. This is also helpful if you have a long-running job
where you are applying bulk security to a large number of files and folders.
About this task
To display detailed information about a security policy job, use the -instance parameter.
Step
1. Monitor the security policy job:

vserver security file-directory job show -vserver vserver_name
Example
vserver security file-directory job show -vserver vs1
Job ID Name
Vserver
Node
State
------ -------------------- ---------- -------------- ---------53322 Fsecurity Apply
vs1
node1
Success
Description: File Directory Security Apply Job
Verifying the applied audit policy

You can verify the audit policy to confirm that the files or folders on the Vserver with FlexVol
volumes to which you applied the security policy have the desired audit security settings.
About this task
You use the vserver security file-directory show command to display audit policy
information. You must supply the name of the Vserver that contains the data and the path to the data
whose file or folder audit policy information you want to display.
Step

Example
The following command displays the audit policy information applied to the path /corp in
Vserver vs1. The path has both a SUCCESS and a SUCCESS/FAIL SACL entry applied to it:

cluster::> vserver security file-directory show -vserver vs1 -path /
corp
Vserver:
File Path:
Security Style:
Effective Style:
DOS Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
vs1
/corp
ntfs
ntfs
10
----D--0
0
777
rwxrwxrwx
Control:0x8014
SACL - ACEs
ALL-DOMAIN\Administrator-0x100081-OI|CI|
SA|FA
DACL - ACEs
ALLOW-BUILTIN\Administrators-0x1f01ff-OI|
CI
Commands for managing NTFS security descriptors

There are specific Data ONTAP commands for managing security descriptors. You can create,
modify, delete, and display information about security descriptors.
If you want to...
Use this command...
Create NTFS security descriptors
vserver security file-directory ntfs

create
Modify existing NTFS security

descriptors

modify
Display information about existing NTFS vserver security file-directory ntfs show
security descriptors
Delete NTFS security descriptors

delete
See the man pages for the vserver security file-directory ntfs commands for more
information.
Commands for managing NTFS DACL access control entries

There are specific Data ONTAP commands for managing DACL access control entries (ACEs). You
can add ACEs to NTFS DACLs at any time. You can also manage existing NTFS DACLs by
modifying, deleting, and displaying information about ACEs in DACLs.
If you want to...
Use this command...
Create ACEs and add them to NTFS

DACLs
vserver security file-directory ntfs dacl

add
Modify existing ACEs in NTFS DACLs

modify
Display information about existing ACEs vserver security file-directory ntfs dacl
in NTFS DACLs
show
Remove existing ACEs from NTFS
DACLs

remove
See the man pages for the vserver security file-directory ntfs dacl commands for
more information.
Commands for managing NTFS SACL access control entries

There are specific Data ONTAP commands for managing SACL access control entries (ACEs). You
can add ACEs to NTFS SACLs at any time. You can also manage existing NTFS SACLs by
modifying, deleting, and displaying information about ACEs in SACLs.
If you want to...
Use this command...
Create ACEs and add them to NTFS

SACLs
vserver security file-directory ntfs sacl

add
Modify existing ACEs in NTFS SACLs

modify
Display information about existing ACEs vserver security file-directory ntfs sacl
in NTFS SACLs
show
Remove existing ACEs from NTFS
SACLs

remove
See the man pages for the vserver security file-directory ntfs sacl commands for
more information.
Commands for managing security policies

There are specific Data ONTAP commands for managing security policies. You can display
information about policies and you can delete policies. You cannot modify a security policy.
If you want to...
Use this command...
Create security policies
vserver security file-directory policy create
Display information about

security policies
Delete security policies
vserver security file-directory policy delete
See the man pages for the vserver security file-directory policy commands for more
information.
Commands for managing security policy tasks

There are Data ONTAP commands for adding, modifying, removing, and displaying information
about security policy tasks.
If you want to...
Use this command...
Add security policy tasks
vserver security file-directory policy task

add
Modify security policy tasks

modify
Display information about security vserver security file-directory policy task

policy tasks
show
Remove security policy tasks

remove
See the man pages for the vserver security file-directory policy task commands for
more information.
Commands for managing security policy jobs

There are Data ONTAP commands for pausing, resuming, stopping, and displaying information
about security policy jobs.
If you want to...
Use this command...
Pause security policy jobs
vserver security file-directory job pause

vserver vserver_name -id integer

If you want to...
Use this command...
Resume security policy jobs
vserver security file-directory job resume

Display information about

security policy jobs
vserver security file-directory job show

vserver vserver_name
You can determine the job ID of a job using this command.

Stop security policy jobs
vserver security file-directory job stop

See the man pages for the vserver security file-directory job commands for more
information.
Using security tracing to verify or troubleshoot file and

directory access
You can add permission tracing filters to instruct Data ONTAP to log information about why the
CIFS server on a Vserver with FlexVol volumes allows or denies a client or user's request to perform
an operation. This can be useful when you want to verify that your file access security scheme is
appropriate or when you want to troubleshoot file access issues.
How security tracing works

Security tracing allows you to configure a filter that detects client operations over CIFS on the
Vserver with FlexVol volumes, and traces all access checks matching that filter. You can then view
the tracing results, which provides a convenient summary of the reason that access was allowed or
denied.
When you want to verify the security settings for CIFS access on files and folders on a Vserver or if
you are faced with an access problem, you can quickly add a filter to turn on permission tracing.
The following list outlines important facts about how security tracing works:
Data ONTAP applies security traces at a Vserver level.

Each incoming request is screened to see if it matches filtering criteria of any enabled security
traces.
Traces are performed for both file and folder access requests.
Traces can filter based on the following criteria:
Client IP
CIFS path
Windows name
UNIX name
Requests are screened for Allowed and Denied access response results.
Each request matching filtering criteria of enabled traces is recorded in the trace results log.
The storage administrator can configure a timeout on a filter to automatically disable it.
If a request matches multiple filters, the results from the filter with the highest index number is
recorded.
The storage administrator can print results from the trace results log to determine why an access
request was allowed or denied.
Related concepts
How to interpret security trace results on page 315

Related tasks
Types of access checks security traces monitor

Access checks for a file or folder are done based on multiple criteria. Security traces conveniently
monitor operations on all these criteria.
The types of access checks that security traces monitor include the following:
Volume and qtree security style

Effective security of the file system containing the files and folders on which operations are
requested
User mapping
Share-level permissions
File-level permissions
Considerations when creating security traces

You should keep several considerations in mind when you create security traces on Vservers with
FlexVol volumes. For example, you need to know on which protocols you can create a trace, which
security-styles are supported, and what the maximum number of active traces is.
You can only create security traces on Vservers with FlexVol volumes.
Each security trace filter entry is Vserver specific.
You must specify the Vserver on which you want to run the trace.
You can add permission tracing filters for CIFS requests only.
You must set up the CIFS server on the Vserver on which you want to create trace filters.
You can create security traces for files and folders residing on NTFS, UNIX, and mixed securitystyle volumes and qtrees.
You can add a maximum of 10 permission tracing filters per Vserver.
You must specify a filter index number when creating or modifying a filter.
Filters are considered in order of the index number. The criteria in a filter with a higher index
number is considered before the criteria with a lower index number. If the request being traced
matches criteria in multiple enabled filters, only the filter with the highest index number is
triggered.
After you have created and enabled a security trace filter, you must perform some file or folder
requests on a client system to generate activity that the trace filter can capture and log in the trace
results log.
You should add permission tracing filters for file access verification or troubleshooting purposes
only.
Adding permission tracing filters has a minor effect on controller performance.
When you are done with verification or troubleshooting activity, you should disable or remove all
permission tracing filters. Furthermore, the filtering criteria you select should be as specific as
possible so that Data ONTAP does not send a large number of trace results to the log.
Performing security traces

Performing a security trace involves creating a security trace filter, verifying the filter criteria,
generating access requests on a client that match filter criteria, and viewing the results.
About this task
After you are finished using a security filter to capture trace information, you can modify the filter
and reuse it, or disable it if you no longer need it. After viewing and analyzing the filter trace results,
you can then delete them if they are no longer needed.
Steps
1. Creating security trace filters on page 308

You can create security trace filters that detect CIFS client operations on Vservers with FlexVol
volumes and trace all access checks matching the filter. You can use the results from security
traces to validate your configuration or to troubleshoot access issues.
2. Displaying information about security trace filters on page 310
You can display information about security trace filters configured on your Vserver. This enables
you to see which types of access events each filter traces.
3. Displaying security trace results on page 311
You can display the security trace results generated for file operations that match security trace
filters. You can use the results to validate your file access security configuration or to troubleshoot
CIFS file access issues.
4. Modifying security trace filters on page 312
If you want to change the optional filter parameters used to determine which access events are
traced, you can modify existing security trace filters.
5. Deleting security trace filters on page 313
When you no longer need a security trace filter entry, you can delete it. Because you can have a
maximum of 10 security trace filters per Vserver, deleting unneeded filters enables you to create
new filters if you have reached the maximum.
6. Deleting security trace records on page 314

After you finish using a filter trace record to verify file access security or to troubleshoot CIFS
client access issues, you can delete the record from the security trace log results.
7. Deleting all security trace records on page 315
If you do not want to keep any of the existing security trace records, you can delete all of the
records on a node with a single command.
Related concepts
How security tracing works on page 305

Considerations when creating security traces on page 306
How to interpret security trace results on page 315
Creating security trace filters
You can create security trace filters that detect CIFS client operations on Vservers with FlexVol
volumes and trace all access checks matching the filter. You can use the results from security traces
to validate your configuration or to troubleshoot access issues.
About this task
There are two required parameters for this command:

-vserver
vserver_name
Vserver
The name of the Vserver that contains the files or folders on which you
want to apply the security trace filter.
-index
index_number
Filter index number

The index number you want to apply to the filter. You are limited to a
maximum of 10 trace filters per Vserver. The allowed values for this
parameter are 1 through 10.
A number of optional filter parameters enable you to customize the security trace filter so that you
can narrow down the results produced by the security trace:
Filter parameter
Description
-client-ip
IP_Address
This filter specifies the IP address from which the user is accessing the
Vserver.

Filter parameter
Description
-path path
This filter specifies the path on which to apply the permission trace filter.
The value for -path can use either of the following formats:
The complete path, starting from the root of the share

A partial path, relative to the root of the share
You must use NFS style directory separators in the path value.
-windows-name
win_user_name or unix-name
unix_user_name
You can specify either the Windows user name or UNIX user name whose
access requests you want to trace. The user name variable is case
insensitive. You cannot specify both a Windows user name and a UNIX
user name in the same filter.
Note: Even though you can only trace CIFS access events, the mapped
UNIX user and the mapped UNIX users' groups might be used when
performing access checks on mixed or UNIX security-style data.
-trace-allow
{yes|no}
Tracing for deny events is always enabled for a security trace filter. You
can optionally trace allow events. To trace allow events, you set this
parameter to yes.
-enabled {enabled| You can enable or disable the security trace filter. By default, the security
trace filter is enabled.
disabled}
-time-enabled
integer
You can specify a timeout for the filter, after which it is disabled.
Steps
1. Create a security trace filter:

vserver security trace filter create -vserver vserver_name -index
index_number filter_parameters
Example
The following command creates a security trace filter for any user accessing a file with a share
path \\server\share1\dir1\dir2\file.txt from the IP address 10.10.10.7. The filter uses
a complete path for the -path option. The client's IP address used to access data is 10.10.10.7.
The filter times out after 30 minutes:
vserver security trace filter create -vserver vs1 -index 1 -path /dir1/
dir2/file.txt -time-enabled 30 -client-ip 10.10.10.7
filter_parameters is a list of optional filter parameters.
For more information, see the man pages for the command.
2. Verify the security trace filter entry:

vserver security trace filter show -vserver vserver_name -index
index_number
Example
vserver security trace filter show -vserver vs1 -index 1
Vserver Index
-------- -----vs1
1
Client-ip
----------10.10.10.7
Win-Path
--------/dir1/dir2/file.txt
Trace-Allow
-----------
windows-name
---------
Example
The following command creates a security trace filter using a relative path for the -path
option. The filter traces access for a Windows user named joe. Joe is accessing a file with a
share path \\server\share1\dir1\dir2\file.txt. The filter traces allow and deny
events:
cluster1::> vserver security trace filter create -vserver vs1 -index 2 -path /dir1/
dir2/file.txt -trace-allow yes -windows-name mydomain\joe
cluster1::> vserver security trace filter show -vserver vs1 -index 2
Vserver Index
Client-ip
Win-Path
Trace-Allow windows-name
-------- ------ ----------- ------------------- --------vs1
2
/dir1/dir2/file.txt
yes
mydomain\joe
Displaying information about security trace filters

You can display information about security trace filters configured on your Vserver. This enables
you to see which types of access events each filter traces.
Step
1. Display information about security trace filter entries by using the vserver security trace
filter show command.
Example
vserver security trace filter show -vserver vs1
Vserver
-------vs1
vs1
Index
-----1
2
Client-ip
----------
Win-Path
/dir3/dir4/
Trace-Allow
----------yes
-
windows-name
--------mydomain\joe
For more information about using this command, see the man pages.
Displaying security trace results

You can display the security trace results generated for file operations that match security trace
filters. You can use the results to validate your file access security configuration or to troubleshoot
CIFS file access issues.
Before you begin
An enabled security trace filter must exist and operations must have been performed from a CIFS
client that matches the security trace filter to generate security trace results.
About this task
You can display a summary of all security trace results, or you can customize what information is
displayed in the output by specifying optional parameters. This can be helpful when the security trace
results contain a large number of records. If you do not specify any of the optional parameters, the
following is displayed:
Vserver name
Node name
Security trace index number
User name
Security style
Path
Reason
If you want to customize the output, you can use the following optional parameters:
Optional parameter
Description
-fields
field_name, ...
Displays output on the fields you choose. You can use this parameter either
alone or in combination with other optional parameters.
-instance
Displays detailed information about all security trace events.
-node node_name
Displays information only about events on the specified node.
-vserver
vserver_name
Displays information only about events on the specified Vserver.
-seqnum integer
Displays information about the event with this sequence number.
-keytime date
Displays information about the events that occurred at the specified time.
-index integer
Displays information about the events that occurred as a result of the filter
corresponding to the specified index number.
-client-ip
IP_address
Displays information about the events that occurred as a result of file

access from the specified client IP address.

Optional parameter
Description
-path path

access to the specified path.
-user-name
user_name

access by the specified Windows or UNIX user.
-security-style
security_style
Displays information about the events that occurred on file systems with
the specified security style.
-result text
Displays information about the events that have the specified result.
Step
1. Display security trace filter results by using the vserver security trace trace-result
show command.
Example
vserver security trace trace-result show -user-name domain\user
Vserver: vs1
Node
Index
Filter Details
-------- ------- --------------------node1
3
User:domain\user
Security Style:mixed
Path:/dir1/dir2/
Reason
----------------------------Access denied by explicit ACE
node1
Access denied by explicit ACE
User:domain\user
Security Style:unix
Path:/dir1/
Related references
List of effective security styles on file systems on page 316

Modifying security trace filters
If you want to change the optional filter parameters used to determine which access events are traced,
you can modify existing security trace filters.
About this task
You must identify which security trace filter you want to modify by specifying the Vserver name on
which the filter is applied and the index number of the filter. You can modify all the optional filter
parameters.
Steps
1. Modify a security trace filter:

vserver security trace filter modify -vserver vserver_name -index
index_number filter_parameters
Example
The following command modifies the security trace filter with the index number 1. The filter
traces events for any user accessing a file with a share path \\server
\share1\dir1\dir2\file.txt from any IP address. The filter uses a complete path for the path option. The filter traces allow and deny events:
vserver security trace filter modify -vserver vs1 -index 1 -path /dir1/
dir2/file.txt -trace-allow yes
vserver_name is the name of the Vserver on which you want to apply a security trace filter.
index_number is the index number that you want to apply to the filter. The allowed values for
this parameter are 1 through 10.

filter_parameters is a list of optional filter parameters.
For more information about how to use the command, see the man pages.
2. Verify the security trace filter entry:
vserver security trace filter show -vserver vserver_name -index
index_number
Example
vserver security trace filter show -vserver vs1 -index 1
Vserver Index
-------- -----vs1
1
Client-ip
----------
Win-Path
Trace-Allow
----------yes
windows-name
---------
Deleting security trace filters

When you no longer need a security trace filter entry, you can delete it. Because you can have a
maximum of 10 security trace filters per Vserver, deleting unneeded filters enables you to create new
filters if you have reached the maximum.
About this task
To uniquely identify the security trace filter that you want to delete, you must specify the following:
The name of the Vserver to which the trace filter is applied

The filter index number of the trace filter
Steps
1. Identify the filter index number of the security trace filter entry you want to delete:
vserver security trace filter show -vserver vserver_name

Example
Vserver
-------vs1
vs1
Index
-----1
2
Client-ip
----------
Win-Path
/dir3/dir4/
Trace-Allow
----------yes
-
windows-name
2. Using the filter index number information from the previous step, delete the filter entry:
vserver security trace filter delete -vserver vserver_name -index
index_number
Example
vserver security trace filter delete -vserver vs1 -index 1
3. Verify that the security trace filter entry is deleted:

vserver security trace filter show -vserver vserver_name
Example
Vserver Index
-------- -----vs1
2
Client-ip
----------
Win-Path
--------/dir3/dir4/
Trace-Allow
-----------
windows-name
Deleting security trace records

After you finish using a filter trace record to verify file access security or to troubleshoot CIFS client
access issues, you can delete the record from the security trace log results.
About this task
Before you can delete a security trace record, you must know the record's sequence number.
Note: Each Vserver can store a maximum of 128 trace records. If the maximum is reached on a
Vserver, the oldest trace records are automatically deleted as new ones are added. If you do not
want to manually delete trace records on a Vserver, you can let Data ONTAP automatically delete
the oldest trace results after the maximum is reached to make room for new results.
Steps
1. Identify the sequence number of the record you want to delete:

vserver security trace trace-result show -vserver vserver_name -instance
2. Delete the security trace record:

vserver security trace trace-result delete -node node_name -vserver
vserver_name -seqnum integer

Example
vserver security trace trace-result delete -vserver vs1 -node node1 seqnum 999
-node node_name is the name of the cluster node on which the permission tracing event that you
want to delete occurred. This is a required parameter.

-vserver vserver_name is the name of the Vserver on which the permission tracing event that
you want to delete occurred. This is a required parameter.

-seqnum integer is the sequence number of the log event that you want to delete. This is a
required parameter.
Deleting all security trace records
If you do not want to keep any of the existing security trace records, you can delete all of the records
on a node with a single command.
Step
1. Delete all security trace records:

vserver security trace trace-result delete -node node_name -vserver
vserver_name *
-node node_name is the name of the cluster node on which the permission tracing event that you
want to delete occurred. This is a required parameter.

-vserver vserver_name is the name of the Vserver on which the permission tracing event that
you want to delete occurred. This is a required parameter.
How to interpret security trace results

Security trace results provide the reason that a request was allowed or denied. Output displays the
result as a combination of the reason for allowing or denying access and the location within the
access checking pathway where access is either allowed or denied. You can use the results to isolate
and identify why actions are or are not allowed.
Security trace results also list the effective security style of the file system containing files or folders
matching the filter criteria under the Filter details field.
The following is an example of the output from the Reason field that appears in the trace results log
in an Allow result type:
Access is allowed because CIFS implicit permission grants requested
access while opening existing file or directory.
The following is an example of the output from the Reason field that appears in the trace results log
in a Deny result type:
Access is denied. The requested permissions are not granted by the
ACE while checking for child-delete access on the parent.

The following is an example of the output from the Filter details field that appears in the trace results
log:
Security Style: MIXED and NT ACL
Related tasks

List of effective security styles on file systems
Security trace results provide information about the effective security style on file systems containing
files and folders monitored by trace filters, which helps you understand why access operations are
allowed or denied.
It is not always obvious what the effective security style is on files and folders, or what the impact of
the effective security style is on a user who is trying to access files or folders over CIFS or NFS. The
list of effective security styles provided in the following table helps you decide what parameter
setting to use when you create trace filters, and helps you interpret trace results obtained when
running security traces:
Effective security styles
Description
SECURITY_NONE
Security not set
SECURITY_UNIX_MODEBITS
UNIX and UNIX permissions
SECURITY_UNIX_ACL
UNIX and NFSv4 ACL
SECURITY_UNIX_SD
UNIX and NT ACL
SECURITY_MIXED_MODEBITS
MIXED and UNIX permissions
SECURITY_MIXED_ACL
MIXED and NFSv4 ACL
SECURITY_MIXED_SD
MIXED and NT ACL
SECURITY_NTFS_MODEBITS
NTFS and UNIX permissions
SECURITY_NTFS_ACL
NTFS and NFSv4 ACL
SECURITY_NTFS_SD
NTFS and NT ACL
SECURITY_UNIX
UNIX
SECURITY_MIXED
MIXED
SECURITY_NTFS
NTFS
SECURITY_MODEBITS
UNIX permissions
SECURITY_ACL
NFSv4 ACL
SECURITY_SD
NT ACL
List of reasons why access is allowed

Before you can interpret security trace results, you need to have a list of the reasons that access can
be allowed. You must also have the list of the locations within the access checking pathway where
access can be allowed. This information also aids you in planning your security trace filter.
A complete Allow result is derived by concatenating a location to the reason.
List of reasons
The list of Allow reasons is provided in the following table:
Access allowed reason
Access is allowed because the operation is trusted and no security is configured
Access is allowed because the user has UNIX root privileges
Access is allowed because the user has UNIX owner privileges
Access is allowed because UNIX implicit permission grants requested access
Access is allowed because the CIFS user is owner
Access is allowed because the user has take ownership privilege
Access is allowed because there is no CIFS ACL
Access is allowed because CIFS implicit permission grants requested access
Access is allowed because the security descriptor is corrupted and the user is a member of the
Administrators group
Access is allowed because the ACL is corrupted and the user is a member of the Administrators
group
Access is allowed because the use has UNIX permissions
Access is allowed because explicit ACE grants requested access
Access is allowed because the user has audit privileges
Access is allowed because the user has superuser credentials
Access is allowed because inherited ACE grants requested access
List of locations
The list of locations that are concatenated onto a reason are provided in the following table:

Locations within the access checking
path ...
Locations within the access checking path ...
while traversing the directory.
while reading the directory.
while truncating the file.
while deleting the target during rename.
while creating the directory.
while deleting the child during rename.
while creating the file.
while writing data in the parent during rename.
while checking parent's modebits during

delete.
while adding a directory during rename.
while deleting the child.
while adding a file during rename.
while checking for child-delete access on the

parent.
while updating the target directory during rename.
while reading security descriptor.
while setting attributes.
while accessing the link.
while writing to the file.
while creating or writing the file.
while extending the coral file.
while opening existing file or directory.
while creating the vdisk file.
while setting the attributes.
while checking for stale locks before open.
while deleting a file or a directory.
while reading the file.
while truncating a hidden file.
List of reasons why access is denied

Before you can interpret security trace results, you need a list of the reasons that access can be
denied. You must also have the list of the locations within the access checking pathway where access
can be denied. This information also aids you in planning your security trace filter.
A complete Deny result is derived by concatenating a location to the reason.
List of reasons
The list of Deny reasons is provided in the following table:
Reasons for denying access
Access is denied by UNIX permissions
Access is denied by an explicit ACE
Access is denied. The requested permissions are not granted by the ACE

Reasons for denying access
Access is denied. The security descriptor is corrupted
Access is denied. The ACL is corrupted
Access is denied. The sticky bit is set on the parent directory and the user is not the owner of file or
parent directory
Access is denied. The owner can be changed only by root
Access is denied. The UNIX permissions/uid/gid/NFSv4 ACL can be changed only by owner or
root
Access is denied. The GID can be set by owner to a member of its legal group list only if 'Owner
can chown' is not set
Access is denied. The file or the directory has readonly bit set
Access is denied. There is no audit privilege
Access is denied. Enforce DOS bits blocks the access
Access is denied. Hidden attribute is set
Access is denied by an inherited ACE
List of locations
The list of locations that are concatenated onto a reason are provided in the following table:
path ...
while reading the directory.
while truncating the file.
while deleting the target during rename.
while creating the directory.
while deleting the child during rename.
while creating the file.
while writing data in the parent during rename.
while checking parent's modebits during

delete.
while adding a directory during rename.
while deleting the child.
while adding a file during rename.
while checking for child-delete access on the

parent.
while updating the target directory during rename.
while reading security descriptor.
while setting attributes.
while accessing the link.
while writing to the file.

path ...
while creating or writing the file.
while extending the coral file.
while opening existing file or directory.
while creating the vdisk file.
while setting the attributes.
while checking for stale locks before open.
while deleting a file or a directory.
while reading the file.
while truncating a hidden file.
Configuring the metadata cache for CIFS shares

Metadata caching enables file attribute caching on a CIFS client to provide faster access to file and
folder attributes. You can enable or disable attribute caching on a per-share basis. You can also
configure the time-to-live for cached entries if metadata caching is enabled.
How CIFS metadata caching works

When enabled, the CIFS metadata cache stores path and file attribute data for a limited amount of
time. This can improve CIFS performance for common workloads.
For certain tasks, CIFS creates a significant amount of traffic that can include multiple identical
queries for path and file metadata. You can reduce the number of redundant queries and improve
performance by using CIFS metadata caching to fetch information from the cache instead.
Attention: While unlikely, it is possible that the metadata cache might serve stale information to
CIFS clients. If your environment cannot afford this risk, you should not enable this feature.
Enabling the CIFS metadata cache

You can improve CIFS performance by enabling the CIFS metadata cache. By default, CIFS
metadata caching is disabled.
Step

If you want to...
Enable CIFS metadata caching

when you create a share
vserver cifs share create -vserver

vserver_name -share-name share_name -path path
-share-properties attributecache
Enable CIFS metadata caching on

an existing share
vserver cifs share properties add -vserver

vserver_name -share-name share_name -shareproperties attributecache

See the man page for the vserver cifs share create and vserver cifs share
properties add man pages for more information.
Related tasks
Configuring the lifetime of CIFS metadata cache entries on page 321

Configuring the lifetime of CIFS metadata cache entries

You can configure the lifetime of CIFS metadata cache entries. This enables you to optimize the
CIFS metadata cache performance in your environment. The default is 10 seconds.
Before you begin
You must have enabled the CIFS metadata cache feature. If CIFS metadata caching is not enabled,
the CIFS cache TTL setting is not used.
Step

If you want to configure the
lifetime of CIFS metadata cache
when you...
Create a share
vserver cifs share -create -vserver

-attribute-cache-ttl [integerh][integerm]
[integers]
Modify an existing share
vserver cifs share -modify -vserver

vserver_name -share-name share_name -attributecache-ttl [integerh][integerm][integers]
You can specify additional share configuration options and properties when you create or modify
shares. See the man pages for the vserver cifs share create and vserver cifs share
modify commands for more information.
Managing file locks

You can display information about a Vserver's current locks as a first step to determining why a
client cannot access a volume or file. You can use this information if you need to break file locks.
About file locking between protocols

File locking is a method used by client applications to prevent a user from accessing a file previously
opened by another user. How Data ONTAP locks files depends on the protocol of the client.
If the client is an NFS client, locks are advisory; if the client is a CIFS client, locks are mandatory.
Because of differences between the NFS and CIFS file locks, an NFS client might fail to access a file
previously opened by a CIFS application.
The following occurs when an NFS client attempts to access a file locked by a CIFS application:
In mixed or NTFS volumes, file manipulation operations, such as rm, rmdir, and mv, can cause
the NFS application to fail.
NFS read and write operations are denied by CIFS deny-read and deny-write open modes,
respectively.
NFS write operations fail when the written range of the file is locked with an exclusive CIFS
bytelock.
How Data ONTAP treats read-only bits

The read-only bit is a binary digit, which holds a value of 0 or 1, that is set on a file-by-file basis to
reflect whether a file is writable (disabled) or read-only (enabled).
CIFS clients that use MS-DOS and Windows can set a per-file read-only bit. NFS clients do not set a
per-file read-only bit because NFS clients do not have any protocol operations that use a per-file
read-only bit.
Data ONTAP can set a read-only bit on a file when a CIFS client that uses MS-DOS or Windows
creates that file. Data ONTAP can also set a read-only bit when a file is shared between NFS clients
and CIFS clients. Some software, when used by NFS clients and CIFS clients, requires the read-only
bit to be enabled.
For Data ONTAP to keep the appropriate read and write permissions on a file shared between NFS
clients and CIFS clients, it treats the read-only bit according to the following rules:
NFS treats any file with the read-only bit enabled as if it has no write permission bits enabled.
If an NFS client disables all write permission bits and at least one of those bits had previously
been enabled, Data ONTAP enables the read-only bit for that file.
If an NFS client enables any write permission bit, Data ONTAP disables the read-only bit for that
file.
If the read-only bit for a file is enabled and an NFS client attempts to discover permissions for the
file, the permission bits for the file are not sent to the NFS client; instead, Data ONTAP sends the
permission bits to the NFS client with the write permission bits masked.
If the read-only bit for a file is enabled and a CIFS client disables the read-only bit, Data ONTAP
enables the owners write permission bit for the file.
Files with the read-only bit enabled are writable only by root.

Note: Changes to file permissions take effect immediately on CIFS clients, but might not take
effect immediately on NFS clients if the NFS client enables attribute caching.
How Data ONTAP differs from Windows on handling locks on share path
components
Unlike Windows, Data ONTAP does not lock each component of the path to an open file while the
file is open. This behavior also affects share paths.
Because Data ONTAP does not lock each component of the path, it is possible to rename a path
component above the open file or share, which can cause problems for certain applications, or can
cause the share path in the CIFS configuration to be invalid. This can cause the share to be
inaccessible.
To avoid issues caused by renaming path components, you can apply security settings that prevent
users or applications from renaming critical directories.
Displaying information about locks

You can use the vserver locks show command to display information about the current file
locks, including what types of locks are held and what the lock state is, details about byte-range
locks, sharelock modes, delegation locks, and opportunistic locks, and whether locks are opened with
durable or persistent handles.
About this task
The client IP address cannot be displayed for locks established through NFSv4 or NFSv4.1.
By default, the command displays information about all locks. You can use command parameters to
display information about locks for a specific Vserver or to filter the command's output by other
criteria. If you do not specify any parameter, the command displays the following information:
Vserver name
Volume name of the FlexVol volume or the name of the namespace constituent for the Infinite
Volume
Path of the locked object
Protocol by which the lock was established
Type of lock
Client
The vserver locks show displays information about four types of locks:
Byte-range locks, which lock only a portion of a file.

Share locks, which lock open files.
Opportunistic locks, which control client-side caching over SMB.
Delegations, which control client-side caching over NFSv4.x.

By specifying optional parameters, you can determine important information about each of these lock
types including the following:
What the lock state is.

What the detailed byte-range lock information is.
What the oplock level is.
Whether lease oplocks are granted.
What the sharelock mode is.
Whether sharelocks are granted with durable handles, persistent handles, or no handles.
Whether delegation locks are granted with read or read-write caching.
Step
1. Display information about locks by using the vserver locks show command.
Examples
The following example displays summary information for an NFSv4 lock on a file with the
path /vol1/file1. The sharelock access mode is write-deny_none, and the lock was granted
with write delegation:
Vserver: vs0
Volume Object Path
LIF
Protocol Lock Type
------- ------------------------- ----------- --------- ----------vol1
/vol1/file1
lif1
nfsv4
share-level
Sharelock Mode: write-deny_none
delegation
Delegation Type: write
Client
-------
The following example displays detailed oplock and sharelock information about the SMB
lock on a file with the path /data2/data2_2/intro.pptx. A durable handle is granted on
the file with a share lock access mode of write-deny_none to a client with an IP address of
10.3.1.3. A lease oplock is granted with a batch oplock level:
cluster1::> vserver locks show -instance -path /data2/data2_2/intro.pptx
Vserver:
Volume:
Logical Interface:
Object Path:
Lock UUID:
Lock Protocol:
Lock Type:
Node Holding Lock State:
Lock State:
Bytelock Starting Offset:
Number of Bytes Locked:
Bytelock is Mandatory:
Bytelock is Exclusive:
Bytelock is Superlock:
Bytelock is Soft:
Oplock Level:
Shared Lock Access Mode:
vs1
data2_2
lif2
/data2/data2_2/intro.pptx
553cf484-7030-4998-88d3-1125adbba0b7
cifs
share-level
node3
granted
write-deny_none

Shared Lock is Soft: false
Delegation Type: Client Address: 10.3.1.3
SMB Open Type: durable
SMB Connect State: connected
Vserver: vs1
Volume: data2_2
Object Path: /data2/data2_2/test.pptx
Lock UUID: 302fd7b1-f7bf-47ae-9981-f0dcb6a224f9
Lock Protocol: cifs
Lock Type: op-lock
Lock State: granted
Bytelock Starting Offset: Number of Bytes Locked: Bytelock is Mandatory: Bytelock is Exclusive: Bytelock is Superlock: Bytelock is Soft: Oplock Level: batch
Breaking locks
When file locks are preventing client access to files, you can display information about currently held
locks, and then break specific locks. Examples of scenarios in which you might need to break locks
include debugging applications or resolving networking problems.
About this task
The vserver locks break command is available only at the advanced privilege level and higher.
Steps
1. To find the information you need to break a lock, use the vserver locks show command.

If you want to break a lock by specifying...
The Vserver name, volume name, LIF name,

and file path
vserver locks break -vserver

vserver_name -volume volume_name -path
path -lif lif
The lock ID
vserver locks break -lockid UUID

-volume volume_name specifies the volume name of the FlexVol volume or the name of the
namespace constituent for the Infinite Volume.

-path path specifies the path.
-lif lif specifies the logical interface.
-lockid specifies the universally unique identifier for the lock.

Monitoring CIFS activity

You can monitor CIFS activity by displaying information about SMB sessions and open files. You
can also display information about SMB and CIFS statistics.
Displaying CIFS session information

You can display information about established CIFS sessions, including the CIFS connection and
session ID and the IP address of the workstation using the session. You can display information
about the session's SMB protocol version and continuously available protection level, which helps
you identify whether the session supports nondisruptive operations.
About this task
You can display information for all sessions on a Vserver in summary form by using the vserver
cifs session show command without any optional parameters. However, in many cases, the
amount of output returned is large. You can customize what information is displayed in the output by
specifying optional parameters. This can be helpful when the results contain a large number of
records. If you do not specify any of the optional parameters, the following is displayed:
Vserver name
Node name
CIFS connection ID
CIFS session ID
Workstation IP address
CIFS user name
CIFS open files

Session idle time
You can use the optional -fields parameter to display output on the fields you choose. You can use
this parameter either alone or in combination with other optional parameters. Alternatively, you can
use the -instance parameter to display detailed information about established CIFS sessions. You
can use this parameter either alone or in combination with other optional parameters.
Step

If you want to
display CIFS
session information
for established
sessions...
For all sessions on a vserver cifs session show -vserver vserver_name
Vserver in summary
form
On a specified
connection ID
vserver cifs session show -vserver vserver_name connection-id integer
From a specified
workstation IP
address
vserver cifs session show -vserver vserver_name -address

workstation_IP_address
On the specified LIF vserver cifs session show -vserver vserver_name -lifIP address
address LIF_IP_address
On a specified node
vserver cifs session show -vserver vserver_name -node

{node_name|local}
From a specified
Windows user
vserver cifs session show -vserver vserver_name windows-user user_name

The format for user_name is [domain]\user.
With a specified
authentication
mechanism
vserver cifs session show -vserver vserver_name -authmechanism authentication_mechanism

The value for -auth-mechanism can be one of the following:
NTLMv1
NTLMv2
Kerberos
Anonymous

If you want to
display CIFS
session information
for established
sessions...
With the specified
protocol version
vserver cifs session show -vserver vserver_name protocol-version protocol_version

The value for -protocol-version can be one of the following:
SMB1
SMB2
SMB2_1
SMB3
Note: Continuously available protection is available only on SMB 3.0 sessions.

To see continuously available protection status on all qualifying sessions, specify
this parameter with the value set to SMB3.
With the specified
vserver cifs session show -vserver vserver_name level of continuously continuously-available
available protection continuously_available_protection_level
The value for -continuously-available can be one of the following:
No
Yes
Partial
Note: If the continuously available status is Partial, this means that the
session contains at least one open continuously available file, but the session has
some files that are not open with continuously available protection. You can use
the vserver cifs sessions file show command to determine which
files on the established session are not open with continuously available
protection.
There are additional optional parameters. See the man page on the vserver cifs session
show command for more information.
Examples
The following example displays session information on sessions Vserver vs1 established from
a workstation with the IP address of 10.1.1.1:
cluster1::> vserver
Node:
node1
Vserver: vs1
Connection Session
ID
ID
---------- ------3151272279 1
cifs session show -address 10.1.1.1

Open
Idle
Workstation
Windows User
Files
Time
---------------- ------------- ------- -----------10.1.1.1
DOMAIN\joe
2
23s

The following example displays detailed session information on sessions with continuously
available protection on Vserver vs1. The connection was made by using the domain computermachine account:
cluster1::> vserver cifs session show -instance -continuously-available Yes
Node: node1
Vserver: vs1
Session ID: 1
Connection ID: 3151274158
Incoming Data LIF IP Address: 10.2.1.1
Workstation IP address: 10.1.1.2
Authentication Mechanism: Kerberos
Windows User: DOMAIN\SERVER1$
UNIX User: pcuser
Open Shares: 1
Open Files: 1
Open Other: 0
Connected Time: 10m 43s
Idle Time: 1m 19s
Protocol Version: SMB3
Continuously Available: Yes
The following example displays session information on sessions using SMB 3.0 on Vserver
vs1. The user connected to this share from a SMB 3.0 capable client by using the LIF IP
address; therefore, the authentication mechanism defaulted to NTLMv2. The connection must
be made using Kerberos authentication to connect with continuously available protection:
cluster1::> vserver cifs session show -instance -protocol-version SMB3
Node:
Vserver:
Session ID:
Connection ID:
Incoming Data LIF IP Address:
Workstation IP address:
Authentication Mechanism:
Windows User:
UNIX User:
Open Shares:
Open Files:
Open Other:
Connected Time:
Idle Time:
Protocol Version:
Continuously Available:
node1
vs1
1
3151272607
10.2.1.2
10.1.1.3
NTLMv2
DOMAIN\administrator
pcuser
1
0
0
6m 22s
5m 42s
SMB3
No
Displaying information about open CIFS files

You can display information about open CIFS files, including the CIFS connection and session ID,
the hosting volume, the share name, and the share path. You can display information about a file's

continuously available protection level, which is helpful in determining whether an open file is in a
state that supports nondisruptive operations.
About this task
You can use the vserver cifs sessions file show command to display information about
open files on an established CIFS session. The displayed information is useful when you need to
determine CIFS session information for particular files within a CIFS session. For example, if you
have a CIFS session where some of the open files are open with continuously available protection
and some are not open with continuously available protection (the value for the -continuouslyavailable field in vserver cifs session show command output is Partial), you can
determine which files are not continuously available by using this command.
You can display information for all open files on established CIFS sessions on Vservers in summary
form by using the vserver cifs session file show command without any optional
parameters. However, in many cases, the amount of output returned is large. You can customize what
information is displayed in the output by specifying optional parameters. This can be helpful when
you want to view information for only a small subset of open files. If you do not specify any of the
optional parameters, the following is displayed:
Vserver name
Node name
CIFS connection ID
CIFS session ID
CIFS file ID
CIFS file type
CIFS file open mode
CIFS file hosting volume
CIFS share name
CIFS file path
Continuously available protection level
use the -instance parameter to display detailed information about open CIFS files. You can use
this parameter either alone or in combination with other optional parameters.
Step

If you want to display Enter the following command...
open CIFS files...
On a Vserver in
summary form
vserver cifs session file show -vserver vserver_name

open CIFS files...
On a specified node
vserver cifs session file show -vserver vserver_name node {node_name|local}
On a specified file ID
vserver cifs session file show -vserver vserver_name file-id integer
On a specified CIFS
connection ID
vserver cifs session file show -vserver vserver_name connection-id integer
On a specified CIFS
session ID
vserver cifs session file show -vserver vserver_name session-id integer
On the specified
hosting aggregate
vserver cifs session file show -vserver vserver_name hosting-aggregate aggregate_name
On the specified
volume
vserver cifs session file show -vserver vserver_name hosting-volume volume_name
On the specified CIFS

share
vserver cifs session file show -vserver vserver_name share share_name
On the specified CIFS

path
vserver cifs session file show -vserver vserver_name path path
With the specified

level of continuously
available protection
vserver cifs session file show -vserver vserver_name continuously-available continuously_available_status

No
Yes
Note: If the continuously available status is No, this means that these open
files are not capable of nondisruptively recovering from takeover and
giveback. They also cannot recover from general aggregate relocation between
partners in a high-availability relationship.

open CIFS files...
With the specified
reconnected state
vserver cifs session file show -vserver vserver_name reconnected reconnected_state

The value for -reconnected can be one of the following:
No
Yes
Note: If the reconnected state is No, the open file is not reconnected after a
disconnection event. This can mean that the file was never disconnected, or
that the file was disconnected and is not successfully reconnected. If the
reconnected state is Yes, this means that the open file is successfully
reconnected after a disconnection event.
There are additional optional parameters that you can use to refine the output results, including
specifying that you want to see output only for specified open mode and share mode types, file
types, and the specified number of range locks. See the man page on the vserver cifs
session file show command for more information.
Examples
The following example displays information about open files on Vserver vs1:
cluster1::> vserver cifs session
Node:
node1
Vserver:
vs1
Connection: 3151274158
Session:
1
File
File
Open Hosting
ID
Type
Mode Volume
------- --------- ---- --------41
Regular
r
data
Path: \mytest.rtf
file show -vserver vs1
Continuously
Share
Available
----------- -----------data
Yes
The following example displays detailed information about open CIFS files with file ID 82 on
Vserver vs1:
cluster1::> vserver cifs session file show -vserver vs1 -file-id 82 instance
Node:
Vserver:
File ID:
Connection ID:
Session ID:
File Type:
Open Mode:
Aggregate Hosting File:
Volume Hosting File:
CIFS Share:
Path from CIFS Share:
Share Mode:
node1
vs1
82
104617
1
Regular
rw
aggr1
data1
data1
windows\win8\test\test.txt
rw

Range Locks: 1
Reconnected: No
Determining which statistics objects and counters are available

Before you can obtain information about CIFS statistics and monitor performance, you must know
which objects and counters are available from which you can obtain data.
Step

If you want to determine...
Enter the following...
Which objects are available
statistics catalog object show
Specific objects that are available

object object_name
Which counters are available at the admin privilege statistics catalog counter show
level
object object_name
Which counters are available at the advanced
privilege level

statistics catalog counter show
object object_name
See the man page for the statistics catalog object show and statistics catalog
counter show commands for more information.
Examples
The following example displays descriptions of selected statistic objects related to CIFS access
in the cluster:
cluster1::> statistics catalog object show -object audit
audit_ng
CM object for exporting audit_ng performance
counters
cluster1::> statistics catalog object show -object cifs
cifs
The CIFS object reports activity of the
Common Internet File System protocol
subsystem. This is the Microsoft file-sharing
protocol that evolved from the Server Message
Block (SMB) application layer network
protocol to connect PCs to Network Attached
Storage devices (NAS). This object reports
activity for both SMB and SMB2 revisions of
the CIFS protocol. For information related
only to SMB, see the 'smb1' object. For
information related only to SMB2, see the
'smb2' object.
cluster1::> statistics catalog object show -object nblade_cifs
nblade_cifs
Exported counters associated with the

N-Blade's CIFS subsystem and relevant to the
entire node, rather than individual virtual
servers.
cluster1::> statistics catalog object show -object smb1
smb1
These counters report activity from the SMB
revision of the protocol. For information
specific to SMB2, see the 'smb2' object. To
see an overview across both revisions, see
the 'cifs' object.
smb2
These counters report activity from the SMB2
specific to SMB, see the 'smb1' object. To
the 'cifs' object.
cluster1::> statistics catalog object show -object hashd
hashd
The hashd object provides counters to measure
the performance of the BranchCache hash
daemon.
The following example displays information about some of the counters for the cifs object as
seen at the advanced-privilege level:
Note: This example does not display all of the available counters for the CIFS object.
Output is truncated.
Warning: These advanced commands are potentially dangerous; use them only when
directed to do so by support personnel.
Do you want to continue? {y|n}: y
cluster1::*> statistics catalog counter show -object cifs
Object: cifs
Counter
--------------------------active_searches
auth_reject_too_many
Description
---------------------------------------------Number of active searches over SMB and SMB2
Authentication refused after too many
requests were made in rapid succession
avg_directory_depth
Average number of directories crossed by SMB
and SMB2 path-based commands
avg_junction_depth
Average number of junctions crossed by SMB
branchcache_hash_fetch_fail Total number of times a request to fetch hash
data failed. These are failures when
attempting to read existing hash data. It
does not include attempts to fetch hash data
that has not yet been generated.
branchcache_hash_fetch_ok
Total number of times a request to fetch hash
data succeeded.
branchcache_hash_sent_bytes Total number of bytes sent to clients
requesting hashes.
branchcache_missing_hash_bytes
Total number of bytes of data that had to be
read by the client because the hash for that
content was not available on the server.
change_notifications_outstanding
Number of active change notifications over
SMB and SMB2
cifs_latency
Average latency for CIFS operations
cifs_latency_base
Total observed CIFS operations to be used as
a base counter for CIFS average latency
calculation
cifs_ops
Total number of CIFS operations
cifs_read_ops
Total number of CIFS read operations

cifs_write_ops
Total number of CIFS write operations
[...]
Related tasks
Displaying CIFS and audit statistics

You can display various CIFS and audit statistics to monitor performance and diagnose issues.
Before you begin
You must use the statistics start and optional statistics stop commands to collect a data
sample. For more information about these commands, see the Clustered Data ONTAP System
Step

If you want to display statistics for...
All versions of SMB
statistics show -object cifs
SMB 1.0
statistics show -object smb1
SMB 2.x and SMB 3.0
CIFS subsystem of the node
statistics show -object nblade_cifs
Multiprotocol audit
statistics show -object audit_ng
BranchCache hash service
statistics show -object hashd
See the man page for more information.
Deploying CIFS client-based services

You can deploy a number of CIFS client-based services, such as accessing files in Snapshot copies
using the Previous Versions Windows Properties tab; and configuring offline folders, roaming
profiles, and folder redirection.
Using offline files to allow caching of files for offline use

Data ONTAP supports the Microsoft Offline Files feature, or client-side caching, which allows files
to be cached on the local host for offline use. Users can use the offline files functionality to continue
working on files even when they are disconnected from the network.
You can specify whether Windows user documents and programs are automatically cached on a
share or whether the files must be manually selected for caching. Manual caching is enabled by
default for new shares. The files that are made available offline are synchronized to the Windows
client's local disk. Synchronization occurs when network connectivity to a specific storage system
share is restored.
Because offline files and folders retain the same access permissions as the version of the files and
folders saved on the CIFS server, the user must have sufficient permissions on the files and folders
saved on the CIFS server to perform actions on the offline files and folders.
When the user and someone else on the network make changes to the same file, the user can save the
local version of the file to the network, keep the other version, or save both. If the user keeps both
versions, a new file with the local user's changes is saved locally and the cached file is overwritten
with changes from the version of the file saved on the CIFS server.
You can configure offline files on a share-by-share basis by using share configuration settings. You
can choose one of the four offline folder configurations when you create or modify shares:
No caching
Disables client-side caching for the share. Files and folders are not automatically cached locally
on clients and users cannot choose to cache files or folders locally.
Manual caching
Enables manual selection of files to be cached on the share. This is the default setting. By default,
no files or folders are cached on the local client. Users can choose which files and folders they
want to cache locally for offline use.
Automatic document caching
Enables user documents to be automatically cached on the share. Only files and folders that are
accessed are cached locally.
Automatic program caching
Enables programs and user documents to be automatically cached on the share. Only files,
folders, and programs that are accessed are cached locally. Additionally, this setting allows the
client to run locally cached executables even when connected to the network.
Deploying CIFS client-based services | 337

For more information about configuring offline files on Windows servers and clients, consult the
Microsoft TechNet Library.
Related concepts
Using roaming profiles to store user profiles centrally on a Vserver's CIFS server on page 341
Using folder redirection to store data on a Vserver's CIFS server on page 342
Using BranchCache to cache CIFS share content at a branch office on page 366
Related information
Microsoft TechNet Library: technet.microsoft.com/en-us/library/
Requirements for using offline files

Before you can use the Microsoft Offline Files feature with your Vserver's CIFS server, you need to
know which versions of Data ONTAP and SMB and which Windows clients support the feature.
Data ONTAP version requirements
Data ONTAP 8.2 and later releases support offline files.
For Vservers with FlexVol volumes, Data ONTAP supports offline files on SMB 1.0, SMB 2.x, and
SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports offline files on SMB 1.0.
Windows client requirements
The Windows client must support the offline files.
For the latest information about which Windows clients supports the Offline Files feature, see the
Considerations when deploying offline files

There are some important considerations you need to understand when you deploy offline files on
home directory shares that have the showsnapshot share property set on home directories.
If the showsnapshot share property is set on a home directory share that has offline files
configured, Windows clients cache all of the Snapshot copies under the ~snapshot folder in the
user's home directory.
Windows clients cache all of the Snapshot copies under the home directory if one of more of the
following is true:
The user makes the home directory available offline from the client.
The contents of the ~snapshot folder in the home directory is included and made available
offline.
The user configures folder redirection to redirect a folder such as My Documents to the root of a
home directory residing on the CIFS server share.
Some Windows clients might automatically make the redirected folder available offline. If the
folder is redirected to the root of the home directory, the ~snapshot folder is included in the
cached offline content.
Note: Offline file deployments where the ~snapshot folder is included in offline files should be
avoided. The Snapshot copies in the ~snapshot folder contain all data on the volume at the point
at which Data ONTAP created the Snapshot copy. Therefore, creating an offline copy of the
~snapshot folder consumes significant local storage on the client, consumes network bandwidth
during offline files synchronization, and increases the time it takes to synchronize offline files.
Configuring offline files support on SMB shares using the CLI

You can configure offline files support using the Data ONTAP CLI by specifying one of the four
offline files setting when you create SMB shares or at any time by modifying existing SMB shares.
Manual offline files support is the default setting.
About this task
When configuring offline files support, you can choose one of the following four offline files
settings:
Setting
Description
none
Disallows Windows clients from caching any files on this share.
manual
Allows users on Windows clients to manually select files to be

cached.
documents
Allows Windows clients to cache user documents that are used by

the user for offline access.
programs
Allows Windows clients to cache programs that are used by the

user for offline access. Clients can use the cached program files in
offline mode even if the share is available.
You can choose only one offline file setting. If you modify an offline files setting on an existing
SMB share, the new offline files setting replaces the original setting. Other existing SMB share
configuration settings and share properties are not removed or replaced. They remain in effect until
they are explicitly removed or changed.
Steps

If you want to configure
offline files on...
A new SMB share
vserver cifs share create -vserver vserver_name

-share-name share_name -path path -offline-files
{none|manual|documents|programs}
An existing SMB share
vserver cifs share modify -vserver vserver_name

-share-name share_name -offline-files {none|
manual|documents|programs}
For more information about configuring and managing SMB shares, see the man pages for the
vserver cifs share create, vserver cifs share modify, vserver cifs share
properties add, and vserver cifs share properties remove commands.
2. Verify that the SMB share configuration is correct:
vserver cifs share show -vserver vserver_name -share-name share_name instance
Example
The following command creates an SMB share named data1 with offline files set to
documents:
cluster1::> vserver cifs share create -vserver vs1 -share-name data1 -path /
data1 -comment "Offline files" -offline-files documents
cluster1::> vserver cifs share vserver cifs share show -vserver vs1 -sharename data1 -instance
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
File Mode Creation Mask:
Directory Mode Creation Mask:
Share Comment:
Share ACL:
File Attribute Cache Lifetime:
Volume Name:
Offline Files:
vs1
data1
VS1
/data1
oplocks
browsable
changenotify
enable
Offline files
Everyone / Full Control
documents
The following command modifies an existing SMB share named data1 by changing the
offline files setting to manual and adding values for the file and directory mode creation
mask:
cluster1::> vserver cifs share modify -vserver vs1 -share-name data1 offline-files manual -file-umask 644 -dir-umask 777
cluster1::> vserver cifs share vserver cifs share show -vserver vs1 -share-

name data1 -instance
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
data1
VS1
/data1
oplocks
browsable
changenotify
enable
644
777
Offline files
manual
Related tasks

Configuring offline files support on SMB shares by using the Computer

Management MMC
If you want to permit users to cache files locally for offline use, you can configure offline files
support by using the Computer Management MMC (Microsoft Management Console).
Steps
1. To open the MMC on your Windows server, in Windows Explorer, right-click the icon for the
local computer and select Manage.
2. On the left panel, select Computer Management.
3. Select Action > Connect to another computer.
The Select Computer dialog box appears.
4. Type the name of the Vserver's CIFS server or click Browse to locate the CIFS server.
If the name of CIFS server is the same as the Vserver host name, type the Vserver name. If the
CIFS server name is different from the Vserver host name, type the name of the CIFS server.
5. Click OK.
6. In the console tree, click System Tools > Shared Folders.
7. Click Shares.
8. In the results pane, right-click the share.
9. Click Properties.
Properties for the share you selected are displayed.

10. In the General tab, click Offline Settings.
The Offline Settings dialog box appears.
11. Configure the offline availability options as appropriate.
12. Click OK.
Using roaming profiles to store user profiles centrally on a

Vserver's CIFS server
Data ONTAP supports storing Windows roaming profiles on a Vserver's CIFS server. Configuring
user roaming profiles provides advantages to the user such as automatic resource availability
regardless of where the user logs in. Roaming profiles also simplify the administration and
management of user profiles.
Roaming user profiles have the following advantages:
Automatic resource availability

A user's unique profile is automatically available when that user logs in to any computer on the
network that is running Windows 8, Windows 7, Windows Vista, Windows 2000, or Windows
XP. Users do not need to create a profile on each computer they use on a network.
Simplified computer replacement
Because all of the user's profile information is maintained separately on the network, a user's
profile can be easily downloaded onto a new, replacement computer. When the user logs in to the
new computer for the first time, the server copy of the user's profile is copied to the new
computer.
Related concepts
Using offline files to allow caching of files for offline use on page 336
Using folder redirection to store data on a Vserver's CIFS server on page 342
Requirements for using roaming profiles

Before you can use Microsoft's roaming profiles with your Vserver's CIFS server, you need to know
which versions of Data ONTAP and SMB and which Windows clients support the feature.
Data ONTAP 8.2 and later support roaming profiles.
For Vservers with FlexVol volumes, Data ONTAP supports roaming profiles on SMB 1.0, SMB 2.x,
and SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports roaming profiles on SMB 1.0.

Before a user can use the roaming profiles, the Windows client must support the feature.
For the latest information about which Windows clients support roaming profiles, see the
Configuring roaming profiles

If you want to automatically make a user's profile available when that user logs on to any computer
on the network, you can configure roaming profiles through the Active Directory Users and
Computers MMC snap-in. If you are configuring roaming profiles on Windows Server 2012, you can
use the Active Directory Administration Center.
Steps
1. On the Windows server, open the Active Directory Users and Computers MMC (or the Active
Directory Administration Center on Windows 2012 and later servers).
2. Locate the user for which you want to configure a roaming profile.
3. Right-click the user and click Properties.
4. On the Profile tab, enter the profile path to the share where you want to store the user's roaming
profile, followed by %username%.
For example, a profile path might be the following: \\vs1.example.com\profiles\
%username%. The first time a user logs in, %username% is replaced with the user's name.
Note: In the path \\vs1.example.com\profiles\%username%, profiles is the share
name of a share on Vserver vs1 that has Full Control rights for Everyone.
5. Click OK.
Using folder redirection to store data on a Vserver's CIFS

server
Data ONTAP supports Microsoft folder redirection, which enables users or administrators to redirect
the path of a local folder to a location on the Vserver's CIFS server. It appears as if redirected folders
are stored on the local Windows client, even though the data is stored on a CIFS share.
Folder redirection is intended mostly for organizations that have already deployed home directories,
and that want to maintain compatibility with their existing home directory environment.
Documents, Desktop, and Start Menu are examples of folders that you can redirect.
Users can redirect folders from their Windows client.
Administrators can centrally configure and manage folder redirection by configuring GPOs in
Active Directory.
If administrators have configured roaming profiles, folder redirection enables administrators to
divide user data from profile data.
Administrators can use folder redirection and offline files together to redirect data storage for
local folders to the CIFS server, while allowing users to cache the content locally.
Related concepts
Using roaming profiles to store user profiles centrally on a Vserver's CIFS server on page 341
Requirements for using folder redirection

Before you can use Microsoft's folder redirection with your Vserver's CIFS server, you need to know
which versions of Data ONTAP and SMB and which Windows clients support the feature.
Clustered Data ONTAP 8.2 and later support Microsoft folder redirection.
For Vservers with FlexVol volumes, Data ONTAP supports Microsoft's folder redirection on SMB
1.0, SMB 2.x, and SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports Microsoft's folder redirection on SMB
1.0.
Before a user can use Microsoft's folder redirection, the Windows client must support the feature.
For the latest information about which Windows clients support folder redirection, see the
Configuring folder redirection

You can configure folder redirection using the Windows Properties window. The advantage to using
this method is that the Windows user can configure folder redirection without assistance from the
Vserver administrator.
Steps
1. In Windows Explorer, right-click the folder that you want to redirect to a network share.
Properties for the share you selected are displayed.
3. In the Shortcut tab, click Target and specify the path to the network location where you want to
redirect the selected folder.
For example, if you want to redirect a folder to the data folder in a home directory that is
mapped to Q:\, specify Q:\data as the target.

4. Click OK.
For more information about configuring offline folders, consult the Microsoft TechNet Library.
Related information
How to access the ~snapshot directory from Windows

clients using SMB 2.x
The method that you use to access the ~snapshot directory from Windows clients using SMB 2.x
differs from the method used for SMB 1.0. You need to understand how to access the ~snapshot
directory when using SMB 2.x connections to successfully access data stored in Snapshot copies.
The Vserver administrator controls whether users on Windows clients can view and access the
~snapshot directory on a share by enabling or disabling the showsnapshot share property.
When the showsnapshot share property is disabled, a user on a Windows client using SMB 2.x
cannot view the ~snapshot directory and cannot access Snapshot copies within the ~snapshot
directory, even when manually entering the path to the ~snapshot directory or to specific Snapshot
copies within the directory.
When the showsnapshot share property is enabled, a user on a Windows client using SMB 2.x still
cannot view the ~snapshot directory either at the root of the share or within any junction or
directory below the root of the share. However, after connecting to a share, the user can access the
hidden ~snapshot directory by manually appending \~snapshot to the end of the share path. The
hidden ~snapshot directory is accessible from two entry points:
At the root of the share

At every junction point in the share space
The hidden ~snapshot directory is not accessible from non-junction subdirectories within the share.
Example
With the configuration shown in the following example, a user on a Windows client with an
SMB 2.x connection to the eng share can access the ~snapshot directory by manually
appending \~snapshot to the share path at the root of the share and at every junction point in
the path. The hidden ~snapshot directory is accessible from the following three paths:
\\vs1\eng\~snapshot
\\vs1\eng\projects1\~snapshot
\\vs1\eng\projects2\~snapshot
cluster1::> volume show -fields volume,junction-path
vserver volume
junction-path

------vs1
vs1
vs1
vs1
------------ ---------------------------------------vs1_root
/
vs1_vol1
/eng
vs1_vol2
/eng/projects1
vs1_vol3
/eng/projects2
cluster1::> vserver cifs share show

Vserver Share
Path
Properties
-------- ------ ------- ---------vs1
eng
/eng
oplocks
Control
changenotify
browsable
showsnapshot
Comment ACL
-------- ---------Everyone / Full
Recovering files and folders using Previous Versions

The ability to use Microsoft Previous Versions is applicable to file systems that support Snapshot
copies in some form and have them enabled. Snapshot technology is an integral part of Data
ONTAP. Users can recover files and folders from Snapshot copies from their Windows client by
using the Microsoft Previous Versions feature.
Previous Versions functionality provides a method for users to browse through the Snapshot copies
or to restore data from a Snapshot copy without a storage administrator's intervention. Previous
Versions is not configurable. It is always enabled. If the storage administrator has made Snapshot
copies available on a share, then the user can use Previous Versions to perform the following tasks:
Recover files that were accidentally deleted.

Recover from accidentally overwriting a file.
Compare versions of file while working.
The data stored in Snapshot copies is read-only. Users must save a copy of a file to another location
to make any changes to the file. Snapshot copies are periodically deleted; therefore, users need to
create copies of files contained in Previous Versions if they want to indefinitely retain a previous
version of a file.
Requirements for using Microsoft Previous Versions

Before you can use Previous Versions with your Vserver's CIFS server, you need to know which
versions of Data ONTAP and SMB, and which Windows clients, support it. You also need to know
about the Snapshot copy setting requirement.
Data ONTAP 8.2 and later supports Previous Versions.

For Vservers with FlexVol volumes, Data ONTAP supports Previous Versions on SMB 1.0, SMB
2.x, and SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports Previous Versions on SMB 1.0.
Before a user can use Previous Versions to access data in Snapshot copies, the Windows client must
support the feature.
For the latest information about which Windows clients support Previous Versions, see the
Requirements for Snapshot copy settings
To use Previous Versions to access data in Snapshot copies, an enabled Snapshot policy must be
associated to the volume containing the data, clients must be able to access to the Snapshot data, and
Snapshot copies must exist.
Using the Previous Versions tab to view and manage Snapshot copy data
Users on Windows client machines can use the Previous Versions tab on the Windows Properties
window to restore data stored in Snapshot copies without needing to involve the Vserver
administrator.
About this task
You can only use the Previous Versions tab to view and manage data in Snapshot copies of data
stored on the Vserver if the administrator has enabled Snapshot copies on the volume containing the
share, and if the administrator configures the share to show Snapshot copies.
Steps
1. In Windows Explorer, display the contents of the mapped drive of the data stored on the CIFS
server.
2. Right-click the file or folder in the mapped network drive whose Snapshot copies you want to
view or manage.
Properties for the file or folder you selected are displayed.
4. Click the Previous Versions tab.
A list of available Snapshot copies of the selected file or folder is displayed in the Folder
versions: box. The listed Snapshot copies are identified by the Snapshot copy name prefix and the
creation timestamp.
5. In the Folder versions: box, right-click the copy of the file or folder that you want to manage.

If you want to...
Do the following...
View data from that Snapshot copy
Click Open.
Create a copy of data from that Snapshot copy
Click Copy.
Data in Snapshot copies is read-only. If you want to make modifications to files and folders listed
in the Previous Versions tab, you must save a copy of the files and folders that you want to
modify to a writable location and make modifications to the copies.
7. After you finish managing Snapshot data, close the Properties dialog box by clicking OK.
For more information about using the Previous Versions tab to view and manage Snapshot data,
consult the Microsoft TechNet Library.
Related information
Determining whether Snapshot copies are available for Previous Versions

use
You can view Snapshot copies from the Previous Versions tab only if an enabled Snapshot policy is
applied to the volume containing the share, and if the volume configuration allows access to
Snapshot copies. Determining Snapshot copy availability is helpful when assisting a user with
Previous Versions access.
Steps
1. Determine whether the volume on which the share data resides has automatic Snapshot copies
enabled and whether clients have access to Snapshot directories:
volume show -vserver vserver-name -volume volume-name -fields
vserver,volume,snapdir-access,snapshot-policy,snapshot-count
The output displays what Snapshot policy is associated with the volume, whether client Snapshot
directory access is enabled, and the number of available Snapshot copies.
2. Determine whether the associated Snapshot policy is enabled:
volume snapshot policy show -policy policy-name
3. List the available Snapshot copies:

volume snapshot show -volume volume_name
For more information about configuring and managing Snapshot policies and Snapshot schedules,
see the Clustered Data ONTAP Data Protection Guide.

Example
The following example displays information about Snapshot policies associated with the
volume named data1 that contains the shared data and available Snapshot copies on data1.
cluster1::> volume show -vserver vs1 -volume data1 -fields
vserver,volume,snapshot-policy,snapdir-access,snapshot-count
vserver volume snapdir-access snapshot-policy snapshot-count
-------- ------ -------------- --------------- -------------vs1
data1 true
default
10
cluster1::> volume snapshot policy show -policy default
Vserver: cluster1
Number of Is
Policy Name
Schedules Enabled Comment
------------------ --------- ------- ---------------------------------default
3 true
Default policy with hourly, daily &
weekly schedules.
Schedule
Count
Prefix
SnapMirror Label
---------------- -------------------------- ------------------hourly
6
hourly
daily
2
daily
daily
weekly
2
weekly
weekly
cluster1::> volume snapshot show -volume data1
Vserver Volume Snapshot
-------- ------- ------------------------vs1
data1
weekly.2012-12-16_0015
daily.2012-12-22_0010
daily.2012-12-23_0010
weekly.2012-12-23_0015
hourly.2012-12-23_1405
hourly.2012-12-23_1505
hourly.2012-12-23_1605
hourly.2012-12-23_1705
hourly.2012-12-23_1805
hourly.2012-12-23_1905
---Blocks--State
Size Total% Used%
-------- -------- ------ ----valid
valid
valid
valid
valid
valid
valid
valid
valid
valid
408KB
420KB
192KB
360KB
196KB
196KB
212KB
136KB
200KB
184KB
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
1%
1%
0%
1%
0%
0%
0%
0%
0%
0%
Related tasks
Creating a Snapshot configuration to enable Previous Versions access on page 348
Creating a Snapshot configuration to enable Previous Versions access

The Previous Versions functionality is always available, provided that client access to Snapshot
copies is enabled and provided that Snapshot copies exist. If your Snapshot copy configuration does
not meet these requirements, you can create a Snapshot copy configuration that does.
Steps
1. If the volume containing the share to which you want to allow Previous Versions access does not
have an associated Snapshot policy, associate a Snapshot policy to the volume and enable it by
using the volume modify command.

For more information about using the volume modify command, see the man pages.
2. Enable access to the Snapshot copies by using the volume modify command to set the -snapdir option to true.
For more information about using the volume modify command, see the man pages.
3. Verify that Snapshot policies are enabled and that access to Snapshot directories is enabled by
using the volume show and volume snapshot policy show commands.
For more information about using the volume show and volume snapshot policy show
commands, see the man pages.
For more information about configuring and managing Snapshot policies and Snapshot schedules,
see the Clustered Data ONTAP Data Protection Guide
Considerations when restoring directories that contain junctions

There are certain considerations you need to know about when using Previous Versions to restore
folders that contain junction points.
When using Previous Versions to restore folders that have child folders that are junction points, the
restore can fail with an Access Denied error.
You can determine whether the folder that you are attempting to restore contains a junction by using
the vol show command with the -parent option. You can also use the vserver security
trace commands to create detailed logs about file and folder access issues.
Related concepts
Creating and managing data volumes and the NAS namespace on page 38
Deploying CIFS server-based services

You can deploy a number of CIFS server-based services that can provide you with enhanced
functionality for your CIFS deployment. CIFS server-based services include dynamic home
directories, CIFS access to UNIX symbolic links, BranchCache remote office caching, automatic
node referrals, ODX copy offload, and folder security using access-based enumeration (ABE).
Managing home directories

You can use Data ONTAP home directory functionality to create users' home directories on the CIFS
Vserver and automatically offer each user a dynamic share to their home directory without creating
an individual CIFS share for each user.
How Data ONTAP enables dynamic CIFS home directories

Data ONTAP CIFS home directories enable you to configure a share that maps to different
directories based on the user that connects to it and a set of variables. Instead of having to create
separate shares for each user, you can configure a single share with a few home directory parameters
to define a user's relationship between an entry point (the share) and their home directory (a directory
on the Vserver).
There are four variables that determine how a user is mapped to a directory:
Share name This is the name of the share that you create that the user connects to. It can be static
(for example, home), dynamic (for example, %w), or a combination of the two. You
must set the home directory property for this share.
The share name can use the following dynamic names:
%w (the user's Windows user name)

%d (the user's Windows domain name)
%u (the user's mapped UNIX user name)
Share path
This is the relative path, defined by the share and therefore associated with one of the
share names, that is appended to each search path to generate the user's entire home
directory path from the root of the Vserver. It can be static (for example, home),
dynamic (for example, %w), or a combination of the two (for example, eng/%w).
Search
paths
This is the set of absolute paths from the root of a Vserver that you specify that
directs the Data ONTAP search for home directories. You specify one or more
search paths by using the vserver cifs home-directory search-path add
command. If you specify multiple search paths, Data ONTAP tries them in the order
specified until it finds a valid path.
Deploying CIFS server-based services | 351

Directory
This is the user's home directory that you create for the user. It is usually the user's
name. You must create it in one of the directories defined by the search paths.
As an example, consider the following setup:
User: John Smith

User domain: acme
User name: jsmith
Vserver name: vs1
Home directory share name #1: home - share path: %w
Home directory share name #2: %w - share path: %d/%w
Search path #1: /aggr0home/home
Home directory: /aggr1home/home/jsmith
Scenario 1: The user connects to \\vs1\home. This matches the first home directory share name and
generates the relative path jsmith. Data ONTAP now searches for a directory named jsmith by
checking each search path in order:
/aggr0home/home/jsmith does not exist; moving on to search path #2.

/aggr1home/home/jsmith does exist, therefore search path #3 is not checked; the user is now
connected to his home directory.

Scenario 2: The user connects to \\vs1\jsmith. This matches the second home directory share
name and generates the relative path acme/jsmith. Data ONTAP now searches for a directory
named acme/jsmith by checking each search path in order:
/aggr0home/home/acme/jsmith does not exist; moving on to search path #2.

/aggr1home/home/acme/jsmith does not exist; moving on to search path #3.
/aggr2home/home/acme/jsmith does not exist; the home directory does not exist, therefore
the connection fails.

Related tasks
Adding a home directory share on page 352

Adding a home directory search path on page 353
Creating a home directory configuration using the %w and %d variables on page 354
Configuring home directories using the %u variable on page 356
Adding a home directory share

If you want to use the CIFS home directory feature, you must add at least one share with the home
directory property included in the share properties.
About this task
You can create a home directory share at the time you create the share using the vserver cifs
share create command, or you can change an existing share into a home directory share at any
time using the vserver cifs share modify command.
To create a home directory share, you must include the homedirectory value in the -shareproperties option when you create or modify a share. You can specify the share name and share
path using variables that are dynamically expanded when the user connects to their home directory.
Available variables that you can use in the path are %w, %d, and %u, corresponding to the Windows
user name, domain, and mapped UNIX user name respectively.
Steps
1. Add a home directory share by entering the following command:

vserver cifs share create -vserver vserver -share-name share_name -path
path -share-properties homedirectory[,...]
-vserver vserver specifies the CIFS-enabled Vserver on which to add the search path.
-share-name share-name specifies the home directory share name.
-path path specifies the relative path to the home directory.
-share-properties homedirectory[,...] specifies the share properties for that share. You
must specify the homedirectory value. You can specify additional share properties using a
comma delimited list.
2. Verify that you successfully added the home directory share using the vserver cifs share
show command.
Example
The following example adds the home directory share home1 to the CIFS home directory
configuration on Vserver vs1:
cluster1::> vserver cifs share create -vserver vs1 -share-name %w path %w -share-properties
oplocks,browsable,changenotify,homedirectory
vs1::> vserver cifs
Vserver
Share
---------- -------vs1
%w
share show -vserver vs1 -share-name %w

Path
Properties
Comment ACL
------------ -------------- -------- ----------%w
oplocks
Everyone /

Full Control
browsable
changenotify
homedirectory
Related concepts
How Data ONTAP enables dynamic CIFS home directories on page 350
Requirements and considerations when using automatic node referrals on page 400
Related tasks

Adding a home directory search path on page 353
Adding a home directory search path

If you want to use Data ONTAP CIFS home directories, you must add at least one home directory
search path.
About this task
You can add a home directory search path by using the vserver cifs home-directory
search-path add command.
The vserver cifs home-directory search-path add command checks the path specified in
the -path option during command execution. If the specified path does not exist, the command
generates a message prompting for whether you want to continue. You choose y or n. If you choose
y to continue, Data ONTAP creates the search path. However, you must create the directory structure
before you can use the search path in the home directory configuration. If you choose not to continue,
the command fails; the search path is not created. You can then create the path directory structure
and rerun the vserver cifs home-directory search-path add command.
Steps
1. Add a home directory search path by entering the following command:

vserver cifs home-directory search-path add -vserver vserver -path path
-path path specifies the directory path to the search path.
2. Verify that you successfully added the search path using the vserver cifs home-directory
search-path show command.

Example
The following example adds the path /home1 to the CIFS home directory configuration on
Vserver vs1.
cluster::> vserver cifs home-directory search-path add -vserver vs1
-path /home1
vs1::> vserver cifs home-directory search-path show
Vserver
Position Path
----------- -------- ----------------vs1
1
/home1
The following example attempts to add the path /home2 to the CIFS home directory
configuration on Vserver vs1. The path does not exist. The choice is made to not continue.
-path /home2
Warning: The specified path "/home2" does not exist in the namespace
belonging to Vserver "vs1".
Do you want to continue? {y|n}: n
Related concepts
How Data ONTAP enables dynamic CIFS home directories on page 350
Related tasks
Adding a home directory share on page 352
Creating a home directory configuration using the %w and %d variables

You can create a home directory configuration using the %w and %d variables. Users can then connect
to their home share using dynamically created shares.
Steps
1. Optional: Create a qtree to contain user's home directories by entering the following command:
volume qtree create -vserver vserver_name -qtree-path qtree_path
2. Optional: Verify that the qtree is using the correct security style by entering the following
command:
volume qtree show
3. Optional: If the qtree is not using the desired security style, change the security style using the
volume qtree security command.

vserver cifs share create -vserver vserver -share-name %w -path %d/%w share-properties homedirectory[,...]
-share-name %w specifies the home directory share name. Data ONTAP dynamically creates the
share name as each user connects to their home directory. The share name will be of the form
windows_user_name.
-path %d/%w specifies the relative path to the home directory. The relative path is dynamically
created as each user connects to their home directory and will be of the form domain/
windows_user_name.

5. Verify that the share has the desired configuration using the vserver cifs share show
command.
-path path specifies the absolute directory path to the search path.
8. For users with a home directory, create a corresponding directory in the qtree or volume
designated to contain home directories.
For example, if you created a qtree with the path of /vol/vol1/users and the user name whose
directory you want to create is mydomain\user1, you would create a directory with the following
path: /vol/vol1/users/mydomain/user1.
9. Verify that a user can successfully connect to the home share either by mapping a drive or
connecting using the UNC path.
For example, if user mydomain\user1 wants to connect to the directory created in Step 8 that is
located on Vserver vs1, user1 would connect using the UNC path \\vs1\user1.
Example
The following example creates a home directory configuration using %w as the share name and
%d/%w for the relative home directory path that is appended to the configured absolute search
path or paths. The CIFS home directory configuration is created on Vserver vs1. The
qtree /vol/vol1/home1, used to contain the home directories, is configured as a NTFSsecurity style qtree. You can use this type of home directory configuration when users access
their home directories from Windows hosts. You can also use this type of configuration when

users access their home directories from Windows and UNIX hosts and the file system
administrator uses Windows-based users and groups to control access to the file system.
cluster::> volume qtree create -vserver vs1 /vol/vol1/users
cluster::>
Vserver
---------vs1
vs1
vs1
volume qtree show

Volume
Qtree
----------- -------root_vol
""
vol1
""
vol1
users
Style
-------ntfs
ntfs
ntfs
Oplocks
--------enable
enable
enable
Status
-------normal
normal
normal
cluster::> vserver cifs share create -vserver vs1 -share-name %w -path

%d/%w -share-properties oplocks,browsable,changenotify,homedirectory
cluster::> vserver cifs share show -vserver vs1 -share-name %w
Vserver Share Path
Properties
Comment ACL
-------- ----- ----- ------------------- ----------vs1
%w
%d/%w oplocks
browsable
changenotify
homedirectory
path /vol/vol1/users
cluster::> vserver cifs home-directory search-path show
Vserver
Position Path
----------- -------- ----------------vs1
1
/vol/vol1/users
Related concepts
Additional home directory configurations on page 359

Related tasks
Configuring home directories using the %u variable on page 356
Configuring home directories using the %u variable

You can create a home directory configuration where you designate the share name using the %w
variable but you use the %u variable to designate the relative path to the home directory share. Users
can then connect to their home share using dynamically shares created using their Windows user
name without being aware of the actual name or path of the home directory.
Steps
1. Optional: Create a qtree to contain user's home directories by entering the following command:
volume qtree create -vserver vserver_name -qtree-path qtree_path
2. Optional: Verify that the qtree is using the correct security style by entering the following
command:

volume qtree show
3. Optional: If the qtree is not using the desired security style, change the security style using the
volume qtree security command.
vserver cifs share create -vserver vserver -share-name %w -path %u share-properties homedirectory[,...]
-share-name %w specifies the home directory share name. The share name is dynamically
created as each user connects to their home directory and is of the form windows_user_name.
Note: You can also use the %u variable for the -share-name option. This creates a relative
share path that uses the mapped UNIX user name.
-path %u specifies the relative path to the home directory. The relative path is created
dynamically as each user connects to their home directory and is of the form
mapped_UNIX_user_name.
Note: The value for this option can contain static elements as well. For example, eng/%u.

5. Verify that the share has the desired configuration using the vserver cifs share show
command.
-path path specifies the absolute directory path to the search path.
8. Optional: If the UNIX user does not exist, create the UNIX user using the vserver services
unix-user create command.
Note: The UNIX user name to which you map the Windows user name must exist before
mapping the user.
9. Optional: Create a name mapping for the Windows user to the UNIX user using the following
command:
vserver name-mapping create -vserver vserver_name -direction win-unix priority integer -pattern windows_user_name -replacement unix_user_name
Note: If name mappings already exist that map Windows users to UNIX users, you do not have
to perform the mapping step.

The Windows user name is mapped to the corresponding UNIX user name. When the Windows
user connects to their home directory share, they connect to a dynamically created home directory
with a share name that corresponds to their Windows user name without being aware that the
directory name corresponds to the UNIX user name.
10. For users with a home directory, create a corresponding directory in the qtree or volume
designated to contain home directories.
For example, if you created a qtree with the path of /vol/vol1/users and the mapped UNIX user
name of the user whose directory you want to create is unixuser1, you would create a directory
with the following path: /vol/vol1/users/unixuser1.
11. Verify that a user can successfully connect to the home share either by mapping a drive or
connecting using the UNC path.
For example, if user mydomain\user1 maps to UNIX user unixuser1 and wants to connect to the
directory created in Step 10 that is located on Vserver vs1, user1 would connect using the UNC
path \\vs1\user1.
Example
The following example creates a home directory configuration using %w as the share name
and %u for the relative home directory path that is appended to the configured absolute search
path or paths. The CIFS home directory configuration is created on Vserver vs1. The
qtree /vol/vol1/home1, used to contain the home directories, is configured as a UNIX-security
style qtree. You can use this type of home directory configuration when users access their
home directories from both Windows hosts or Windows and UNIX hosts and the file system
administrator uses UNIX-based users and groups to control access to the file system.
cluster::> volume qtree create -vserver vs1 /vol/vol1/users
cluster::>
Vserver
---------vs1
vs1
vs1
volume qtree show

Volume
Qtree
----------- --------root_vol
""
vol1
""
vol1
users
Style
--------unix
unix
unix
Oplocks
--------enable
enable
enable
Status
-------normal
normal
normal
cluster::> vserver cifs share create -vserver vs1 -share-name %w -path %u

share-properties oplocks,browsable,changenotify,homedirectory
cluster::> vserver cifs share show -vserver vs1 -share-name %u
Vserver Share Path Properties
Comment ACL
-------- ------ ----- ------------- -------- ----------vs1
%w
%u
oplocks
browsable
changenotify
homedirectory
path /vol/vol1/users
cluster::> vserver cifs home-directory search-path show -vserver vs1
Vserver
Position Path
----------- -------- ----------------vs1
1
/vol/vol1/users
cluster::> vserver name-mapping create -vserver vs1 -direction win-unix

position 5 -pattern user1 -replacement unixuser1
cluster::> vserver name-mapping show -pattern user1
Vserver
Direction Position
-------------- --------- -------vs1
win-unix 5
Pattern: user1
Replacement: unixuser1
Related concepts
Additional home directory configurations on page 359

Related tasks
Creating a home directory configuration using the %w and %d variables on page 354
Additional home directory configurations

You can create additional home directory configurations using the %w, %d, and %u variables, which
enables you to customize the home directory configuration to meet your needs.
You can create a number of home directory configurations using a combination of variables and
static share names and variables and static search paths. The following table provides some examples
illustrating how you use variables and static names to create different home directory configurations:
Paths created when /vol/vol1/user
contains home directories...
Share command...
To create a share path \\vs1\~ that directs the

user to /vol/vol1/user/win_username
vserver cifs share create -sharename ~ -path %w -share-properties

oplocks,browsable,changenotify,homed
irectory
To create a share path \\vs1\cifs.homedir

that directs the user to /vol/vol1/user/
vserver cifs share create -sharename CIFS.HOMEDIR -path %w -shareproperties

irectory
win_username
To create a share path \\vs1\~win_username

win_username
To create a share path \\vs1\win_username

domain/win_username
vserver cifs share create -sharename ~%w -path %w -share-properties

irectory
vserver cifs share create -sharename %w -path %d/%w -shareproperties
irectory

Paths created when /vol/vol1/user
contains home directories...
Share command...
To create a share path \\vs1\win_username

vserver cifs share create -sharename %w -path %u -share-properties

irectory
unix_username
To create a share path \\vs1\unix_username

unix_username
vserver cifs share create -sharename %u -path %u -share-properties

irectory
Commands for managing search paths

There are specific Data ONTAP commands for managing search paths for CIFS home directory
configurations. For example, there are commands for adding, removing, and displaying information
about search paths. There is also a command for changing the search path order.
If you want to...
Use this command...
Add a search path
vserver cifs home-directory searchpath add
Display search paths
vserver cifs home-directory searchpath show
Change the search path order
vserver cifs home-directory searchpath reorder
Remove a search path
vserver cifs home-directory searchpath remove
Configuring SMB client access to UNIX symbolic links

You can configure the Vserver's CIFS server to provide SMB client access to UNIX symbolic links.
The symbolic links can point to files within the volume that contain the share, or to files that are
contained in other volumes on the Vserver, or even to volumes contained on other Vservers.
How Data ONTAP enables you to provide SMB client access to UNIX
symbolic links
You must understand certain concepts about how Data ONTAP enables you to manage symbolic
links. This is important to provide access to SMB users connecting to the Vserver.
A symbolic link is a file created in a UNIX environment that contains a reference to another file or
directory. If a client accesses a symbolic link, it is redirected to the target file or directory that the
symbolic link refers to.
Data ONTAP provides SMB clients the ability to follow UNIX symbolic links configured on the
Vserver. This feature is optional and you can configure it on a per-share basis with one of the
following settings:
Enabled with read/write access

Enabled with read-only access
Disabled by hiding symbolic links from SMB clients
Disabled with no access to symbolic links from SMB clients
There are two types of symbolic links:

Relative A relative symbolic link contains a reference to the file or directory relative to its parent
directory. Therefore, the path of the file it is referring to should not begin with a slash (/).
A relative symbolic link always refers to a file or directory within the same file system.
If you enable symbolic links on a share, relative symbolic links work without further
configuration.
Absolute An absolute symbolic link contains a reference to a file or directory in the form of an
absolute path. Therefore, the path of the file it is referring to should begin with a slash
(/). It is treated as an absolute path location of the file from the root of the file system.
An absolute symbolic link can refer to a file or directory within or outside of the file
system of the symbolic link. If the target is not in the same local file system, the
symbolic link is called a widelink. If you enable symbolic links on a share, absolute
symbolic links do not work right away. You must first create a mapping between the
UNIX path of the symbolic link to the destination CIFS path. When creating absolute
symbolic link mappings, you specify whether it is a local or widelink. If you create an
absolute symbolic link to a file or directory outside of the local share but set the locality
to local, Data ONTAP disallows access to the target.
Note that if a client attempts to delete a local symbolic link (absolute or relative), only
the symbolic link is deleted, not the target file or directory. However, if a client attempts
to delete a widelink, it might delete the actual target file or directory that the widelink
refers to. Data ONTAP does not have control over this because the client can explicitly
open the target file or directory outside the Vserver and delete it.

Related concepts
Limits when configuring UNIX symbolic links for SMB access

You need to be aware of certain limits when configuring UNIX symbolic links for SMB access.
Limit
Description
45
Maximum length of the CIFS server name that you can specify when using an FQDN for
the CIFS server name.
Note: You can alternatively specify the CIFS server name as a NetBIOS name, which
is limited to 15 characters.
80
Maximum length of the share name.
256
Maximum length of the UNIX path that you can specify when creating a symbolic link or
when modifying an existing symbolic link's UNIX path.
The UNIX path must start with a / (slash) and end with a /. Both the beginning and
ending slashes count as part of the 256-character limit.
256
Maximum length of the CIFS path that you can specify when creating a symbolic link or
when modifying an existing symbolic link's CIFS path.
The CIFS path must start with a / (slash) and end with a /. Both the beginning and
ending slashes count as part of the 256-character limit.
2048
Maximum number of symbolics links you can create per Vserver.
Related tasks
Creating symbolic link mappings for SMB on page 364
Configuring UNIX symbolic link support on SMB shares

You can configure UNIX symbolic link support on SMB shares by specifying a symbolic link shareproperty setting when you create SMB shares or at any time by modifying existing SMB shares.
UNIX symbolic link support is enabled by default. You can also disable UNIX symbolic link support
on a share.
About this task
When configuring UNIX symbolic link support for SMB shares, you can choose one of the following
settings:
Setting
Description
enable
This setting specifies that symbolic links are enabled for readwrite access. This is the default setting.

Setting
Description
enable,read_only
This setting specifies that symbolic links are enabled for read-only
access.
This setting is the only multiple-value setting allowed. For
example, hide,read_only is not a valid setting.
hide
This setting specifies that SMB clients are prevented from seeing
symbolic links.
"" (null, not set)
This setting disables symbolic links on the share.
- (not set)
This setting disables symbolic links on the share.
Steps

If you want to...
Configure or disable symbolic link

support on a new SMB share
vserver cifs share create -vserver

-symlink-properties {enable|hide|
read_only|""|-},...]
Configure or disable symbolic link

support on an existing SMB share
vserver cifs share modify -vserver

vserver_name -share-name share_name -symlinkproperties {enable|hide|read_only|""|-},...]
For more information about configuring and managing SMB shares, see the man pages for the
vserver cifs share create and vserver cifs share modify commands.
2. Verify that the SMB share configuration is correct:
vserver cifs share show -vserver vserver_name -share-name share_name instance
Example
The following command creates an SMB share named data1 with the UNIX symbolic link
configuration set to enable:
cluster1::> vserver cifs share create -vserver vs1 -share-name data1 -path /
data1 -symlink-properties enable
cluster1::> vserver cifs share vserver cifs share show -vserver vs1 -sharename data1 -instance
Vserver:
Share:
Path:
vs1
data1
VS1
/data1

Share Properties: oplocks
browsable
changenotify
Symlink Properties: enable
File Mode Creation Mask: Directory Mode Creation Mask: Share Comment: Share ACL: Everyone / Full Control
File Attribute Cache Lifetime: Volume Name: Offline Files: manual
Related tasks

Creating symbolic link mappings for SMB on page 364
Creating symbolic link mappings for SMB

You can create mappings of UNIX symbolic links for SMB users. You can either create a relative
symbolic link, which refers to the file or folder relative to its parent folder, or you can create an
absolute symbolic link, which refers to the file or folder using an absolute path.
About this task
You cannot configure widelinks on shares to which Mac OS X clients connect. Widelinks are not
accessible from Mac OS X clients. When a user attempts to connect to a share using widelinks from a
Mac OS X client, the attempt fails.
Step
1. To create symbolic link mappings for SMB, enter the following command:
vserver cifs symlink create -vserver virtual_server_name -unix-path path
-share-name share_name -cifs-path path [-cifs-server server_name] [locality {local|widelink}] [-home-directory {true|false}]
-unix-path path specifies the UNIX path. The UNIX path must begin with a slash (/) and
must end with a slash (/).
-share-name share_name specifies the name of the SMB share to map.
-cifs-path path specifies the CIFS path. The CIFS path must begin with a slash (/) and must
end with a slash (/).
-cifs-server server_name specifies the CIFS server name. The CIFS server name can be
specified as a DNS name (for example, mynetwork.cifs.server.com), IP address, or NetBIOS

name. The NetBIOS name can be determined by using the vserver cifs show command. If
this optional parameter is not specified, the default value is the NetBIOS name of the local CIFS
server.

-locality {local|widelink} specifies whether to create a local or wide symbolic link. A
local symbolic link maps to the local SMB share, and a wide symbolic link maps to any SMB
share on the network. If you do not specify this optional parameter, the default value is
widelink.
-home-directory {true|false} specifies whether the target share is a home directory. Even
though this parameter is optional, you must set this parameter to true when the target share is
configured as a home directory. The default is false.
Example
The following command creates a symbolic link mapping on a Vserver named vs1. It has the
UNIX path /src/, the SMB share name SOURCE, the SMB path /mycompany/source/,
and the CIFS server IP address 123.123.123.123, and it is a widelink.
cluster1::> vserver cifs symlink create -vserver vs1 -unix-path /src/ share-name SOURCE -cifs-path "/mycompany/source/" -cifs-server
123.123.123.123 -locality widelink
Related concepts
How Data ONTAP enables you to provide SMB client access to UNIX symbolic links on page 361
Related tasks
Configuring UNIX symbolic link support on SMB shares on page 362
Commands for managing symbolic link mappings

There are specific Data ONTAP commands for managing symbolic link mappings.
If you want to...
Use this command...
Create a symbolic link mapping
vserver cifs symlink create
Display information about symbolic link

mappings
vserver cifs symlink show
Modify a symbolic link mapping
vserver cifs symlink modify
Delete a symbolic link mapping
vserver cifs symlink delete
Using BranchCache to cache CIFS share content at a

branch office
BranchCache was developed by Microsoft to enable caching of content on computers local to
requesting clients. The Data ONTAP implementation of BranchCache can reduce wide-area network
(WAN) utilization and provide improved access response time when users in a branch office access
content stored on a storage system using CIFS.
If you configure BranchCache, Windows BranchCache clients first retrieve content from the storage
system and then cache the content on a computer within the branch office. If another BranchCacheenabled client in the branch office requests the same content, the storage system first authenticates
and authorizes the requesting user. The storage system then determines whether the cached content is
still up-to-date and, if it is, sends the client metadata about the cached content. The client then uses
the metadata to retrieve content directly from the locally based cache.
Related concepts
Requirements, considerations, and recommendations

Before you can use the BranchCache feature with your Vserver with FlexVol volumes, you need to
be aware of certain requirements, considerations, and recommendations. For example, you need to
know about Data ONTAP support for the feature. You also need to know about SMB version support
and about supported Windows hosts.
Related tasks
Configuring BranchCache on the CIFS server on page 370

BranchCache version support
You should be aware of what BranchCache versions Data ONTAP supports.
Data ONTAP supports BranchCache 1 and the enhanced BranchCache 2:
When you configure BranchCache on the Vserver's CIFS server, you can enable BranchCache 1,
BranchCache 2, or all versions.
By default, all versions are enabled.
If you enable only BranchCache 2, the remote office Windows client machines must support
BranchCache 2.
Only SMB 3.0 or later clients support BranchCache 2.
For more information about BranchCache versions, see the Microsoft TechNet Library.

Related information

Network protocol support requirements
You must be aware of the network protocol requirements for implementing Data ONTAP
BranchCache.
You can implement the Data ONTAP BranchCache feature over IPv4 and IPv6 networks using SMB
2.1 or later.
All CIFS servers and branch office machines participating in the BranchCache implementation must
have the SMB 2.1 or later protocol enabled. SMB 2.1 has protocol extensions that allow a client to
participate in a BranchCache environment. This is the minimum SMB protocol version that offers
BranchCache support. SMB 2.1 supports version BranchCache version 1.
If you want to use BranchCache version 2, SMB 3.0 is the minimum supported version. All CIFS
servers and branch office machines participating in a BranchCache 2 implementation must have
SMB 3.0 or later enabled.
If you have remote offices where some of the clients support only SMB 2.1 and some of the clients
support SMB 3.0, you can implement a BranchCache configuration on the CIFS server that provides
caching support over both BranchCache 1 and BranchCache 2.
Note: Even though the Microsoft BranchCache feature supports using both the HTTP/HTTPS and
SMB protocols as file access protocols, Data ONTAP BranchCache only supports the use of SMB.
Data ONTAP and Windows hosts version requirements
Data ONTAP and branch office Windows hosts must meet certain version requirements before you
can configure BranchCache.
Before configuring BranchCache, you must ensure that the version of Data ONTAP on the cluster
and participating branch office clients support SMB 2.1 or later and support the BranchCache
feature. If you configure Hosted Cache mode, you must also ensure that you use a supported host for
the cache server.
BranchCache 1 is supported on the following Data ONTAP versions and Windows hosts:
Content server: Vserver with Data ONTAP 8.2 or later

Cache server: Windows Server 2008 R2 or Windows Server 2012 or later
Peer or client: Windows 7 Enterprise, Windows 7 Ultimate, Windows 8, Windows Server 2008
R2 or Windows Server 2012 or later
BranchCache 2 is supported on the following Data ONTAP versions and Windows hosts:
Content server: Vserver with Data ONTAP 8.2 or later

Cache server: Windows Server 2012 or later
Peer or client: Windows 8 or Windows Server 2012 or later

For the latest information about which Windows CIFS clients support BranchCache, see the
Reasons Data ONTAP invalidates BranchCache hashes
Understanding the reasons why Data ONTAP invalidates hashes can be helpful as you plan your
BranchCache configuration. It can help you decide which operating mode you should configure and
can help you choose on which shares to enable BranchCache.
Data ONTAP must manage BranchCache hashes to ensure that hashes are valid. If a hash is not
valid, Data ONTAP invalidates the hash and computes a new hash the next time that content is
requested, assuming that BranchCache is still enabled.
Data ONTAP invalidates hashes for the following reasons:
The server key is modified.

If the server key is modified, Data ONTAP invalidates all hashes in the hash store.
A hash is flushed from the cache because the BranchCache hash store maximum size has been
reached.
This is a tunable parameter and can be modified to meet your business requirements.
A file is modified either through CIFS or NFS access.
A file for which there are computed hashes is restored using the snap restore command.
A volume that contains CIFS shares that are BranchCache-enabled is restored using the snap
restore command.
Considerations when choosing the hash store location

When configuring BranchCache, you choose where to store hashes and what size the hash store
should be. Understanding certain considerations when choosing the hash store location and size can
help you plan your BranchCache configuration on a CIFS-enabled Vserver.
You should locate the hash store on a volume where atime updates are permitted.
The access time on a hash file is used to keep frequently accessed files in the hash store. If atime
updates are disabled, the creation time is used for this purpose. It is preferable to use atime to
track frequently used files.
You cannot store hashes on read-only file systems such as SnapMirror destinations and SnapLock
volumes.
If the maximum size of the hash store is reached, older hashes are flushed to make room for new
hashes.
You can increase the maximum size of the hash store to reduce the amount of hashes that are
flushed from the cache.
If the volume on which you store hashes is unavailable or full, or if there is an issue with intracluster communication where the BranchCache service cannot retrieve hash information,
BranchCache services are not available.
The volume might be unavailable because it is offline or because the storage administrator
specified a new location for the hash store.

This does not cause issues with file access. If access to the hash store is impeded, Data ONTAP
returns a Microsoft-defined error to the client, which causes the client to request the file using the
normal SMB read request.
Related concepts
Managing and monitoring the BranchCache configuration on page 377

Related tasks
Configuring BranchCache on the CIFS server on page 370

BranchCache recommendations
Before you configure BranchCache, there are certain recommendations you should keep in mind
when deciding on which CIFS shares you want to enable BranchCache caching.
You should keep the following recommendations in mind when deciding on which operating mode to
use and on which shares to enable BranchCache:
The benefits of BranchCache are reduced when the data to be remotely cached changes
frequently.
BranchCache services are beneficial for shares containing file content that is reused by multiple
remote office clients or by file content that is repeatedly accessed by a single remote user.
Consider enabling caching for read-only content such as data in Snapshot copies and SnapMirror
destinations.
Configuring BranchCache
You configure BranchCache on your CIFS server using Data ONTAP commands. To implement
BranchCache, you must also configure your clients, and optionally your hosted cache servers at the
branch offices where you want to cache content.
If you configure BranchCache to enable caching on a share-by-share basis, you must enable
BranchCache on the SMB shares for which you want to provide BranchCache caching services.
Prerequisites for configuring BranchCache
After meeting some prerequisites, you can set up BranchCache.
The following requirements must be met before configuring BranchCache on your Vserver's CIFS
server:
Data ONTAP 8.2 or later must be installed on all nodes in the cluster.
CIFS must be licensed and a CIFS server must be configured.
IPv4 or IPv6 network connectivity must be configured.
For BranchCache 1, SMB 2.1 or later must be enabled.
For BranchCache 2, SMB 3.0 must be enabled and the remote Windows clients must support
BranchCache 2.
Configuring BranchCache on the CIFS server

You can configure BranchCache to provide BranchCache services on a per-share basis.
Alternatively, you can configure BranchCache to automatically enable caching on all SMB shares.
About this task
You can configure BranchCache on Vservers with FlexVol volumes.
You can create a per-share BranchCache configuration if want to offer caching services for all
content contained within all SMB shares on the CIFS server.
You can create an all shares BranchCache configuration if you want to offer caching services for
content contained within selected SMB shares on the CIFS server.
You must specify the following parameters when configuring BranchCache:

Required parameters
Description
Vserver
BranchCache is configured on a per Vserver basis. You must specify

on which CIFS-enabled Vserver you want to configure the
BranchCache service.
Path to hash store
BranchCache hashes are stored in regular files on a Vserver volume.

You must specify the path to an existing directory where you want
Data ONTAP to store the hash data.
The destination path must be read-writable. Read-only paths, such as
Snapshot directories are not allowed. You can store hash data in a
volume that contains other data or you can create a separate volume to
store hash data.
You can optionally specify the following parameters:

Optional parameters
Description
Supported Versions
Data ONTAP support BranchCache 1 and 2. You can enable version 1,

version 2, or both versions. The default is to enable both versions.
Maximum size of hash

store
You can specify the size to use for the hash data store. If the hash data
exceeds this value, Data ONTAP deletes older hashes to make room
for newer hashes. The default size for the hash store is 1 GB.
BranchCache performs more efficiently if hashes are not discarded in
an overly aggressive manner. If you determine that hashes are
discarded frequently because the hash store is full, you can increase
the hash store size by modifying the BranchCache configuration.

Optional parameters
Description
Server key
You can specify a server key that the BranchCache service uses to
prevent clients from impersonating the BranchCache server. If you do
not specify a server key, one is randomly generated when you create
the BranchCache configuration.
You can set the server key to a specific value so that if multiple
servers are providing BranchCache data for the same files, clients can
use hashes from any server using that same server key. If the server
key contains any spaces, you must enclose the server key in quotation
marks.
Operating mode
The default is to enable BranchCache on a per-share basis.
To create a BranchCache configuration where you enable

BranchCache on a per-share basis, you can either not specify this
optional parameter or you can specify per-share.
To automatically enable BranchCache on all shares, you must set
the operating mode to all-shares.
Steps
1. Enable SMB 2.1 and 3.0 as needed:

a) Set the privilege level to advanced:
b) Check the configured Vserver SMB settings to determine whether all needed versions of SMB
are enabled:
vserver cifs options show -vserver vserver_name
c) If necessary, enable SMB 2.1:

vserver cifs options modify -vserver vserver_name -smb2-enabled true
The command enables both SMB 2.0 and SMB 2.1.

d) If necessary, enable SMB 3.0:
vserver cifs options modify -vserver vserver_name -smb3-enabled true
e) Return to the admin privilege level:

2. Configure BranchCache:
vserver cifs branchcache create -vserver vserver_name -hash-store-path
path [-hash-store-max-size {integer[KB|MB|GB|TB|PB]}] [-versions {v1enable|v2-enable|enable-all] [-server-key text] -operating-mode {pershare|all-shares}

The specified hash storage path must exist and must reside on a volume managed by the Vserver.
The path must also be located on a read-writable volume. The command fails if the path is readonly or does not exist.
If you want to use the same server key for additional Vserver BranchCache configurations, record
the value you enter for the server key. The server key does not appear when you display
information about the BranchCache configuration.
For more information, see the man page for the vserver cifs branchcache create
command.
3. Verify that the BranchCache configuration is correct:
vserver cifs branchcache show -vserver vserver_name
Examples
The following commands verify that both SMB 2.1 and 3.0 are enabled and configure
BranchCache to automatically enable caching on all CIFS shares on Vserver vs1:
cluster1::*> vserver cifs options show -vserver vs1
Vserver: vs1
Copy Offload Enabled:
Default Unix Group:
Default Unix User:
Export Policies Enabled:
Is Referral Enabled:
Is Local Auth Enabled:
Is Local Users and Groups Enabled:
Max Multiplex Count:
Read Grants Exec:
Shadowcopy Dir Depth:
Shadowcopy Enabled:
SMB2 Enabled:
SMB3 Enabled:
WINS Servers:
Is Use Junction as Reparse Point Enabled:
true
pcuser
false
false
true
true
255
disabled
5
true
true
true
true

cluster1::> vserver cifs branchcache create -vserver vs1 -hash-store-path /
hash_data -hash-store-max-size 20GB -versions enable-all -server-key "my
server key" -operating-mode all-shares
cluster1::> vserver cifs branchcache show -vserver vs1
Vserver:
Supported BranchCache Versions:
Path to Hash Store:
Maximum Size of the Hash Store:
Encryption Key Used to Secure the Hashes:
CIFS BranchCache Operating Modes:
vs1
enable_all
/hash_data
20GB
all_shares

The following commands verify that both SMB 2.1 and 3.0 are enabled, configure
BranchCache to enable caching on a per-share basis on Vserver vs1, and verify the
BranchCache configuration:
cluster1::*> vserver cifs options show -vserver vs1
Vserver: vs1
Default Unix Group:
Default Unix User:
Read Grants Exec:
Shadowcopy Enabled:
SMB2 Enabled:
SMB3 Enabled:
WINS Servers:
true
pcuser
false
false
true
true
255
disabled
5
true
true
true
true

cluster1::> vserver cifs branchcache create -vserver vs1 -hash-store-path /
hash_data -hash-store-max-size 20GB -versions enable-all -server-key "my
server key"
Vserver:
Path to Hash Store:
vs1
enable_all
/hash_data
20GB
per_share
Related concepts
Requirements, considerations, and recommendations on page 366

Where to find information about configuring BranchCache at the remote office on page 374
Managing and monitoring the BranchCache configuration on page 377
Disabling or enabling BranchCache on a Vserver on page 389
Deleting the BranchCache configuration on a Vserver on page 391
Related tasks
Creating a BranchCache-enabled SMB share on page 374
Enabling BranchCache on an existing SMB share on page 376

Where to find information about configuring BranchCache at the remote office
After configuring BranchCache on the CIFS server, you must install and configure BranchCache on
client computers and, optionally, on caching servers at your remote office. Microsoft provides
instructions for configuring BranchCache at the remote office.
Instructions for configuring branch office clients and, optionally, caching servers to use BranchCache
are on the Microsoft BranchCache web site at Microsoft BranchCache: technet.microsoft.com/ENUS/NETWORK/DD425028.
Configuring BranchCache-enabled SMB shares

After you configure BranchCache on the CIFS server and at the branch office, you can enable
BranchCache on SMB shares that contain content that you want to allow clients at branch offices to
cache.
BranchCache caching can be enabled on all SMB shares on the CIFS server or on a share-by-share
basis.
If you enable BranchCache on a share-by-share basis, you can enable BranchCache as you create
the share or by modifying existing shares.
If you enable caching on an existing SMB share, Data ONTAP begins computing hashes and
sending metadata to clients requesting content as soon as you enable BranchCache on that share.
Any clients that have an existing SMB connection to a share do not get BranchCache support if
BranchCache is subsequently enabled on that share.
Data ONTAP advertises BranchCache support for a share at the time the SMB session is set up.
Clients that already have established sessions when BranchCache is enabled need to disconnect
and reconnect to use cached content for this share.
Note: If BranchCache on a SMB share is subsequently disabled, Data ONTAP stops sending
metadata to the requesting client. A client that needs data retrieves it directly from the content
server (CIFS server).
Creating a BranchCache-enabled SMB share

You can enable BranchCache on a SMB share when you create the share by setting the
branchcache share property.
About this task
If BranchCache is enabled on the SMB share, the share must have the offline files configuration set
to manual caching. This is the default setting when you create a share.
You can set the branchcache property on a share even if BranchCache is not configured and
enabled on the Vserver. However, if you want the share to offer cached content, you must configure
and enable BranchCache on the Vserver.

Steps
1. To create a BranchCache-enabled SMB share, enter the following command:

vserver cifs share create -vserver vserver_name -share-name share_name path path -share-properties branchcache
path specifies the path to the share. Path separators can be backward or forward slashes,
although Data ONTAP displays them as forward slashes.

You can specify additional optional share settings and additional share properties when you
create a SMB share. For more information, see the man page for the vserver cifs share
create command.
2. Verify that the BranchCache share property is set on the SMB share by using the vserver cifs
share show command.
Example
The following command creates a BranchCache-enabled SMB share named data with a path
of /data on Vserver vs1. By default, offline files is set to manual:
cluster1::> vserver cifs share create -vserver vs1 -share-name data -path /
data -share-properties branchcache,oplocks,browsable,changenotify
cluster1::> vserver cifs share
data
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
show -vserver vs1 -share-name

vs1
data
VS1
/data
branchcache
oplocks
browsable
changenotify
enable
data
manual
Related tasks

Disabling BranchCache on a single SMB share on page 388
Enabling BranchCache on an existing SMB share

You can enable BranchCache on an existing SMB share by adding the branchcache share property
to the existing list of share properties.
About this task
If BranchCache is enabled on the SMB share, the share must have the offline files configuration set
to manual caching. If the existing share's offline files setting is not set to manual caching, you must
configure it by modifying the share.
You can set the branchcache property on a share even if BranchCache is not configured and
enabled on the Vserver. If you want the share to offer cached content, you must configure and enable
BranchCache on the Vserver.
Steps
1. If necessary, configure the offline files share setting for manual caching:
a) Determine what the offline files share setting is by using the vserver cifs share show
command.
b) If the offline files share setting is not set to manual, change it to the required value:
vserver cifs share modify -vserver vserver_name -share-name share_name
-offline-files manual
2. Enable BranchCache on an existing SMB share by entering the following command:

vserver cifs share properties add -vserver vserver_name -share-name
share_name -share-properties branchcache
Existing share settings and share properties are preserved. The BranchCache share property is
added to the existing list of share properties.
For more information about using the vserver cifs share properties add command, see
the man pages.
3. Verify that the BranchCache share property is set on the SMB share:
Example
The following command enables BranchCache on an existing SMB share named data2 with
a path of /data2 on Vserver vs1:
cluster1::> vserver cifs share show -vserver vs1 -share-name data2
Vserver:
Share:
Path:
Share Properties:
vs1
data2
VS1
/data2
oplocks
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
browsable
changenotify
showsnapshot
10s
manual
cluster1::> vserver cifs share properties add

data2 -share-properties branchcache
-vserver vs1 -share-name

Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
data2
VS1
/data2
oplocks
browsable
showsnapshot
changenotify
branchcache
10s
manual
Related tasks

Disabling BranchCache on a single SMB share on page 388
Managing and monitoring the BranchCache configuration

You manage the BranchCache configuration by modifying BranchCache parameters, changing the
server secret key, configuring BranchCache to pre-compute hashes, flushing the hash cache, and
configuring BranchCache GPOs. You can also display information about BranchCache statistics.
Related concepts
Considerations when choosing the hash store location on page 368

Modifying BranchCache configurations
You can modify the configuration of the BranchCache service on a Vserver, including changing the
hash store directory path, the hash store maximum directory size, the operating mode, and which

BranchCache versions are supported. You can also increase the size of the volume that contains the
hash store.
Steps

If you want to...
Modify the hash

store directory size
vserver cifs branchcache modify -vserver vserver_name hash-store-max-size {integer[KB|MB|GB|TB|PB]}
Increase the size of

the volume that
contains the hash
store
volume size -vserver vserver_name -volume volume_name new-size new_size[k|m|g|t]
Modify the hash

store directory path
If the volume containing the hash store fills up, you might be able to increase the
size of the volume. You can specify the new volume size as a number followed by
a unit designation. See the Clustered Data ONTAP Logical Storage Management
Guide for more information about increasing volume size.
vserver cifs branchcache modify -vserver vserver_name hash-store-path path -flush-hashes {true|false}
If you modify the hash store path, -flush-hashes is a required parameter that
specifies whether you want Data ONTAP to flush the hashes from the original hash
store location.
If you specify true for the value of -flush-hashes, Data ONTAP deletes the
hashes in the original location and creates new hashes in the new location as new
requests are made by BranchCache-enabled clients. If set to false, the hashes are
not flushed. In this case, you can choose to reuse the existing hashes later by
changing the hash store path back to the original location.
Change the operating vserver cifs branchcache modify -vserver vserver_name mode
operating-mode mode
The possible values for -operating-mode are as follows:
per-share
all-shares
disable
Note: You should be aware of the following when modifying the operating
mode:
Data ONTAP advertises BranchCache support for a share when the SMB
session is set up.
Clients that already have established sessions when BranchCache is enabled
need to disconnect and reconnect to use cached content for this share.

If you want to...
Change the
vserver cifs branchcache modify -vserver vserver_name BranchCache version versions {v1-enable|v2-enable|enable-all}
support
See the man page for the vserver cifs branchcache modify command for more
information.
2. Verify the configuration changes by using the vserver cifs branchcache show command.
Displaying information about BranchCache configurations
You can display information about BranchCache configurations on a Vserver with FlexVol volumes,
which can be used when verifying a configuration or when determining current settings before
modifying a configuration.
Step

Summary information about BranchCache

configurations on all Vservers
vserver cifs branchcache show
Detailed information about the configuration on a

Vserver
vserver cifs branchcache show vserver vserver_name
branchcache show command. See the man page for this command for more information.
Example
The following example displays information about the BranchCache configuration on Vserver
vs1:
Vserver:
Path to Hash Store:
vs1
enable_all
/hash_data
20GB
per_share
Changing the BranchCache server key

You can change the BranchCache server key by modifying the BranchCache configuration on the
Vserver and specifying a different server key.
About this task
You can set the server key to a specific value so that if multiple servers are providing BranchCache
data for the same files, clients can use hashes from any server using that same server key.
When you change the server key, you must also flush the hash cache. After flushing the hashes, Data
ONTAP creates new hashes as new requests are made by BranchCache-enabled clients.
Steps
1. Change the server key by using the following command:

vserver cifs branchcache modify -vserver vserver_name -server-key text flush-hashes true
text specifies the text string to use as the server key. If the server key contains any spaces,
enclose the server key in quotation marks. When configuring a new server key, you must also
specify -flush-hashes and set the value to true.
2. Verify that the BranchCache configuration is correct by using the vserver cifs
branchcache show command.
Example
The following example sets a new server key that contains spaces and flushes the hash cache
on Vserver vs1:
cluster1::> vserver cifs branchcache modify -vserver vs1 -server-key "new
vserver secret" -flush-hashes true
Vserver:
Path to Hash Store:
vs1
enable_all
/hash_data
20GB
per_share
Related concepts
Reasons Data ONTAP invalidates BranchCache hashes on page 368
Pre-computing BranchCache hashes on specified paths

You can configure the BranchCache service to pre-compute hashes for a single file, for a directory,
or for all files in a directory structure. This can be helpful if you want to compute hashes on data in a
BranchCache-enabled share during off, non-peak hours.
Before you begin
You must use the statistics start and optional statistics stop commands to collect a data
sample before you can display hash statistics. For more information about these commands, see the
About this task
You must specify the Vserver and path on which you want to pre-compute hashes. You must also
specify whether you want hashes computed recursively. If you want hashes computed recursively,
the BranchCache service traverses the entire directory tree under the specified path, and computes
hashes for each eligible object.
Steps
1. Perform the appropriate command:

If you want to pre-compute hashes on... Enter the command...
A single file or directory
vserver cifs branchcache hash-create vserver vserver_name -path path -recurse

false
Recursively on all files in a directory

structure
vserver cifs branchcache hash-create vserver vserver_name -path path -recurse

true
path is specified as an absolute path.
2. Verify that hashes are being computed by using the statistics command:
a) Display statistics for the hashd object on the desired Vserver instance:
statistics show -object hashd -instance vserver_name
b) Verify that the number of hashes created is increasing by repeating the command.
Examples
The following example creates hashes on the path /data and on all contained files and
subdirectories on Vserver vs1:
cluster1::> vserver cifs branchcache hash-create -vserver vs1 -path /data recurse true

cluster1::> statistics show -object hashd -instance vs1
Object: hashd
Instance: vs1
Start-time: 9/6/2012 19:09:54
End-time: 9/6/2012 19:11:15
Cluster: cluster1
Counter
Value
-------------------------------- -------------------------------branchcache_hash_created
85
branchcache_hash_files_replaced
0
branchcache_hash_rejected
0
branchcache_hash_store_bytes
0
branchcache_hash_store_size
0
instance_name
vs1
node_name
node1
node_uuid
11111111-1111-1111-1111-111111111111
process_name
cluster1::> statistics show -object hashd -instance vs1
Object: hashd
Instance: vs1
Start-time: 9/6/2012 19:09:54
End-time: 9/6/2012 19:11:15
Cluster: cluster1
Counter
Value
-------------------------------- -------------------------------branchcache_hash_created
92
0
0
0
branchcache_hash_store_size
0
instance_name
vs1
node_name
node1
node_uuid
11111111-1111-1111-1111-111111111111
process_name
-
Flushing hashes from a Vserver BranchCache hash store

You can flush all cached hashes from the Vserver BranchCache hash store. This can be useful if you
have changed the branch office BranchCache configuration. For example, if you recently
reconfigured the caching mode from distributed caching to hosted caching mode, you would want to
flush the hash store.
About this task
After flushing the hashes, Data ONTAP creates new hashes as new requests are made by
BranchCache-enabled clients.
Step
1. Flush the hashes from the BranchCache hash store:

vserver cifs branchcache hash-flush -vserver vserver_name

The Vserver name is the only parameter available for this command. It is a required parameter.
Example
The following command flushes the hashes from the BranchCache hash store for Vserver vs1:
cluster1::> vserver cifs branchcache hash-flush -vserver vs1
Displaying BranchCache statistics

You can display BranchCache statistics to, among other things, identify how well caching is
performing, determine whether your configuration is providing cached content to clients, and
determine whether hash files were deleted to make room for more recent hash data.
About this task
The hashd statistic object contain counters that provide statistical information about BranchCache
hashes. You can collect and display information about the hashd object at the admin-privilege level.
The cifs statistic object contain counters that you can use at the advanced-privilege level that
provide statistical information about BranchCache-related activity.
Steps
1. Display the BranchCache-related counters by using the statistics catalog counter show
command.
For more information about statistics counters, see the man page for this command.
Example
cluster1::> statistics catalog counter show -object hashd
Object: hashd
Counter
Description
--------------------------- ---------------------------------------------branchcache_hash_created
Number of times a request to generate
BranchCache hash for a file succeeded.
Number of times a BranchCache hash file was
deleted to make room for more recent hash
data. This happens if the hash store size is
exceeded.
Number of times a request to generate
BranchCache hash data failed.
Total number of bytes used to store hash data.
branchcache_hash_store_size Total space used to store BranchCache hash
data for the Vserver.
instance_name
Instance Name
instance_uuid
Instance UUID
node_name
System node name
node_uuid
System node id

Object: cifs
Counter
--------------------------active_searches
Description
avg_directory_depth
avg_junction_depth
data succeeded.
requesting hashes.
....Output truncated....
2. Collect BranchCache-related statistics by using the statistics start and statistics

stop commands.
For more information about collecting statistics, see the Clustered Data ONTAP System
Example
cluster1::*> statistics start -object cifs -vserver vs1 -sample-id 11
Statistics collection is being started for Sample-id: 11
cluster1::*> statistics stop -sample-id 11
Statistics collection is being stopped for Sample-id: 11
3. Display the collected BranchCache statistics by using the statistics show command.
If you want to display statistics for counters that are available only in advanced-privilege level,
you must run the statistics show command at the advanced-privilege level. For more
information about displaying statistical information, see the Clustered Data ONTAP System

Example
cluster1::*> statistics show -object cifs -counter
branchcache_hash_sent_bytes -sample-id 11
Object: cifs
Instance: vs1
Start-time: 12/26/2012 19:50:24
End-time: 12/26/2012 19:51:01
Cluster: cluster1
Counter
Value
-------------------------------- -------------------------------branchcache_hash_sent_bytes
0
branchcache_hash_sent_bytes
0
0
0
cluster1::*> statistics show -object cifs -counter
branchcache_missing_hash_bytes -sample-id 11
Object: cifs
Instance: vs1
Start-time: 12/26/2012 19:50:24
End-time: 12/26/2012 19:51:01
Cluster: cluster1
Counter
Value
-------------------------------- -------------------------------branchcache_missing_hash_bytes
0
0
0
0
Related tasks

Support for BranchCache Group Policy Objects
Data ONTAP BranchCache provides support for BranchCache Group Policy Objects (GPOs), which
allow centralized management for certain BranchCache configuration parameters. There are two
GPOs used for BranchCache, the Hash Publication for BranchCache GPO and the Hash Version
Support for BranchCache GPO.
Hash Publication for
BranchCache GPO
The Hash Publication for BranchCache GPO corresponds to the operating-mode parameter. When GPO updates occur, this value is
applied to Vserver objects contained within the organizational unit (OU)
to which the group policy applies.
Hash Version Support The Hash Version Support for BranchCache GPO corresponds to the for BranchCache GPO versions parameter. When GPO updates occur, this value is applied to
Vserver objects contained within the organizational unit to which the
group policy applies.

Related concepts

Displaying information about BranchCache Group Policy Objects
You can display information about the CIFS server's Group Policy Object (GPO) configuration to
determine whether BranchCache GPOs are defined for the domain to which the CIFS server belongs
and, if so, what the allowed settings are. You can also determine whether BranchCache GPO settings
are applied to the CIFS server.
About this task
Even though a GPO setting is defined within the domain to which the CIFS server belongs, it is not
necessarily applied to the organizational unit (OU) containing the CIFS-enabled Vserver. Applied
GPO setting are the subset of all defined GPOs that are applied to the CIFS-enabled Vserver.
BranchCache settings applied through GPOs override settings applied through the CLI.
Steps
1. Display the defined BranchCache GPO setting for the Active Directory domain by using the
vserver cifs group-policy show-defined command.
Example
cluster1::> vserver cifs group-policy show-defined -vserver vs1
Vserver: vs1
Level: Domain
Status: enabled
Registry Settings:
Hash Version Support for BranchCache : all-versions
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Status: disabled
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7

2. Display the BranchCache GPO setting applied to the CIFS server by using the vserver cifs
group-policy show-applied command.
Example
cluster1::> vserver cifs group-policy show-applied -vserver vs1
Vserver: vs1
Level: Domain
Status: enabled
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Registry Settings:
Security Settings:
Kerberos:
Max Clock Skew: 5
Max Ticket Age: 10
Max Renew Age: 7
Related tasks
Disabling BranchCache on SMB shares

If you do not want to provide BranchCache caching services on certain SMB shares but you might
want to provide caching services on those shares later, you can disable BranchCache on a share-byshare basis. If you have BranchCache configured to offer caching on all shares but you want to
temporarily disable all caching services, you can modify the BranchCache configuration to stop
automatic caching on all shares.
If BranchCache on a SMB share is subsequently disabled after first being enabled, Data ONTAP
stops sending metadata to the requesting client. A client that needs data retrieves it directly from the
content server (CIFS server on the Vserver).
Related concepts
Configuring BranchCache-enabled SMB shares on page 374
Disabling BranchCache on a single SMB share

If you do not want to offer caching services on certain shares that previously offered cached content,
you can disable BranchCache on an existing SMB share.
Step

vserver cifs share properties remove -vserver vserver_name -share-name
share_name -share-properties branchcache
For more information about using the vserver cifs share properties remove command,
see the man pages.
The BranchCache share property is removed. Other applied share properties remain in effect.
Example
The following command disables BranchCache on an existing SMB share named data2:
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
data2
VS1
/data2
oplocks
browsable
changenotify
attributecache
branchcache
10s
manual

data2 -share-properties branchcache
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
vs1
data2
VS1
/data2
oplocks
browsable
changenotify
attributecache
-

Share ACL:
Volume Name:
Offline Files:

10s
manual
Stopping automatic caching on all SMB shares

If your BranchCache configuration automatically enables caching on all SMB shares on a Vserver
with FlexVol volumes, you can modify the BranchCache configuration to stop automatically caching
content for all SMB shares.
About this task
To stop automatic caching on all SMB shares, you change the BranchCache operating mode to pershare caching.
Steps
1. Configure BranchCache to stop automatic caching on all SMB shares by entering the following
command:
vserver cifs branchcache modify -vserver vserver_name -operating-mode
per-share
2. Verify that the BranchCache configuration is correct:

Example
The following command changes the BranchCache configuration on Vserver vs1 to stop
automatic caching on all SMB shares:
cluster1::> vserver cifs branchcache modify -vserver vs1 -operating-mode
per-share
Vserver:
Path to Hash Store:
vs1
enable_all
/hash_data
20GB
per_share
Disabling or enabling BranchCache on a Vserver

You can disable BranchCache on the Vserver if you temporarily do not want to offer caching
services on that Vserver. You can easily offer caching services again in the future by enabling
BranchCache on the Vserver.
What happens when you disable or reenable BranchCache on the CIFS server
If you previously configured BranchCache but do not want the branch office clients to use cached
content, you can disable caching on the CIFS server. You must be aware of what happens when you
disable BranchCache.
When you disable BranchCache, Data ONTAP no longer computes hashes or sends the metadata to
the requesting client. However, there is no interruption to file access. Thereafter, when BranchCacheenabled clients request metadata information for content they want to access, Data ONTAP responds
with a Microsoft-defined error, which causes the client to send a second request, requesting the actual
content. In response to the request for content, the CIFS server sends the actual content that is stored
on the Vserver.
After BranchCache is disabled on the CIFS server, CIFS shares do not advertise BranchCache
capabilities. To access data on new SMB connections, clients make normal read SMB requests.
You can reenable BranchCache on the CIFS server at any time.
Because the hash store is not deleted when you disable BranchCache, Data ONTAP can use the
stored hashes when replying to hash requests after you reenable BranchCache, provided that the
requested hash is still valid.
Any clients that have made SMB connections to BranchCache-enabled shares during the time
when BranchCache was disabled do not get BranchCache support if BranchCache is subsequently
reenabled.
This is because Data ONTAP advertises BranchCache support for a share at the time the SMB
session is set up. Clients that established sessions to BranchCache-enabled shares while
BranchCache was disabled need to disconnect and reconnect to use cached content for this share.
Note: If you do not want to save the hash store after you disable BranchCache on a CIFS server,
you can manually delete it. If you reenable BranchCache, you must ensure that the hash store
directory exists. After BranchCache is reenabled, BranchCache-enabled shares advertise
BranchCache capabilities. Data ONTAP creates new hashes as new requests are made by
BranchCache-enabled clients.
Disabling or enabling BranchCache

You can disable BranchCache on the Vserver with FlexVol volumes by changing the BranchCache
operating mode to disabled. You can enable BranchCache at any time by changing the operating
mode to either offer BranchCache services per-share or automatically for all shares.
Steps
1. Run the appropriate command:

If you want to...
Then enter the following...
Disable BranchCache
vserver cifs branchcache modify -vserver

vserver_name -operating-mode disable

If you want to...
Enable BranchCache per share
vserver cifs branchcache modify -vserver

vserver_name -operating-mode per-share
Enable BranchCache for all shares vserver cifs branchcache modify -vserver
vserver_name -operating-mode all-shares
2. Verify that the BranchCache operating mode is configured with the desired setting:
Example
The following example disables BranchCache on Vserver vs1:
cluster1::> vserver cifs branchcache modify -vserver vs1 -operating-mode
disable
Vserver:
Path to Hash Store:
vs1
enable_all
/hash_data
20GB
disable
Deleting the BranchCache configuration on a Vserver

You can delete the BranchCache configuration if you no longer want to offer caching services on that
Vserver.
What happens when you delete the BranchCache configuration
If you previously configured BranchCache but do not want the Vserver to continue providing cached
content, you can delete the BranchCache configuration on the CIFS server. You must be aware of
what happens when you delete the configuration.
When you delete the configuration, Data ONTAP removes the configuration information for that
Vserver from the cluster and stops the BranchCache service. You can choose whether Data ONTAP
should delete the Vserver's hash store.
Deleting the BranchCache configuration does not disrupt access by BranchCache-enabled clients.
Thereafter, when BranchCache-enabled clients request metadata information on existing SMB
connections for content that is already cached, Data ONTAP responds with a Microsoft defined error,
which causes the client to send a second request, requesting the actual content. In response to the
request for content, the CIFS server sends the actual content that is stored on the Vserver.
After the BranchCache configuration is deleted, CIFS shares do not advertise BranchCache
capabilities. To access content that has not previously been cached using new SMB connections,
clients make normal read SMB requests.
Deleting the BranchCache configuration

The command you use for deleting the BranchCache service on a Vserver differs depending on
whether you want to delete or keep existing hashes.
Step
1. Run the appropriate command:

If you want to...
Delete the BranchCache configuration and

delete existing hashes
vserver cifs branchcache delete -vserver

vserver_name -flush-hashes true
Delete the BranchCache configuration but

keep existing hashes
vserver cifs branchcache delete -vserver

vserver_name -flush-hashes false
Example
The following example deletes the BranchCache configuration on Vserver vs1 and deletes all
existing hashes:
cluster1::> vserver cifs branchcache delete -vserver vs1 -flush-hashes true
What happens to BranchCache when reverting

It is important to understand what happens when you revert Data ONTAP to a release that does not
support BranchCache.
When you revert to a version of Data ONTAP that does not support BranchCache, the CIFS
shares do not advertise BranchCache capabilities to BranchCache-enabled clients; therefore, the
clients do not request hash information.
Instead, they request the actual content using normal SMB read requests. In response to the
request for content, the CIFS server sends the actual content that is stored on the Vserver.
When a node hosting a hash store is reverted to a release that does not support BranchCache, the
storage administrator needs to manually revert the BranchCache configuration using a command
that is printed out during the revert.
This command deletes the BranchCache configuration and hashes.
After the revert completes, the storage administrator can manually delete the directory that
contained the hash store if desired.
Related concepts
Deleting the BranchCache configuration on a Vserver on page 391
Improving Microsoft remote copy performance

Microsoft Offloaded Data Transfer (ODX), also known as copy offload, enables direct data transfers
within or between compatible storage devices without transferring the data through the host
computer.
Data ONTAP supports ODX for both the CIFS and SAN protocols. The source can be either a CIFS
server or LUNs, and the destination can be either a CIFS server or LUNs.
In non-ODX file transfers, the data is read from the source and is transferred across the network to
the client computer. The client computer transfers the data back over the network to the destination.
In summary, the client computer reads the data from the source and writes it to the destination. With
ODX file transfers, data is copied directly from the source to the destination.
Because ODX offloaded copies are performed directly between the source and destination storage,
there are significant performance benefits. The performance benefits realized include faster copy
time between source and destination, reduced resource utilization (CPU, memory) on the client, and
reduced network I/O bandwidth utilization.
For CIFS environments, this functionality is only available when both the client and the storage
server support SMB 3.0 and the ODX feature. For SAN environments, this functionality is only
available when both the client and the storage server support the ODX feature. Client computers that
support ODX and have ODX enabled automatically and transparently use offloaded file transfer
when moving or copying files. ODX is used irrespective of whether you drag-and-drop files through
Windows Explorer or use command-line file copy commands, or whether a client application
initiates file copy requests.
Related concepts
Improving client response time by providing SMB automatic node referrals with Auto Location on
page 399
How ODX copy offload is used with Hyper-V over SMB on page 417
How ODX works

ODX copy offload uses a token-based mechanism for reading and writing data within or between
ODX-enabled CIFS servers. Instead of routing the data through the host, the CIFS server sends a
small token, which represents the data, to the client. The ODX client presents that token to the
destination server, which then can transfer the data represented by that token from the source to the
destination.
When an ODX client learns that the CIFS server is ODX-capable, it opens the source file and
requests a token from the CIFS server. After opening the destination file, the client uses the token to
instruct the server to copy the data directly from the source to the destination.
Note: The source and destination can be on the same Vserver or on different Vservers, depending
on the scope of the copy operation.

The token serves as a point-in-time representation of the data. As an example, when you copy data
between storage locations, a token representing a data segment is returned to the requesting client,
which the client copies to the destination, thereby removing the need to copy the underlying data
through the client.
Data ONTAP supports tokens that represent 8 MB of data. ODX copies of greater than 8 MB are
performed by using multiple tokens, with each token representing 8 MB of data.
The following figure explains the steps that are involved with an ODX copy operation:
2
3
To ke n
To ke n
A1
A2
A3
A4
Data Transfer
6
1. A user copies or moves a file by using Windows Explorer, a command-line interface, or as part of
a virtual machine migration, or an application initiates file copies or moves.
2. The ODX-capable client automatically translates this transfer request into an ODX request.
The ODX request that is sent to the CIFS server contains a request for a token.
3. If ODX is enabled on the CIFS server and the connection is over SMB 3.0, the CIFS server
generates a token, which is a logical representation of the data on the source.

4. The client receives a token that represents the data and sends it with the write request to the
destination CIFS server.
This is the only data that is copied over the network from the source to the client and then from
the client to the destination.
5. The token is delivered to the storage subsystem.
6. The Vserver internally performs the copy or move.
If the file that is copied or moved is larger than 8 MB, multiple tokens are needed to perform the
copy. Steps 2 through 6 as performed as needed to complete the copy.
Note: If there is a failure with the ODX offloaded copy, the copy or move operation falls back to
traditional reads and writes for the copy or move operation. Similarly, if the destination CIFS
server does not support ODX or ODX is disabled, the copy or move operation falls back to
traditional reads and writes for the copy or move operation.
Requirements for using ODX

Before you can use ODX for copy offloads with your Vserver with FlexVol volumes, you need to be
aware of certain requirements.
Clustered Data ONTAP 8.2 and later releases support ODX for copy offloads.
SMB version requirements for CIFS
Clustered Data ONTAP supports ODX with SMB 3.0 and later.
SMB 3.0 must be enabled on the CIFS server before ODX can be enabled:
Enabling ODX also enables SMB 3.0, if it is not already enabled.

Disabling SMB 3.0 also disables ODX.
Windows server and client requirements

Before a user can use ODX for copy offloads, the Windows client must support the feature. Support
for ODX starts with Windows 2012 Server and Windows 8.
For the latest information about which Windows clients support ODX, see the Interoperability Matrix
at support.netapp.com/NOW/products/interoperability.
Volume requirements
Source volumes must be a minimum of 1.25 GB.

Deduplication must be enabled on volumes used with copy offload.
Compression must not be enabled on volumes used with copy offload.
Considerations for using ODX

Before you can use ODX for copy offload, you need to be aware of certain considerations. For
example, you need to know on which types of volumes you can use ODX and you need to understand
the intra-cluster and inter-cluster ODX considerations.
Volume considerations
You must keep the following volume considerations in mind:
You cannot use ODX for copy offload with the following volume configurations:
Source volume size is less than 1.25 GB

The volume size must be 1.25 GB or larger to use ODX.
Read-only volumes
ODX is not used for file and folders residing in load sharing mirrors or in SnapMirror or
SnapVault destination volumes.
FlexCache volumes
If the source volume is compressed
If the source volume is not deduplicated
ODX copies are supported only for intra-cluster copies.
You cannot use ODX to copy files or folders to a volume in another cluster.
ODX is supported for Vservers with FlexVol volumes.
You cannot use ODX to copy data to or from volumes in Vservers with Infinite Volume.
Other considerations
There are some additional considerations you should keep in mind:
In CIFS environments, to use ODX for copy offload, the files must be 256 kb or larger.
Smaller files are transferred using a traditional copy operation.
ODX copy offload uses deduplication as part of the copy process.
If you do not want deduplication to occur on a Vserver's volumes when copying or moving data,
you should disable ODX copy offload on that Vserver.
The application that performs the data transfer must be written to support ODX.
Application operations that support ODX include the following:
Hyper-V management operations, such as creating and converting virtual hard disks (VHDs),
managing Snapshot copies, and copying files between virtual machines
Windows Explorer operations
Windows PowerShell copy commands
Windows command prompt copy commands
Robocopy at the Windows command prompt supports ODX.
Note: The applications must be running on Windows servers or clients that support ODX.

For more information about supported ODX applications on Windows servers and clients,
consult the Microsoft TechNet Library.
Related information
Use cases for ODX

You should be aware of the use cases for using ODX on Vservers with FlexVol volumes so that you
can determine under what circumstances this feature provides you with performance benefits.
Windows servers and clients that support ODX use copy offload as the default way of copying data
across remote servers. If the Windows server or client does not support ODX or the ODX copy
offload fails at any point, the copy or move operation falls back to traditional reads and writes for the
copy or move operation.
The following use cases support using ODX copies and moves:
Intra-volume
The source and destination files or LUNs are within the same volume. The copy is performed by
using FlexClone file technology, which provides additional remote copy performance benefits.
Inter-volume, same node, same Vserver
The source and destination files or LUNs are on different volumes that are located on the same
node. The data is owned by the same Vserver.
Inter-volume, different nodes, same Vserver
The source and destination files or LUNs are on different volumes that are located on different
nodes. The data is owned by the same Vserver.
Inter-Vserver, same node
The source and destination file or LUNs are on different volumes that are located on the same
node. The data is owned by different Vservers.
Inter-Vserver, different nodes
The source and destination file or LUNs are on different volumes that are located on different
nodes. The data is owned by different Vservers.
There are some additional special use cases:
With the Data ONTAP ODX implementation, you can use ODX to copy files between SMB
shares and FC or iSCSI attached virtual drives.
You can use Windows Explorer, the Windows CLI or PowerShell, Hyper-V, or other applications
that support ODX to copy or move files seamlessly using ODX copy offload between SMB
shares and connected LUNs, provided the SMB shares and LUNs are on the same cluster.
Hyper-V provides some additional use cases for ODX copy offload:
You can use ODX copy offload pass-through with Hyper-V to copy data within or across
virtual hard disk (VHD) files or to copy data between mapped SMB shares and connected
iSCSI LUNs within the same cluster.
This allows copies from guest operating systems to pass through to the underlying storage.
When creating fixed-sized VHDs, ODX is used for initializing the disk with zeros, using a
well-known zeroed token.
ODX copy offload is used for virtual machine storage migration if the source and destination
storage is on the same cluster.
Note: To take advantage of the use cases for ODX copy offload pass-through with Hyper-V, the
guest operating system must support ODX and the guest operating system's disks must be SCSI
disks backed by storage (either SMB or SAN) that supports ODX. IDE disks on the guest
operating system do not support ODX pass-through.
Enabling or disabling ODX

You can enable or disable ODX on Vservers with FlexVol volumes. The default is to enable support
for ODX copy offload if SMB 3.0 is also enabled.
Before you begin
SMB 3.0 must be enabled.

About this task
If you disable SMB 3.0, Data ONTAP also disables SMB ODX. If you reenable SMB 3.0, you must
manually reenable SMB ODX.
Steps


If you want ODX copy
offload to be...
Enabled

-copy-offload-enabled true
Disabled

-copy-offload-enabled false

Example
The following example enables ODX copy offload on Vserver vs1:

cluster1::*> vserver cifs options modify -vserver vs1 -copy-offload-enabled
true
Improving client response time by providing SMB automatic

node referrals with Auto Location
Auto Location uses SMB automatic node referrals to increase SMB client performance on Vservers
with FlexVol volumes. Automatic node referrals automatically redirect the requesting client to a LIF
on the Vserver node that is hosting the FlexVol volume in which the data resides, which can lead to
improved client response times.
When an SMB client connects to an SMB share hosted on a Vserver, it might connect using a LIF
that is on a node that does not own the requested data. The node to which the client is connected
accesses data owned by another node by using the cluster network. The client can experience faster
response times if the SMB connection uses a LIF located on the node containing the requested data:
Data ONTAP provides this functionality by using Microsoft DFS referrals to inform SMB clients
that a requested file or folder in the namespace is hosted somewhere else.
A node makes a referral when it determines that there is a Vserver LIF on the node containing the
data.
Automatic node referrals are supported for IPv4 and IPv6 LIF IP addresses.
Referrals are made based on the location of the root of the share through which the client is
connected.
The referral occurs during SMB negotiation.
The referral is made before the connection is established. After Data ONTAP refers the SMB
client to the target node, the connection is made, and the client accesses data through the referred
LIF path from that point on. This allows the clients faster access to the data and avoids extra
cluster communication.
Note: If a share spans multiple junction points and some of the junctions are to volumes
contained on other nodes, data within the share is spread across multiple nodes. Because Data
ONTAP provides referrals that are local to the root of the share, Data ONTAP must use the
cluster network to retrieve the data contained within these non-local volumes.
With this type of namespace architecture, automatic node referrals might not provide
significant performance benefits.
If the node hosting the data does not have an available LIF, Data ONTAP establishes the connection
using the LIF chosen by the client. After a file is opened by an SMB client, it continues to access the
file through the same referred connection.

If, for any reason, the CIFS server cannot make a referral, there is no disruption to SMB service. The
SMB connection is established as if automatic node referrals were not enabled.
Related concepts
Requirements and considerations when using automatic node referrals

Before you can use SMB automatic node referrals, you need to be aware of certain requirements,
including which versions of Data ONTAP support the feature. You also need to know about
supported SMB protocol versions and certain other special considerations.
Data ONTAP version and license requirements
Data ONTAP 8.2 and later support SMB automatic node referrals.
All nodes in the cluster must be running a version of Data ONTAP that supports automatic node
referrals.
CIFS must be licensed, and a CIFS server must exist on the Vserver.
For Vservers with FlexVol volumes, Data ONTAP supports automatic node referrals on SMB
1.0, SMB 2.x, and SMB 3.0.
For Vservers with Infinite Volume, Data ONTAP supports automatic node referrals on SMB 1.0.
SMB client requirements

All Microsoft clients supported by Data ONTAP support SMB automatic node referrals.
For the latest information about which Windows clients Data ONTAP supports, see the
NTLM authentication requirements when making a referred SMB connection
NTLM authentication must be allowed on the domain containing the CIFS server and on the domains
containing clients that want to use automatic node referrals.
When making a referral, the CIFS server refers an IP address to the Windows client. Because NTLM
authentication is used when making a connection using an IP address, Kerberos authentication is not
performed for referred connections.
This happens because the Windows client cannot craft the service principal name used by Kerberos
(which are of the form service/NetBIOS name and service/FQDN), which means the client
cannot request a Kerberos ticket to the service.

Considerations when using node referrals with the home directory feature
When shares are configured with the home directory share property enabled, there can be one or
more home directory search paths configured for a home directory configuration. The search paths
can point to volumes contained on each node containing Vserver volumes. Clients receive a referral
and, if an active, local data LIF is available, connect through a referred LIF that is local to the home
user's home directory.
There are considerations when SMB 1.0 clients access dynamic home directories with auto node
referrals enabled. This is because SMB 1.0 clients require the automatic node referral before they
have authenticated, thus, before the CIFS server has the user's name. However, CIFS home directory
access works correctly for SMB 1.0 clients if the following are true:
CIFS home directories are configured to use simple names such as %w (Windows user name),
or %u (mapped Unix user name) and not domain-name style names %d\%w (domain-name
\user-name).
When creating home directory shares, the CIFS home directory shares names are configured with
variables (%w or %u) and not with static names such as HOME.
For SMB 2.x and SMB 3.0 clients, there are no special considerations when accessing home
directories using node referrals.
Considerations when disabling node referrals on CIFS servers with existing referred
connections
If you disable automatic node referrals after the option has been enabled, clients currently connected
to a referred LIF keep the referred connection. Because Data ONTAP uses DFS referrals as the
mechanism for SMB automatic node referrals, clients can even reconnect to the referred LIF after
you disable the option until the client's cached DFS referral for the referred connection times out.
This is true even in the case of a revert to a version of Data ONTAP that does not support automatic
node referrals. Clients continue to use referrals until the DFS referral times out from the client's
cache.
Related concepts
Managing home directories on page 350
Support for automatic node referrals

Before you enable automatic node referrals, you should be aware that certain Data ONTAP
functionality does not support referrals.
The following types of volumes do not support automatic node referrals:
FlexCache target volumes

Read-only members of a load-sharing mirror
Destination volume of a data-protection mirror
When determining locality, if the target component belongs to a FlexCache cache volume, it is
considered local access and bypasses automatic referrals. If a referral is generated, it only reflects
the LIFs on the node hosting the origin (writable) volume.
Node referrals do not move alongside a LIF move.
If a client is using a referred connection over an SMB 2.x or SMB 3.0 connection and a data LIF
moves nondisruptively, the client continues to use the same referred connection, even if the LIF is
no longer local to the data.
Node referrals do not move alongside a volume move.
If a client is using a referred connection over any SMB connection and a volume move occurs,
the client continues to use the same referred connection, even if the volume is no longer located
on the same node as the data LIF.
Node referrals are not supported on Vservers containing Hyper-V over SMB configurations.
You must not enable automatic node referrals if you wish to use the Witness protocol for faster
nondisruptive failover with Hyper-V over SMB solutions.
Enabling or disabling SMB automatic node referrals

You can enable SMB automatic node referrals to increase SMB client access performance. You can
disable automatic node referrals if you do not want Data ONTAP to make referrals to SMB clients.
Before you begin
A CIFS server must be configured and running on the Vserver with FlexVol volumes.
About this task
Automatic node referrals are enabled and disabled on a Vserver basis. The functionality is disabled
by default. Automatic node referrals are not supported on Vservers containing HyperV over SMB
configurations. You must set the option to false if the Vserver hosts HyperV over SMB
configurations.
This option is available at the advanced privilege level.
Steps


If you want SMB node
automatic referrals to be...
Enabled

vserver_name -is-referral-enabled true

If you want SMB node
automatic referrals to be...
Disabled

vserver_name -is-referral-enabled false
The option setting takes effect for new SMB sessions. Clients with existing connection can utilize
node referral only when their existing cache timeout expires.
Using statistics to monitor automatic node referral activity

To determine how many SMB connections are referred, you can monitor automatic node referral
activity by using the statistics command. By monitoring referrals you can determine the extent
to which automatic referrals are locating connections on nodes that host the shares and whether you
should redistribute your data LIFs to provide better local access to shares on the CIFS server.
About this task
The cifs object provides several counters at the advanced privilege level that are helpful when
monitoring SMB automatic node referrals:
node_referral_issued
Number of clients that have been issued a referral to the share root's node after the client
connected using a LIF hosted by a node different from the share root's node.
node_referral_local
Number of clients that connected using a LIF hosted by the same node that hosts the share root.
Local access generally provides optimal performance.
node_referral_not_possible
Number of clients that have not been issued a referral to the node hosting the share root after
connecting using a LIF hosted by a node different from the share root's node. This is because an
active data LIF for the share root's node was not found.
node_referral_remote
Number of clients that connected using a LIF hosted by a node different from the node that hosts
the share root. Remote access might result in degraded performance.
You can monitor automatic node referral statistics on a Vserver by collecting and viewing data for a
specific time period (a sample). You can view data from the sample if you do not stop data
collection. Stopping data collection gives you a fixed sample. Not stopping data collection gives you
the ability to get updated data that you can use to compare against previous queries. The comparison
can help you identify performance trends.
Note: To evaluate and use the information you gather from the statistics command, you
should understand the distribution of clients in your environments.

For more information about using the statistics command, see the Clustered Data ONTAP
System Administration Guide for Cluster Administrators.
Steps

2. View automatic node referral statistics by using the statistics command.

Example
This example views automatic node referral statistics by collecting and viewing data for a
sampled time period:
a. Start the collection:
statistics start -object cifs -instance vs1 -sample-id sample1
Statistics collection is being started for Sample-id: sample1
b. Wait for the desired collection time to elapse.

c. Stop the collection:
statistics stop -sample-id sample1
Statistics collection is being stopped for Sample-id: sample1
d. View the automatic node referral statistics:

statistics show -sample-id sample1 -counter *node*
Object: cifs
Instance: vs1
Start-time: 2/4/2013 19:27:02
End-time: 2/4/2013 19:30:11
Cluster: cluster1
Counter
Value
----------------------------- --------------------------node_name
node1
0
node_referral_local
1
2
2
...
node_name
node_referral_local
...
node2
2
1
0
2

Output displays counters for all nodes participating in Vserver vs1. For clarity, only output
fields related to automatic node referral statistics are provided in the example.
Related tasks
How to monitor client-side SMB automatic node referral information using

a Windows client
To determine what referrals are made from the client's perspective, you can use the Windows
dfsutil.exe utility.
The Remote Server Administration Tools (RSAT) kit available with Windows 7 and later clients
contains the dfsutil.exe utility. Using this utility, you can display information about the contents
of the referral cache as well as view information about each referral that the client is currently using.
You can also use the utility to clear the client's referral cache. For more information, consult the
Microsoft TechNet Library.
Related information
Providing folder security on shares with access-based

enumeration
When access-based enumeration (ABE) is enabled on a CIFS share, users who do not have
permission to access a shared folder or file underneath it (whether through individual or group
permission restrictions) do not see that shared resource displayed in their environment.
Conventional share properties allow you to specify which users (individually or in groups) have
permission to view or modify shared resources. However, they do not allow you to control whether
shared folders or files are visible to users who do not have permission to access them. This could
pose problems if the names of shared folders or files describe sensitive information, such as the
names of customers or products under development.
Access-based enumeration (ABE) extends share properties to include the enumeration of shared
resources. ABE therefore enables you to filter the display of shared resources based on user access
rights. In addition to protecting sensitive information in your workplace, ABE enables you to
simplify the display of large directory structures for the benefit of users who do not need access to
your full range of content.
Enabling or disabling access-based enumeration on SMB shares

You can enable or disable access-based enumeration (ABE) on SMB shares to allow or prevent users
from seeing shared resources that they do not have permission to access.
About this task
By default, ABE is disabled.

Steps

If you want to...
Enable ABE on a
new share
vserver cifs share create -vserver vserver_name -sharename share_name -path path -share-properties access-basedenumeration
path specifies the path to the share. Path separators can be backward or forward
slashes, although Data ONTAP displays them as forward slashes.
You can specify additional optional share settings and additional share properties
when you create an SMB share. For more information, see the man page for the
vserver cifs share create command.
Enable ABE on an vserver cifs share properties add -vserver vserver_name existing share
share-name share_name -share-properties access-basedenumeration
Existing share properties are preserved. The ABE share property is added to the
existing list of share properties.
Disable ABE on
an existing share
vserver cifs share properties remove -vserver vserver_name

-share-name share_name -share-properties access-basedenumeration
Other share properties are preserved. Only the ABE share property is removed from
the list of share properties.
2. Verify that the share configuration is correct by using the vserver cifs share show
command.
Examples
The following example creates an ABE SMB share named sales with a path of /sales on
Vserver vs1. The share is created with access-based-enumeration as a share property:
cluster1::> vserver cifs share create -vserver vs1 -share-name sales -path /
sales -share-properties access-based-

enumeration,oplocks,browsable,changenotify
cluster1::> vserver cifs share show -vserver vs1 -share-name sales
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
sales
VS1
/sales
oplocks
browsable
changenotify
enable
manual
The following example adds the access-based-enumeration share property to an SMB

share named data2:
data2 -share-properties access-based-enumeration
cluster1::> vserver cifs share show -vserver vs1 -share-name data2 -fields
share-name,share-properties
server share-name share-properties
------- ---------- ------------------------------------------------------vs1
data2
oplocks,browsable,changenotify,access-based-enumeration
Related tasks

Enabling or disabling access-based enumeration from a Windows client

You can enable or disable access-based enumeration (ABE) on SMB shares from a Windows client,
which allows you to configure this share setting without needing to connect to the CIFS server.
Step
1. From a Windows client that supports ABE, enter the following command:
abecmd [/enable | /disable] [/server CIFS_server_name] {/all |
share_name}
For more information about the abecmd command, see your Windows client documentation.
Configuring Data ONTAP for the Hyper-V over

SMB solution
With the new capabilities provided in Data ONTAP 8.2 and later, you can now use continuously
available SMB 3.0 file shares to store Hyper-V virtual machine files on volumes residing in Vservers
with FlexVol volumes, while at the same time providing nondisruptive operations (NDOs) for both
planned and unplanned events.
To create a Hyper-V over SMB solution, you must first configure Data ONTAP to provide storage
services for Microsoft Hyper-V servers. Additionally, you must also configure Microsoft clusters (if
using a clustered configuration), Hyper-V servers, continuously available SMB 3.0 connections to
the shares hosted by the Vserver's CIFS server, and, optionally, backup services to protect the virtual
machine files that are stored on Vserver volumes.
Note: The Hyper-V servers must be configured on Windows 2012 Server or later. Both standalone and clustered Hyper-V server configurations are supported.
For information about creating Microsoft clusters and Hyper-V servers, see the Microsoft web
site.
SnapManager for Hyper-V is a host-based application that facilitates rapid, Snapshot copy-based
backup services, designed to integrate with Hyper-V over SMB configurations.
For information about using SnapManager with Hyper-V over SMB configurations, see
SnapManager for Hyper-V Installation and Administration Guide.
What nondisruptive operations for Hyper-V over SMB means

Nondisruptive operations for Hyper-V over SMB refers to the combination of capabilities that enable
Hyper-V and the contained virtual machines to remain online and to provide continuous availability
during many tasks performed by storage administrators. This includes both planned and unplanned
downtime of the storage infrastructure.
Supported nondisruptive operations for Hyper-V over SMB include the following:
Planned takeover and giveback

Unplanned takeover
Upgrade
To perform a nondisruptive upgrade, all nodes in the cluster must be running a version of
clustered Data ONTAP that supports this functionality. Data ONTAP 8.2 is the first release that
supports NDUs for Hyper-V over SMB solutions; therefore, nondisruptive upgrades are
supported if all nodes in the cluster are running Data ONTAP 8.2 or later. This includes upgrades
within the Data ONTAP 8.2 release family.
Planned aggregate relocation (ARL)
LIF migration and failover
Configuring Data ONTAP for the Hyper-V over SMB solution | 409
Planned volume move
Related concepts
Concepts to understand about NDOs for Hyper-V over SMB solutions on page 409
Remote VSS concepts on page 414
What the protocols are that enable nondisruptive operations for Hyper-V
Along with the release of SMB 3.0, Microsoft has released new protocols to provide the capabilities
necessary to offer support for Hyper-V over SMB. Data ONTAP uses these protocols when
providing nondisruptive operations for Hyper-V over SMB.
The following new protocols provide enabling functionality for NDO for Hyper-V over SMB:
SMB 3.0
Witness
Related concepts
How SMB 3.0 functionality supports NDOs for Hyper-V over SMB on page 411
What the Witness protocol does to enhance transparent failover on page 411
Concepts to understand about NDOs for Hyper-V over SMB solutions

There are certain concepts you should understand before you configure your Hyper-V over SMB
solution.
Continuously
available share
An SMB 3.0 share that has the continuously available share property set.
Clients connecting through continuously available shares can survive
disruptive events such as takeover, giveback, and aggregate relocation.
Node
A single controller that is a member of a cluster. To distinguish between the

two nodes in an SFO pair, one node is sometimes called the local node and the
other node is sometimes called the partner node or remote node. The primary
owner of the storage is the local node. The secondary owner, which takes
control of the storage when the primary owner fails, is the partner node. Each
node is the primary owner of its storage and secondary owner for its partner's
storage.
Nondisruptive
aggregate
relocation
The ability to move an aggregate between partner nodes within an SFO pair in
a cluster without interrupting client applications.
Nondisruptive
failover
See Takeover.
Nondisruptive
LIF migration
The ability to perform a LIF migration without interrupting client applications

that are connected to the cluster through that LIF. For SMB connections, this
is only possible for clients that connect using SMB 2.0 or later.

Nondisruptive
operations
The ability to perform major clustered Data ONTAP management and upgrade
operations as well as withstand node failures without interrupting client
applications. This term refers to the collection of nondisruptive takeover,
nondisruptive upgrade, and nondisruptive migration capabilities as a whole.
Nondisruptive
upgrade
The ability to upgrade node hardware or software without application

interruption.
Nondisruptive
volume move
The ability to move a volume freely throughout the cluster without

interrupting any applications that are using the volume. For SMB connections,
all versions of SMB support nondisruptive volume moves.
Persistent handles A property of SMB 3.0 that allows continuously available connections to
transparently reconnect to the CIFS server in the event of a disconnection.
Similar to durable handles, persistent handles are maintained by the CIFS
server for a period of time after communication to the connecting client is lost.
However, persistent handles have more resilience than durable handles. In
addition to giving the client a chance to reclaim the handle within a 60-second
window after reconnecting, the CIFS server denies access to any other clients
requesting access to the file during that 60-second time.
Information about persistent handles are mirrored on persistent storage on the
SFO partner, which allows clients with disconnected persistent handles to
reclaim the durable handles after an event where the SFO partner takes
ownership of the node's storage. In addition to providing nondisruptive
operations in the event of LIF moves (which durable handles support),
persistent handles provide nondisruptive operations for takeover, giveback,
and aggregate relocation.
SFO giveback
Returning aggregates to their home locations when recovering from a takeover

event.
SFO pair
A pair of nodes whose controllers are configured to serve data for each other if
one of the two nodes stops functioning. Depending on the system model, both
controllers can be in a single chassis, or one controller can be in one chassis
and the other controller can be in a separate chassis. Known as an HA pair in a
two-node cluster.
Takeover
The process by which the partner takes control of the storage when the
primary owner of that storage fails. In the context of SFO, failover and
takeover are synonymous.
Related concepts
Remote VSS concepts on page 414
How SMB 3.0 functionality supports NDOs for Hyper-V over SMB
SMB 3.0 provides crucial functionality that enables support for NDOs for Hyper-V over SMB
shares. This includes the new continuously-available share property and a new type of file
handle known as a persistent handle that allow SMB clients to reclaim file open state and
transparently reestablish SMB connections.
Persistent handles can be granted to SMB 3.0 capable clients that connect to a share with the
continuously available share property set. If the SMB session is disconnected, the CIFS server retains
information about persistent handle state. The CIFS server blocks other client requests during the 60second period in which the client is allowed to reconnect, thus allowing the client with the persistent
handle to reclaim the handle after a network disconnection. Clients with persistent handles can
reconnect by using one of the Vserver's data LIFs, either by reconnecting through the same LIF or
through a different LIF.
Aggregate relocation, takeover, and giveback all occur between SFO pairs. To seamlessly manage
the disconnection and reconnection of sessions with files that have persistent handles, the partner
node maintains a copy of all persistent handle lock information. Whether the event is planned or
unplanned, the SFO partner can nondisruptively manage the persistent handle reconnects. With this
new functionality, SMB 3.0 connections to the CIFS server can transparently and nondisruptively fail
over to another data LIF assigned to the Vserver in what traditionally has been disruptive events.
Although the use of persistent handles allows the CIFS server to transparently fail over SMB 3.0
connections, if a failure causes the Hyper-V application to fail over to another node in the Windows
Server 2012 cluster, the client has no way to reclaim the file handles of these disconnected handles.
In this scenario, file handles in the disconnected state can potentially block access of the Hyper-V
application if it is restarted on a different node. Failover Clustering is a part of SMB 3.0 that
addresses this scenario by providing a mechanism to invalidate stale, conflicting handles. Using this
mechanism, a Hyper-V cluster can recover quickly when Hyper-V cluster nodes fail.
Related concepts

Related tasks
Creating Data ONTAP configurations for Hyper-V over SMB solutions on page 430
Configuring existing shares for continuous availability on page 444
What the Witness protocol does to enhance transparent failover

The Witness protocol provides enhanced client failover capabilities for SMB 3.0 continuously
available shares. Witness facilitates faster failover because it bypass the LIF failover recovery period.

It notifies Hyper-V servers when a node is unavailable without needing to wait for the SMB 3.0
connection to time out.
The failover is seamless with applications running on the client not being aware that a failover
occurred. If Witness is not available, failover operations still occur successfully, but failover without
Witness is less efficient.
Witness enhanced failover is possible when the following requirements are met:
It can only be used with SMB 3.0-capable CIFS servers that have SMB 3.0 enabled.
The shares must use SMB 3.0 with the continuous availability share property set.
The SFO partner of the node to which the Hyper-V server is connected must have at least one
operational data LIF assigned to the Vserver hosting the Hyper-V over SMB solution.
Note: The Witness protocol operates between SFO pairs. Because LIFs can migrate to any
node within the cluster, any node might need to be the witness for its SFO partner.
The Witness protocol cannot provide rapid failover of SMB connections on a given node if the
Vserver hosting the Hyper-V over SMB solution does not have an active data LIF on the
partner node. This leads to the requirement that every node in the cluster must have at least one
data LIF for a Vserver hosting a Hyper-V over SMB configuration.
Hyper-V servers must connect to the CIFS server by using the CIFS server name that is stored in
DNS instead of by using individual LIF IP addresses.
Related tasks
Verifying LIF status on page 455
How the Witness protocol works
Data ONTAP implements the Witness protocol by using a node's SFO partner as the witness. In the
event of a failure, the partner quickly detects the failure and notifies the SMB client.
The Witness protocol provides enhanced failover using the following process:
1. When the Hyper-V server establishes a continuously available SMB connection to Node1, the
CIFS server informs the Hyper-V server that Witness is available.
2. The Hyper-V server requests the IP addresses of the Witness server from Node1 and receives a
list of Node2 (the SFO partner) data LIF IP addresses assigned to the Vserver.
3. The Hyper-V server chooses one of the IP addresses, creates a Witness connection to Node2, and
registers to be notified if the continuously available connection on Node1 must move.
4. If a failover event occurs on Node1, Witness facilitates failover events, but is not involved with
giveback.
5. Witness detects the failover event and notifies the Hyper-V server through the Witness
connection that the SMB connection must move to Node2.
6. The Hyper-V server moves the SMB session to Node2 and recovers the connection without
interruption to client access.
1. SMB
3. Witness (monitor)
OS
LIF1
2. Witness (discover)
LIF2
Node 1
Node 2
4. Failover
5. Witness (report)
OS
LIF1
Node 1
6. SMB 3
(reconnect)
LIF2
Node 2
Share-based backups of Hyper-V virtual machines with Remote VSS

You can use Remote VSS to perform share-based backups of Hyper-V virtual machine files that are
stored on a CIFS server.
Microsoft Remote VSS (Volume Shadow Copy Services) is an extension of the existing Microsoft
VSS infrastructure. Previously, VSS could be used for backup services only for data stored on local
disk. This limited the use of VSS to applications that store data either on a local disk or on SANbased storage. With Remote VSS, Microsoft has extended the VSS infrastructure to support shadow
copy of SMB shares. Server applications such as Hyper-V are now storing VHD files on SMB file
shares. With these new extensions, it is possible to take application consistent shadow copies for
virtual machines that store data and configuration files on shares.
Related tasks
Enabling or disabling the VSS shadow copy feature on page 447
Remote VSS concepts

You should be aware of certain concepts that are required to understand how Remote VSS (Volume
Shadow Copy Service) is used by backup services with Hyper-V over SMB configurations.
VSS (Volume
Shadow Copy
Service)
A Microsoft technology that is used to take backup copies or snapshots of

data on a specific volume at a specific point in time. VSS coordinates among
data servers, backup applications, and storage management software to
support the creation and management of consistent backups.
Remote VSS
(Remote Volume
Shadow Copy
Service)
A Microsoft technology that is used to take share-based backup copies of

data that is in a data-consistent state at a specific point in time where the data
is accessed over SMB 3.0 shares. Also known as Volume Shadow Copy
Service.
Shadow copy
A duplicate set of data contained in the share at a well-defined instant in

time. Shadow copies are used to create consistent point-in-time backups of
data while the system or applications can continue updating data on the
original volumes.
Shadow copy set
A collection of one or more shadow copies, with each shadow copy

corresponding to one share. The shadow copies within a shadow copy set
represent all the shares to back up in the same operation. The VSS client on
the VSS-enabled application identifies which shadow copies to include in the
set.
Shadow copy set

auto-recovery
The part of the backup process for remote VSS-enabled backup applications
where the replica directory containing the shadow copies is made point-intime consistent. At the start of the backup, the VSS client on the application
triggers the application to take software checkpoints on the data scheduled
for backup (the virtual machine files in the case of Hyper-V). The VSS client
then allows the applications to continue. After the shadow copy set is
created, Remote VSS makes the shadow copy set writeable and exposes the
writeable copy to the applications. The application prepares the shadow copy
set for backup by performing an automatic recovery using the software
checkpoint taken earlier. Automatic recovery brings the shadow copies into a
consistent state by unrolling the changes made to the files and directories
since the checkpoint was created. Automatic recovery is an optional step for
VSS-enabled backups.
Shadow copy ID
A GUID that uniquely identifies a shadow copy.
Shadow copy set ID A GUID that uniquely identifies a collection of shadow copy IDs to the same
server.
SnapManager for
Hyper-V
The software that automates and simplifies backup and restore operations for
Microsoft Windows Server 2012 Hyper-V. SnapManager for Hyper-V uses
Remote VSS with auto-recovery to back up Hyper-V files over SMB shares.
Related concepts
Concepts to understand about NDOs for Hyper-V over SMB solutions on page 409
Example of a directory structure used by Remote VSS
Remote VSS traverses the directory structure that stores Hyper-V virtual machine files as it creates
shadow copies. It is important to understand what an appropriate directory structure is so that
backups of virtual machine files succeed.
A supported directory structure for successful shadow copy creation conforms to the following
requirements:
Only directories and regular files are present within the directory structure used to store virtual
machine files.
The directory structure does not contain junctions, links, or non-regular files.
All files for a virtual machine reside within a single share.
The directory structure used to store virtual machine files does not exceed the configured shadow
copy directory depth.
The root directory of the share contains only virtual machine files or directories.
In the following example, the volume named vm_vol1 is created with a junction point at /
hyperv/vm1 on Vserver vs1. Subdirectories to contain the virtual machine files are created under
the junction point. The Hyper-V server's virtual machine files are accessed over share1 that has the
path /hyperv/vm1/dir1/vmdir. The shadow copy service creates shadow copies of all the virtual
machine files contained within the directory structure under share1 (up to the configured shadow
copy directory depth).
/ (vs1_rootvol)
/hyperv/vm1 (vm_vol1)
dir1/vmdir
\\vs1\share1
vhd 1
vhd 2
...
xml
...
How SnapManager for Hyper-V manages Remote VSS-based backups for Hyper-V over
SMB
You can use SnapManager for Hyper-V to manage Remote VSS-based backup services. There are
benefits to using SnapManager for Hyper-V managed backup service to create space efficient backup
sets.
Optimizations to SnapManager for Hyper-V managed backups include the following:
SnapDrive integration with Data ONTAP provides performance optimization when discovering
SMB share location.
Data ONTAP provides SnapDrive with the name of the volume where the share resides.
SnapManager for Hyper-V specifies the list of virtual machine files in the SMB shares that the
shadow copy service needs to copy.
By providing a targeted list of virtual machine files, the shadow copy service does not need to
creates shadow copies of all the files in the share.
The Vserver retains the Snapshot copies for SnapManager for Hyper-V to use for restores.
There is no backup phase. The backup is the space-efficient Snapshot copy.
SnapManager for Hyper-V provides backup and restore capabilities for HyperV over SMB using the
following process:
1. Preparing for the shadow copy operation
The SnapManager for Hyper-V application's VSS client sets up the shadow copy set. The VSS
client gathers information about what shares to include in the shadow copy set and provides this
information to Data ONTAP. A set might contain one or more shadow copies, and one shadow
copy corresponds to one share.
2. Creating the shadow copy set (if automatic-recovery is used)
For every share included in the shadow copy set, Data ONTAP creates a shadow copy and makes
the shadow copy writable.
3. Exposing the shadow copy set
After Data ONTAP creates the shadow copies, they are exposed to SnapManager for Hyper-V so
that the application's VSS writers can perform automatic recovery.
4. Automatically recovering the shadow copy set
During the shadow copy set creation, there is a period of time when active changes are occurring
to the files included in the backup set. The application's VSS writers must update the shadow
copies to make sure that they are in a completely consistent state prior to backup.
Note: The way that automatic recovery is done is application specific. Remote VSS is not
involved in this phase.
5. Completing and cleaning up the shadow copy set

The VSS client notifies Data ONTAP after it completes automatic recovery. The shadow copy set
is made read-only and then is ready for backup. When using SnapManager for Hyper-V for
backup, the files in a Snapshot copy become the backup; therefore, for the backup phase, a
Snapshot copy is created for every volume containing shares in the backup set. After the backup
is complete, the shadow copy set is removed from the CIFS server.
How ODX copy offload is used with Hyper-V over SMB

Offloaded Data Transfer (ODX), also known as copy offload, enables direct data transfers within or
between compatible storage devices without transferring the data through the host computer. Data
ONTAP ODX copy offload provides you with performance benefits when performing copy
operations on your Hyper-V over SMB installation.
In non-ODX file transfers, the data is read from the source CIFS server and is transferred across the
network to the client computer. The client computer transfers the data back over the network to the
destination CIFS server. In summary, the client computer reads the data from the source and writes it
to the destination. With ODX file transfers, data is copied directly from the source to the destination.
Because ODX offloaded copies are performed directly between the source and destination storage,
there are significant performance benefits. The performance benefits realized include faster copy
time between source and destination, reduced resource utilization (CPU, memory) on the client, and
reduced network I/O bandwidth utilization.
This functionality is available on Windows Server 2012 Hyper-V servers. Data ONTAP ODX copy
offload is supported on both SAN LUNs and SMB 3.0 continuously available connections.
The following use cases support using ODX copies and moves:
Intra-volume
The source and destination files or LUNs are within the same volume. The copy is performed by
using FlexClone file technology, which provides additional remote copy performance benefits.
Inter-volume, same node, same Vserver
The source and destination files or LUNs are on different volumes that are located on the same
node. The data is owned by the same Vserver.
Inter-volume, different nodes, same Vserver
The source and destination files or LUNs are on different volumes that are located on different
nodes. The data is owned by the same Vserver.
Inter-Vserver, same node
The source and destination file or LUNs are on different volumes that are located on the same
node. The data is owned by different Vservers.
Inter-Vserver, different nodes
The source and destination file or LUNs are on different volumes that are located on different
nodes. The data is owned by different Vservers.
Specific use cases for ODX copy offload with Hyper-V solutions include the following:
You can use ODX copy offload pass-through with Hyper-V to copy data within or across virtual
hard disk (VHD) files or to copy data between mapped SMB shares and connected iSCSI LUNs
within the same cluster.
This allows copies from guest operating systems to pass through to the underlying storage.
When creating fixed-sized VHDs, ODX is used for initializing the disk with zeros, using a wellknown zeroed token.
ODX copy offload is used for virtual machine storage migration if the source and destination
storage is on the same cluster.
Note: To take advantage of the use cases for ODX copy offload pass-through with Hyper-V, the
guest operating system must support ODX and the guest operating system's disks must be SCSI
disks backed by storage (either SMB or SAN) that supports ODX. IDE disks on the guest
operating system do not support ODX pass-through.
Related concepts

Related tasks
Configuration requirements, considerations, and

recommendations
There are certain requirements, considerations, and recommendations that you must keep in mind
while planning and configuring your Hyper-V over SMB configuration.
Related concepts
Planning the configuration on page 424

Considerations for reverting Hyper-V over SMB configurations on page 443
Related tasks
Configuration requirements
You need to be aware of certain requirements when configuring Hyper-V over SMB solutions.
General requirements
Hyper-V over SMB is the only supported application for nondisruptive operations (NDOs) in
clustered Data ONTAP 8.2. The solution is supported on Windows Server 2012 or later.
For the latest list of Windows servers supporting Hyper-V over SMB, consult the Microsoft TechNet
Library.
Licensing requirements
The following licenses are required:
CIFS
FlexClone
This license is required if Remote VSS is used for backups. The shadow copy service uses
FlexClone to create point-in-time copies of files that are then used when creating a backup. A
FlexClone license is optional if you use a backup method that does not use Remote VSS.
Network protocol requirements
IPv4 and IPv6 networks support the Hyper-V over SMB solution.
SMB 3.0 or later is required.
SMB 3.0 provides the functionality needed to create the continuously available SMB connections
necessary to offer nondisruptive operations.
DNS servers must contain entries that map the CIFS server name to the IP addresses assigned to
the Vserver's data LIFs.
Hyper-V servers must use the CIFS server name stored in DNS when creating SMB connections
to the CIFS server. Hyper-V servers typically make multiple connections over multiple data LIFS
when accessing virtual machine files. For proper functionality, the Hyper-V servers must make
these multiple SMB connections by using a single host name instead of making multiple
connections to multiple unique IP addresses.
Witness also requires the use of the CIFS server's DNS name instead of individual LIF IP
addresses.

Vserver requirements
Only Vservers with FlexVol volumes support Hyper-V over SMB solutions.
The Vserver's volumes used in the Hyper-V solution must use NTFS security style.
CIFS server requirements
Both Kerberos and NTLM authentication must be allowed in the domain to which the CIFS
server belongs.
Data ONTAP does not advertise the Kerberos service for Remote VSS; therefore, the domain
should be set to permit NTLM.
SMB 3.0 must be enabled.
This is enabled by default.
Shadow copy functionality must be enabled.
This functionality is enabled by default.
The Windows domain account that the shadow copy service uses when creating shadow copies
must be a member of the CIFS server's local BUILTIN\Administrators or BUILTIN\Backup
Operators group.
The default UNIX user CIFS option must be configured with a valid UNIX user account.
Starting with Data ONTAP 8.2, when you create a CIFS server, Data ONTAP creates a default
user named pcuser and assigns that user as the default UNIX user. If you upgraded your cluster
from an earlier Data ONTAP release, the default UNIX user might not be configured.
Hyper-V servers use the machine account when creating an SMB connection. Because all SMB
access requires that the Windows user successfully map to a UNIX user account or to the default
UNIX user account, Data ONTAP must be able to map the Hyper-V server machine account to
the default UNIX user account.
ODX copy offload must be enabled if you want enhance copy performance.
This option must be enabled if you want to migrate virtual machine files directly from source to
the destination storage location without sending data through the Hyper-V servers. Using ODX
copy offload to migrate virtual machines provides a significant performance benefit. This CIFS
option is enabled by default.
Note: To use ODX copy offload to migrate guests with and between disks, the Hyper-V
servers must be configured to use SCSI disks. The default is to configure IDE disks, but ODX
copy offload does not work when guests are migrated if disks are created using IDE disks.
Automatic node referrals must be disabled.

Automatic node referrals are disabled by default. If you want to use automatic node referrals for
data other than Hyper-V files, you must create a separate Vserver for that data.
Data LIF requirements
The Vserver hosting the Hyper-V over SMB solution must have at least one operational data LIF
on every node in the cluster.
Vserver data LIFs can fail over to other data ports within the cluster, including nodes that are not
currently hosting data accessed by the Hyper-V servers. Additionally, because the Witness node
is always the SFO partner of a node to which the Hyper-V server is connected, every node in the
cluster is a potential Witness node.
Data LIFs must not be configured to automatically revert.
After a takeover or giveback event, you should manually revert the data LIFs to their home ports.
All data LIF IP addresses must have an entry in DNS and all entries must resolve to the CIFS
server name.
The Hyper-V servers must connect to SMB shares by using the CIFS server name. You must not
configure the Hyper-V servers to make connections by using the LIF IP addresses.
If the CIFS server name is different from the Vserver name, the DNS entries must resolve to the
CIFS server name.
Volume and share requirements
Volumes used to store virtual machine files must be created as NTFS security-style volumes.
To provide NDOs for Hyper-V servers using continuously available SMB connections, the
volume containing the share must be an NTFS volume. Moreover, it must always have been an
NTFS volume. You cannot change a mixed security-style volume or UNIX security-style volume
to an NTFS security-style volume and directly use it in an NDO for Hyper-V over SMB
configurations. If you change a mixed security-style volume to an NTFS security style volume
and intend to use it in the Hyper-V over SMB configuration, you must manually place an ACL at
the top of the volume and propagate that ACL to all contained files and folders. Otherwise,
Hyper-V virtual machine migrations where virtual files are moved to another volume can fail if
either the source or the destination volumes were initially created as mixed or UNIX securitystyle volumes and later changed to NTFS security style.
For shadow copy operations to succeed, you must have enough available space on the volume.
The available space must be at least as large as the combined space used by all files, directories,
and subdirectories contained within the shares included in the shadow copy backup set. This
requirement only applies to shadow copies with auto-recovery.
If you want to use Remote VSS-enabled backup services, you cannot put Hyper-V files into
shares that contain junctions.
In the auto-recovery case, the shadow copy creation will fail if a junction is encountered while
traversing the share. In the non auto-recovery case, the shadow copy creation does not fail, but
the junction does not point to anything.
If you want to use Remote VSS-enabled backup services with auto-recovery, you cannot put
Hyper-V files into shares that contain the following:
Symlinks, hardlinks, or widelinks

Non-regular files
The shadow copy creation will fail if there are any links or non-regular files in the share to
shadow copy. This requirement only applies to shadow copies with auto-recovery.
Shares used by the Hyper-V servers must be configured with the continuously available property
set.
Hyper-V servers that connect to continuously available shares receive persistent handles that
allow them to reconnect nondisruptively to SMB shares and reclaim file locks after disruptive
events such as takeover, giveback, and aggregate relocation.
The following share properties must not be set on continuously available shares used by the
Hyper-V servers:
Home directory
Change notify
Attribute caching
BranchCache
Access-based enumerations
ODX copy offload requirements
SMB 3.0 must be enabled to use ODX copy offload.

Source volumes must be a minimum of 1.25 GB.
Deduplication must be enabled on volumes used with copy offload.
Compression must not be enabled on volumes used with copy offload.
Related information
Considerations and limits

You need to be aware of certain considerations and limits when configuring Hyper-V over SMB.
Considerations
Quotas are not supported on continuously available shares.

Even if a quota is specified, the continuously available share ignores quota policies.
The following functionality is not supported for Hyper-V over SMB configurations:
Auditing
FPolicy
FlexCache
Remote VSS limits
Maximum of 64 shares can be configured for a Hyper-V server.

The shadow copy operation fails if there are more than 64 shares in a shadow copy set. This is a
Microsoft requirement.
Only one active shadow copy set per CIFS server is allowed.
A shadow copy operation will fail if there is an ongoing shadow copy operation on the same
CIFS server. This is a Microsoft requirement.
Maximum directory depth of five is allowed for shadow copy creation.
This is the directory depth over which the shadow copy service creates a shadow copy backup set.
Shadow copy creation fails if directories containing virtual machine file are nested deeper than
five levels. This is intended to limit the directory traversal when cloning the share. The maximum
directory depth can be changed by using a CIFS option.
This limit only applies to shadow copies with auto-recovery.
Amount of available space on the volume must be adequate.
The available space must be at least as large as the combined space used by all files, directories,
and subdirectories contained within the shares included in the shadow copy backup set. This limit
only applies to shadow copies with auto-recovery.
No junctions are allowed within the directory structure on which Remote VSS creates a shadow
copy.
In the auto-recovery case, the shadow copy creation will fail if a junction is encountered while
traversing the share. In the non auto-recovery case, the shadow copy creation does not fail, but
the junction does not point to anything.
No links or non-regular files are allowed within the directory structure on which Remote VSS
creates a shadow copy.
The shadow copy creation fails if there are any links or non-regular files in the share to the
shadow copy. The clone process does not support them. This limit only applies to shadow copies
with auto-recovery.
No NFSv4 ACLs are allowed on directories.
Even though shadow copy creation retains NFSv4 ACLs on files, the NFSv4 ACLs on directories
are lost.
Maximum of 60 seconds allowed to create a shadow copy set.
Microsoft specifications allow a maximum of 60 seconds to create the shadow copy set. If the
VSS client cannot create the shadow copy set within this time, the shadow copy operation fails;
therefore, this limits the number of files in a shadow copy set. The actual number of files or
virtual machines that can be included in a backup set varies, is dependent on many factors, and
must be determined for each customer environment.
Recommendations when configuring Hyper-V over SMB

To ensure that your Hyper-V over SMB configuration is robust and operational, you need to be
familiar with recommended best practices for configuring Hyper-V over SMB solutions.
Hyper-V recommendations
Separate Hyper-V files from general user data.

If possible, devote an entire Vserver and its storage for Hyper-V over SMB solutions.
For best performance, do not enable SMB signing on Vservers with Hyper-V over SMB
solutions.
Do not create continuously available shares on any shares other than those used in the Hyper-V
over SMB configuration.
Configuring other shares to be continuously available needlessly generates overhead.
Use iSCSI drives when creating virtual machines or when adding disks to an existing virtual
machine.
Do not perform a volume move at the same time as ARL because ARL has phases that pause
some operations.
Disable change notify on shares used for continuous availability.
There is no reason to have them enabled on Hyper-V shares. Disabling them can enhance
performance.
Remote VSS recommendations
If Hyper-V files and general data reside on the same Vserver, do not store user data within shares
containing Hyper-V files.
Create your data structure so that the root directory of the share contains only virtual machine
Plan your share configuration so that all virtual machine files that you want to back up on the
same schedule are contained within shares belonging to a single shadow copy set.
The files for a single virtual machine should be contained within the same share.
Do not place virtual machine files belonging to different shadow copy sets within the same
shares.
You should segregate files belonging to different backups into their own shares.
Keep the share for the life of the virtual machine.
Plan your backup schedule so that the backup of each shadow copy set finishes before the next
backup starts.
There can be only one active shadow copy set at a time for each CIFS server. A shadow copy
operation will fail if there is an ongoing shadow copy operation on the same CIFS server. This is
a Microsoft requirement.
Plan your nondisruptive upgrades (NDUs) so that there are no ongoing shadow copy operations
during the upgrade.
Ongoing shadow copies might fail during an NDU. If shadow copies fail during an NDU, Data
ONTAP cleans up the failed shadow copies; however, you have to reschedule any failed backups
after you have completed the upgrade.
Planning the configuration

Before you configure Hyper-V over SMB on Vservers with FlexVol volumes, you must understand
the choices you need to make when configuring this solution. You should plan your volume, LIF, and
share configuration prior to performing the configuration. This can help you create a configuration
that follows the best practices and recommendations.
Related concepts
Configuration requirements, considerations, and recommendations on page 418

Related tasks
Completing the data LIF and network configuration worksheet

Use this worksheet to record the values that you need during the data LIF and network configuration
process.
Information for creating LIFs on the Vserver
Data LIF names

The name to give to the logical network interfaces that clients use
when accessing data from the CIFS server. The Vserver must have at
least one data LIF on every node in the cluster.
You can provide descriptive names for the interfaces, such as naming
the data LIFs according to the node assigned as their home node. For
example, you can name a LIF whose home node is node1 lif1, a
LIF whose home node is node2 lif2, and so on.
Protocols allowed on the data LIFs
Protocols that can use the data LIFs (CIFS, NFS, FlexCache, iSCSI,
and FC). This is an optional setting. By default, CIFS, NFS, and
FlexCache are allowed.
Note: You cannot modify the list of protocols that can use the LIF
after the LIF is created.
Data LIF home node

The node to which the logical interface returns when the LIF is
reverted to its home port. Record a home node for each data LIF.
Data LIF home port
The port to which the logical interface returns when the LIF is
reverted to its home port. Record a home port for each data LIF.
Data LIF IP addresses
Record an IP address for each data LIF.
All data LIFs used to create continuously available SMB connections
to Hyper-V servers must be on the same subnet.
Data LIF network mask
Record the netmask for the data LIFs.
Values

Values
Optional custom routing groups for the data

Data ONTAP automatically creates a routing group that is
appropriate for the netmask provided when creating the data LIF. If
an appropriate routing group exists, Data ONTAP assigns the
existing routing group to the LIF. You can optionally create your
own custom routing group.
Data LIF default gateway IP address
Record the IP address of the default gateway.
Optional static routes for the data LIF
You can configure optional static routes for the routing group
assigned to the data LIFs.
Information for DNS entries on the DNS server for the data LIFS
After you configure your data LIFs, the DNS administrator must create DNS A and PTR records
for the IP addresses assigned to the data LIFs. To load balance client connections to the assigned data
IP addresses, you must create multiple A records that all point to the same host name. DNS will
load balance connections that are made using the host name to the assigned IP addresses in a roundrobin fashion.
Note: If you assigned the CIFS server a name that is different from the Vserver name, you must
create DNS entries that point to the CIFS server name instead of the Vserver name. Clients must
use the CIFS server name when connecting to SMB shares, not the Vserver name.
For example, if you create a CIFS server named CIFS1 in the EXAMPLE.LOCAL domain that
is hosted on a Vserver named vs1 and assign the IP addresses 10.1.1.1, 10.1.1.2, 10.1.1.3, and
10.1.1.4 to the four data LIFs, your DNS A record entries are as follows:
10.1.1.1
10.1.1.2
10.1.1.3
10.1.1.4
A
A
A
A
CIFS1.EXAMPLE.COM
CIFS1.EXAMPLE.COM
CIFS1.EXAMPLE.COM
CIFS1.EXAMPLE.COM
CIFS1
CIFS1
CIFS1
CIFS1
There are alternative methods for creating the data LIF DNS records and managing DNS load
balancing for the CIFS server. Data ONTAP supports onboard Vserver DNS load balancing using
DNS delegation. To learn more about Vserver DNS load balancing, see the section about balancing
network loads in the Clustered Data ONTAP Network Management Guide. To learn more about
configuring DNS load balancing using delegation and conditional forwarding, see the knowledge
base article How to set up DNS load balancing in Cluster-Mode on the support site:
support.netapp.com.
Values
DNS A and PTR records for the CIFS server

You need to create A and PTR records for IP
addresses assigned to the data LIFs. The host
name for these records is the CIFS server name.
Completing the volume configuration worksheet

Use this worksheet to record the values that you need during the volume creation process.
For each volume, you must specify the following information:
Vserver name
The Vserver name is the same for all volumes.
Volume name
Aggregate name
You can create volumes on aggregates located on any node in the cluster.
Size
Junction path
NTFS security style
If the root volume has NTFS security style, all volumes contained on the Vserver inherit the
NTFS security style. If the root volume does not have NTFS security style, you must specify the
security style when you create the volume.
You should keep the following in mind when creating volumes for Hyper-V over SMB
configurations:
Volumes should be configured with the default volume space guarantee.

You can optionally configure the autosize space management setting.
You should set the option that determines the Snapshot copy space reserve to 0.
The Snapshot policy applied to the volume must be disabled.
If the Vserver Snapshot policy is disabled, then you do not need to specify a Snapshot policy for
the volumes. The volumes inherit the Vserver's Snapshot policy. If the Vserver's Snapshot policy
is not disabled and is configured to create Snapshot copies, you must specify a Snapshot policy at
the volume level, and that policy must be disabled. Shadow copy service-enabled backups
manage Snapshot copy creation and deletion.
You cannot configure volumes used for Hyper-V over SMB configurations as FlexCache
volumes.
You cannot configure load-sharing mirrors for Hyper-V over SMB volumes.
Junction paths on which you plan to create shares that the Hyper-V servers use should be chosen so
that there are no junctioned volumes below the share entry point. Shadow copy operations cannot be
performed on files that are within subdirectories that are junction points to volumes.
For example, if you want to store virtual machine files on four volumes named vm1, vm2,
vm3, and vm4, you can create the namespace shown in the example. You can then create shares

for the Hyper-V servers at the following paths: /hyperv1/vm1, /hyperv1/vm2, /hyperv2/vm3,
and /hyperv2/vm4.
Vserver
------vs1
vs1
vs1
vs1
vs1
vs1
Volume
-----------hyperv1
vm1
vm2
hyperv2
vm3
vm4
Junction
Active
-------true
true
true
true
true
true
Junction Path
------------------/hyperv1
/hyperv1/vm1
/hyperv1/vm2
/hyperv2
/hyperv2/vm3
/hyperv2/vm4
Junction
Path Source
----------RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
Values
Volume 1: Volume name, aggregate, size,

junction path
junction path
junction path
junction path
junction path
junction path
Additional volumes: Volume name, aggregate,
size, junction path
Completing the SMB share configuration worksheet

Use this worksheet to record the values that you need during the share configuration process.
Information about SMB shares properties and configuration settings
For each share, you must specify the following information:
Vserver name
The Vserver name is the same for all shares
Share name
Path
Share properties
You must configure the following two share properties:
oplocks
The following share properties must not be set for Hyper-V SMB shares:
homedirectory
changenotify
attributecache
branchcache
Symlinks must be disabled (the value for the -symlink-properties parameter must be null
[""]).
Information about share paths

If you are using Remote VSS to back up Hyper-V files, the choice of share paths to use when making
SMB connections from the Hyper-V servers to the storage locations where the virtual machine files
are stored is important. Although shares can be created at any point in the namespace, paths for
shares that the Hyper-V servers use should not contain junctioned volumes. Shadow copy operations
cannot be performed on share paths that contain junction points.
For example, given the namespace shown, if you want to store virtual machine files on volumes
vm1, vm2, vm3, and vm4, you should create shares for the Hyper-V servers at the following
paths: /hyperv1/vm1, /hyperv1/vm2, /hyperv2/vm3, and /hyperv2/vm4.
Vserver
------vs1
vs1
vs1
vs1
vs1
vs1
Volume
-----------hyperv1
vm1
vm2
hyperv2
vm3
vm4
Junction
Active
-------true
true
true
true
true
true
Junction Path
------------------/hyperv1
/hyperv1/vm1
/hyperv1/vm2
/hyperv2
/hyperv2/vm3
/hyperv2/vm4
Junction
Path Source
----------RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
RW_volume
Note: Although you can create shares on the /hyperv1 and /hyperv2 paths for administrative
management, you must not configure the Hyper-V servers to use those shares to store Hyper-V
files.
Planning worksheet
Volume 1: SMB share name and path

Values

Values

Additional volumes: SMB share names and
paths
Creating Data ONTAP configurations for Hyper-V over SMB

solutions
There are several Data ONTAP configuration steps you must perform to prepare for a Hyper-V
installation that provides NDOs (nondisruptive operations) over SMB.
Before you begin
You must have already created a Vserver, configured DNS, set up desired names services, and
created the CIFS server.
Steps
1. Verifying that both Kerberos and NTLMv2 authentication are permitted on page 431
Nondisruptive operations for Hyper-V over SMB require that the Vserver's CIFS server and the
Hyper-V server permit both Kerberos and NTLMv2 authentication. You must verify settings on
both the CIFS server and the Hyper-V servers that control what authentication methods are
permitted.
2. Verifying that the Hyper-V server's domain computer account maps to the default UNIX user on
page 433
Hyper-V servers use the domain computer account to create SMB connections to continuously
available shares. To successfully create the connection, the computer account must successfully
map to a UNIX user. The most convenient way to accomplish this is to map the computer account
to the default UNIX user.
3. Verifying that the Vserver root volume uses NTFS security style on page 435
To ensure that nondisruptive operations for Hyper-V over SMB are successful, volumes must be
created with NTFS security style. To ensure that all volumes are created with NTFS security style
by default, you can set the security style of the Vserver's root volume to NTFS.
4. Verifying that required CIFS options are configured on page 436
You must verify that the required CIFS options are enabled and configured according to
requirements for nondisruptive operations for Hyper-V over SMB.
5. Verifying that automatic node referrals are disabled on page 437
Automatic node referrals are not supported with Hyper-V over SMB configurations. You must
verify that automatic node referrals are disabled on CIFS servers that provide nondisruptive
operations for Hyper-V over SMB.
6. Creating data LIFs for Hyper-V over SMB configurations (cluster administrators only) on page
438
Before Hyper-V servers can connect to continuously available shares, you must create data LIFs
for the Vserver.
7. Creating NTFS data volumes on page 440
You must create data volumes in the Vserver namespace before you can configure continuously
available shares. Use the volume configuration worksheet to create your data volumes.
8. Creating continuously available SMB shares on page 441
After you create your data volumes, you can create the continuously available shares that the
Hyper-V servers use to access virtual machine and configuration files. You should use the share
configuration worksheet as you create the SMB shares.
9. Configuring the VSS shadow copy directory depth on page 443
Optionally, you can configure the maximum depth of directories on which to create shadow
copies on Vservers with FlexVol volumes. This parameter is useful if you want to manually
control the maximum level of subdirectories on which Data ONTAP should create shadow copies.
Related concepts
Planning the configuration on page 424

Configuration requirements, considerations, and recommendations on page 418
Verifying that both Kerberos and NTLMv2 authentication are permitted

Nondisruptive operations for Hyper-V over SMB require that the Vserver's CIFS server and the
Hyper-V server permit both Kerberos and NTLMv2 authentication. You must verify settings on both
the CIFS server and the Hyper-V servers that control what authentication methods are permitted.
About this task
Kerberos authentication is required when making a continuously available share connection. Part of
the Remote VSS process uses NTLMv2 authentication. Therefore, connections using both
authentication methods must be supported for Hyper-V over SMB configurations.
The following settings must be configured to allow both Kerberos and NTLMv2 authentication:
Export policies for SMB must be disabled on the Vserver.

Both Kerberos and NTLMv2 authentication are always enabled on a Vserver, but export policies
can be used to restrict access based on authentication method.
Prior to Data ONTAP 8.2, configuring export policies for CIFS access was a requirement. Export
policies control what types of authentication are allowed when accessing data using NAS
protocols. Starting with Data ONTAP 8.2 and later releases, export policies for CIFS are optional
and are disabled by default. If export policies are disabled, both Kerberos and NTLMv2
authentication are allowed on a CIFS server by default.
The domain to which the CIFS server and Hyper-V servers belong must permit both Kerberos
and NTLMv2 authentication.
Kerberos authentication is enabled by default on Active Directory domains. However, NTLMv2
authentication can be disallowed, either using Security Policy settings or Group Policies.
Steps
1. Perform the following to verify that export policies are disabled on the Vserver:
b) Verify that the -is-exportpolicy-enabled CIFS option is set to false:

vserver cifs options show -vserver vserver_name -fields vserver,isexportpolicy-enabled
c) Return to the admin privilege level:

2. If export policies for CIFS are not disabled, disable them:

vserver cifs options modify -vserver vserver_name -is-exportpolicyenabled false
3. Verify that both NTLMv2 and Kerberos authentication are allowed in the domain.
For information about determining what authentication methods are allowed in the domain, see
the Microsoft TechNet Library.
4. If the domain does not permit NTMLv2 authentication, enable NTLMv2 authentication by using
one of the methods described in Microsoft documentation.
Example
The following commands verify that export policies for CIFS are disabled on Vserver vs1:
cluster1::*> vserver cifs options show -vserver vs1 -fields vserver,isexportpolicy-enabled
vserver is-exportpolicy-enabled
-------- ----------------------vs1
false
Verifying that the Hyper-V server's domain computer account maps to the
default UNIX user
Hyper-V servers use the domain computer account to create SMB connections to continuously
available shares. To successfully create the connection, the computer account must successfully map
to a UNIX user. The most convenient way to accomplish this is to map the computer account to the
default UNIX user.
Steps
1. Determine whether there is a default UNIX user:

2. If the default user option is not set, determine whether there is a UNIX user that can be
designated as the default UNIX user:
vserver services unix-user show -vserver vserver_name
Starting with Data ONTAP 8.2 and later releases, Data ONTAP automatically creates the default
user named pcuser (with a UID of 65534) and the group named pcuser (with a GID of
65534), and adds the default user to the pcuser group. If you are configuring a Hyper-V over
SMB solution on a Vserver that existed prior to upgrading the cluster to Data ONTAP 8.2, the
default user and group might not exist. If they do not, you must create them before configuring
the CIFS server's default UNIX user.
3. If the default user option is not set and there is not a UNIX user that can be designated as the
default UNIX user, create the default UNIX user and the default group, and add the default user
to the group.
Generally, the default user is given the user name pcuser and must be assigned the UID of
65534. The default group is generally given the group name pcuser. The GID assigned to the
group must be 65534.
a) Create the default group:

vserver services unix-group create -vserver vserver_name -name pcuser
-id 65534
b) Create the default user and add the default user to the default group:
vserver services unix-user create -vserver vserver_name -user pcuser id 65534 -primary-gid 65534
c) Verify that the default user and default group are configured correctly:
vserver services unix-user show -vserver vserver_name
vserver services unix-group show -vserver vserver_name -members
4. If the CIFS server's default user is not configured, perform the following:

a) Configure the default user:
vserver cifs options modify -vserver vserver_name -default-unix-user
pcuser
b) Verify that the default UNIX user is configured correctly:

5. To verify that the Hyper-V computer account correctly maps to the default user, map a drive to a
share residing on the Vserver and confirm the Windows user to UNIX user mapping by using the
vserver cifs sessions show command.
For more information about using this command, see the man pages.
Example
The following commands determine that the CIFS server's default user is not set, but
determines that the pcuser user and pcuser group exist. The pcuser user is assigned as
the CIFS server's default user on Vserver vs1:
cluster1::> vserver cifs options show
Vserver: vs1
Default Unix Group:
Default Unix User :
Read Grants Exec :
WINS Servers
:
disabled
-
cluster1::> vserver services unix-user show

User
User
Group Full
Vserver
Name
ID
ID
Name
--------- --------------- ------ ------ ---------------vs1
nobody
65535 65535 vs1
pcuser
65534 65534 vs1
root
0
1
cluster1::> vserver services unix-group show -members
Vserver
Name
ID
vs1
daemon
1
Users: vs1
nobody
65535
Users: vs1
pcuser
65534
Users: vs1
root
0
Users: cluster1::> vserver cifs options modify -default-unix-user pcuser
cluster1::> vserver cifs options show
Vserver: vs1
Default Unix Group:
Default Unix User :
Read Grants Exec :
WINS Servers
:
pcuser
disabled
-
Verifying that the Vserver root volume uses NTFS security style
To ensure that nondisruptive operations for Hyper-V over SMB are successful, volumes must be
created with NTFS security style. To ensure that all volumes are created with NTFS security style by
default, you can set the security style of the Vserver's root volume to NTFS.
About this task
The security style set on the root volume is the default security style applied to all volumes created
on that Vserver.
You can specify the root volume security style at the time you create the Vserver. If the Vserver is
not created with the root volume set to NTFS security style, you can change the security style later by
using the volume modify command.
Steps
1. Determine the current security style of the Vserver's root volume:

volume show -vserver vserver_name -fields vserver,volume,security-style
2. If the root volume is not an NTFS security-style volume, change the security style to NTFS:
volume modify -vserver vserver_name -volume root_volume_name -securitystyle ntfs
3. Verify that the Vserver's root volume is set to NTFS security style:
volume show -vserver vserver_name -fields vserver,volume,security-style
Example
The following commands verify that the root volume security style is NTFS on Vserver vs1:
cluster1::> volume show -vserver vs1 -fields vserver,volume,security-style
vserver volume
security-style
-------- ---------- -------------vs1
vs1_root
unix
cluster1::> volume modify -vserver vs1 -volume vs1_root -security-style ntfs
cluster1::> volume show -vserver vs1 -fields vserver,volume,security-style
vserver volume
security-style
-------- ---------- -------------vs1
vs1_root
ntfs
Verifying that required CIFS options are configured

You must verify that the required CIFS options are enabled and configured according to
requirements for nondisruptive operations for Hyper-V over SMB.
About this task
SMB 2.x and SMB 3.0 must be enabled.

VSS Shadow Copy services must be enabled if the Hyper-V over SMB solution uses Remote
VSS-enabled backup services.
ODX copy offload must be enabled to use performance enhancing copy offload.
Steps
1. Perform the following to verify that the required CIFS options are enabled on the Vserver:
b) Enter the following command:

The following options should be set to true:
-smb2-enabled
-smb3-enabled
-shadowcopy-enabled
-copy-offload-enabled
2. If any of the options are not set to true, perform the following:
a) Set them to true by using the vserver cifs options modify command.
b) Verify that the options are set to true by using the vserver cifs options show
command.
Example
The following commands verify that the required options for the Hyper-V over SMB
configuration are enabled on Vserver vs1. In the example, ODX copy offload must be enabled
to meet the option requirements:
cluster1::*> vserver cifs options show
Vserver: vs1
Default Unix Group:
Default Unix User:
Read Grants Exec:
Shadowcopy Enabled:
SMB2 Enabled:
SMB3 Enabled:
WINS Servers:
false
pcuser
false
false
true
true
255
disabled
5
true
true
true
true
cluster-1::*> vserver cifs options modify -vserver vs1 -copy-offloadenabled true

cluster-1::*> vserver cifs options show -vserver vs1 -fields copy-offloadenabled
vserver copy-offload-enabled
-------- -------------------vs1
true
Verifying that automatic node referrals are disabled

Automatic node referrals are not supported with Hyper-V over SMB configurations. You must verify
that automatic node referrals are disabled on CIFS servers that provide nondisruptive operations for
Hyper-V over SMB.
About this task
Automatic node referrals are disabled by default. If you have enabled them on the CIFS server that
will provide Hyper-V over SMB services, you must disable them.
Steps
1. Perform the following to verify that automatic node referrals are disabled on the CIFS server:
b) Verify that the -is-referral-enabled CIFS options is set to false:

vserver cifs options show -vserver vserver_name -fields is-referralenabled
2. If automatic node referrals are not disabled, perform the following:

a) Disable automatic node referrals:

vserver cifs options modify -vserver vserver_name -is-referral-enabled
false
b) Verify that the new setting is correct:

vserver cifs options show -vserver vserver_name -fields is-referralenabled

Example
The following commands verify that automatic node referrals are disabled on Vserver vs1:
cluster1::*> vserver cifs options show -vserver vs1 -fields is-referralenabled
vserver is-referral-enabled
-------- ------------------vs1
false
Creating data LIFs for Hyper-V over SMB configurations (cluster

administrators only)
Before Hyper-V servers can connect to continuously available shares, you must create data LIFs for
the Vserver.
Before you begin
You must have the list of IP addresses to assign to the data LIFs.
About this task
You can associate data LIFs with ports that are assigned the data role.
To use host names to connect to the CIFS server data ports, you must create DNS A and PTR
record entries that assign the IP addresses to the FQDN of the CIFS server.
You must not configure the data LIFs that carry traffic for the Hyper-V servers to automatically
revert to their home nodes.

Steps
1. Determine what data ports are available:
network port show -role data
2. Using the information in the planning worksheet, create the Vserver data LIFs:
network interface create -vserver vserver_name -lif lif_name -role data
-home-node node_name -home-port port -address -netmask-length integer
For more information about configuring LIFs, see the Clustered Data ONTAP Network
Management Guide.
After the command executes, the following message is displayed: Info: Your interface
was created successfully; the routing group <routing_group_name> was
created. An associated routing group is automatically created when you create the first data LIF
in an IP subnet. A routing group is a container for Vserver routes, including the default route.
3. Record the name of the routing group.
4. Create a default (static) route for the data LIFs:
network routing-groups route create -vserver vserver_name -routing-group
routing_group_name -destination 0.0.0.0/0 -gateway gateway_IP_address
5. Verify that the LIF network configuration is correct by using the network interface show
and network routing-groups route show commands.
For more information about configuring network solutions, see the Clustered Data ONTAP
Network Management Guide.
6. Create the DNS A and PTR records for the data LIF IP addresses assigned to the CIFS
server.
Example
The following commands create a data LIF on each node in the cluster for Vserver vs1. The
CIFS server name is CIFS1, and it is a member of the IEPUB.LOCAL domain. A default
route is added to the routing group that was automatically created during LIF creation. The
following DNS A records and the corresponding PTR records are added to the DNS
server:
10.1.1.128
10.1.1.129
10.1.1.130
10.1.1.131
A
A
A
A
CIFS1.IEPUB.LOCAL
CIFS1.IEPUB.LOCAL
CIFS1.IEPUB.LOCAL
CIFS1.IEPUB.LOCAL
CIFS1
CIFS1
CIFS1
CIFS1
cluster1::> network port show -role data

Auto-Negot
Node
Port
Role
Link
MTU Admin/Oper
------ ------ ------------ ---- ----- ----------node1
a0a
data
down 1500 true/e0c
data
up
1500 true/true
e0d
data
up
1500 true/true
e1b
data
up
1500 true/true
e1c
data
down 1500 true/true
e1d
data
down 1500 true/true
node2
Duplex
Speed (Mbps)
Admin/Oper Admin/Oper
---------- -----------auto/full/full
full/full
full/full
full/half
full/half
auto/auto/1000
auto/1000
auto/1000
auto/10
auto/10

e0c
e0d
e1b
e1c
e1d
data
data
data
data
data
up
up
up
down
down
1500
1500
1500
1500
1500
true/true
true/true
true/true
true/true
true/true
full/full
full/full
full/full
full/half
full/half
auto/1000
auto/1000
auto/1000
auto/10
auto/10
e0c
e0d
e1b
e1c
e1d
data
data
data
data
data
up
up
up
down
down
1500
1500
1500
1500
1500
true/true
true/true
true/true
true/true
true/true
full/full
full/full
full/full
full/half
full/half
auto/1000
auto/1000
auto/1000
auto/10
auto/10
e0c
e0d
e1b
e1c
e1d
data
data
data
data
data
up
up
up
down
down
1500
1500
1500
1500
1500
true/true
true/true
true/true
true/true
true/true
full/full
full/full
full/full
full/half
full/half
auto/1000
auto/1000
auto/1000
auto/10
auto/10
node3
node4
cluster1::> network interface create -vserver vs1 -lif lif1 -role data home-node node1 -home-port e1b -address 10.1.1.128 -netmask-length 24
Info: Your interface was created successfully; the routing group
d10.1.1.0/24 was created
cluster1::> network routing-groups route create -vserver vs1 -routinggroup d10.1.1.0/24 -destination 0.0.0.0/0 -gateway 10.1.1.1
Logical
Status
Network
Vserver
--------- ---------- ---------- --------------vs1
lif1
up/up
10.1.1.128/24
lif2
up/up
10.1.1.129/24
lif3
up/up
10.1.1.130/24
lif4
up/up
10.1.1.131/24
cluster1::> network routing-groups route
Routing
Vserver
Group
Destination
--------- -----------------------vs1
d10.1.1.0/24
0.0.0.0/0
Current
Current Is
Node
Port
Home
---------- ------- ---node1
node2
node3
node4
e1b
e1b
e1b
e1b
true
true
true
true
show -vserver vs1

Gateway
---------10.1.1.1
Metric
-----20
Creating NTFS data volumes

You must create data volumes in the Vserver namespace before you can configure continuously
available shares. Use the volume configuration worksheet to create your data volumes.
About this task
There are optional parameters that you can use to customize a data volume. For more information
about customizing volumes, see the Clustered Data ONTAP Logical Storage Management Guide.
As you create your data volumes, you should not create junction points within a volume that contains
Hyper-V files for which Data ONTAP makes shadow copies.
Note: If you inadvertently create a volume that uses mixed or UNIX security style, you cannot
change the volume to an NTFS security style volume and then directly use it in the Hyper-V
configuration. Nondisruptive operations for Hyper-V over SMB do not work correctly unless the
volumes used in the configuration are created as NTFS security-style volumes.
You must either delete the volume and re-create the volume with NTFS security style, or you can
map the volume on a Windows host and apply an ACL at the top of the volume and propagate the
ACL to all files and folders in the volume.
Steps
1. Create the data volume by entering the appropriate command:

If you want to create a
volume in a Vserver where
the root volume security
style is...
NTFS
volume create -vserver vserver_name -volume

volume_name -aggregate aggregate_name -size
integer[KB|MB|GB|TB|PB] -junction-path path
Not NTFS
volume create -vserver vserver_name -volume

volume_name -aggregate aggregate_name -size
integer[KB|MB|GB|TB|PB] -security-style ntfs junction-path path
2. Verify that the volume configuration is correct:

volume show -vserver vserver_name -volume volume_name
Creating continuously available SMB shares

After you create your data volumes, you can create the continuously available shares that the HyperV servers use to access virtual machine and configuration files. You should use the share
Steps
1. Display information about the existing data volumes and their junction paths:
volume show -vserver vserver_name -junction
2. Create a continuously available CIFS share on the CIFS server by entering the following
command:
vserver cifs share create -vserver vserver_name -share-name share_name path path -share-properties oplocks,continuously-available -symlink ""
[-comment text]
You can optionally add a comment to the share configuration.

By default, the offline files share property is configured on the share and is set to manual.
Data ONTAP creates the share with the Windows default share permission of Everyone /
Full Control.
3. Repeat the previous step for all shares in the share configuration worksheet.
4. Verify that your configuration is correct by using the vserver cifs share show command.
5. Configure NTFS file permissions on the continuously available shares by mapping a drive to each
share, and configuring file permissions by using the Windows Properties box.
Example
The following commands create a continuously available share named vm1 on Vserver vs1.
Offline files are left at the default setting and symlinks are disabled. Symlinks are disabled by
setting the -symlink parameter to "". The disabled symlink setting is indicated by a hyphen
in the Symlink Properties field output of the vserver cifs share show command:
Junction
Vserver
Volume
Active
Junction Path
--------- ----------- -------- ---------------vs1
hyperv
true
/hyperv
vs1
vm1
true
/hyperv/vm1
vs1
vm2
true
/hyperv/vm2
vs1
vs1_root
/
Junction
Path Source
-----------RW_volume
RW_volume
RW_volume
-
cluster1::> vserver cifs share create -vserver vs1 -share-name vm2 -path /
hyperv/vm2 -share-properties oplocks,continuously-available -symlink ""
cluster1::>
vserver cifs share show -vserver vs1 -share-name vm2
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
vm2
VS1
/hyperv/vm2
oplocks
manual
Configuring the VSS shadow copy directory depth

Optionally, you can configure the maximum depth of directories on which to create shadow copies
on Vservers with FlexVol volumes. This parameter is useful if you want to manually control the
maximum level of subdirectories on which Data ONTAP should create shadow copies.
Before you begin
The VSS shadow copy feature must be enabled.

About this task
The default is to create shadow copies for a maximum of five subdirectories. If the value is set to 0,
Data ONTAP creates shadow copies for all subdirectories.
Note: Although you can specify that the shadow copy set directory depth include more than five
subdirectories or all subdirectories, there is a Microsoft requirement that shadow copy set creation
must be completed within 60 seconds. Shadow copy set creation fails if it cannot be completed
within this time. The shadow copy directory depth you choose must not cause the creation time to
exceed the time limit.
Steps

2. Set the VSS shadow copy directory depth to the desired level:
vserver cifs options modify -vserver vserver_name -shadowcopy-dir-depth
integer
Example
vserver cifs options modify -vserver vs1 -shadowcopy-dir-depth 6

Considerations for reverting Hyper-V over SMB

configurations
Before you revert to a Data ONTAP version that does not support nondisruptive operations for
Hyper-V over SMB, you must be aware of certain considerations to ensure that you are prepared for
the revert.
Before you revert, you must consider the following and take action where necessary:
If you are reverting to a version of Data ONTAP that does not support SMB 3.0 and persistent
handle locks, operations such as failover and giveback are disruptive because Hyper-V servers
cannot reclaim disconnected durable handles.
There must be no file access by the Hyper-V servers to virtual machine files when you revert:
You can use the Hyper-V application to migrate virtual machine files to another storage
device or to local storage.
You can power down all virtual machines and manually terminate Hyper-V server
connections to the data LIFs.
Data ONTAP disables SMB 3.0 before reverting; therefore, if the SMB connections are not
manually terminated, Data ONTAP terminates them during the revert.
You cannot use the Hyper-V over SMB solution if you revert to a version of Data ONTAP that
does not support it.
You must configure the Hyper-V servers to use connected LUNs to store and access virtual
machine files. You must then copy the virtual machine files from the SMB shares to the
connected LUNs.
To revert, there can be no ongoing Remote VSS shadow copy operations.
If there are any, you must wait for the operations to finish or manually abort them before
proceeding with the revert. If you need to abort any shadow copy operations, contact technical
support for assistance. Upon a revert, Data ONTAP does not delete existing Snapshot copies.
Managing Hyper-V over SMB configurations

There are certain Data ONTAP tasks that you can perform to manage Hyper-V over SMB
configurations.
Related tasks
Configuring existing shares for continuous availability

You can modify existing shares to become continuously available shares that the Hyper-V servers
use to access virtual machine and configuration files.
About this task
You cannot change a share with the homedirectory share property set to a continuously available
share. You cannot use a share that contains enabled symlinks or widelinks or that contains junctioned
volumes below the root of the share.
You must verify that the two following share parameters are set correctly:
The -offline-files parameter is set to either manual (the default) or none.

Symlinks must be disabled.
The following share properties must be configured for continuously available shares:
oplocks
The following share properties are not compatible with Hyper-V over SMB configurations. If they
are present in the list of current share properties, they need to be removed from the continuously
available share:
changenotify
attributescache
branchcache
Steps
1. Display the current share parameter settings and the current list of configured share properties:
2. If necessary, modify the share parameters to disable symlinks by using the vserver cifs
share properties modify command and setting the value of the -symlink property to ""
and setting the -offline-files parameter to manual.
3. Add the continuously-available share property, and, if needed, the oplocks share
property:
vserver cifs share properties add -vserver vserver_name -share-name
share_name -share-properties continuously-available[,oplock]
If the oplocks share property is not already set, you must add it along with the continuouslyavailable share property.
4. Remove any share properties that are not supported on continuously available shares:
vserver cifs share properties remove -vserver vserver_name -share-name
share_name -share-properties properties[,...]
You can remove one or more share properties by specifying the share properties with a commadelimited list.
5. Verify that the -symlink and -offline-files parameters are set correctly:
vserver cifs share show -vserver vserver_name -share-name share_name fields symlink-properties,offline-files
6. Verify that the list of configured share properties is correct:

vserver cifs shares properties show -vserver vserver_name -share-name
share_name
Examples
The following example shows how to configure an existing share named hyperv1 on Verver
vs1 for use in a Hyper-V over SMB solution.
Symlinks are disabled on the share by setting the -symlink parameter to "".
The -offline-file parameter is modified and set to manual.
The continuously-available share property is added to the share.
The oplocks share property is already in the list of share properties; therefore, it does not
need to be added.
The attributecache and changenotify share properties are removed from the share.
The browsable share property is optional for a continuously available share used for
Hyper-V over SMB configurations and is retained as one of the share properties.
cluster1::> vserver cifs share show -vserver vs1 -share-name hyperv1
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
vs1
hyperv1
vs1
/hyperv1
oplocks
browsable
changenotify
attributecache
enable
10s
hypverv1
documents
cluster1::> vserver cifs share modify -vserver vs1 -share-name hyperv1 offline-file manual -symlink ""
hyperv1 -share-properties continuously-available
hyperv1 -share-properties attributecache,changenotify
cluster1::> vserver cifs share show -vserver vs1 -share-name hyperv1 fields symlink-properties,offline-files
vserver share-name symlink-properties offline-files
-------- ---------- ------------------ ------------vs1
hyperv1
manual
cluster1::> vserver cifs share properties show -vserver vs1 -share-name
hyperv1
Vserver: vs1
Share: hyperv1
Share Properties: oplocks
browsable
Related tasks
Creating continuously available SMB shares on page 441
Enabling or disabling the VSS shadow copy feature

If you use a VSS-aware backup application to back up Hyper-V virtual machine files stored on
Vservers with FlexVol volumes, VSS shadow copy must be enabled. You can disable the VSS
shadow copy if you do not use VSS-aware backup applications. The default is to enable the VSS
shadow copy.
About this task
You can enable or disable the VSS shadow copy feature at any time.
Steps


If you want VSS shadow copy Enter the command...
to be...
Enabled

vserver_name -shadowcopy-enabled true
Disabled

vserver_name -shadowcopy-enabled false

Example
The following commands enable the VSS shadow copy feature on Vserver vs1:
cluster1::*> vserver cifs options modify -vserver vs1 -shadowcopy-enabled
true
Using statistics to monitor Hyper-V over SMB activity

You can display various CIFS and SMB statistics to monitor Hyper-V over SMB activity. For
example, you can obtain information about the number of SMB sessions, the number of sessions
from clients with continuously available capability, and the number of reconnection requests.
Related tasks
Determining whether SMB sessions are continuously available on page 456
Determining which statistics objects and counters are available

Before you can obtain information about CIFS statistics and monitor performance, you must know
which objects and counters are available from which you can obtain data.
Step

If you want to determine...
Which objects are available
Specific objects that are available

object object_name
Which counters are available at the admin privilege statistics catalog counter show
level
object object_name
Which counters are available at the advanced
privilege level

statistics catalog counter show
object object_name
See the man page for the statistics catalog object show and statistics catalog
counter show commands for more information.
Examples
The following example displays descriptions of selected statistic objects related to CIFS access
in the cluster:
cluster1::> statistics catalog object show -object audit
audit_ng
CM object for exporting audit_ng performance
counters
cluster1::> statistics catalog object show -object cifs
cifs
The CIFS object reports activity of the
Common Internet File System protocol
subsystem. This is the Microsoft file-sharing
protocol that evolved from the Server Message
Block (SMB) application layer network
protocol to connect PCs to Network Attached
Storage devices (NAS). This object reports
activity for both SMB and SMB2 revisions of
the CIFS protocol. For information related
only to SMB, see the 'smb1' object. For
information related only to SMB2, see the
'smb2' object.
cluster1::> statistics catalog object show -object nblade_cifs
nblade_cifs
Exported counters associated with the
N-Blade's CIFS subsystem and relevant to the
entire node, rather than individual virtual
servers.
smb1
These counters report activity from the SMB
specific to SMB2, see the 'smb2' object. To
the 'cifs' object.
smb2
These counters report activity from the SMB2
specific to SMB, see the 'smb1' object. To
the 'cifs' object.
cluster1::> statistics catalog object show -object hashd
hashd
The hashd object provides counters to measure
the performance of the BranchCache hash
daemon.
The following example displays information about some of the counters for the cifs object as
seen at the advanced-privilege level:
Note: This example does not display all of the available counters for the CIFS object.
Output is truncated.
Object: cifs
Counter
--------------------------active_searches
Description
avg_directory_depth
avg_junction_depth
data succeeded.
requesting hashes.

change_notifications_outstanding
Number of active change notifications over
SMB and SMB2
cifs_latency
Average latency for CIFS operations
cifs_latency_base
Total observed CIFS operations to be used as
a base counter for CIFS average latency
calculation
cifs_ops
Total number of CIFS operations
cifs_read_ops
Total number of CIFS read operations
cifs_write_ops
Total number of CIFS write operations
[...]
Related tasks
Displaying SMB statistics

You can display various SMB statistics to monitor performance and diagnose issues.
Steps
1. Use the statistics start and optional statistics stop commands to collect a data
sample.
For more information about these commands, see the Clustered Data ONTAP System
If you want to display statistics for...
All versions of SMB
statistics show -object cifs
SMB 1.0
SMB 2.x and SMB 3.0
CIFS subsystem of the node
statistics show -object nblade_cifs
See the man page for more information.
Verifying that the configuration is capable of nondisruptive

operations
You can verify that the Hyper-V over SMB configuration is healthy and able to perform operations
nondisruptively by displaying health monitor information, verifying that the SMB shares are shared
persistently, and by verifying the status of the LIF configuration.
How to use health monitoring to determine whether NDO status is healthy

Health monitoring provides information about system health status across the cluster. The health
monitor monitors Hyper-V over SMB configurations to ensure nondisruptive operations to Hyper-V
servers. If the status is degraded, you can view details about the problem, including the probable
cause and recommended recovery actions.
There are several health monitors. Data ONTAP monitors both overall system health and health for
individual health monitors. The node connectivity health monitor contains the CIFS-NDO subsystem.
The monitor has a set of health policies that trigger alerts if certain physical conditions can lead to
disruption, and if a disruptive condition exists, generates alerts and provides information about
corrective actions. For Hyper-V over SMB configurations, alerts are generated for the two following
conditions:
Alert ID
Severity
Condition
HaNotReadyCifsNdo_Aler
t
Major
One or more files hosted by a volume in an aggregate

on the node have been opened through a continuously
available CIFS share with the promise of persistence in
the event of a failure; however, the HA relationship
with the partner is either not configured or not healthy.
NoStandbyLifCifsNdo_Al
ert
Minor
A Vserver is actively serving data over CIFS through a

node, and there are CIFS files opened persistently over
continuously available shares; however, its partner
node is not exposing any active data LIFs for the
Vserver.
Displaying NDO status by using system health monitoring

You can use the system health commands to display information about the overall system health
of the cluster and the health of the CIFS-NDO subsystem, to respond to alerts, to configure future
alerts, and to display information about how health monitoring is configured.
About this task
For more information about using system health monitoring, see the Clustered Data ONTAP System
Steps
1. Monitor health status by performing the appropriate action:

The health status of the system, which reflects the overall

status of individual health monitors
system health status show

Information about the health status of the CIFS-NDO

subsystem
system health subsystem show

-subsystem CIFS-NDO instance
2. Display information about how CIFS-NDO alert monitoring is configured by performing the
appropriate actions:
If you want to display information about...
The configuration and status of the health monitor for the

CIFS-NDO subsystem, such as nodes monitored,
initialization state, and status
system health config show subsystem CIFS-NDO
The CIFS-NDO alerts that a health monitor can potentially

generate
system health alert

definition show -subsystem
CIFS-NDO
CIFS-NDO health monitor policies, which determine when

alerts are raised
system health policy

definition show -monitor
node-connect
Note: Use the-instance parameter to display detailed information.
Examples
The following output shows information about the overall health status of the cluster and the
CIFS-NDO subsystem:
cluster1::> system health status show
Status
--------------ok
cluster1::> system health subsystem show -instance -subsystem CIFS-NDO
Subsystem:
Health:
Initialization State:
Number of Outstanding Alerts:
Number of Suppressed Alerts:
CIFS-NDO
ok
initialized
0
0
The following output shows detailed information about the configuration and status of the
health monitor of the CIFS-NDO subsystem:
cluster1::> system health config show -subsystem CIFS-NDO -instance
Node:
Monitor:
Subsystem:
Health:
Monitor Version:
Policy File Version:
Context:
Aggregator:
node1
node-connect
SAS-connect, HA-health, CIFS-NDO
ok
2.0
1.0
node_context
system-connect
Resource: SasAdapter, SasDisk, SasShelf, HaNodePair,
HaICMailbox, CifsNdoNode, CifsNdoNodeVserver
Subsystem Initialization Status: initialized
Subordinate Policy Versions: 1.0 SAS, 1.0 SAS multiple adapters, 1.0, 1.0
Node:
Monitor:
Subsystem:
Health:
Monitor Version:
Policy File Version:
Context:
Aggregator:
Resource:
node2
node-connect
SAS-connect, HA-health, CIFS-NDO
ok
2.0
1.0
node_context
system-connect
SasAdapter, SasDisk, SasShelf, HaNodePair,
HaICMailbox, CifsNdoNode, CifsNdoNodeVserver
Subsystem Initialization Status: initialized
Subordinate Policy Versions: 1.0 SAS, 1.0 SAS multiple adapters, 1.0, 1.0
Verifying the continuously available configuration of Hyper-V SMB shares

To support NDO, Hyper-V SMB shares must be configured as continuously available shares.
Additionally, there are certain other share settings that you must check. You should verify that the
shares are properly configured to ensure seamless nondisruptive operations for the Hyper-V
application if there are planned or unplanned disruptive events.
About this task
You must verify that the two following share parameters are set correctly:
The -offline-files parameter is set to either manual (the default) or none.

Symlinks must be disabled.
To ensure proper nondisruptive operations for Hyper-V over SMB, the following share properties
must be set for Hyper-V SMB shares:
oplocks
The following share properties must not be set for Hyper-V SMB shares:
homedirectory
changenotify
attributecache
branchcache
Steps
1. Verify that the offline files are set to manual or disabled and that symlinks are disabled:
vserver cifs shares show -vserver vserver_name
2. Verify that the Hyper-V SMB shares are configured for continuous availability:
vserver cifs shares properties show -vserver vserver_name

Examples
The following example displays the share setting for the shares named vm1 and vm2 on
Vserver vs1. Offline files are set to manual and symlinks are disabled (designated by a
hyphen in the Symlink Properties field output):
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
Vserver:
Share:
Path:
Share Properties:
Symlink Properties:
Share Comment:
Share ACL:
Volume Name:
Offline Files:
show -vserver vs1 -share-name vm1

vs1
vm1
VS1
/hyperv/vm1
oplocks
manual
show -vserver vs1 -share-name vm2
vs2
vm2
VS2
/hyperv/vm2
oplocks
manual
The following example displays the share properties for the shares named vm1 and vm2
on Vserver vs1:
cluster1::> vserver cifs share properties show -vserver vs1 -share-name vm1
Vserver
Share
Properties
--------- ------ ---------vs1
vm1
oplocks
cluster1::> vserver cifs share properties show -vserver vs1 -share-name vm2
Vserver
Share
Properties
--------- ------ ---------vs1
vm2
oplocks
Related tasks
Creating continuously available SMB shares on page 441
Verifying LIF status

Even though you configured the Vserver to have data LIFs on each node in the cluster, during dayto-day operations some data LIFs might have moved to other ports, either on the same node or on
another node. You need to verify LIF status and take any necessary corrective actions.
About this task
To provide seamless NDO support, all Vserver data LIFs must be associated with their home port. If
some of the configured LIFs are not currently associated with their home port, you need to fix any
port issues and then revert the LIFs to their home port.
Steps
1. Display information about configured data LIFS for the Vserver:

network interface show -vserver vserver_name
Each node in the cluster should have at least one data LIF for the Vserver, and the LIFs should be
associated with the LIF's home port.
2. If some of the data LIFs are not on their home port, perform the following:
a) For each data LIF, determine what the LIF's home port is:
network interface show -vserver vserver_name -lif lif_name -failover
b) For each data LIF, determine whether the LIF's home port is up:
network port show -node node_name -port port -fields
node,port,role,link
3. If any of the home port network interfaces to which the data LIFs should be associated are not in
the up state, resolve the problem so that these interfaces are up.
4. If needed, revert the LIFs back to the home port:
network interface revert -vserver vserver_name -lif lif_name
5. Verify that each node in the cluster has an active data LIF for the Vserver:
network interface show -vserver vserver_name
Example
The following commands verify that Vserver vs1 has at least one data LIF on every node in
the cluster, by associating all data LIFs for Vserver vs1 with their home port:
Logical
Status
Network
Vserver
Current
Node
Current Is
Port
Home

----------- ---------- ---------- ---------------vs1
lif1
up/up
10.1.1.128/24
lif2
up/up
10.1.1.129/24
lif3
up/up
10.1.1.130/24
lif4
up/up
10.1.1.131/24
---------- ------- ---node3

node2
node3
node2
e1b
e1b
e1b
e1b
false
true
true
false
cluster1::> network interface show -vserver vs1 -lif lif1 -failover

Logical
Home
Failover
Failover
Vserver Interface
Node:Port
Policy
Group
-------- ----------- --------------- ----------- --------------vs1
lif1
node1:e1b
nextavail
system-defined
Failover Targets: node1:e1b, node1:e1c,
node1:e1d, node1:a0a,
node1:e0c, node1:e0d,
node3:e1b, node3:e1c,
node3:e1d, node3:e0c,
node3:e0d
cluster1::> network interface show -vserver vs1 -lif lif4 -failover
Logical
Home
Failover
Failover
Vserver Interface
Node:Port
Policy
Group
-------- ----------- --------------- ----------- --------------vs1
lif4
node4:e1b
nextavail
system-defined
Failover Targets: node4:e1b, node4:e1c,
node4:e1d, node4:e0c,
node4:e0d, node2:e1b,
node2:e1c, node2:e1d,
node2:e0c, node2:e0d
cluster1::>
node
port
------ ---node1 e1b
network port show -node node1 -port e1b -fields node,port,role,link

role link
---- ---data up
cluster1::>
node
port
------ ---node4 e1b
network port show -node node4 -port e1b -fields node,port,role,link

role link
---- ---data up
cluster1::> network interface revert -vserver vs1 -lif lif1

cluster1::> network interface revert -vserver vs1 -lif lif4
Logical
Status
Network
Vserver
----------- ---------- ---------- ---------------vs1
lif1
up/up
10.1.1.128/24
lif2
up/up
10.1.1.129/24
lif3
up/up
10.1.1.130/24
lif4
up/up
10.1.1.131/24
Current
Current Is
Node
Port
Home
---------- ------- ---node1
node2
node3
node4
e1b
e1b
e1b
e1b
true
true
true
true
Related tasks
Determining whether SMB sessions are continuously available

You can display information about SMB sessions and SMB open files to determine whether they are
continuously available.
Related tasks
Using statistics to monitor Hyper-V over SMB activity on page 448

You can display information about established CIFS sessions, including the CIFS connection and
session ID and the IP address of the workstation using the session. You can display information
about the session's SMB protocol version and continuously available protection level, which helps
you identify whether the session supports nondisruptive operations.
About this task
Vserver name
Node name
CIFS connection ID
CIFS session ID
CIFS user name
CIFS open files
Session idle time
Step

If you want to
display CIFS
session information
for established
sessions...
Vserver in summary
form

If you want to
display CIFS
session information
for established
sessions...
On a specified
connection ID
From a specified
workstation IP
address

On a specified node

{node_name|local}
From a specified
Windows user

With a specified
authentication
mechanism

With the specified

protocol version
NTLMv1
NTLMv2
Kerberos
Anonymous

SMB1
SMB2
SMB2_1
SMB3
If you want to
display CIFS
session information
for established
sessions...
With the specified
No
Yes
Partial
protection.
Examples
cluster1::> vserver
Node:
node1
Vserver: vs1
Connection Session
ID
ID
---------- ------3151272279 1

Open
Idle
Workstation
Windows User
Files
Time
---------------- ------------- ------- -----------10.1.1.1
DOMAIN\joe
2
23s
Node: node1
Vserver: vs1
Session ID: 1
UNIX User: pcuser

Open Shares:
Open Files:
Open Other:
Connected Time:
Idle Time:
Protocol Version:
1
1
0
10m 43s
1m 19s
SMB3
Yes
Node:
Vserver:
Session ID:
Connection ID:
Windows User:
UNIX User:
Open Shares:
Open Files:
Open Other:
Connected Time:
Idle Time:
Protocol Version:
node1
vs1
1
3151272607
10.2.1.2
10.1.1.3
NTLMv2
pcuser
1
0
0
6m 22s
5m 42s
SMB3
No

You can display information about open CIFS files, including the CIFS connection and session ID,
the hosting volume, the share name, and the share path. You can display information about a file's
continuously available protection level, which is helpful in determining whether an open file is in a
state that supports nondisruptive operations.
About this task
Vserver name
Node name
CIFS connection ID
CIFS session ID
CIFS user name
CIFS open files
Session idle time
Step

If you want to
display CIFS
session information
for established
sessions...
Vserver in summary
form
On a specified
connection ID
From a specified
workstation IP
address

On a specified node

{node_name|local}
From a specified
Windows user


If you want to
display CIFS
session information
for established
sessions...
With a specified
authentication
mechanism

With the specified

protocol version
NTLMv1
NTLMv2
Kerberos
Anonymous

SMB1
SMB2
SMB2_1
SMB3
With the specified

No
Yes
Partial
protection.
Examples
cluster1::> vserver
Node:
node1
Vserver: vs1
Connection Session
ID
ID
---------- ------3151272279 1

Open
Idle
Workstation
Windows User
Files
Time
---------------- ------------- ------- -----------10.1.1.1
DOMAIN\joe
2
23s
Node: node1
Vserver: vs1
Session ID: 1
UNIX User: pcuser
Open Shares: 1
Open Files: 1
Open Other: 0
Connected Time: 10m 43s
Idle Time: 1m 19s
Node:
Vserver:
Session ID:
Connection ID:
Windows User:
UNIX User:
Open Shares:
Open Files:
Open Other:
Connected Time:
Idle Time:
node1
vs1
1
3151272607
10.2.1.2
10.1.1.3
NTLMv2
pcuser
1
0
0
6m 22s
5m 42s

Continuously Available: No
465
File access to Infinite Volumes

Infinite Volumes support access by Windows and UNIX users over multiple protocols, including
SMB 1.0, NFSv3, pNFS, and NFSv4.1.
Infinite Volumes offer enhanced multiprotocol support through the unified security style. Both
Windows and UNIX users can access files on Infinite Volumes and can also view and set file
permissions interchangeably.
The way that you set up NFS or SMB access to a Vserver with Infinite Volume is similar to that of a
Vserver with FlexVol volumes.
Note: This documentation uses Infinite Volumes and Vservers with Infinite Volume
interchangeably. Although client access is configured at the Vserver level, there is a one-to-one
relationship between the Infinite Volume and its containing Vserver with Infinite Volume.
Therefore, configuring access to the Vserver is effectively configuring access to the Infinite
Volume.
Support for NFS on Infinite Volumes

Infinite Volumes support core NFS versions and features, including client access by using NFSv3,
NFSv4.1, and pNFS. However, Infinite Volumes do not support all of the NFS versions and NFS
features that Vservers with FlexVol volumes support.
NFS versions
The following table identifies the versions or types of NFS that are supported on Infinite Volumes:
Supported
Not supported
NFSv3
NFSv4.1
pNFS
NFSv4.0
NFS features
Almost all NFS features are supported on Infinite Volumes in the same way that they are supported
for FlexVol volumes. For example, NFSv4.1 ACLs are supported.
The following NFS features are not supported on Infinite Volumes:
delegations
migrations and referrals
configurations related to other features that Infinite Volumes do not support, such as quotas or
vstorage
FPolicy, which is used to monitor and manage file access events
Fsecurity, SACLs (System ACLs), and auditing of NAS file access events
Clients can set SACLs on files, but the SACLs are not currently used.
security tracing
Support for CIFS on Infinite Volumes

Infinite Volumes support SMB 1.0 and core CIFS functionality. However, Infinite Volumes do not
support all of the SMB versions and CIFS features that Vservers with FlexVol volumes support.
SMB versions
The following table identifies the versions of SMB that are supported and not supported on Vservers
with Infinite Volume:
Supported
Not supported
SMB 1.0
SMB 2.x
SMB 3.0
CIFS features
Most CIFS features are supported on Vservers with Infinite Volume in the same way that they are
supported for all Vservers.
The following CIFS features are not supported by Vservers with Infinite Volume:
BranchCache
Hyper-V over SMB feature
Remote copy offload
VSS shadow copy
Automatic node referrals
FPolicy, which is used to monitor and manage file access events
Fsecurity, SACLs (System ACLs), and auditing of NAS file access events
Clients can set SACLs on files, but the SACLs are not currently used.
Security tracing
Change notification is supported on Infinite Volumes but is disabled by default. Enabling change
notification on an Infinite Volume share requires advanced privilege level and might require that
clients restart their sessions.
File access to Infinite Volumes | 467
Comparison of namespaces for Infinite Volumes and

FlexVol volumes
The namespace architecture of a Vserver with Infinite Volume is different from the namespace
architecture of a Vserver with FlexVol volumes. Understanding this difference can help you plan
each Vserver's namespace.
When you create and mount FlexVol volumes in a Vserver with FlexVol volumes, you can create
one or more trees of junction paths. Each FlexVol volume can connect to another FlexVol volume or
directly to the Vserver root volume.
In contrast, when you configure a Vserver with Infinite Volume, you need to define only one
junction path in the entire Vservera single junction path for the Infinite Volume. No other junction
paths are needed; the Infinite Volume contains all of the Vserver's data. For an Infinite Volume, the
Vserver's namespace and Infinite Volume's namespace are essentially the same.
Inside both FlexVol volumes and Infinite Volumes, you can create a directory tree of your choosing.
Where clients access Infinite Volumes

Clients access an Infinite Volume at or below the Infinite Volume's junction path.
All SMB shares and NFS mounts must occur at the Infinite Volume's junction path or at a directory
under the junction path. For example, if the Infinite Volume junction is /NS, clients can access /NS
or any directory created below /NS, such as /NS/admin, /NS/video, and /NS/eng/images.
Clients must not access the following locations:
The Vserver root volume, /

Directories created immediately below the Vserver root volume, such as /admin, /videos,
or /eng/images
Directories under the private .system namespace, such as /.system/constituents
Although it is possible to create an SMB share in an incorrect location, such as /.system, files
created in such locations are not part of the Infinite Volume or its advanced features.
How access to an Infinite Volume is controlled

To successfully access data on an Infinite Volume, clients pass through one or more layers of
security that can include an export policy, a share ACL, and file permissions.
The following table summarizes the security layers and what each one affects:

Layer
What it controls
Method of control
Affects
NFS
access?
Affects
CIFS
access?
Export
policy
Whether a user can

mount all or part of
the Infinite Volume
Comparing the client's IP and other

networking information to export
rules in the export policy applied to
the entire Infinite Volume
Yes
Not by
default
Share ACL
Whether a user can

access a share
Comparing the user's Windows

credential to the access control
entries (ACEs) in the ACL on a
given share
No
Yes
Comparing the user's credentials

both Windows and UNIXto the
effective file permissions
Yes
Yes
File
Whether a user can
permissions see and work with
specific directories
and files
Note: Each of these security layers depends upon security provided by user authentication and
authorization processes.
How export policies affect access to an Infinite Volume

By default, an Infinite Volume has an export policy that gives clients full read/write access to the
entire namespace, which you might want to restrict.
The default export policy for an Infinite Volume is called repos_namespace_export_policy and
it contains no restrictions on client access. If you want to restrict access, you can add export rules to
the existing export policy or you can create a new export policy and assign it to the Infinite Volume.
The export policy of an Infinite Volume affects the entire namespace of the Vserver with Infinite
Volume because each Vserver with Infinite Volume contains only a single volume junction.
By default, export policies apply only to NFS access. If you want an export policy to apply to SMB
access, you must use advanced privilege to set the -is-exportpolicy-enabled parameter of the
cifs options modify command.
The Vserver with Infinite Volume also has other export policies, which you should leave unchanged:
The root volume of the Vserver with Infinite Volume has an export policy called
repos_root_readonly_export_policy, which gives clients read-only access to the root
volume so that clients can gain access to the Infinite Volume's junction path.
Because clients should not access a Vserver root volume, you should not change this policy to
give clients write permissions.
The data constituents have an export policy called repos_restricted_export_policy,
which restricts all access to the data constituents.
Because clients should never access data constituents directly, you must not change this export
policy in any way.

Related tasks
Controlling access to an Infinite Volume with IP-based export rules on page 480
How share ACLs affect SMB access to Infinite Volumes

Share ACLs control access by SMB clients to each share on an Infinite Volume. Share ACLs apply
only to Windows users accessing over SMB, not to NFS clients.
You can create multiple shares on an Infinite Volume, and each share has a default share ACL that
allows all Windows users full control. You can configure each share ACL independently of other
shares' ACLs.
Share ACLs work the same way on Infinite Volumes and FlexVol volumes.
Related concepts

Related tasks
Controlling SMB access to an Infinite Volume share with share ACLs on page 481
How file permissions control access to Infinite Volumes

Files and directories on an Infinite Volume can have a variety of effective file permissions, which
control a user's access to a specific file based on the user's credentials.
Types of files permissions
Infinite Volumes support all types of file permissions, including the following:
UNIX permissions (also called mode bits)

NFSv3 and NFSv4.1 clients set mode bits by using the following UNIX commands: chgrp,
chown, and chmod. The chmod command can be on permissions or on the sticky bit, setuid flag,
or setgid flag.
NTFS file permissions (also called SMB ACLs)
Windows users can set NTFS (NT File System) file permissions by using Windows commandline interface or the Security tab of the Properties dialog box in Windows Explorer. The process
of setting NTFS file permissions on a file sets an SMB ACL on the file.
NFSv4.1 ACLs
If NFSv4.1 ACLs have been enabled on the Vserver with Infinite Volume, NFSv4.1 clients can
set NFSv4.1 ACLs using commands specific to each operating system.
Each file or directory can only have one type of file permissions in effect at one time. But different
file permissions can be used across files and directories. For example, the Infinite Volume itself
might use UNIX permissions, while one subdirectory uses NTFS file permissions, and another
subdirectory uses UNIX permissions.

Method of checking access
The general method of determining the user's rights is the same for Infinite Volumes and FlexVol
volumes. A user's credentials are compared with the effective file permissions.
On an Infinite Volume, if NTFS file permissions are in effect, the access check has one additional
aspect. The NTFS file permissions can include entries for UNIX users, which are then compared with
the user's UNIX credential.
What the default permissions are on Infinite Volumes

By default, an Infinite Volume has no restrictions on client access from either the export policy or
share ACL. At the file level, an Infinite Volume uses UNIX permissions (mode bits) by default.
Default export policy
An Infinite Volume has a default export policy repos_namespace_export_policy that contains
no restrictions on client access.
Default share ACL
Each time a CIFS share is created on an Infinite Volume, it has a default ACL that allows everyone
full control.
Default file permissions
By default, a new Infinite Volume uses UNIX file permissions (also called mode bits). An Infinite
Volume has no default NTFS file permissions (also called SMB ACLs) or NFSv4.1 ACLs.
When an Infinite Volume is created, the default UNIX permissions are 0755 (drwxr-xr-x), which
allow the UNIX owner to read, write, and execute his or her own files and allow others to read or
execute files. If you want a new Infinite Volume to have UNIX permissions other than 0755, you can
use the -unix-permissions parameter of the volume create command.
How unified security style supports multiprotocol access to

Infinite Volumes
The unified security style used by all Infinite Volumes enables all users using NFSv3, NFSv4.1, and
SMB 1.0 to view and set file permissions, regardless of the file permissions that are currently in

effect on a given file or directory. In addition, unified security style supports UNIX principals in
How an Infinite Volume gets unified security style
Infinite Volumes always use unified security style. Unlike FlexVol volumes, Infinite Volumes do not
inherit security styles from the root volume of their containing Vservers. Unlike with FlexVol
volumes, you cannot, and do not need to, configure the security style of an Infinite Volumes or its
Setting permissions on all files
In unified security style, clients can set file permissions regardless of the file permissions that are
currently in effect, including the following multiprotocol situations:
NFS clients can set UNIX permissions bits on a file with NTFS file permissions.
SMB clients can set NTFS file permissions on a file with UNIX permissions or an NFSv4.1 ACL.
NFSv4.1 clients can set an NFSv4.1 ACL on a file with NTFS file permissions.
Displaying permissions on all files

In unified security style, clients can view file permissions of any file regardless of the file
permissions that are currently in effect, including the following multiprotocol situations:
NFS clients can display UNIX permissions of a file with NTFS file permissions.
SMB clients can view permissions of a file with UNIX permissions or an NFSv4.1 ACL.
NFSv4.1 clients can display an equivalent NFSv4.1 ACL for a file with NTFS file permissions.
Support for UNIX principals in NTFS file permissions

In unified security style, NTFS file permissions can contain UNIX principals, which facilitate
multiprotocol access in the following ways:
When a Windows or UNIX user uses any supported protocol to access a file that contains NTFS
file permissions, the user's UNIX credential is compared with any UNIX principals in the NTFS
file permissions.
When an SMB client views a file's permissions, any UNIX users in the permissions are displayed
without being converted to Windows users.
When an SMB client sets NTFS file permissions, the SMB client can specify permissions for
UNIX principals.
When an NFS client changes the UNIX permissions, owner, or group of a file that uses NTFS file
permissions, UNIX principals are used in the affected permissions while leaving the remaining
NTFS file permissions unchanged.
NTFS file permissions are unaffected as long as the v4 ACL Preserve parameter is enabled.
How group mapping supports multiprotocol access to Infinite Volumes

Group mapping improves the accuracy of permissions that appear when NFSv4.1 clients display the
ACL of a file or directory that has NTFS file permissions. If an Infinite Volume supports both
NFSv4.1 ACLs and SMB, you should configure group mapping, which is similar to user mapping.
Why group mapping is necessary
Groups are often used in ACLs to simplify security management. However, groups in multiple
Windows domains cannot be easily translated to the groups of a single NFSv4.1 domain.
Mapping groups from Windows to UNIX ensures that group names appear when NFSv4.1 ACLs are
displayed on NFSv4.1 clients.
If a Windows group is not mapped to a UNIX group and a default UNIX group is not configured, the
Windows group is displayed to an NFSv4.1 client as nobody (specifically nobody@v4-iddomain).
What group mapping is required
If an Infinite Volume supports both SMB and NFSv4.1 ACLs, you should perform the following
configurations:
Create a Windows-to-UNIX mapping for every Windows group.

Define a default UNIX group that is used when no mapping exists for a Windows group and the
lowercase name of the Windows group is not a valid group name in the UNIX domain.
Comparison of user and group mapping

Group mapping and user mapping share the following similarities:
They can both be defined either using Data ONTAP or using LDAP.
In Data ONTAP CLI, the vserver name-mapping commands configure user mapping and the
vserver group-mapping commands configure group mapping.
If they are defined using Data ONTAP, they are defined in a similar way and using the same
conversion rules.
Group mapping is unique in the following ways:
It is available only on Vservers with Infinite Volume, not Vservers with FlexVol volumes.
It is necessary only if a Vserver is configured for both SMB and NFSv4.1, including NFSv4.1
ACLs.
It does not affect access; it affects only what NFSv4.1 clients display.
During access checks, a user's group membership is determined in the same way on all Vservers.
It is necessary only in one directionfrom Windows to UNIX.
UNIX groups do not have to be mapped to Windows groups.

Related concepts

Name mapping conversion rules on page 74
Related tasks
Configuring group mapping on an Infinite Volume on page 479
Setting up client access to an Infinite Volume

After meeting some prerequisites, you can set up client access to an Infinite Volume by configuring
user and groups, enabling access to one or two protocols, and then controlling access with a mixture
of export policies, share ACLs, and file permissions.
Steps
1. Preparing an Infinite Volume for client access on page 473

2. Configuring name services, user authentication, and user mapping on an Infinite Volume on page
475
3. Setting up basic NFS access to an Infinite Volume on page 475
4. Setting up basic SMB access to an Infinite Volume on page 477
5. Configuring group mapping on an Infinite Volume on page 479
6. Controlling access to an Infinite Volume with IP-based export rules on page 480
7. Controlling SMB access to an Infinite Volume share with share ACLs on page 481
8. Controlling access to Infinite Volumes with file permissions on page 482
Preparing an Infinite Volume for client access

Before setting up client access to an Infinite Volume, you should verify that the protocol that you
want is allowed on the Vserver with Infinite Volume, verify that the Infinite Volume is online, and
ensure that you know the name of its junction path.
Before you begin
The cluster must have an NFS license, a CIFS license, or both licenses.
For information about configuring licenses, see the Clustered Data ONTAP System
The time zone must be set and synchronized across the cluster by configuring NTP.
This prevents authentication errors and ensures that time stamps in log files are consistent across
the cluster.
For information about configuring the time zone, see the Clustered Data ONTAP System
The Infinite Volume and its containing Vserver with Infinite Volume must have been created.
If not, see the Clustered Data ONTAP Logical Storage Management Guide.
Data-access LIFs and routing groups must have been configured on the Vserver with Infinite
Volume.
If not, see the Clustered Data ONTAP Network Management Guide.
Steps
1. Verify that the protocols that you want are allowed on the Vserver with Infinite Volume.
a) View the protocols that are allowed on the Vserver with Infinite Volume by using the
vserver show command with the -vserver parameter.
For a Vserver with Infinite Volume, the allowed protocols can be set to any of the following
values:
nfs
cifs
cifs,nfs
By default, both CIFS and NFS are allowed on a Vserver with Infinite Volume.
Example
cluster1::> vserver show -vserver vs1
Vserver: vs1
...
Allowed Protocols: nfs, cifs
Disallowed Protocols: fcp, iscsi, ndmp
...
b) If the output does not match your requirements, use the vserver modify command with the
-allowed-protocol parameter.
2. Verify that the Infinite Volume is online and mounted by using the volume show command with
the -vserver, -volume, -fields state,junction-path parameters.
Example
cluster1::> volume show -vserver vs1 -volume ivol -fields state,junction-path
vserver volume state junction-path
------- ------ ------ ------------vs1
ivol
online /NS
a) If the Infinite Volume is not online, bring it online by using the volume online command.
b) If the Infinite Volume does not have a junction path, which indicates it is not mounted, mount
it by using the volume mount command.
3. Note the junction path that is displayed in the output of the previous step so that you can use it for
client access later.
Configuring name services, user authentication, and user mapping on an

Infinite Volume
You can configure name services, user authentication, user name mapping, and default users for a
Vserver with Infinite Volume in the same way that you do for a Vserver with FlexVol volumes.
Steps
1. If you allow NFS access and you want to use Kerberos for authentication, configure Kerberos.
2. If you allow NFS access, configure either or both of the following name services components:
NIS name services

Local UNIX users and groups
3. If you allow SMB access to the Infinite Volume and you want to use local Windows users and
groups for authentication and authorization, configure local Windows users and groups.
SMB access uses Active Directory (AD) users and groups. You can configure local Windows
users and groups in addition to the AD users and groups.
4. If you allow both SMB and NFS access to the Infinite Volume, configure either or both of the
following name translation components:
User name mapping

The default UNIX user and the default Windows users
Related concepts
Configuring local UNIX users and groups on page 77

Using Kerberos with NFS for strong security on page 62
Related tasks
Setting up basic NFS access to an Infinite Volume

If you want NFS clients to access an Infinite Volume, you must use the vserver nfs create
command to create an NFS server on the Vserver with Infinite Volume and enable NFSv3, NFSv4.1,
or both. Then you should test the access using a test UNIX user on an NFS client.
About this task
The way that you set up NFS access is the same for all Vservers.

Steps
1. Plan what type of NFS access you will enable.

a) Decide whether you are going to enable NFSv3, NFSv4.1, or both.
b) If you decided to enable NFSv4.1, decide whether you are going to enable NFSv4.1 ACLs.
c) Consider other optional parameters by using the man page for the vserver nfs create
command or by seeing the links below.
2. Create an NFS server by using the vserver nfs create command with the parameters based
on your choice in the previous step.
Example
cluster1::> vserver nfs create -vserver vs1 -v3 enabled -v4.1 enabled
-v4.1-acl enabled
3. Verify that NFS is enabled by using the vserver nfs show command.
Example
cluster1::> vserver nfs show -vserver vs1
Vserver: vs1
General NFS Access: true
NFS v3: enabled
NFS v4.0: disabled
UDP Protocol: disabled
TCP Protocol: enabled
Spin Authentication: disabled
Default Windows User: NFSv4.0 ACL Support: disabled
NFSv4.0 Read Delegation Support: disabled
NFSv4.0 Write Delegation Support: disabled
NFSv4 ID Mapping Domain: defaultv4iddomain.com
NFSv4.1 Minor Version Support: enabled
Rquota Enable: disabled
NFSv4.1 Parallel NFS Support: disabled
NFSv4.1 ACL Support: enabled
NFS vStorage Support: disabled
Default Windows Group: NFSv4.1 Read Delegation Support: disabled
NFSv4.1 Write Delegation Support: disabled
NFS Mount Root Only: enabled
NFS Root Only: disabled
4. If you enabled NFSv3 access, mount the client over NFSv3 and create a new directory.
5. If you enabled NFSv4.1, mount the client over NFSv4.1 and create a new directory.
Related concepts
Support for NFS on Infinite Volumes on page 465

Managing NFSv4 ACLs on page 98

Related tasks
Creating an NFS server on page 47
Setting up basic SMB access to an Infinite Volume

If you want Windows users to access an Infinite Volume over SMB, you must create a CIFS server
on the Vserver with Infinite Volume and create a CIFS share on the Infinite Volume. You can then
test the access from an SMB client, create folders, and create shares to specific folders.
Before you begin
You must have the name of the domain that you will associate with the CIFS server.
You must have the name and password of a Windows account with sufficient privileges to add
computers to the chosen organizational unit.
The directory where you want to create the share must already exist.
If no directories exist, you can create a share on the Infinite Volume as a whole and use it to
create the directory structure for future shares.
About this task
The way that you set up SMB access is the same for all Vservers, except that all shares on a Vserver
with Infinite Volume must be located at or under the Infinite Volume's junction path.
Steps
1. Determine what optional CIFS functionality that you will enable.

See the links below and see the man page for the vserver cifs create and vserver cifs
modify commands.
2. Configure DNS on the Vserver with Infinite Volume by using the vserver services dns
create command.
Example
cluster::> vserver services dns create -vserver vs1 -domains example.com -nameservers 10.1.1.50,10.1.1.51
3. Create a CIFS server and associate it with an Active Directory domain by using the vserver
cifs create command and then entering the user name and password of the Windows account
with sufficient privileges to add computers to the chosen organizational unit.
Example
cluster::> vserver cifs create -vserver vs1 -cifs-server CIFS1 domain example.com
4. Verify that CIFS is enabled by using the vserver cifs show command.

Example
cluster::>vserver cifs show -vserver vs1
Server
Domain/Workgroup
Vserver
Name
Name
Authentication Style
-------------- ----------- ---------------- -------------------vs1
CIFS1
EXAMPLE
domain
5. Create a share on the Infinite Volume by using the vserver cifs share create command
on the junction path of the Infinite Volume.
The path of every SMB share must be located at or under the junction path for the Infinite
Volume. You must not create a share at the root of the Vserver with Infinite Volume or in
the /.system directory.
Example
cluster::> vserver cifs share create -vserver vs1 -share-name
InfiniteVol -path /NS
6. On an SMB client, map a share in either of the following ways:
In Windows Explorer, select Tools > Map Network Drive, and enter \
\cifs_server_name\share_name.
In a command window, enter the following command:

net use * \\cifs_server_name\share_name /user:domain_name\user_name
password
7. On the same SMB client, test the access by performing the following actions:
a)
b)
c)
d)
e)
View the share.

Create a folder in the share.
Create a new file in the share.
Modify the file.
Delete the file.
8. Create the directory structure that you want inside the Infinite Volume.
Example
You can create a folder called Engineering for the Engineering department.
9. Create shares for specific folders on the Infinite Volume by using the vserver cifs share
create command.
Example
The following command creates a share on the Engineering folder for the Engineering
department:

cluster::> vserver cifs share create -vserver vs1 -share-name
Engineering -path /ns/Engineering -comment "Engineering Department"
Related concepts
Support for CIFS on Infinite Volumes on page 466

Configuring CIFS servers on page 118
Configuring group mapping on an Infinite Volume

If an Infinite Volume is accessed by both SMB and NFSv4.1 clients, you should ensure that NFSv4.1
clients see accurate security information by mapping Windows groups to UNIX groups and by
configuring the default UNIX group.
Before you begin
The UNIX and Windows groups that you want to map must exist.
The UNIX group that you want to set as a default must exist.
You must be aware of the conversion rules that apply to name mapping of both users and groups.
About this task
You should perform this task only if NFSv4.1 ACLs are enabled on the Infinite Volume and the
Infinite Volume supports access through both SMB and NFSv4.1.
Steps
1. Create mappings from Windows groups to UNIX groups by using the vserver group
mapping create command.
In all mappings, you should set the -direction parameter to win-unix, because Windows-toUNIX mappings are the only ones that are relevant.
2. Show the mappings by using the vserver group mapping show command, and review the
output to evaluate whether the mappings match what you intend.
3. If necessary, fix the mappings with any of the following commands:
vserver group-mapping modify

vserver group-mapping insert
vserver group-mapping swap
vserver group-mapping delete
4. Set the default UNIX group by using the vserver cifs options modify command with the
-default-unix-group parameter.

Related concepts
How group mapping supports multiprotocol access to Infinite Volumes on page 472
Name mapping conversion rules on page 74
Controlling access to an Infinite Volume with IP-based export rules

The export policy on an Infinite Volume allows full read/write access by default. If you want to
restrict access based on IP address, you must define export rules for specific host names, IP
addresses, or netgroups in the default export policy called repos_namespace_export_policy.
About this task
By default, an export policy affects only NFS clients, not SMB clients.
Steps
1. View the export rules in the Infinite Volume's export policy by using the vserver exportpolicy rule show command with the -vserver and -policyname
repos_namespace_export_policy parameters.
Example
cluster1::> vserver export-policy rule show -vserver vs1 -policyname
repos_namespace_export_policy
Policy
Rule
Access
Client
RO
Vserver
Name
Index
Protocol Match
Rule
------------ --------------- ------ -------- --------------------- --------vs0
repos_namespace_export_policy 1
any
0.0.0.0/0
any
vs0
repos_namespace_export_policy 2
any
::0/0
any
2. Define export rules for the export policy by using the vserver export-policy rule
create, vserver export-policy rule modify, vserver export-policy rule
delete, and vserver export-policy rule setindex commands.
Example
cluster1::> vserver export-policy rule create -vserver vs1 -policyname
repos_namespace_export_policy -ruleindex 3 -protocol any clientmatch .example.com -rorule any -rwrule "ntlm,krb5,sys" -anon 65534 allow-suid false -allow-dev false
3. Verify that the rules match your requirements by using the vserver export-policy rule
show command with the -vserver and -policyname repos_namespace_export_policy
parameters.

Related concepts
How export policies affect access to an Infinite Volume on page 468

Controlling SMB access to an Infinite Volume share with share ACLs

By default, an SMB share on an Infinite Volume has a share-level ACL that allows all Windows
users Full Control within the share. If you want to restrict specific Windows users and groups from
accessing the share, you can modify the ACEs in the share ACL.
Before you begin
The share must already exist.

You must have the names of the Windows users and groups that you want to restrict.
About this task
You configure share ACLs on a Vserver with Infinite Volume the same way you configure them on a
Vserver with FlexVol volumes.
Steps
1. Display the share ACL on the share by using the vserver cifs share show command.
2. Display the ACEs in the share ACL by using the vserver cifs share access-control
show command.
3. Modify the ACEs in the share ACL by using any of the following commands:
vserver cifs share access-control create command

vserver cifs share access-control modify command
vserver cifs share access-control delete command
Example
If you want everyone to view the share but only people in the Engineering department to work on
the share, you can modify the existing ACE so that Everyone has read-only access, and then add
an ACE that gives full control to the Engineering group.
4. Verify that the share ACL contains the ACEs you want by using the vserver cifs share
access-control show command.
Related concepts
How share ACLs affect SMB access to Infinite Volumes on page 469
Controlling access to Infinite Volumes with file permissions

With an Infinite Volume, you can set file permissions in one or more ways, including UNIX
permissions, NTFS file permissions, and NFSv4.1 ACLs. You can set file permissions on the Infinite
Volume or on directories inside the Infinite Volume.
Before you begin
In most cases, you must have access to a Windows or UNIX client to set permissions.
You can use the CLI to set UNIX permissions on the Infinite Volume. In all other cases, you must
use a client to set file permissions.
You must have decided what method you will use for the Infinite Volume or for the directories
inside it.
About this task
You need to set file permissions only if you do not want to use the default UNIX permissions that
were specified when the Infinite Volume was created.
Choices
If you want to change the default UNIX permissions for the entire Infinite Volume, use the
volume modify command with the -unix-permissions parameter.
Example
The following command gives read, write, and execute permissions to the owner and group and
no permissions to others:
cluster::> volume modify -vserver vs1 -volume ivol -unix-permissions
0770
The permissions apply to all newly created files, depending on other configurations such as
inheritable ACLs or client-side settings.
If you want a directory to have UNIX permissions that are different than the default UNIX
permissions for the Infinite Volume, use an NFS client, such as a Linux client, to configure
permissions for the directory by using the umask and chmod UNIX commands.
For information about configuring UNIX permissions, see the Linux documentation.
If you want to use NTFS file permissions (SMB ACLs) on the entire Infinite Volume or a
directory inside the Infinite Volume, use a Windows client to set the permissions on the volume
or a directory, keeping in mind the following considerations:
Similar to when you set NTFS file permissions on any directory or volume, you must decide
whether the permissions will be inherited by selecting a value in the Apply to box of the
Windows Security tab in the Windows Properties window.
On an Infinite Volume, you can set permissions for UNIX users and groups, in addition to
Windows users and groups.
Although you can set SACLs, they have no effect on Infinite Volumes.
For information about configuring NTFS file permissions, see the Windows documentation.
The new NTFS file permissions are propagated by the client to existing files in the directory, and
used when creating new files, depending on the setting in the Apply to box.
If you want to use NFSv4.1 ACLs on the entire Infinite Volume or a directory inside the Infinite
Volume, use an NFSv4.1 client to set an NFSv4.1 ACL either by editing the ACL directly or by
using GUI software that is capable of editing NFSv4.1 ACLs.
For information about configuring NFSv4.1 ACLs, see the NFSv4.1 protocol standard or the GUI
software documentation.
The NFSv4.1 ACL is set on all new and existing files in the directory. Depending on how you
configured the ACL, the entire ACL or ACEs within the ACL can be inherited by child
directories.
Related concepts
Advanced Infinite Volume file access concepts

When you configure file access to an Infinite Volume, it is helpful to understand the outcome when
each type of client sets permissions, the outcome when each type of client display permissions, and
other advanced concepts.
What happens when NFS clients set UNIX permissions on Infinite Volumes
When an NFS client issues a UNIX command that affects permissions on a file on an Infinite
Volume, the success of the command depends on several factors, including the effective file
permissions, the specific commands, and whether the ACL preservation feature is enabled on the
NFS server.
ACL preservation, which is enabled by default, is a configurable feature of each NFS server. It is
configured with the -v4-acl-preserve parameter of the nfs modify command. Although the
parameter refers to NFSv4, it also applies to SMB ACLs.
Setting UNIX permissions when UNIX permissions are effective
If an NFS client uses UNIX commands to set permissions on a file where UNIX permissions are
effective, the UNIX permissions are updated.
Setting mode bits when NFSv4.1 ACLs are effective
If an NFS client uses UNIX commands to set permissions on a file that has an NFSv4.1 ACL, the
NFSv4.1 ACL can be modified, dropped, or unaffected, as shown in the following table:

UNIX command
Result
chmod on permissions
If ACL preservation is enabled, the NFSv4.1 ACL remains effective

and ACEs for OWNER@, GROUP@, or EVERYONE@ are modified
or added to the NFSv4.1 ACL.
If ACL preservation is disabled, the NFSv4.1 ACL is dropped and the
UNIX permissions sent in the command become effective.
chgrp or chown
There is no effect on the NFSv4.1 ACL.
chmod on the setuid,
Inside the NFSv4.1 ACL, the affected special mode bits are added,
dropped, or modified. (The display mode bits are also updated.)
setgid, or sticky bit
Setting mode bits when NTFS file permissions are effective

If an NFS client uses UNIX commands to set permissions on a file that has NTFS file permissions
(which are stored as SMB ACLs), the SMB ACL can be modified, dropped, or unaffected, as shown
in the following table:
UNIX command
Result
Any of the following

commands:
If ACL preservation is enabled, the SMB ACL remains effective and

ACEs for OWNER@, GROUP@, or EVERYONE@ are modified or
added to the SMB ACL.
If ACL preservation is disabled, the SMB ACL is dropped and the
UNIX permissions sent in the command become effective.
chmod on permissions
chgrp
chown
chmod on the setuid,
There is no effect on the SMB ACL.
setgid, or sticky bit
What happens when SMB clients set NTFS file permissions on Infinite
Volumes
When an SMB client sets NTFS file permissions on a file on an Infinite Volume, existing NFS-style
permissions are dropped and an SMB ACL is created. If any UNIX users or groups were included in
the permissions set by the SMB client, the UNIX names are stored in the resulting SMB ACL.
When an SMB client sets NTFS file permissions on a file on an Infinite Volume, the following
occurs:
1. An SMB ACL is set in one of the following ways:
If effective permissions are
The SMB ACL is set in this way
The SMB ACL is updated.
UNIX permissions
The UNIX permissions are dropped (including the setuid,

setgid, and sticky bit), and an SMB ACL is created.

If effective permissions are
The SMB ACL is set in this way
NFSv4.1 ACL
The NFSv4.1 ACL is dropped, and an SMB ACL is created.
2. If any ACEs reference UNIX users or groups, the ACEs are stored in the SMB ACL in NFSv4.1
style, using the UNIX user and group names.
3. Display mode bits are created based on the user in the ACL with the most access.
What happens when NFS clients set NFSv4.1 ACLs on Infinite Volumes
When an NFSv4.1 client sets an NFSv4.1 ACL on a file on an Infinite Volume, most or all existing
permissions are dropped and an NFSv4.1 ACL is created.
When an NFSv4.1 client sets an NFSv4.1 ACL on a file on an Infinite Volume file, the following
occurs:
1. An NFSv4.1 ACL is set in one of the following ways:
If effective permissions
are
The NFSv4 ACL is set in this way
The SMB ACL is dropped, and an NFSv4.1 ACL is created.
UNIX permissions
The UNIX permissions are dropped, and an NFSv4.1 ACL is

created.
NFSv4.1 ACL
The existing NFSv4.1 ACL is dropped while leaving the setuid,

setgid, and sticky bit unaffected. A new NFSv4 ACL is created.
2. Display mode bits are created based on the user in the ACL with the least access.
How SMB clients set permissions for UNIX users of Infinite Volumes
On Infinite Volumes, SMB clients are able to set NTFS file permissions for UNIX users and groups.
SMB clients can work with permissions in the following ways:
Set permissions for any specific user or group in the NFS domain.
Set permissions for the NFS well-known principals OWNER@, GROUP@, and EVERYONE@.
Make any specific user or group in the NFS domain the owner of a file.
How file permissions on Infinite Volumes are displayed to clients

File permissions on an Infinite Volume are displayed to SMB and NFS clients irrespective of the
type of file permissions that are effective, including NFSv4.1 ACLs, NTFS permissions, and UNIX
permissions. The details vary, depending on the exact combination of client and effective file
permissions.
Permissions displayed on Windows clients
When a user on a Windows client views the security settings of a file or folder, the following
information is displayed:

Effective file
permissions
What NTFS file permissions are shown
UNIX permissions
Three entries for OWNER@, GROUP@, and EVERYONE@ (using the

NFSv4 well-known principals)
Three entries for the setuid, setgid, and sticky bit (using principals known
only to Data ONTAP). These entries are for informational purposes only.
NFSv4.1 ACL
Entries for each UNIX user and group, using either the UNIX user and
group names or the NFSv4 well-known principals OWNER@,
GROUP@, and EVERYONE@
Standard NTFS file permissions, except that some entries can represent
UNIX users and groups, including the NFSv4 well-known principals
OWNER@, GROUP@, and EVERYONE@
Permissions displayed when UNIX permissions are requested

When a user displays UNIX permissions by using a ls-l command on an NFSv3 or NFSv4.1 client,
the following information is displayed:
Effective file
permissions
What mode bits are shown
UNIX permissions
Standard UNIX permissions
NFSv4.1 ACL
Display mode bits, which represent the least access that is granted to the
requesting user based on the ACL.
Display mode bits, represent the most access that is granted to the
requesting user based on the NTFS file permissions.
Permissions displayed when NFSv4.1 ACLs are requested

When a user displays an ACL on an NFSv4.1 clientfor example, by using the ls -V command
the following information is displayed:
Effective file
permissions
What NFSv4.1 ACL is shown
UNIX permissions
Entries for OWNER@, GROUP@, and EVERYONE@
NFSv4.1 ACL
Standard NFSv4.1 ACL
Standard NFSv4.1 ACL but all Windows user and group names have been
mapped to UNIX user and group names
Note: Group mapping must be configured, or "nobody" appears as the
group name.
What happens when NFSv4.1 ACLs contain the user nobody

If NFSv4.1 clients display ACLs on files that have NTFS file permissions and the ACLs contain
access control entries (ACEs) for the user nobody, user or group mapping has failed. These ACLs
should not be saved, or the original Windows SID will be accidentally overwritten.
When NTFS file permissions are displayed as an NFSv4.1 ACL, the Windows user and group is
mapped to a UNIX user and group. If the mapping fails, the affected Windows SID appears as
"nobody@v4-id-domain", where v4-id-domain is the NFSv4 ID mapping domain.
The user or group mapping can fail for the following reasons:
Use of well-known Windows SIDs, which are translated to nobody instead of well-known NFS
principals
A Windows 2008 client has set permissions for a new well-known Windows principal that a
Windows 2003 domain controller cannot understand because the principal was introduced in
Windows 2008
Issues with the configuration of user mapping, group mapping, the default UNIX user, or the
default UNIX group
How the mixed state of an Infinite Volume affects its availability

Unlike other volumes, an Infinite Volume can go into a mixed state, which means its constituents are
not all in the same state. When an Infinite Volume is in a mixed state, you cannot perform operations
on it, and client access might be interrupted.
Causes of mixed state
Mixed state occurs whenever any constituent in the Infinite Volume has a state that differs from the
state of other constituents.
A mixed state typically occurs when most constituents are online but one constituent is offline. For
example, if you take an aggregate offline that contains constituents, you also cause the constituents to
go offline.
An Infinite Volume cannot be set to a mixed state. Mixed is a read-only state.
The impact of mixed state on administrative operations
When an Infinite Volume is in a mixed or restricted state, administrators cannot run operations on the
volume.
The impact of mixed state on client access
The impact of mixed state on client access depends on which constituent is unavailable, as explained
in the following table:

Type of constituent that is
unavailable
Impact on client access
The namespace constituent
Disruptive:
Data constituents
If the node that contains the namespace constituent is not

available, all client access is disrupted
If the node that contains the namespace constituent is
available, clients can continue accessing data that they
recently accessed but cannot access new data
Partially disruptive:
Data in the affected data constituents is unavailable

Data in other data constituents is available
A namespace mirror constituent No impact

How to respond to a mixed state
If an Infinite Volume is in a mixed state, the way that you respond depends on the cause.
You should view the state of all constituents to determine which one is in a restricted or offline state.
You can view the state of the constituents in an Infinite Volume by running the volume show
command with the -is-constituent true parameter.
If the mixed state is caused by a new namespace mirror constituent that is in restricted state while it
is first being initialized, you do not need to respond. You can wait until the SnapMirror initialization
finishes and the Infinite Volume automatically returns to an online state.
If a namespace constituent or data constituent is offline, you should investigate the cause and resolve
the issue.
Why an Infinite Volume's size appears smaller from a client

When you use a client to view the size of an entire Infinite Volume, the size appears smaller than the
size reported in Data ONTAP, because the namespace mirror constituents are not included in the size
that is displayed to clients.
For example, if an Infinite Volume has a size of 100 TB, which includes a 10 TB namespace mirror
constituent, the size that is displayed to a client is 90 TB instead of 100 TB.
Namespace mirror constituents are not included because they are data protection mirror copies of the
namespace consistent and therefore do not represent the space available for data. The namespace
constituent is included because it is part of the mechanism that is used to store data.
Clients can display the size of a volume in various ways. For example, a Windows user with a share
for the entire volume can view the share's properties, or a UNIX user can use the df command.
How locks work on Infinite Volumes

In Infinite Volumes, the support of locks is tied to the versions of the supported protocols. When you
display information about locks, the volume name, file path, and protocol can display unique settings
for Infinite Volumes.
Oplocks on Infinite Volumes
Traditional oplocks are supported on Infinite Volumes. They can be enabled on an SMB share.
Lease oplocks, which require SMB 2.x, are not supported on Infinite Volumes.
NFSv4.1 delegations
NFSv4.1 delegations are not supported on Infinite Volumes.
Output of locks on Infinite Volumes
When you display information about locks for files on an Infinite Volume by using the vserver
locks show command, the output shows the following values:
The volume name of a client-held lock, which is the name of the Infinite Volume data constituent
that holds the data of the locked file.
The file path of the lock, which is the path to the namespace constituent using the format /
Infinite_Volume_junction_path/optional_directories/filenamefor
example, /NS/Users/Bob/cifsfile.txt.
While a file is being removed or if the namespace constituent is unavailable, the path to the data
constituent might be displayedfor example, /.system/constituents/
1024_data0002/1647/P48BAAIEAIAAAAAAAAAAAI8NAAAWImIC.
The protocol, which can be crposix
A crposix lock indicates a transitory lock that is created internally by the Infinite Volume. If a
crposix lock persists for more than a minute, you should break the lock.
Related concepts
Managing file locks on page 92
Comparison of unified and mixed security styles

Understanding the differences between unified and mixed security styles can help you understand
how file permissions behave differently on FlexVol volumes that use mixed security style and
Infinite Volumes, which use unified security style.
Access checks
When a client tries to access a file, unified security style handles the access check the same way
except that unified security style also supports UNIX principals in NTFS file permissions.

The following table identifies whether the outcome is the same for mixed and unified security styles
when clients try to access a file:
When...
Of a file where
UNIX
permissions are
effective
Of a file that uses NTFS file permissions Of a file that has

an NFSv4.1 ACL
An NFSv3 or
NFSv4.1
client tries to
access a file
The outcome is
the same: the
UNIX credentials
are compared to
the UNIX
permissions.

Windows credential (obtained by using
user mapping) is compared to the
permissions.
the user's UNIX credential is compared
against any UNIX principals in the NTFS
file permissions.
The outcome is
the same: the
UNIX credentials
are compared to
the NFSv4.1
ACL.
An SMB
client tries to
access a file
The outcome is
the same: the
user's UNIX
credentials
(obtained by
using user name
mapping) is
compared to the
UNIX
permissions.

Windows credential is compared to the
permissions.
the user's UNIX credential (obtained by
using name mapping) is compared against
any UNIX principals in the NTFS file
permissions.
The outcome is
the same: the
user's UNIX user
credential
(obtained by
using user name
mapping) is
compared to the
NFSv4.1 ACL.
Ability to set permissions

The ability to set permissions is similar under both security styles, but unified security style has the
following benefits:
When an NFS client sets UNIX permissions on a file that uses NTFS file permissions, the
changes are merged into the NTFS file permissions.
When an SMB client sets NTFS permissions on a file, the permissions can include UNIX
principals.
The following table identifies whether the outcome is the same under mixed and unified security
styles when clients set file permissions:

When...

permissions are
effective

permissions
An NFSv3 or
NFSv4.1 client
sets UNIX
permissions by
changing
permissions
The outcome is the

same: the UNIX
permissions are
updated.
An NFSv3 or
NFSv4.1 client
sets UNIX
permissions by
changing the
owner or
group
The outcome is the

same: the owner and
An SMB client The outcome is similar:

sets NTFS
permissions
are set.
In addition, under
the NTFS file
permissions can
include UNIX users.
The outcome is the

same: ACEs for
OWNER@,
GROUP@, and
EVERYONE@ are
permissions become
modified or added in
effective.
the NFSv4.1 ACL.
(This occurs only if the
the
v4 ACL preserve
ACEs for OWNER@,
GROUP@, and
EVERYONE@ are
modified or added to the
(This occurs only if the v4
ACL preserve parameter is
enabled.)

NFSv4.1 ACL

permissions become
effective.
the Owner SID and the
Group SID of the existing
NTFS permissions are
updated. (This occurs only
if the v4 ACL preserve
The outcome is similar: The

new NTFS file permissions
replace the existing NTFS file
permissions.
security style, the NTFS file
permissions can include UNIX
users.
The outcome is the

same: the owner and

the NFSv4.1 ACL is
dropped and NTFS file
permissions are set.
In addition, under
the NTFS file
permissions can
include UNIX users.

When...

permissions are
effective
An NFSv4.1
The outcome is the
client sets an
same: an NFSv4.1
NFSv4.1 ACL ACL is set.

permissions

NFSv4.1 ACL
The outcome is the same: the

NTFS file permissions are
dropped, and an NFSv4.1 ACL
is set.
The outcome is the

same: the NFSv4.1
ACL is dropped and a
new NFSv4.1 ACL is
set.
Viewing permissions
The ability of clients to view permissions is significantly better under unified security style in the
following ways:
An SMB client can show the permissions of a file that has an NFSv4.1 ACL.
An NFSv4.1 client can display an equivalent NFSv4.1 ACL for a file that has NTFS file
permissions.
When an SMB client shows permissions of a file that uses NTFS file permissions, UNIX
principals can appear in the permissions.
The following table identifies whether the outcome is the same or different under mixed and unified
security styles when clients show file permissions:
When...


file permissions

NFSv4.1 ACL
An NFS
client shows
UNIX
permissions

The UNIX permissions are
displayed.

The display UNIX
permissions (that are
calculated each time an ACL
is set) are displayed.
The outcome is the

same: The display
mode bits (that are
calculated each time
an ACL is set) are
displayed.

When...


file permissions

NFSv4.1 ACL
An SMB
client shows
permissions

permissions are displayed
for Owner, Group, and
Everyone. The sticky bit,
setuid flag, and setgid flag
are also displayed if they are
set.
effective permissions are
also displayed for current
user.
permissions for OWNER@,
GROUP@, and
EVERYONE@ appear as
UNIX names when
displayed in Windows
Explorer.
The outcome is generally the The outcome is

same: the NTFS permissions different:
are displayed.
Under mixed
security style,
security style, UNIX users
permissions are
and groups can appear in the
displayed for
permissions.
Owner, Group, and
Everyone, and
effective
permissions are
displayed for
current user. The
sticky bit, setuid
flag, and setgid
flag are also
displayed if they
are set.
Under unified
security style,
effective NTFS
file permissions
are displayed.
All of the users
and groups are
UNIX principals.

When...


file permissions

NFSv4.1 ACL
An NFSv4.1
client
displays an
NFSv4.1
ACL

An NFSv4.1 ACL is
displayed, containing ACEs
for OWNER@, GROUP@,
and EVERYONE@.
The outcome is the

same: The NFSv4.1
ACL is displayed.
Under mixed security

style, an NFSv4.1 ACL
is displayed, containing
ACEs for OWNER@,
GROUP@, and
EVERYONE@.
Under unified security
style, an NFSv4 ACL is
displayed, containing
users and groups that
have been mapped from
Windows to UNIX.
(User and group
mappings must be
configured.)
How storage classes affect client access to Infinite Volumes

Client access is configured in the same way for an Infinite Volume regardless of whether it uses
storage classes. However, if an Infinite Volume uses storage classes, you must also create any users
and directories that you plan to use in the Infinite Volume's data policy.
An Infinite Volume with storage classes supports the same client access and requires the same client
access configuration as an Infinite Volume that does not use storage classes.
You can configure client access to an Infinite Volume with storage classes by using either the
command-line interface or OnCommand Workflow Automation. Even if you use OnCommand
Workflow Automation to create an Infinite Volume and configure client access, you can further
configure client access by using the command-line interface.
When you configure client access to an Infinite Volume that uses storage classes, you must configure
the following functionality before you import or activate the Infinite Volume's data policy:
Any users that you plan to use in rules that filter data based on file owner
Any directories that you plan to use in rules that filter data based on directory path
For more information about data policies, see the OnCommand Unified Manager Online Help.
495
Auditing NAS file access events on Vservers with

FlexVol volumes
Auditing for NAS file access events is a security measure that enables you to track and log CIFS and
NFS file and folder access events on objects stored on a Vserver with FlexVol volumes. This helps
you track potential security problems and provides evidence of any file access security breaches.
How auditing works

Before you plan and configure your auditing configuration, you should understand how auditing
works.
Basic auditing concepts

To understand auditing in Data ONTAP, you should be aware of some basic auditing concepts.
Staging files
The intermediate binary files on individual nodes where audit records are stored
prior to consolidation and conversion. Staging files are contained in staging
volumes.
Staging volume
A dedicated volume created by Data ONTAP to store staging files. There is one
staging volume per aggregate. Staging volumes are shared by all audit-enabled
Vservers with volumes in that particular aggregate. Staging volumes are a type
of system volume.
System volumes are FlexVol volumes that contain special metadata, such as
metadata for file services audit logs. System volumes are owned by the admin
Vserver and are visible across the cluster; therefore, there is no multi-tenancy for
staging volumes. Only cluster administrators can view staging volumes.
Additionally, cluster administrators can modify, or delete staging volumes, but
they cannot create staging volumes.
Consolidation
task
A task that takes the binary audit records from staging files across a Vserver's
member nodes on a per-Vserver basis and merges them in sorted chronological
order and then converts them to a user-readable event log format (XML). The
event logs are stored in the Vserver namespace's auditing log directory (as
configured by the administrator).
How the Data ONTAP auditing process works

The Data ONTAP auditing process is different than the Microsoft auditing process. Before you
configure auditing, you should understand how the Data ONTAP auditing process works.
Audit records are initially stored in binary staging files on individual nodes. If auditing is enabled on
a Vserver with FlexVol volumes, every member node maintains staging files for that Vserver.
Periodically, they are consolidated and converted to user-readable event logs, which are stored in the
Vserver's audit record log directory.
What happens when auditing is enabled on a Vserver
Auditing can only be enabled on Vservers with FlexVol volumes. When the storage administrator
enables auditing on a Vserver, the auditing subsystem checks to determine if staging volumes are
present. A staging volume must exist for each aggregate containing data volumes owned by the
Vserver. The auditing subsystem creates any needed staging volumes if they do not exist. The
auditing subsystem also completes other prerequisite tasks before auditing is enabled:
The auditing subsystem verifies that the log directory path is available and does not contain
symlinks. If the log directory path specified in the auditing configuration is not a valid path,
auditing configuration creation fails with the following error: The specified path "/
<path>" does not exist in the namespace belonging to Vserver
"<Vserver_name>". The auditing subsystem does not assign a default log file location.
Configuration creation fails if the directory exists but contains symlinks.

Auditing schedules the consolidation task.
After these tasks are completed successfully, auditing is enabled. The Vserver auditing configuration
and the log files persist across a reboot or if the NFS or CIFS servers are stopped or restarted.
What the triggers for event log consolidation are
Log consolidation is a scheduled task that runs on a routine basis until auditing is disabled. When
auditing is disabled, the final run of the consolidation task ensures that all the remaining logs are
consolidated.
How Data ONTAP guarantees auditing
Data ONTAP guarantees that all auditable file access events (as specified by configured audit policy
ACLS) are recorded, even if a node is unavailable. A requested file operation cannot complete until
the audit record for that operation is saved to the staging volume on persistent storage. By default,
auditing guarantee is on. If audit records cannot be committed to the disk in the staging files, either
because of insufficient space or because of other issues, client operations are denied.
Auditing NAS file access events on Vservers with FlexVol volumes | 497
What the consolidation process is when a node is unavailable
If a node containing volumes belonging to a Vserver with auditing enabled is unavailable, the
process for auditing consolidation depends on whether the node's SFO partner (or the HA partner in
the case of a two-node cluster) is available.
If the staging volume is available through the SFO partner, the staging volumes last reported from
the node are scanned, and consolidation proceeds normally.
If the SFO partner is not available, the task creates a partial log file.
When a node is not reachable, the consolidation task consolidates the audit records from the other
available nodes of that Vserver. But to identify that it is not complete, the task add the
suffix .partial to the consolidated file name.
After the unavailable node is available, the audit records in that node are consolidated with the
audit records from the other nodes at that point of time.
All audit records are preserved.
How audit event logs are rotated

Audit event log files are rotated when they reach a configured threshold log size or on a configured
schedule. When an event log file is rotated, the scheduled consolidation task first renames the active
converted file to a time-stamped archive file and creates a new active converted event log file.
What happens when auditing is disabled on a Vserver
When auditing is disabled on a Vserver, the consolidation task is triggered. All outstanding, recorded
audit records are logged in user-readable format before auditing is disabled. Existing event logs
stored in the event log directory are not deleted when auditing is disabled on a Vserver and are
available for viewing.
After all existing staging files for that Vserver are consolidated, the consolidation task is removed
from the schedule. Disabling a Vserver's auditing configuration does not remove the auditing
configuration. A storage administrator can reenable auditing at any time.
When staging volumes are created on aggregates

When an auditing configuration is created on at least one Vserver in the cluster, the auditing
subsystem creates staging volumes on all existing aggregates and on all new aggregates that are
created. You need to be aware of certain considerations when you enable auditing on the cluster.
Staging volume creation might fail due to non-availability of space in an aggregate. This might
happen if you create an auditing configuration and existing aggregates do not have enough space to
contain the staging volume. If this occurs on an aggregate hosting volumes that belong to a Vserver
on which auditing is enabled, data access is denied since there are no staging volumes on the
aggregate.
Auditing requirements and considerations

Before you configure and enable auditing on your Vserver with FlexVol volumes, you need to be
aware of certain requirements and considerations.
Before you can enable auditing on a Vserver, all nodes in the cluster must be running Data
ONTAP 8.2 or later.
Due to performance considerations, there is a limit on the number of audit-enabled Vservers on
the cluster.
The number of Vservers on which you can enable auditing is limited to 10 in a 2-node cluster.
This number scales linearly with additional nodes in the cluster. For example the limit for a 4node cluster is 20, and so on. If this limit is exceeded, there might be a significant increase in the
CPU utilization, which can affect other services in the system during load scenarios.
Auditing is not tied to CIFS or NFS licensing.
You can configure and enable auditing even if CIFS and NFS licenses are not installed on the
cluster.
NFS auditing supports security ACEs (type U).
For NFS auditing, there is no mapping between mode bits and audit ACEs.
When converting ACLs to mode bits, audit ACEs are skipped. When converting mode bits to
ACLs, audit ACEs are not generated.
The directory specified in the auditing configuration must exist.
If it does not exist, the command to create the auditing configuration fails.
The directory specified in the auditing configuration must not contain symbolic links.
If the directory specified in the auditing configuration contains symbolic links, the command to
create the auditing configuration fails.
Auditing is dependent on having available space in the staging volumes.
You must be aware of and have a plan for ensuring that there is sufficient space for the staging
volumes in aggregates that contain audited volumes.
Auditing is dependent on having available space in the volume containing the directory where
converted audit event logs are stored.
You must be aware of and have a plan for ensuring that there is sufficient space in the volumes
used to store event logs.
Related concepts
Planning the auditing configuration on page 501
What the supported audit event log formats are

XML viewing tools can be used to view the audit logs provided you have the XML schema and
information about definitions for the XML fields. For more information about obtaining the XML
schema and documents related to XML definitions, please contact technical support or your account
team.
CIFS file and folder access events that can be audited

Data ONTAP can audit certain CIFS file and folder access events. Knowing what access events can
be audited is helpful when interpreting results from the converted audit event logs.
The following CIFS file and folder access events can be audited:
Event ID
(EVT/EVTX)
Event
Description
Category
560/4656
Open Object/
Create Object
OBJECT ACCESS: Object (file or directory) File Access

open.
567/4663
Read Object/
OBJECT ACCESS: Object access attempt
File Access
Write Object/Get (read, write, get attribute, set attribute).
Object
Note: For this Event, Data ONTAP audits
Attributes/Set
only the first SMB read and first SMB
Object Attributes
write operation (success or failure) on an
object. This prevents Data ONTAP from
creating excessive log entries when a
single client opens an object and performs
many successive read or write operations
to the same object.
N/A/4664
Hard link
OBJECT ACCESS: An attempt was made to File Access

create a hard link.
N/A/N/A Data
ONTAP Event
ID 9999
Rename Object
OBJECT ACCESS: Object renamed. This is

a Data ONTAP event. It is not currently
supported by Windows as a single event.
File Access
N/A/N/A Data
ONTAP Event
ID 9998
Unlink Object
OBJECT ACCESS: Object unlinked. This is

a Data ONTAP event. It is not currently
supported by Windows as a single event.
File Access
Note: The object path printed in an audit record is the relative path from the root of the containing
volume. For example, consider the following volume information:
Vserver
--------vs1
vs1
Volume
-----------data
data1
Junction
Active
-------true
true
Junction Path
-----------------/data
/data/data1
Junction
Path Source
----------RW_volume
RW_volume

If a user accesses a file with the path /data/data1/dir1/file.txt, the path used in the
<ObjectName> tag in the XML event contained in the audit logs is /data1/dir1/file.txt.
Related concepts
NFS file and directory access events that can be audited

Data ONTAP can audit certain NFS file and directory access events. Knowing what access events
can be audited is helpful when interpreting results from the converted audit event logs.
You can audit the following NFS file and directory access events:
READ
OPEN
READDIR
WRITE
SETATTR
CREATE
LINK
OPENATTR
REMOVE
GETATTR
VERIFY
NVERIFY
RENAME
To reliably audit NFS RENAME events, you should set audit ACEs on directories instead of files
because file permissions are not checked for a RENAME operation if the directory permissions are
sufficient.
Related tasks
Configuring auditing for UNIX security style files and directories on page 511
How implementing auditing is a two-step process

Implementing auditing on file and folder access events is a two-step process. First you must create
and enable an auditing configuration on a Vserver with FlexVol volumes. Second, you must
configure audit policies on the files and folders that you want auditing to monitor. You can configure
audit policies to monitor both successful and failed access attempts.
After the Vserver auditing configuration is completed and auditing is enabled, both CIFS and NFS
audit polices can be configured. If the appropriate audit policies are configured, Data ONTAP can
monitor CIFS and NFS access events provided the CIFS or NFS servers are up. Each type has
different configuration requirements and audit capabilities.
Planning the auditing configuration

Before you configure auditing on Vservers with FlexVol volumes, you must understand which
configuration options are available and plan the values that you want to set for each option. This
information can help you configure the auditing configuration that meets your business needs.
An important part of planning the auditing configuration is determining how to rotate the
consolidated and converted audit logs. When you create an auditing configuration, there are two
methods for the logs. You can specify either one of the two methods when you configure auditing:
Rotate logs based on log size

By default, audit logs are rotated based on log size.
Rotate logs based on a schedule
If you choose to rotate the audit logs based on a schedule, you can schedule log rotation by using the
time-based rotation parameters in any combination. If you use time-based rotation, the -rotateschedule-minute parameter is mandatory. All other time-based rotation parameters are optional.
The rotation schedule is calculated by using all the time-related values. For example, if you specify
only the -rotate-schedule-minute parameter, the audit log files are rotated based on the
minutes specified on all days of the week, during all hours on all months of the year. If you specify
only one or two time-based rotation parameters (for example, -rotate-schedule-month and rotate-schedule-minutes), the log files are rotated based on the minute values that you
specified on all days of the week, during all hours, but only during the specified months. For
example, you can specify that the audit log is to be rotated during the months January, March, and
August on all Mondays, Wednesdays, and Saturdays at 10:30 a.m.
If you specify values for both -rotate-schedule-dayofweek and -rotate-schedule-day,
they are considered independently. For example, if you specify -rotate-schedule-dayofweek as
Friday and -rotate-schedule-day as 13, then the audit logs would be rotated on every Friday
and on the 13th day of the specified month, not just on every Friday the 13th.
You can use the following list of available auditing parameters to help you plan your configuration:

Type of information
Option
Required
Vserver name
Name of the Vserver on which to create the auditing
configuration.
The Vserver must already exist.
Yes
Log destination path

-destination text
Specifies where the consolidated audit logs are stored.
The path must already exist on the Vserver. If the path
is not valid, the audit configuration command fails.
Yes
Log file size limit

Determines the audit log file size limit.
By default, audit logs are rotated based on size.
The default audit log size is 100 MB.
No
-rotate-size
{integer[KB|MB|GB|TB|
PB]}
Log rotation schedule: Month

-rotate-schedule-month
chron_month
Determines the monthly schedule for rotating audit
logs.
Valid values are Januarythrough December, and
all.
For example, you can specify that the audit log is to be
rotated during the months January, March, and
August.
No
Log rotation schedule: Day of week

-rotate-scheduledayofweek
Determines the daily (day of week) schedule for
chron_dayofweek
rotating audit logs.
Valid values are Januarythrough December, and
all.
rotated on Tuesdays and Fridays, or during all the days
of a week.
No
Log rotation schedule: Day

-rotate-schedule-day
Determines the day of the month schedule for rotating chron_dayofmonth
the audit log.
Valid values range from 1 through 31.
rotated on the 10th and 20th days of a month, or all
days of a month.
No
Type of information
Option
Required
Log rotation schedule: Hour

-rotate-schedule-hour
chron_hour
Determines the hourly schedule for rotating the audit
log.
Valid values range from 0 (midnight) to 23 (11:00
p.m.). Specifying all rotates the audit logs every
hour.
rotated at 6 (6 a.m.) and 18 (6 p.m.).
No
Log rotation schedule: Minute

-rotate-scheduleDetermines the minute schedule for rotating the audit minute chron_minute
log.
Valid values range from 0 to 59.
rotated at the 30th minute.
No
Log files rotation limit

-rotate-limit integer
Determines how many log files to retain before
rotating the oldest log file out.
A value of 0 indicates that all the log files are retained.
The default value is 0.
For example, if you enter a value of 5, the last five
audit logs are retained.
No
Related concepts
How implementing auditing is a two-step process on page 500

Auditing requirements and considerations on page 498
What the supported audit event log formats are on page 498
CIFS file and folder access events that can be audited on page 499
Displaying information about audit policies applied to files and directories on page 512
Related tasks
Creating a file and directory auditing configuration on a Vserver on page 504

Related references
NFS file and directory access events that can be audited on page 500
Completing the auditing configuration worksheet

Use this worksheet to record the values that you need during the auditing configuration process. If a
parameter value is required, you need to determine what value to use for those parameters before you
configure auditing.
Type of information
Required
Include in Your values

configurat
ion
Vserver name
Yes
Yes
Log destination path
Yes
Yes
Log file size limit
No
Log rotation schedule: Month
No
Log rotation schedule: Day of

week
No
Log rotation schedule: Day
No
Log rotation schedule: Hour
No
Log rotation schedule: Minute
No
Log files rotation limit
No
Creating a file and directory auditing configuration on a

Vserver
Creating a file and directory auditing configuration on a Vserver includes understanding the available
configuration options, planning the configuration, and then configuring and enabling the
configuration. You can then display information about the auditing configuration to confirm that the
resultant configuration is the desired configuration.
Steps
1. Creating the auditing configuration on page 505

Before you can begin auditing file and directory events, you must create an auditing configuration
on the Vserver with FlexVol volumes.
2. Enabling auditing on a Vserver on page 506
After you finish setting up the auditing configuration, you must enable auditing on the Vserver.
3. Verifying the auditing configuration on page 506
After completing the auditing configuration, you should verify that auditing is configured properly
and is enabled.
Related concepts
Planning the auditing configuration on page 501

Managing auditing configurations on page 516
Related tasks
Deleting an auditing configuration on page 520
Creating the auditing configuration

Before you can begin auditing file and directory events, you must create an auditing configuration on
the Vserver with FlexVol volumes.
Step
1. Using the information in the planning worksheet, create the auditing configuration:
vserver audit create -vserver vserver_name -destination path
optional_parameters
For more information about the vserver audit create command, see the man page.
Examples
The following example creates an audit configuration for Vserver vs1. The logs are stored in
the /audit_log directory. The log file size limit is 200 MB. The logs are rotated when they
reach 200 MB in size:
cluster1::> vserver audit create -vserver vs1 -destination /audit_log rotate-size 200MB
The following example creates an audit configuration for Vserver vs1 using size-based
rotation. The log file size limit is 200 MB, and the log rotation limit is 5:
cluster1::> vserver audit create -vserver vs1 -destination /audit_log rotate-size 200MB -rotate-limit 5
The following example creates an audit configuration for Vserver vs1 using time-based
rotation. The audit logs are rotated monthly, at 12:30 p.m. on all days of the week:
cluster1::> vserver audit create -vserver vs1 -destination /audit_log rotate-size 200MB -rotate-schedule-month all -rotate-schedule-dayofweek all
-rotate-schedule-hour 12 -rotate-schedule-minute 30
Enabling auditing on a Vserver

After you finish setting up the auditing configuration, you must enable auditing on the Vserver.
Before you begin
The Vserver audit configuration must already exist.

Step
1. Enable auditing on the Vserver:

vserver audit enable -vserver vserver_name
Example
vserver audit enable -vserver vs1
Verifying the auditing configuration

After completing the auditing configuration, you should verify that auditing is configured properly
and is enabled.
Step
1. Verify the auditing configuration:

vserver audit show -instance -vserver vserver_name
Example
The following example displays in list form all audit configuration information for Vserver vs1.
The logs are stored in the /audit_log directory. The log file size limit is 200 MB, and the logs
are rotated when they reach 200 MB in size. Auditing is enabled:
vserver audit show -instance -vserver vs1
Vserver: vs1
Auditing state:
Log Destination Path:
Log File Size Limit:
Log Rotation Schedule: Month:
Log Rotation Schedule: Day of Week:
Log Rotation Schedule: Day:
Log Rotation Schedule: Hour:
Log Rotation Schedule: Minute:
Rotation Schedules:
Log Files Rotation Limit:
true
/audit_log
200MB
0
What to do if aggregates do not contain enough space for

staging volumes
Every aggregate that contains data volumes owned by audit-enabled Vservers must contain staging
volumes. An auditing configuration cannot be created on a Vserver unless Data ONTAP can create
staging volumes on every aggregate that contains volumes owned by the Vserver.
If there is insufficient space in the aggregate, the staging volume cannot be created when the auditing
configuration creation command is run and the command fails.
An administrator cannot manually create staging volumes. Instead, the administrator must increase
the size of any aggregates where there is insufficient space for the staging volume. The administrator
can then run the command to create the auditing configuration again. If there is sufficient space in all
aggregates that contain Vserver volumes, staging volumes are created and auditing configuration
creation succeeds.
Related concepts
Troubleshooting auditing and staging volume space issues on page 521
Configuring audit policies on NTFS security-style files and

directories
Before you can audit file and directory operations, you must configure audit policies on the files and
directories for which you want to collect audit information. This is in addition to setting up and
enabling the audit configuration. You can configure NTFS audit policies by using the Windows
Security tab or by using the Data ONTAP CLI.
Related concepts
Limitations when using the CLI to set file and folder security on page 275
How security descriptors are used to apply file and folder security on page 275
CIFS file and folder access events that can be audited on page 499
Related tasks
Configuring NTFS Audit Policies using the Windows Security tab on page 508
Configuring NTFS Audit Policies using the Windows Security tab

You can configure audit policies on files and directories by using the Windows Security tab in the
Windows Properties window. This is the same method used when configuring audit polices on data
residing on a Windows client, which enables customers to use the same GUI interface that they are
accustomed to using.
Before you begin
Auditing must be configured on the Vserver that contains the data to which you are applying SACLs.
About this task
Configuring NTFS audit policies is done by adding entries to NTFS system access control lists
(SACLs) that are associated with an NTFS security descriptor. The security descriptor is then applied
to NTFS files and directories. These tasks are automatically handled by the Windows GUI. The
security descriptor can contain discretionary access control lists (DACLs) for applying file and folder
access permissions, system access control lists (SACLs) for file and folder auditing, or both SACLs
and DACLs.
You can set NTFS audit policies for auditing access on individual files and folders using the
Windows Security tab in the Windows Properties window by completing the following steps on a
Windows host:
Steps
2. Complete the Map Network Drive box:
b) In the Folder box, type the CIFS server name that contains the share holding the data you
would like to audit and the name of the share.
Example
CIFS server name.
c) Click Finish.
3. Select the file or directory for which you want to enable auditing access.
4. Right-click on the file or directory, and select Properties.
6. Click Advanced.
7. Select the Auditing tab.
If you want to....
Do the following
Set up auditing for a new

user or group
a. Click Add.
b. In the Enter the object name to select box, type the name of the user or
grout that you want to add.
c. Click OK.
Remove auditing from a

user or group
a. In the Enter the object name to select box, select the user or group that
you want to remove.
b. Click Remove.
c. Click OK.
d. Skip the rest of this procedure.
Change auditing for a user

or group
a. In the Enter the object name to select box, select the user or group that
you want to change.
b. Click Edit.
c. Click OK.
If you are setting up auditing on a user or group or changing auditing on an existing user or
group, the Auditing Entry for <object> box opens.
9. In the Apply to box, select how you want to apply this auditing entry.
You can select one of the following:
This folder, subfolders and files

This folder and subfolders
This folder only
This folder and files
Subfolders and files only
Subfolders only
Files only
If you are setting up auditing on a single file, the Apply to box is not active. The Apply to
defaults to This object only.
Note: Since auditing takes Vserver resources, select only the minimal level that provides the
auditing events that meet your security requirements.

10. In the Access box, select what you want audited and whether you want to audit successful events,
failure events or both.
To audit successful events, select the Success box.

To audit failure events, select the Failure box.
You can audit the following events:
Full control
Traverse folder / execute file
List folder / read data
Read attributes
Read extended attributes
Create files / write data
Create folders / append data
Write attributes
Write extended attributes
Delete subfolders and files
Delete
Read permissions
Change permissions
Take ownership
Note: Select only the actions that you need to monitor to meet your security requirements. For
more information on these auditable events, see your Windows documentation.

11. If you do not want the auditing setting to propagate to subsequent files and folders of the original
container, select Apply these auditing entries to objects and/or containers within this
container only box.
12. Click Apply.
13. After you finish adding, removing, or editing auditing entries, click OK.
The Auditing Entry for <object> box closes.
14. In the Auditing box, select the inheritance settings for this folder.
You can choose one of the following:
Select the Include inheritable auditing entries from this object's parent box.
Select the Replace all existing inheritable auditing entries on all descendants with
inheritable auditing entries from this object box.
Select both boxes.
Select neither box.
If you are setting SACLs on a single file, the Replace all existing inheritable auditing entries
on all descendants with inheritable auditing entries from this object box is not present in the
Auditing dialog box.
Note: Select only the minimal level that provides the auditing events that meet your security
requirements.
15. Click OK.

The Auditing box closes.
How to configure NTFS audit policies using the Data ONTAP CLI
You can configure audit policies on files and folders using the Data ONTAP CLI. This enables you
to configure NTFS audit policies without needing to connect to the data using a CIFS share on a
Windows client.
You can configure NTFS audit policies by using the vserver security file-directory
command family.
You can only configure NTFS SACLs using the CLI. Configuring NFSv4 SACLs is not supported
with this Data ONTAP command family. See the man pages for more information about using these
commands to configure and add NTFS SACLs to files and folders.
Configuring auditing for UNIX security style files and

directories
You configure auditing for UNIX security style files and directories by adding audit ACEs to
NFSv4.x ACLs. This allows you to monitor certain NFS file and directory access events for security
purposes.
About this task
For NFSv4.x, both discretionary and system ACEs are stored in the same ACL. They are not stored
in separate DACLs and SACLs. Therefore, you must exercise caution when adding audit ACEs to an
existing ACL to avoid overwriting and losing an existing ACL. The order in which you add the audit
ACEs to an existing ACL does not matter.
Steps
1. Retrieve the existing ACL for the file or directory by using the nfs4_getfacl or equivalent
command.
For more information about manipulating ACLs, see the man pages of your NFS client.
2. Append the desired audit ACEs.
3. Apply the updated ACL to the file or directory by using the nfs4_setfacl or equivalent
command.
Related concepts

Related references
NFS file and directory access events that can be audited on page 500
Displaying information about audit policies applied to files

and directories
Displaying information about audit policies applied to files and directories enables you to verify that
you have the appropriate system access control lists (SACLs) set on specified files and folders.
Displaying information about audit policies using the Windows Security tab
You can display information about audit policies that have been applied to files and directories by
using the Security tab in the Windows Properties window. This is the same method used for data
residing on a Windows server, which enables customers to use the same GUI interface that they are
accustomed to using.
About this task
To display information about SACLs that have been applied to NTFS files and folders, complete the
following steps on a Windows host.
Steps
2. Complete the Map Network Drive dialog box:
b) In the Folder box, type the IP address or CIFS server name of the Vserver containing the
share that holds both the data you would like to audit and the name of the share.
Example
CIFS server name.
c) Click Finish.
3. Select the file or directory for which you display auditing information.
4. Right-click on the file or directory, and select Properties.
6. Click Advanced.
7. Select the Auditing tab.
8. Click Continue.
The Auditing box opens. TheAuditing entries box displays a summary of users and groups that
have SACLs applied to them.
9. In the Auditing entries box select the user or group whose SACL entries you want displayed.
10. Click Edit.
The Auditing entry for <object> box opens.
11. In the Access box, view the current SACLs that are applied to the selected object.
12. Click Cancel to close the Auditing entry for <object> box.
13. Click Cancel to close the Auditing box.

using the CLI
You can display information about NTFS audit policies on FlexVol volumes, including what the
security styles and effective-security styles are, what permissions are applied, and information about
About this task
optional parameters to display information only about file and directory security that matches the
specified parameters:
Optional parameter
Description
-fields
fieldsname, ...
-instance
-volume-name
volume_name

taken as default.
-share-name
share_name

Optional parameter
Description
-lookup-names
{true|false}
-expand-mask
{true|false}

Displays information where the hexadecimal bit mask entry is set to one
of the following:
expanded form.
collapsed form.
-security-style
{unix|ntfs|mixed|
unified}
release.
-effective-style
{unix|ntfs|mixed|
unified}
release.
-dos-attributes
hex_integer
attributes.
-text-dos-attr
text
DOS attributes.
-user-id
unix_user_ID
UNIX user ID.
-group-id
unix_group_ID
UNIX group ID.
Optional parameter
Description
-mode-bits
octal_permissions
-text-mode-bits
text
-acls system_acls

Owner, which applies only in the case of NTFS security descriptors.
Group, which applies only in the case of NTFS security descriptors.
Access Control Entries (ACEs) which includes both discretionary
access control entries (ACEs) in the ACL.
Note: NTFS security-style volumes and qtrees use only NTFS system access control lists for audit
policies. Mixed security-style volumes and qtrees can contain some files and directories that are of
NTFS security style, which can have NTFS audit policies applied to them.
Step

optional_parameters
Example
The following example displays the audit policy information about the path /corp in Vserver
vs1. This NTFS-security-style path has a NTFS-effective security style. The NTFS security
descriptor contains both a SUCCESS and a SUCCESS/FAIL SACL entry:
vserver security file-directory show -vserver vs1 -path /corp
Vserver: vs1
File Path:
Security Style:
Effective Style:
DOS Attributes:
Unix User Id:
Unix Group Id:
Unix Mode Bits:
ACLs:
/corp
ntfs
ntfs
10
----D--0
0
777
rwxrwxrwx
Control:0x8014
SACL - ACEs

ALL-DOMAIN\Administrator-0x100081-OI|CI|SA|FA
DACL - ACEs
ALLOW-BUILTIN\Administrators-0x1f01ff-OI|CI
Managing auditing configurations

You can manage Vserver auditing configurations by enabling or disabling auditing, modifying
auditing configurations, displaying information about auditing configurations, and deleting auditing
configurations. You also need to understand what happens when reverting to a release where auditing
is not supported.
Related concepts
Troubleshooting auditing and staging volume space issues on page 521

What to do if aggregates do not contain enough space for staging volumes on page 507
Related tasks
Creating a file and directory auditing configuration on a Vserver on page 504
Enabling and disabling auditing on a Vserver

You can enable or disable auditing on a Vserver with FlexVol volumes. You might want to
temporarily stop file and directory auditing by disabling auditing. You can enable auditing at any
time (if an auditing configuration exists).
Before you begin
The Vserver auditing configuration must already exist before you enable auditing. Disabling auditing
does not delete the auditing configuration.
Steps
1. Perform the appropriate command:

If you want auditing to be...
Enabled
vserver audit enable -vserver vserver_name
Disabled
vserver audit disable -vserver vserver_name
2. Verify that auditing is in the desired state:

vserver audit show -vserver vserver_name
Examples
The following example enables auditing for Vserver vs1:
cluster1::> vserver audit enable -vserver vs1
cluster1::> vserver audit show -vserver vs1
Vserver
State Target Directory
----------- ------ ---------------------------vs1
true
/audit_log
The following example disables auditing for Vserver vs1:

cluster1::> vserver audit disable -vserver vs1
cluster1::> vserver audit show -vserver vs1
Vserver
----------- ------ ---------------------------vs1
false /audit_log
Displaying information about auditing configurations

You can display information about auditing configurations for Vservers with FlexVol volumes. The
information can help you determine whether the configuration is what you want in place for each
Vserver. The displayed information also enables you to verify whether an auditing configuration is
enabled.
About this task
You can display information about the auditing configuration by using the vserver audit show
command. You can display detailed information about auditing configurations on all Vservers or you
can customize what information is displayed in the output by specifying optional parameters. If you
do not specify any of the optional parameters, the following is displayed:
Vserver name to which the auditing configuration applies

The audit state, which can be true or false
If the audit state is true, auditing is enabled. If the audit state is false, auditing is disabled.
The target directory where the auditing subsystem stores consolidated and converted audit logs
You can specify one of the following three, mutually exclusive optional parameters. You can also
specify one or more of the remaining optional parameters, which enables you display only the
auditing information that you want to see:

Mutually exclusive
optional parameter
Description
-fields
fieldsname, ...
You can specify this parameter to display on the fields that you specify.
You can use this parameter either alone or in combination with other
optional parameters.
-instance
Displays detailed information about all auditing configurations.

-log-save-details
Displays the following information about all the Vservers:
Vserver name
Rotation file size
Rotation schedules
Rotation limit
You can specify one or more of the following optional parameters:
-state {true | false}
-destination text
-rotate-size {integer[KB|MB|GB|TB|PB]}
-rotate-schedule-month chron_month
-rotate-schedule-dayofweek chron_dayofweek
-rotate-schedule-day chron_dayofmonth
-rotate-schedule-hour chron_hour
-rotate-schedule-minute chron_minute
-rotate-schedule-description text
-rotate-limit integer
Step
1. Display information about the auditing configuration by using the vserver audit show
command.
For more information about using the command, see the man pages.
Examples
The following example displays the name, audit state, and target directory for all Vservers:
cluster1::> vserver audit show
Vserver
----------- ------ --------------------vs1
false /audit_log
The following example displays Vserver names and details about the audit log for all
Vservers:
cluster1::> vserver audit show -log-save-details
Rotation
Vserver
File Size Rotation Schedule
----------- --------- -----------------------vs1
100MB
-
Rotation
Limit
-------0
The following example displays, in list form, all audit configuration information about all
Vservers:
cluster1::> vserver audit show -instance
Vserver:
Auditing state:
Log Destination Path:
Log File Size Limit:
Log Rotation Schedule: Month:
Log Rotation Schedule: Day of Week:
Log Rotation Schedule: Day:
Log Rotation Schedule: Hour:
Log Rotation Schedule: Minute:
Rotation Schedules:
Log Files Rotation Limit:
vs1
true
/audit_log
100MB
0
Commands for modifying auditing configurations

If you want to change a Vserver's auditing setting, you can modify the current configuration at any
time.
If you want to...
Modify the log destination path
Use this command...

vserver audit modify with the -destination
parameter
Enabling automatic saves based on
internal log file size
vserver audit modify with the -rotate-size
parameter
Enabling automatic saves based on a time vserver audit modify with the -rotateinterval
schedule-month, -rotate-schedule-dayofweek,
-rotate-schedule-day, -rotate-schedulehour, and -rotate-schedule-minute parameters

If you want to...
Use this command...
Specifying the maximum number of

saved log files
vserver audit modify with the -rotate-limit
parameter
See the man page for the vserver audit modify command for more information.
Deleting an auditing configuration

In you no longer want to audit file and directory events on a Vserver and do not want to maintain an
auditing configuration on the Vserver, you can delete the auditing configuration.
Steps
1. Disable the auditing configuration:

vserver audit disable -vserver vserver_name
Example
vserver audit disable -vserver vs1
2. Delete the auditing configuration:

vserver audit delete -vserver vserver_name
Example
vserver audit delete -vserver vs1
What the process is when reverting

If the cluster administrator plans to revert the cluster to a Data ONTAP release that does not support
auditing and you have audit-enabled Vservers, you should be aware of the process Data ONTAP
follows when reverting.
Prior to revert, Data ONTAP consolidates and converts all auditing logs in the staging files for all
Vservers.
All converted audit logs are stored in the event log directory location specified in the auditing
configuration for each audit-enabled Vserver.
The converted event logs are available post-revert.
During the revert, each file that has an NFSv4.x ACL is checked to determine whether the ACL
contains an audit ACE.
If it does, the complete ACL is dropped.
The revert process disables auditing on all Vservers.
There is no need to manually disable auditing on audit-enabled Vservers.
The revert process deletes all staging volumes.
There is no need to manually delete staging volumes.
Related tasks
Enabling and disabling auditing on a Vserver on page 516

Deleting an auditing configuration on page 520
Troubleshooting auditing and staging volume space issues

Issues can arise when there is insufficient space on either the staging volumes or on the volume
containing the audit event logs. If there is insufficient space, new audit records cannot be created,
which prevents clients from accessing data, and access requests fail. You should know how to
troubleshoot and resolve these volume space issues.
Related concepts
What to do if aggregates do not contain enough space for staging volumes on page 507
How to troubleshoot space issues related to the event log volumes

If volumes containing event log files run out of space, auditing cannot convert log records into log
files. This results in client access failures. You need to know how to troubleshoot space issues related
to event log volumes.
Vserver and cluster administrators can determine whether there is insufficient volume space by
displaying information about volume and aggregate usage and configuration.
If there is insufficient space in the volumes containing event logs, Vserver and cluster
administrators can resolve the space issues by either removing some of the event log files or by
increasing the size of the volume.
Note: If the aggregate that contains the event log volume is full, then the size of the aggregate
must be increased before you can increase the size of the volume. Only a cluster administrator
can increase the size of an aggregate.
The destination path for the event log files can be changed to a directory on another volume by
modifying the auditing configuration.
For more information about viewing information about volumes and increasing volume size, see the
For more information about viewing information about aggregates and managing aggregates, see the
Clustered Data ONTAP Physical Storage Management Guide.
How to troubleshoot space issues related to the staging volumes (cluster

administrators only)
If any of the volumes containing staging files for a Vserver runs out of space, auditing cannot write
log records into staging files. This results in client access failures. To troubleshoot this issue, a

cluster administrator needs to determine whether any of the staging volumes used in a Vserver are
full by displaying information about volume usage.
If the volume containing the consolidated event log files has sufficient space but there are still client
access failures due to insufficient space, then the staging volumes might be out of space. The Vserver
administrator must contact the cluster administrator to determine whether the staging volumes that
contain staging files for the Vserver have insufficient space. The auditing subsystem generates an
EMS event if auditing events cannot be generated due to insufficient space in a staging volume. The
following message is displayed: No space left on device. Only the cluster administrator can
view information about staging volumes.
If there is insufficient space in the staging volumes, the cluster administrators can resolve the space
issues by increasing the size of the volume.
Note: If the aggregate that contains the staging volume is full, then the size of the aggregate must
be increased before the cluster administrator can increase the size of the volume. Only a cluster
administrator can increase the size of an aggregate.
For more information about viewing information about volumes and increasing volume size, see the
For more information about viewing information about aggregates and managing aggregates, see the
Clustered Data ONTAP Physical Storage Management Guide.
523
Using FPolicy for file monitoring and management

on Vservers with FlexVol volumes
FPolicy is a file access notification framework that is used to monitor and manage file access events
on Vservers with FlexVol volumes.
The framework generates notifications that are sent to either external FPolicy servers or to Data
ONTAP. FPolicy supports event notifications for files and directories that are accessed using NFS
and CIFS.
Note: FPolicy is not supported on Vserver with Infinite Volume.
How FPolicy works

Before you plan and create your FPolicy configuration, you should understand the basics of how
FPolicy works.
What the two parts of the FPolicy solution are

There are two parts to an FPolicy solution. There is the Data ONTAP FPolicy framework that
manages activities on the cluster and sends notifications to external FPolicy servers and there are
external FPolicy servers that process notifications sent by Data ONTAP FPolicy.
The Data ONTAP framework creates and maintains the FPolicy configuration, monitors file events,
and sends notifications to external FPolicy servers. Data ONTAP FPolicy provides the infrastructure
that allows communication between external FPolicy servers and Vserver nodes.
The FPolicy framework connects to external FPolicy servers and sends notifications for certain file
system events to the FPolicy servers when these events occur as a result of client access. The external
FPolicy servers process the notifications and send responses back to the node. What happens as a
result of the notification processing depends on the application and whether the communication
between the node and the external servers is asynchronous or synchronous.
What synchronous and asynchronous communications are

FPolicy sends notifications to external FPolicy servers via the FPolicy interface. The notifications are
sent either in synchronous or asynchronous mode. The notification mode determines what Data
ONTAP does after sending notifications to FPolicy servers.
Asynchronous
notifications
With asynchronous notifications, the node does not wait for a response from the
FPolicy server, which enhances overall throughput of the system. This type of
notification is suitable for applications where the FPolicy server does not require
that any action be taken as a result of notification evaluation. For example,
asynchronous notifications are used when the Vserver administrator wants to
monitor and audit file access activity.

Synchronous
notifications
When configured to run in synchronous mode, the FPolicy server must

acknowledge every notification before the client operation is allowed to
continue. This type of notification is used when an action is required based on
the results of notification evaluation. For example, synchronous notifications are
used when the Vserver administrator wants to either allow or deny requests
based on criteria specified on the external FPolicy server.
Synchronous and asynchronous applications

There are many possible uses for FPolicy applications, both asynchronous and synchronous.
Asynchronous applications are ones where the external FPolicy server does not alter access to files or
directories or modify data on the Vserver. Synchronous uses cases are ones where data access is
altered or data is modified by the external FPolicy server.
Asynchronous FPolicy applications include the following:
File access and audit logging

Storage resource management
Synchronous FPolicy applications include the following:
Quota management
File access blocking
File archiving and hierarchical storage management
Encryption and decryption services
Compression and decompression services
These applications are in no way all-encompassing, and by using the SDK for FPolicy,
implementation of other applications are possible.
Roles that cluster components play with FPolicy

The cluster, the contained Vservers, and data LIFs all play a role in an FPolicy implementation.
cluster The cluster contains the FPolicy management framework and maintains and manages
information about all FPolicy configurations in the cluster.
Vserver
An FPolicy configuration is defined at the Vserver level. The scope of the configuration
is the Vserver, and it only operates on Vserver resources. A Vserver configuration
cannot monitor and send notifications for file access requests that are made for data
residing on another Vserver.
FPolicy configurations can be defined on the admin Vserver. Once configurations are
defined on the admin Vserver, they can be seen and used in all Vservers.
data LIFs Connections to the FPolicy servers are made through data LIFs belonging to the
Vserver with the FPolicy configuration. The data LIFs used for these connections can
fail over in the same manner as data LIFs used for normal client access.
Using FPolicy for file monitoring and management on Vservers with FlexVol volumes | 525
How FPolicy on clustered Data ONTAP works with external FPolicy servers
After FPolicy is configured and enabled on the Vserver, FPolicy on clustered Data ONTAP runs on
every node on which the Vserver participates. FPolicy is responsible for establishing and maintaining
connections with external FPolicy servers, for notification processing, and for managing notifications
messages to and from FPolicy servers.
Additionally, as part of connection management, FPolicy has the following responsibilities:
Ensures that file notification flows through the correct LIF to the FPolicy server.
Ensures that when multiple FPolicy servers are associated with a policy, load balancing is done
when sending notifications to the FPolicy servers.
Attempts to reestablish the connection when a connection to an FPolicy server is broken.
Sends the notifications to FPolicy servers over an authenticated session.
How control channels are used for FPolicy communication

FPolicy initiates a control channel connection to an external FPolicy server from the data LIFs of
each node participating on a Vserver. FPolicy uses control channels for transmitting file
notifications; therefore, an FPolicy server might see multiple control channel connections based on
Vserver topology.
How privileged data access channels are used for synchronous communication
With synchronous use cases, the FPolicy server accesses data residing on the Vserver through a
privileged data access path. Access through the privileged path exposes the complete file system to
the FPolicy server. It can access data files to collect information, to scan files, read files, or write into
files.
Because the external FPolicy server can access the entire file system from the root of the Vserver
through the privileged data channel, the privileged data channel connection must be secure.
How FPolicy connection credentials are used with privileged data access channels
The FPolicy server makes privileged data access connections to cluster nodes by using a specific
Windows user credential that is saved with the FPolicy configuration. CIFS is the only supported
protocol for making a privileged data access channel connection.
If the FPolicy server requires privileged data access, the following conditions must be met:
A CIFS license must be enabled on the cluster.

The FPolicy server must run under the credentials configured in the FPolicy configuration.
When making a data channel connection, FPolicy uses the credential for the specified Windows user
name. Data access is made over the admin share ONTAP_ADMIN$.
What granting super user credentials for privileged data access means
Data ONTAP uses the combination of the IP address and the user credential configured in the
FPolicy configuration to grant super user credentials to the FPolicy server.
Super user status grants these privileges when the FPolicy server accesses data:
Avoid permission checks

The user avoids checks on files and directory access.
Special locking privileges
Data ONTAP allows read, write, or modify access to any file regardless of existing locks. If the
FPolicy server takes byte range locks on the file, it results in immediate removal of existing locks
on the file.
By-pass any FPolicy checks
Access does not generate any FPolicy notifications.
How FPolicy manages policy processing

There might be multiple FPolicy policies assigned to a Vserver; each with a different priority. To
create an appropriate FPolicy configuration on a Vserver, it is important to understand how FPolicy
manages policy processing.
Each file access request is initially evaluated to determine which policies are monitoring this event. If
it is a monitored event, information about the monitored event along with interested policies is
passed to FPolicy where it is evaluated. Each policy is evaluated in order of the assigned priority.
You should consider the following recommendations when configuring policies:
When you want a policy to always be evaluated before other policies, configure that policy with a
higher priority.
If the success of requested file access operation on a monitored event is a prerequisite for a file
request that is evaluated against another policy, give the policy that controls the success or failure
of the first file operation a higher priority.
For example, if one policy manages FPolicy file archiving and restore functionality and a second
policy manages file access operations on the online file, the policy that manages file restoration
must have a higher priority so that the file is restored before the operation managed by the second
policy can be allowed.
If you want all policies that might apply to a file access operation to be evaluated, give
synchronous policies a lower priority.
You can reorder policy priorities for existing policies by modifying the policy sequence number.
However, to have FPolicy evaluate policies based on the modified priority order, you must disable
and reenable the policy with the modified sequence number.
What the node-to-FPolicy server communication process is

To properly plan your FPolicy configuration, you should understand what the node-to-Fpolicy server
communication process is.
Every node that participates on a Vserver initiates a connection to an external FPolicy server using
TCP/IP. Connections to the FPolicy servers are set up using node data LIFs; therefore, a participating
node can set up a connection only if the node has an operational data LIF for the Vserver.
Each FPolicy Service Manager process on participating nodes attempts to establish a connection with
the external FPolicy server when the policy is enabled. It uses the IP address and port of the external
engine specified in the policy configuration.
The connection establishes an FPolicy control channel from each of the nodes participating on a
Vserver to the FPolicy server through the data LIF. In addition, if IPv4 and IPv6 data LIF addresses
are present on the same participating node, then FSM attempts to establish connections for both IPv4
and IPv6. Therefore, in a scenario where the Vserver extends over multiple nodes or if both IPv4 and
IPv6 addresses are present, the FPolicy server must be ready for multiple control channel setup
requests from the cluster after the FPolicy policy is enabled on a Vserver.
For example, if a Data ONTAP cluster has three nodesNode1, Node2, and Node3and Vserver
data LIFs are spread across only Node2 and Node3, control channels are initiated only from Node2
and Node3, irrespective of the distribution of data volumes. Say that Node2 has two data LIFsLIF1
and LIF2that belong to the Vserver and that the initial connection is from LIF1. If LIF1 fails, the
FPolicy Service Manager attempts to establish a control channel from LIF2.
Node1
Client N
Node2
Client M
LIF1 LIF2
Node3
FPolicy server
LIF3
Control channel setup
Time lines
Client File request
FPolicy Notification
Priviledged data access - Optional
Client File response
Client File request
FPolicy Response
FPolicy Notification
Priviledged data access - Optional
Client File response
FPolicy Response
Node without
VServer data LIF
Nodes with VServer data LIFs
How FPolicy manages external communication during LIF migration or failover

LIFs can be migrated to data ports in the same node or to data ports on a remote node.
When a data LIF fails over or is migrated, a new control channel connection is made to the FPolicy
server. FPolicy can then retry CIFS and NFS client requests that timed out, with the result that new
notifications are sent to the external FPolicy servers. The node rejects FPolicy server responses to
original, timed-out CIFS and NFS requests.
How FPolicy manages external communication during node failover
If the cluster node that hosts the data ports used for FPolicy communication fails, Data ONTAP
breaks the connection between the FPolicy server and the node.
The impact of cluster failover to the FPolicy server can be mitigated by configuring the LIF manager
to migrate the data port used in FPolicy communication to another active node. After the migration is
complete, a new connection is established using the new data port.
If the LIF manager is not configured to migrate the data port, the FPolicy server must wait for the
failed node to come up. After the node is up, a new connection is initiated from that node with a new
Session ID.
Note: The FPolicy server detects broken connections with the keep-alive protocol message. The
timeout for purging the session ID is determined when configuring FPolicy. The default keep-alive
timeout is two minutes.
How FPolicy services work across Vserver namespaces

Data ONTAP provides a unified Vserver namespace. Volumes across the cluster are joined together
by junctions to provide a single, logical file system. The FPolicy server is aware of the namespace
topology and provides FPolicy services across the namespace.
The namespace is specific to and contained within a Vserver; therefore, you can see the namespace
only from the Vserver context. Namespaces have the following characteristics:
A single namespace exists in a Vserver, with the root of the namespace being the root volume,
represented in the namespace as slash (/).
All other volumes have junction points below the root (/).
Volume junctions are transparent to clients.
A single NFS export can provide access to the complete namespace; otherwise, export policies
can export specific volumes.
CIFS shares can be created on the volume or on qtrees within the volume or on any directory
within the namespace.
The namespace architecture is flexible.
Examples of typical namespace architectures are as follows:
A namespace with a single branch off of the root

A namespace with multiple branches off of the root
A namespace with multiple unbranched volumes off of the root
FPolicy configuration types

There are two basic FPolicy configuration types. One configuration uses external FPolicy servers to
process and act upon notifications. The other configuration does not use external FPolicy servers;
instead, it uses the Data ONTAP internal, native FPolicy server for simple file blocking based on
extensions.
The notification is sent to the FPolicy server, which screens the request and
External FPolicy
server configuration applies rules to determine whether the node should allow the requested file
operation. For synchronous policies, the FPolicy server then sends a
response to the node to either allow or block the requested file operation.
The notification is screened internally. The request is allowed or denied
Native FPolicy
server configuration based on file extensions settings configured in the FPolicy scope.
When to create a native FPolicy configuration
Native FPolicy configurations use the Data ONTAP internal FPolicy engine to monitor and block file
operations based on the file's extension. This solution does not require external FPolicy servers.
Using a native file blocking configuration is appropriate when this simple solution is all that is
needed.
Native file blocking enables you to monitor any file operations that match configured operation and
filtering events and then deny access to files with particular extensions. This is the default
configuration.
This configuration provides a means to block file access based only on the file's extension. For
example, to block files that contain mp3 extensions, you configure a policy to provide notifications
for certain operations with target file extensions of mp3. The policy is configured to deny mp3 file
requests. When a client requests a file with an mp3 extension, the node denies access to the file, based
on the native file blocking configuration.
The following applies to native FPolicy configurations:
The same set of filters and protocols that are supported by server-based file screening are also
supported for native file blocking.
Native file blocking and server-based file screening applications can be configured at the same
time.
To do so, you can configure two separate FPolicy policies for the Vserver, with one configured
for native file blocking and one configured for FPolicy server-based file screening.
The native file blocking feature only screens files based on the extensions and not on the content
of the file.
In the case of symbolic links, native file blocking uses the file extension of the root file.
When to create a configuration that uses external FPolicy servers

FPolicy configurations that use external FPolicy servers to process and manage notifications provide
robust solutions for use cases where more than simple file blocking based on file extension is needed.
You should create a configuration that uses external FPolicy servers when you want to do such things
as monitor and record file access events, provide quota services, perform file blocking based on
criteria other than simple file extensions, provide data migration services using hierarchical storage
management applications, or provide a fine-grained set of policies that monitor only a subset of data
in the Vserver.
What the steps for setting up an FPolicy configuration are

Before FPolicy can monitor file access, an FPolicy configuration must be created and enabled on the
Vserver for which FPolicy services are required.
The process for setting up and enabling an FPolicy configuration on a Vserver is as follows:
1. Create an FPolicy external engine.
The FPolicy external engine identifies the external FPolicy servers that are associated with a
specific FPolicy configuration. If the internal native FPolicy engine is used to create a native
file-blocking configuration, you do not need to create an FPolicy external engine.
2. Create an FPolicy event.
An FPolicy event describes what the FPolicy policy should monitor. Events consist of the
protocols and file operations to monitor, and can contain a list of filters. Events use filters to
narrow the list of monitored events for which the FPolicy external engine must send notifications.
Events also specify whether the policy monitors volume operations.
3. Create an FPolicy policy.
The FPolicy policy is responsible for associating, with the appropriate scope, the set of events
that need to be monitored and for which of the monitored events notifications must be sent to the
designated external FPolicy server (or to the native engine if no external FPolicy servers are
configured). The policy also defines whether the FPolicy server is allowed privileged access to
the data for which it receives notifications. An FPolicy server needs privileged access to data if
the server needs to access the data. Typical use cases where privileged access is needed include
file blocking, quota management, and hierarchical storage management. The policy is where you
specify whether the configuration for this policy uses an external FPolicy server or the internal
native FPolicy server.
A policy specifies whether screening is mandatory. If screening is mandatory and all external
FPolicy servers are down or no response is received from the FPolicy servers within a defined
timeout period, then file access is denied.
A policy's boundaries are the Vserver. A policy cannot apply to more than one Vserver. However,
a Vserver can have multiple FPolicy policies, each with the same or different combination of
scope, event, and external server configurations.
4. Configure the policy scope.
The FPolicy scope determines which volumes, shares, or export-policies the policy acts on or
excludes from monitoring. A scope also determines which file extensions should be included or
excluded from FPolicy monitoring.
Note: Exclude lists take precedence over include lists.
5. Enable the FPolicy policy.

When the policy is enabled, the control channels and, optionally, the privileged data channels are
connected. The FPolicy engine on the nodes on which the Vserver participates begin monitoring
file and folder access and, for events that match configured criteria, sends notifications to the
FPolicy external servers (or to the native engine if no external FPolicy servers are configured).
Note: If the policy uses native file blocking, an external engine is not configured or associated
with the policy.
Requirements, considerations, and best practices for

configuring FPolicy
Before you create and configure FPolicy configurations on your Vservers with FlexVol volumes, you
need to be aware of certain requirements, considerations, and best practices for configuring FPolicy.
Ways to configure FPolicy

FPolicy features are configured either through the command line interface (CLI) or through APIs.
This guide uses the CLI to create, manage, and monitor an FPolicy configuration on the cluster.
Requirements for setting up FPolicy

Before you configure and enable FPolicy on your Vserver with FlexVol volumes, you need to be
aware of certain requirements.
All nodes in the cluster must be running a version of Data ONTAP that supports FPolicy.
If you are not using the Data ONTAP native FPolicy engine, you must have external FPolicy
servers installed.
The external FPolicy servers must be installed on a server accessible from the data LIFs of the
Vserver where FPolicy policies are enabled.
The IP address of the external FPolicy server must be configured as primary or secondary server
in the FPolicy policy external engine configuration.
If the external FPolicy servers access data over a privileged data channel, the following
requirements must be met:
CIFS must be licensed on the cluster.

Privileged data access is accomplished using SMB connections.
A user credential must be configured for accessing files over the privileged data channel.
The FPolicy server must run under the credentials configured in the FPolicy configuration.
The IP address of the external FPolicy server must be configured as primary or secondary
server in the FPolicy policy external engine configuration.
Best practices and recommendations when setting up FPolicy

When setting up FPolicy on Vservers with FlexVol volumes, you need to be familiar with
configuration best practices and recommendations to ensure that your FPolicy configuration provides
robust monitoring performance and results that meet your requirements.
FPolicy servers should be placed in close proximity to the cluster with high-bandwidth
connectivity to provide minimal latency and high-bandwidth connectivity.
The external engine should be configured with more than one FPolicy server to provide resiliency
and high availability of FPolicy server notification processing, especially if policies are
configured for synchronous screening.
It is recommended to disable the FPolicy policy before making any configuration changes.
For example, if you want to add or modify an IP address in the external engine configured for the
enabled policy, you should first disable the policy.
If you configure FPolicy to monitor FlexCache volumes, it is recommended that you do not
configure FPolicy to monitor read and get attr file operations on the FlexCache volumes.
This is because Data ONTAP needs to retrieve inode-to-path (I2P) data with these operations, and
this data cannot be retrieved from the FlexCache volume. Instead, the I2P request is forwarded to
the origin volume, with the result that the performance benefits from FlexCache are not realized
when FPolicy is used to monitor read and get attr operations on FlexCache volumes.
The cluster node-to-FPolicy server ratio should be optimized to ensure that FPolicy servers are
not overloaded, which can introduce latencies when the Vserver responds to client requests.
The optimal ratio depends on the application for which the FPolicy server is being used.
Important revert considerations

You must understand and act on some important revert considerations before reverting to a Data
ONTAP release that does not support FPolicy.
Before reverting to a version of Data ONTAP that does not support FPolicy, the following conditions
must be met:
Every file on which FPolicy servers set the offline bit must be either deleted or replaced with the
original files before disabling FPolicy and reverting to a version of Data ONTAP that does not
support FPolicy.
Note: If you do not replace the files with the offline bit set with the original files prior to
reverting, clients access the stub files instead of the files to which the stub refers.
FPolicy functionality must be disabled on the cluster by disabling every FPolicy policy on the
cluster.
Planning the FPolicy configuration

Before you create an FPolicy configuration, you must understand what is involved in each step of the
configuration. You need to decide what settings you need to use when performing the configuration
and record them in the planning worksheets.
You need to plan for the following configuration tasks:
Creating the FPolicy external engine

Creating the FPolicy policy event
Creating the FPolicy policy
Creating the FPolicy policy scope
FPolicy is supported on Vservers with FlexVol volumes. FPolicy is not supported on Vserver with
Infinite Volume.
Planning the external engine configuration

Before you configure the FPolicy external engine, you must understand what it means to create an
external engine and which configuration parameters are available. This information helps you to
determine which values to set for each parameter.
What it means to create an external engine
Creating the external engine means defining the information that FPolicy needs to make and manage
connections to the external FPolicy servers. The external engine configuration defines the following
configuration information:
Vserver name
Engine name
The IP addresses of the primary and secondary external FPolicy servers and the TCP port number
to use when making the connection to the external FPolicy servers
Whether the engine type is asynchronous or synchronous
How to authenticate the connection between the node and the external FPolicy server
If you choose to configure mutual SSL authentication, then you must also configure parameters
that provide SSL certificate information.
How to manage the connection (advanced privilege settings)
This includes parameters that define such things as timeout values, retry values, keep-alive
values, and maximum request values.
What the basic external engine parameters are

You can use the following table of basic FPolicy configuration parameters to help you plan your
configuration:

Type of information
Option
Vserver
Use this required parameter to specify the Vserver name that you want to
associate with this external engine.
Each FPolicy configuration is defined within a single Vserver. The
external engine, policy event, policy scope, and policy that combine
together to create an FPolicy policy configuration must all be associated
with the same Vserver.
-vserver
vserver_name
Engine name
-engine-name
engine_name
Use this required parameter to give a name to the external engine
configuration. You must specify the engine name later when you create the
FPolicy policy. This associates the external engine with the policy.
Primary FPolicy servers
-primary-servers
Use this required parameter to specify the primary external FPolicy servers IP_address,...
to which the node sends notifications for a given FPolicy policy. The value
is specified as a comma-delimited list of IP addresses.
If more than one primary server IP address is specified, every node on
which the Vserver participates creates a control connection to every
specified primary external FPolicy server at the time the policy is enabled.
If you configure multiple primary external FPolicy servers, notifications
are sent to the external FPolicy servers in a round-robin fashion.
Port number
Use this required parameter to specify the port number of the FPolicy
service.
-port integer
Secondary FPolicy servers

-secondaryservers
Use this parameter to specify the secondary external FPolicy servers to
IP_address,...
which to send file access events for a given FPolicy policy. The value is
specified as a comma-delimited list of IP addresses.
Secondary servers are used only when none of the primary servers are
reachable. Connections to secondary servers are established when the
policy is enabled, but notifications are sent to secondary servers only if
none of the primary servers are reachable. If you configure multiple
secondary servers, notifications are sent to the external FPolicy servers in a
round-robin fashion.
Type of information
Option
External engine type

Use this parameter to specify whether the external engine operates in
synchronous or asynchronous mode. By default, FPolicy operates in
synchronous mode.
When set to synchronous, file request processing sends a notification to
the external FPolicy server, but then does not continue until after receiving
a response from the external FPolicy server. At that point, request flow
either continues or processing results in denial, depending on whether the
response from the external FPolicy server permits the requested action.
When set to asynchronous, file request processing sends a notification to
the external FPolicy server, and then continues.
-extern-enginetype
external_engine_
type
SSL option for communication with external FPolicy server

Use this required parameter to specify the SSL option for communication
with the external FPolicy server. You can choose one of the options based
on the following information:
-ssl-option {noauth|server-auth|
mutual-auth}
When set to no-auth, no authentication takes place.

The communication link is established over TCP.
When set to server-auth, the Vserver authenticates the external
FPolicy server.
If you choose this value, before creating the FPolicy external engine,
you must install the public certificate of the certificate authority (CA)
that signed the FPolicy server certificate.
When set to mutual-auth, mutual authentication takes place between
the Vserver and the external FPolicy server; the Vserver authenticates
the FPolicy server, and the FPolicy server authenticates the Vserver.
If you choose this value, before creating the FPolicy external engine,
the administrator must install the public certificate of the CA that
signed the FPolicy server certificate along with the public certificate
and key file for authentication of the Vserver.
The public certificate of CA that is used to sign the FPolicy server

certificate is installed by using the security certificate install
command with the -type parameter set to client_ca. The private key
and public certificate required for authentication of the Vserver is installed
by using the security certificate install command with the type parameter set to server.
If you choose to configure mutual SSL authentication, then you must also
configure the -certificate-common-name, -certificate-serial,
and -certifcate-ca parameters.
The value for this

parameter can be one
of the following:
synchronous
asynchronous

Type of information
Option
Certificate FQDN or custom common name

Use this parameter to specify the certificate name used if SSL
authentication between the Vserver and the FPolicy server is configured.
You can specify the certificate name as an FQDN or as a custom common
name.
If you specify mutual-auth for the -ssl-option parameter, you must
specify a value for the -certificate-common-name parameter.
-certificatecommon-name text
Certificate serial number

Use this parameter to specify the serial number of the certificate used for
authentication if SSL authentication between the Vserver and the FPolicy
server is configured.
specify a value for the -certificate-serial parameter.
-certificateserial text
Certificate authority
Use this parameter to specify the CA name of the certificate used for
authentication if SSL authentication between the Vserver and the FPolicy
server is configured.
specify a value for the -certifcate-ca parameter.
-certifcate-ca
text
What the advanced external engine options are

You can use the following table of advanced FPolicy configuration parameters as you plan whether
to customize your configuration with advanced parameters. You use these parameters to modify
communication behavior between the cluster nodes and the external FPolicy servers:
Type of information
Option
-reqs-cancelTimeout for canceling a request

Used to specify the time interval in hours (h), minutes (m), or seconds (s) timeout integer[h|
m|s]
that the node waits for a response from the external FPolicy server.
If the timeout interval passes, the node sends a cancel request to the
FPolicy server. The node then sends the notification to an alternate
FPolicy server. This timeout helps in handling an FPolicy server that is not
responding, which can improve CIFS/NFS client response. Also, canceling
requests after a timeout period can help in releasing system resources
because the notification request is moved from a down/bad FPolicy server
to an alternate FPolicy server.
The range for this value is 0 through 100. If the value is set to 0, the
option is disabled and cancel request messages are not sent to the FPolicy
server. The default is 20s.
Timeout for aborting a request

Used to specify the timeout in hours (h), minutes (m), or seconds (s) for
aborting a request.
The range for this value is 0 through 200.
-reqs-aborttimeout integer[h|
Interval for sending status requests

Used to specify the interval in hours (h), minutes (m), or seconds (s) after
which a status request is sent to the FPolicy server.
The range for this value is 0 through 50. If the value is set to 0, the option
is disabled and status request messages are not sent to the FPolicy server.
The default is 10s.
-status-reqinterval
integer[h|m|s]
Maximum outstanding requests on the FPolicy server

Used to specify the maximum number of outstanding requests that can be
queued on the FPolicy server.
The range for this value is 1 through 10000. The default is 50.
-max-server-reqs
integer
Timeout for disconnecting a nonresponsive FPolicy server

Used to specify the time interval in hours (h), minutes (m), or seconds (s)
after which the connection to the FPolicy server is terminated. The
connection is terminated after the timeout period only if the FPolicy
server's queue contains the maximum allowed requests and no response is
received within the this timeout period. The maximum allowed number of
requests is either 50 (the default) or the number specified by the maxserver-reqs- parameter.
The range for this value is 1 through 100. The default is 60s.
-server-progresstimeout integer[h|
m|s]
m|s]

Type of information
Option
Interval for sending keep-alive messages to the FPolicy server

Used to specify the time interval in hours (h), minutes (m), or seconds (s)
at which keep-alive messages are sent to the FPolicy server. Keep-alive
messages detect half-open connections.
The range for this value is 10 through 600. If the value is set to 0, the
option is disabled and keep-alive messages are prevented from being sent
to the FPolicy servers. The default is 120s.
-keep-aliveintervalinteger[h|m|s]
Maximum reconnect attempts

Used to specify the maximum number of times the Vserver attempts to
reconnect to the FPolicy server after the connection has been broken.
The range for this value is 0 through 20. The default is 5.
-max-connectionretries integer
Completing the external engine configuration worksheet

You can use this worksheet to record the values that you need during the external engine
configuration process. If a parameter value is required, you need to determine what value to use for
those parameters before you configure the external engine.
Information for a basic external engine configuration
You should record whether you want to include each parameter setting in the external engine
configuration and then record the value for the parameters that you want to include.
Type of information
Required
Include
Vserver name
Yes
Yes
Engine name
Yes
Yes
Primary FPolicy servers
Yes
Yes
Port number
Yes
Yes
Secondary FPolicy servers
No
External engine type
No
SSL option for

communication with external
FPolicy server
Yes
Certificate FQDN or custom

common name
No
Certificate serial number
No
Yes
Your values
Type of information
Required
Certificate authority
No
Include
Your values
Information for advanced external engine parameters

To configure an external engine with advanced parameters, you must enter the configuration
command while in advanced privilege mode.
Type of information
Required
Timeout for canceling a

request
No
Include
Your values
Timeout for aborting a request No

Interval for sending status
requests
No
Maximum outstanding
No
requests on the FPolicy server
Timeout for disconnecting a
nonresponsive FPolicy server
No
Interval for sending keepalive messages to the FPolicy

server
No
Maximum reconnect attempts No
Planning the FPolicy event configuration

Before you configure FPolicy events, you must understand what it means to create an FPolicy event.
You must determine which protocols you want the event to monitor, which events to monitor, and
which event filters to use. This information helps you plan the values that you want to set.
What it means to create an FPolicy event
Creating the FPolicy event means defining information that the FPolicy Service Manager (FSM)
process needs to determine what file access operations to monitor and for which of the monitored
events notifications should be sent to the external FPolicy server. The FPolicy event configuration
defines the following configuration information:
Vserver name
Event name
Which protocols to monitor
FPolicy can monitor CIFS, NFSv3, and NFSv4 file access operations.
Which file operations to monitor

Not all file operations are valid for each protocol.
Which file filters to configure
Only certain combinations of file operations and filters are valid. Each protocol has its own set of
supported combinations.
Whether to monitor volume operations
Note: There is a dependency with three of the parameters (-protocol, -file-operations, filters). The following are the valid combinations for the three parameters:
You can specify the -protocol and -file-operations parameters.

You can specify all three of the parameters.
You can specify none of the parameters.
What the FPolicy event configuration contains

You can use the following list of available FPolicy event configuration parameters to help you plan
your configuration:
Type of information
Option
Vserver
Use this required parameter to specify the Vserver name that you want to
associate with this FPolicy event.
-vserver
vserver_name
Event name
-event-name
event_name
Use this required parameter to give a name to the FPolicy event
configuration. You must specify the event name later when you create the
FPolicy policy. This associates the FPolicy event with the policy.
Protocol
Use this parameter to specify which protocol to configure for the FPolicy
event. The list for -protocol can include one of the following values:
cifs
nfsv3
nfsv4
Note: If you specify -protocol, then you must specify a valid value
in the -file-operations parameter. As the protocol version
changes, the valid values might change.
-protocol protocol
Type of information
Option
File operations
Use this parameter to specify the list of file operations for the FPolicy
event.
The event checks the operations specified in this list from all client
requests using the protocol specified in the -protocol parameter. You
can list one or more file operations by using a comma-delimited list. The
list for -file-operations can include one or more of the following
values:
-file-operations
file_operations,...
close for file close operations

create for file create operations
create-dir for directory create operations
delete for file delete operations
delete_dir for directory delete operations
getattr for get attribute operations
link for link operations
lookup for lookup operations
open for file open operations
read for file read operations
write for file write operations
rename for file rename operations
rename_dir for directory rename operations
setattr for set attribute operations
symlink for symbolic link operations
Note: If you specify-file-operations, then you must specify a
valid protocol in the -protocol parameter.

Type of information
Option
Filters
Use this parameter to specify the list of filters for a given file operation
for the specified protocol. The values in the -filters parameter are
used to filter client requests. The list can include one or more of the
following:
-filters filter, ...
monitor-ads to filter the client request for alternate data stream

close-with-modification to filter the client request for close
with modification
close-without-modification to filter the client request for close
without modification
first-read to filter the client request for first read
first-write to filter the client request for first write
offline-bit to filter the client request for offline bit set
Setting this filter results in the FPolicy server receiving notification
only when offline files are accessed.
open-with-delete-intent to filter the client request for open
with delete intent
only when an attempt is made to open a file with the intent to delete it.
This is used by file systems when the FILE_DELETE_ON_CLOSE flag
is specified.
open-with-write-intent to filter client request for open with
write intent
only when an attempt is made to open a file with the intent to write
something in it.
write-with-size-change to filter the client request for write with
size change
Note: If you specify the -filters parameter, then you must also
specify valid values for the -file-operations and -protocol
parameters.
Is volume operation required

Use this parameter to specify whether volume operation monitoring is
required. The default is false.
-volume-operation
{true|false}
List of supported file operation and filter combinations that FPolicy can monitor for CIFS
When you configure your FPolicy event, you need to be aware that only certain combinations of file
operations and filters are supported for monitoring CIFS file access operations.
The list of supported file operation and filter combinations for FPolicy monitoring of CIFS file
access events is provided in the following table:
Supported file operations
Supported filters
close
monitor-ads, offline-bit, close-with-modification, close-withoutmodification
create
monitor-ads, offline-bit
create_dir
Currently no filter is supported for this file operation.
delete
delete_dir
getattr
offline-bit
open
monitor-ads, offline-bit, open-with-delete-intent, open-withwrite-intent
read
monitor-ads, offline-bit, first-read
write
monitor-ads, offline-bit, first-write, write-with-size-change
rename
rename_dir
setattr
List of supported file operation and filter combinations that FPolicy can monitor for NFSv3
operations and filters are supported for monitoring NFSv3 file access operations.
The list of supported file operation and filter combinations for FPolicy monitoring of NFSv3 file
Supported filters
create
offline-bit
create_dir
delete
offline-bit
delete_dir

Supported filters
link
offline-bit
lookup
offline-bit
read
offline-bit
write
offline-bit, write-with-size-change
rename
offline-bit
rename_dir
setattr
offline-bit
symlink
offline-bit
List of supported file operation and filter combinations that FPolicy can monitor for NFSv4
operations and filters are supported for monitoring NFSv4 file access operations.
The list of supported file operation and filter combinations for FPolicy monitoring of NFSv4 file
Supported filters
close
offline-bit
create
offline-bit
create_dir
delete
offline-bit
delete_dir
getattr
offline-bit
link
offline-bit
lookup
offline-bit
open
offline-bit
read
offline-bit
write
offline-bit, write-with-size-change
rename
offline-bit
rename_dir
setattr
offline-bit
Supported filters
symlink
offline-bit
Completing the FPolicy event configuration worksheet

You can use this worksheet to record the values that you need during the FPolicy event configuration
process. If a parameter value is required, you need to determine what value to use for those
parameters before you configure the FPolicy event.
You should record whether you want to include each parameter setting in the FPolicy event
Type of information
Required
Include
Vserver name
Yes
Yes
Event name
Yes
Yes
Protocol
No
File operations
No
Filters
No
Is volume operation required
No
Your values
Planning the FPolicy policy configuration

Before you configure the FPolicy policy, you must understand what it means to create an FPolicy
policy. You must understand what configuration options are available. You also need to understand
why you might want to attach more than one event to an FPolicy policy. This information helps you
as you determine what values that you want to set.
What it means to create an FPolicy policy
Creating the FPolicy policy means associating a Vserver, an FPolicy event, and an external engine to
an FPolicy policy. You also specify the following:
Whether mandatory screening is required for this policy.

Whether to use the Data ONTAP native external engine for simple file blocking or whether to
specify an external engine that is configured to use external FPolicy servers for more
sophisticated file blocking and file management.
Whether you want to associate more than one FPolicy event to the policy.
An event is specific to a protocol. You can use a single FPolicy policy to monitor file access
events for more than one protocol by creating an event for each protocol that you want the policy
to monitor, and then associating the events to the policy.
Whether you want the external FPolicy server to have privileged access to the monitored files and
folders by using a privileged data connection.

If you want to configure the policy to allow privileged access, you must also specify the user
name for the account that you want the external FPolicy server to use for privileged access.
After you create an FPolicy policy, you apply an FPolicy scope to the policy.
What the FPolicy policy configuration contains
You can use the following list of available FPolicy policy configuration parameters to help you plan
your configuration:
Type of information
Option
Vserver
Use this required parameter to specify the Vserver name on which you
want to create an FPolicy policy.
external engine, FPolicy event, FPolicy scope, and FPolicy policy that
combine together to create an FPolicy policy configuration must all be
associated with the same Vserver.
-vserver
vserver_name
Policy name
Use this required parameter to specify the name of the FPolicy policy.
The name can be up to 256 characters long and is a string that can only
contain any combination of ASCII-range alphanumeric characters (a
through z, A through Z, 0), through 9, _, and ..
-policy-name
policy_name
Event names
Use this parameter to specify a comma-delimited list of events to
associate with the FPolicy policy. The events must already exist.
-events
event_name, ...
External engine name

-engine
Use this parameter to specify the name of the external engine to associate engine_name
with the FPolicy policy. The external engine must already exist.
An external engine contains information required by the node to send
notifications to an external FPolicy server. The default value for this
parameter is native. This means that, if you do not specify a value for
the external engine, the default native external engine is used. The native
external engine is internal to Data ONTAP and is used if you want to
configure native file blocking and you do not want to use external FPolicy
servers. If you want to use the native external engine, you can either not
specify a value for this parameter or you can specify native as the value.
Type of information
Option
Is mandatory screening required

-is-mandatory
{
true|false}
Use this parameter to specify whether mandatory file access screening is
required.
This parameter specifies what action to take on a file access event in a
case when all primary and secondary servers are down or no response is
received from the FPolicy servers within a given timeout period. When set
to true, file access events are denied. When set to false, file access
events are allowed. The default is true.
Allow privileged access
Use this parameter to specify whether the FPolicy servers can have
privileged access to monitored data.
With this option set to yes, FPolicy servers can access files from the root
of the Vserver containing the monitored data using the privileged data
channel. The default is no.
-allowprivileged-access
{yes|no|}
Privileged user name

-privileged-username user_name
Use this parameter to specify the user name of the account the external
FPolicy servers use for privileged data access.
The value for this parameter should use the domain\user name format. If
-allow-privileged-access is set to no, any value set for this
parameter is ignored.
Completing the FPolicy policy worksheet
You can use this worksheet to record the values that you need during the FPolicy policy
configuration process. If a parameter value is required, you need to determine what value to use for
those parameters before you configure the FPolicy policy.
You should record whether you want to include each parameter setting in the FPolicy policy
Type of information
Required
Include
Vserver name
Yes
Yes
Policy name
Yes
Yes
Event names
Yes
Yes
External engine name
Yes
Yes
Is mandatory screening
required
No
Allow privileged access
No
Your values

Type of information
Required
Privileged user name
No
Include
Your values
Planning the FPolicy scope configuration

Before you configure the FPolicy scope, you must understand what it means to create a scope. You
must understand what the scope configuration contains. You also need to understand what the scope
rules of precedence are. This information can help you plan the values that you want to set.
What it means to create an FPolicy scope
Creating the FPolicy scope means defining the boundaries on which the FPolicy policy applies. The
Vserver is the basic boundary. When you create a scope for an FPolicy policy, you must define the
FPolicy policy to which it will apply, and you must designate to which Vserver you want to apply the
scope. There are a number of parameters that further restrict the scope within the specified Vserver.
You can restrict the scope by specifying what to include in the scope, or you can restrict the scope by
specifying what to exclude from the scope. After you apply a scope to an enabled policy, policy
event checks get applied to the scope defined by this command.
Notifications are generated for file access events where matches are found in the include options.
Notifications are not generated for file access events where matches are found in the exclude
options.
The FPolicy scope configuration defines the following configuration information:
Vserver name
Policy name
The shares to include or exclude from what gets monitored
The export policies to include or exclude from what gets monitored
The volumes to include or exclude from what gets monitored
The file extensions to include or exclude from what gets monitored
Whether to do file extension checks on directory objects
Note: There are special considerations for the scope for a cluster FPolicy policy. The cluster
FPolicy policy is a policy that the cluster administrator creates for the admin Vserver. If the cluster
administrator also creates the scope for that cluster FPolicy policy, a Vserver administrator cannot
create a scope for that same policy. However, if the cluster administrator does not create a scope
for the cluster FPolicy policy, then any Vserver administrator can create the scope for that cluster
policy. In the event that the Vserver administrator creates a scope for that cluster FPolicy policy,
the cluster administrator cannot subsequently create a cluster scope for that same cluster policy.
This is because the cluster administrator cannot override the scope for the same cluster policy.
What the scope rules of precedence are

The following rules of precedence apply to scope configurations:
When a share is included in the -shares-to-include parameter and the parent volume of the
share is included in the -volumes-to-exclude parameter, -volumes-to-exclude has
precedence over -shares-to-include.
When an export policy is included in the -export-policies-to-include parameter and the
parent volume of the export policy is included in the -volumes-to-exclude parameter, volumes-to-exclude has precedence over -export-policies-to-include.
An administrator can specify both -file-extensions-to-include and -fileextensions-to-exclude lists. The -file-extensions-to-exclude parameter is checked
first before the -file-extensions-to-include parameter is checked.
What the FPolicy scope configuration contains

You can use the following list of available FPolicy scope configuration parameters to help you plan
your configuration:
Note: When configuring what shares, export policies, volumes, and file extensions to include or
exclude from the scope, the include and exclude parameters can contain regular expressions and
can include metacharacters such as ? and *.
Type of information
Option
Vserver
Specifies the Vserver name on which you want to create an FPolicy
scope.
-vserver
vserver_name
Policy name
Specifies the name of the FPolicy policy to which you want to attach the
scope. The FPolicy policy must already exist.
-policy-name
policy_name
Shares to include
Specifies a comma-delimited list of shares to monitor for the FPolicy
policy to which the scope is applied.
-shares-to-include
share_name, ...
Shares to exclude
Specifies a comma-delimited list of shares to exclude from monitoring
for the FPolicy policy to which the scope is applied.
-shares-to-exclude
share_name, ...
Volumes to include
Specifies a comma-delimited list of volumes to monitor for the FPolicy
policy to which the scope is applied.
-volumes-toinclude
volume_name, ...

Type of information
Option
Volumes to exclude
Specifies a comma-delimited list of export policies to exclude from
monitoring for the FPolicy policy to which the scope is applied.
-volumes-toexclude
volume_name, ...
Export policies to include

Specifies a comma-delimited list of export policies to monitor for the
FPolicy policy to which the scope is applied.
-export-policiesto-include
export_policy_name
, ...
Export policies to exclude

Specifies a comma-delimited list of export policies to exclude from
-export-policiesto-exclude
export_policy_name
, ...
File extensions to include

Specifies a comma-delimited list of file extensions to monitor for the
FPolicy policy to which the scope is applied.
-file-extensionsto-include
file_extensions, ...
File extension to exclude

Specifies a comma-delimited list of file extensions to exclude from
-file-extensionsto-exclude
file_extensions, ...
Is file extension check on directory enabled

Specifies whether the file name extension checks apply to directory
objects as well. If this parameter is set to true, the directory objects are
subjected to the same extension checks as regular files. If this parameter
is set to false, the directory names are not matched for extensions and
notifications are sent for directories even if their name extensions do not
match.
-is-fileextension-checkon-directoriesenabled {true|
false|}
Completing the FPolicy scope worksheet

You can use this worksheet to record the values that you need during the FPolicy scope configuration
process. If a parameter value is required, you need to determine what value to use for those
parameters before you configure the FPolicy scope.
You should record whether you want to include each parameter setting in the FPolicy scope
Type of information
Required
Include
Vserver name
Yes
Yes
Policy name
Yes
Yes
Shares to include
No
Your values
Type of information
Required
Shares to exclude
No
Volumes to include
No
Volumes to exclude
No
Export policies to include
No
Export policies to exclude
No
File extensions to include
No
File extension to exclude
No
Is file extension check on

directory enabled
No
Include
Your values
Creating the FPolicy configuration

There are several steps you must perform to creating an FPolicy configuration. First, you must plan
your configuration. Then, you create an external engine, an FPolicy event, and an FPolicy policy.
You then create an FPolicy scope and attach it to the FPolicy policy, and then enable the FPolicy
policy.
FPolicy is supported on Vservers with FlexVol volumes. FPolicy is not supported on Vserver with
Infinite Volume.
Steps
1. Creating the FPolicy external engine on page 552

The first step to creating an FPolicy configuration is to create an external engine. The external
engine defines how FPolicy makes and manages connections to external FPolicy servers. If your
configuration uses the native external engine for simple file blocking, you do not need to
configure an external engine.
2. Creating the FPolicy policy event on page 552
As part of creating an FPolicy policy configuration, you need to create an Fpolicy event. You
associate the event with the FPolicy policy when it is created. An event defines which protocol to
monitor and which file access events to monitor and filter.
3. Creating the FPolicy policy on page 553
After creating an external engine and Fpolicy events, you create the FPolicy policy. The policy
associates an external engine and one or more events to the policy. The FPolicy policy also
specifies whether mandatory screening is required and whether the FPolicy servers have
privileged access to data on the Vserver.
4. Creating the FPolicy policy scope on page 553

After creating the FPolicy policy, you need to create an FPolicy scope. When creating the scope,
you associate the scope with an FPolicy policy. A scope defines the boundaries on which the
FPolicy policy applies. Scopes can include or exclude files based on shares, export policies,
volumes, and file extensions.
5. Enabling the FPolicy policy on page 554
After you are through configuring an FPolicy policy configuration, you enable the FPolicy policy.
Enabling the policy sets its priority and starts file access monitoring for the policy.
Creating the FPolicy external engine

The first step to creating an FPolicy configuration is to create an external engine. The external engine
defines how FPolicy makes and manages connections to external FPolicy servers. If your
configuration uses the native external engine for simple file blocking, you do not need to configure
an external engine.
Before you begin
The external engine worksheet should be completed.

Steps
1. Create the FPolicy external engine:

vserver fpolicy policy external-engine create -vserver-name vserver_name
-engine-name engine_name -primary-servers IP_address,... -port integer ssl-option {no-auth|server-auth|mutual-auth} optional_parameters
2. Verify the FPolicy external engine configuration:

vserver fpolicy policy external-engine show -vserver vserver_name
Creating the FPolicy policy event

As part of creating an FPolicy policy configuration, you need to create an Fpolicy event. You
associate the event with the FPolicy policy when it is created. An event defines which protocol to
monitor and which file access events to monitor and filter.
Before you begin
The FPolicy event worksheet should be completed.

Steps
1. Create the FPolicy event by using the following command:

vserver fpolicy policy event create -vserver-name vserver_name -eventname event_name optional_parameters
2. Verify the FPolicy event configuration:

vserver fpolicy policy event show -vserver vserver_name
Creating the FPolicy policy

After creating an external engine and Fpolicy events, you create the FPolicy policy. The policy
associates an external engine and one or more events to the policy. The FPolicy policy also specifies
whether mandatory screening is required and whether the FPolicy servers have privileged access to
data on the Vserver.
Before you begin
The FPolicy policy worksheet should be completed. If you plan on configuring the policy to use
external FPolicy servers, the external engine must exist. At least one FPolicy event that you plan on
associating with the FPolicy policy must exist.
Steps
1. Create the FPolicy policy by entering the following command:

vserver fpolicy policy create -vserver-name vserver_name -policy-name
policy_name -events event_name,... -engine engine_name
optional_parameters
2. Verify the FPolicy policy configuration:

vserver fpolicy policy show -vserver vserver_name
Creating the FPolicy policy scope

After creating the FPolicy policy, you need to create an FPolicy scope. When creating the scope, you
associate the scope with an FPolicy policy. A scope defines the boundaries on which the FPolicy
policy applies. Scopes can include or exclude files based on shares, export policies, volumes, and file
extensions.
Before you begin
The FPolicy scope worksheet must be completed. The FPolicy policy must exist with an associated
external engine (if the policy is configured to use external FPolicy servers) and must have at least one
associated FPolicy event.
Steps
1. Create the FPolicy scope by entering the following command:

vserver fpolicy policy scope create -vserver-name vserver_name -policyname policy_name optional_parameters
2. Verify the FPolicy scope configuration:

vserver fpolicy policy scope show -vserver vserver_name
Enabling the FPolicy policy

After you are through configuring an FPolicy policy configuration, you enable the FPolicy policy.
Enabling the policy sets its priority and starts file access monitoring for the policy.
Before you begin
The FPolicy policy must exist with an associated external engine (if the policy is configured to use
external FPolicy servers) and must have at least one associated FPolicy event. The FPolicy policy
scope must exist and must be assigned to the FPolicy policy.
About this task
The priority is used when multiple policies are enabled on the Vserver and more than one policy has
subscribed to the same file access event. Policies that use the native engine configuration have a
higher priority than policies for any other engine, regardless of the sequence number assigned to
them when enabling the policy.
Note: A policy cannot be enabled on the Admin Vserver.
Steps
1. Enable the FPolicy policy by entering the following command:

vserver fpolicy enable -vserver-name vserver_name -policy-name
policy_name -sequence-number integer
2. Verify that the FPolicy policy is enabled:

vserver fpolicy show -vserver vserver_name
Modifying FPolicy configurations

You can modify FPolicy configurations by modifying the elements that make up the configuration.
You can modify external engines, FPolicy events, FPolicy scopes, and FPolicy policies. You can also
enable or disable FPolicy policies. When you disable the FPolicy policy, file monitoring is
discontinued for that policy.
It is recommended to disable the FPolicy policy before modifying the configuration.
Commands for modifying FPolicy configurations

You can modify FPolicy external engines, events, scopes, and policies.
If you want to modify...
Use this command...
External engines
vserver fpolicy policy external-engine modify
Events
vserver fpolicy policy event modify
If you want to modify...
Use this command...
Scopes
vserver fpolicy policy scope modify
Policies
vserver fpolicy policy modify
See the man pages for the commands for more information.
Enabling or disabling FPolicy policies

You can enable FPolicy policies after the configuration is complete. Enabling the policy sets its
priority and starts file access monitoring for the policy. You can disable FPolicy policies if you want
to stop file access monitoring for the policy.
Before you begin
For enabling FPolicy policies, the FPolicy configuration must be completed.

About this task
The priority is used when multiple policies are enabled on the Vserver and more than one policy has
subscribed to the same file access event. Policies that use the native engine configuration have a
higher priority than policies for any other engine, regardless of the sequence number assigned to
them when enabling the policy. If you want to change the priority of an FPolicy policy, you must
disable the policy and then reenable it using the new sequence number.
Step

If you want to...
Enable an FPolicy policy vserver fpolicy enable -vserver-name vserver_name policy-name policy_name -sequence-number integer
Disable an FPolicy policy vserver fpolicy disable -vserver-name vserver_name policy-name policy_name
Displaying information about FPolicy configurations

You might want to display information about FPolicy configurations to determine whether each
Vserver's configuration is correct or to verify that an FPolicy policy configuration is enabled. You
can display information about external engines, FPolicy events, FPolicy scopes, and FPolicy policies.
How the show commands work

It is helpful when displaying information about the FPolicy configuration to understand how the
show commands work.
A show command without additional parameters displays information in a summary form.

Additionally, every show command has the same two mutually exclusive optional parameters, instance and -fields.
When you use the -instance parameter with a show command, the command output displays
detailed information in a list format. In some cases, the detailed output can be lengthy and include
more information than you need. You can use the -fields fieldname[,fieldname...]
parameter to customize the output so that it displays information only for the fields you specify. You
can identity which fields that you can specify by entering ? after the -fields parameter.
Note: The output of a show command with the -fields parameter might display other relevant
and necessary fields related to the requested fields.
Every show command has one or more optional parameters that filter that output and enable you to
narrow the scope of information displayed in command output. You can identity which optional
parameters are available for a command by entering ? after the show command.
The show command supports UNIX-style patterns and wildcards to enable you to match multiple
values in command-parameters arguments. For example, you can use the wildcard operator (*), the
NOT operator (!), the OR operator (|), the range operator (integer...integer), the less-than operator
(<), the greater-than operator (>), the less-than or equal to operator (<=), and the greater-than or
equal to operator (>=) when specifying values.
For more information about using UNIX-style patterns and wildcards, see the Using the Data
ONTAP command-line interface section of the Clustered Data ONTAP System Administration
Guide for Vserver Administrators.
Commands for displaying information about FPolicy configurations

You use the fpolicy show commands to display information about the FPolicy configuration,
including information about FPolicy external engines, events, scopes, and policies.
If you want to display
Use this command...
information about FPolicy...
External engines
vserver fpolicy policy external-engine show
Events
vserver fpolicy policy event show
Scopes
vserver fpolicy policy scope show
Policies
vserver fpolicy policy show
See the man pages for the commands for more information.
Displaying information about FPolicy policy status

You can display information about the status for FPolicy policies to determine whether a policy is
enabled, what external engine it is configured to use, what the sequence number is for the policy, and
to which Vserver the FPolicy policy is associated.
About this task
If you do not specify any parameter, the command displays the following information:
Vserver name
FPolicy policy name
FPolicy sequence number
FPolicy server status
In addition to displaying information about policy status for FPolicy policies configured on the
cluster or a specific Vserver, you can use command parameters to filter the command's output by
other criteria.
You can specify the -instance parameter to display detailed information about listed policies.
Alternatively, you can use the -fields parameter to display only the indicated fields in the
command output, or -fields ? to determine what fields you can use.
Step
1. Display filtered information about FPolicy policy status by using the appropriate command:
If you want to display status information
about policies...
On the cluster
vserver fpolicy show
That have the specified status
vserver fpolicy show -status {on|off}
vserver fpolicy show -vserver

vserver_name
With the specified policy name
vserver fpolicy show -policy-name

policy_name
With the specified sequence number
vserver fpolicy show -sequence-number

integer
That use the specified external engine
vserver fpolicy show -engine

engine_name
For more information about the commands, see the man pages.
The following example displays the information about FPolicy policies on the cluster:

cluster1::> vserver fpolicy show
Vserver
Policy
Sequence
Number
----------- ---------------------- -------FPolicy
cserver_policy
vs1
v1p1
vs1
v1p2
vs1
v1p3
vs1
cserver_policy
vs2
v1p1
3
vs2
v1p2
1
vs2
cserver_policy
2
Status Engine
-----off
off
off
off
off
on
on
on
--------eng1
eng2
native
native
eng1
native
eng3
eng1
Displaying information about enabled policies

You can display information about enabled FPolicy policies to determine what external engine it is
configured to use, what the priority is for the policy, and to which Vserver the FPolicy policy is
associated.
About this task
If you do not specify any parameters, the command displays the following information:
Vserver name
FPolicy policy name
FPolicy priority
You can use command parameters to filter the command's output by specified criteria.
Step
1. Display information about enabled FPolicy policies by using the appropriate command:
If you want to display information about
enabled policies...
On the cluster
vserver fpolicy show-enabled
vserver fpolicy show-enabled -vserver

vserver_name
With the specified policy name
vserver fpolicy show-enabled -policyname policy_name
With the specified sequence number
vserver fpolicy show-enabled -priority

integer
For more information about the command, see the man pages.
The following example displays the information about enabled FPolicy policies on the cluster:
cluster1::> vserver fpolicy show-enabled
Vserver
Policy Name
Priority
-----------------vs1
vs1
vs1
vs1
---------native
native
2
4
------------------------pol_native
pol_native2
pol1
pol2
Managing FPolicy server connections

You can manage your FPolicy server connections by connecting to external FPolicy servers,
disconnecting from external FPolicy servers, or displaying information about connections and
connection status.
Connecting to external FPolicy servers

To enable file processing, you might need to manually connect to an external FPolicy server if the
connection has previously been terminated. A connection is terminated after the server timeout is
reached or due to some error. Alternatively, the administrator might manually terminate a
connection.
About this task
If a fatal error occurs, the connection to the FPolicy server can be terminated. After resolving the
issue that caused the fatal error, you must manually reconnect to the FPolicy server.
Steps
1. Connect to the external FPolicy server by using the vserver fpolicy engine-connect
command.
2. Verify that the external FPolicy server is connected by using the vserver fpolicy showengine command.
Disconnecting from external FPolicy servers

You might need to manually disconnect from an external FPolicy server. This might be desirable if
the FPolicy server has issues with notification request processing or if you need to perform
maintenance on the FPolicy server.
Steps
1. Disconnect from the external FPolicy server by using the vserver fpolicy enginedisconnect command.

2. Verify that the external FPolicy server is disconnected by using the vserver fpolicy showengine command.
Displaying information about connections to external FPolicy servers

You can display status information about connections to external FPolicy servers for the cluster or
for a specified Vserver. This information can help you determine which external FPolicy servers are
connected.
About this task
If you do not specify any parameter, the command displays the following information:
Vserver name
Node name
FPolicy policy name
FPolicy server IP address
FPolicy server status
FPolicy server type
In addition to displaying information about FPolicy connections on the cluster or a specific Vserver,
you can use command parameters to filter the command's output by other criteria.
You can specify the -instance parameter to display detailed information about listed policies.
Alternatively, you can use the -fields parameter to display only the indicated fields in the
command output. You can enter ? after the -fields parameter to find out which fields you can use.
Step
1. Display filtered information about connection status between the node and the external FPolicy
server by using the appropriate command:
connection status information
about...
FPolicy servers that you specify
vserver fpolicy show-engine -server IP_address
FPolicy servers for a specified

Vserver
vserver fpolicy show-engine -vserver

vserver_name
FPolicy servers that are attached

with a specified policy
vserver fpolicy show-engine -policy-name

policy_name
connection status information
about...
FPolicy servers with the server

status that you specify
vserver fpolicy show-engine -server-status

status
The server status can be one of the following:
FPolicy servers with the

specified type
connected
disconnected
connecting
disconnecting
vserver fpolicy show-engine -server-type type

The FPolicy server type can be one of the following:
FPolicy servers that were

disconnected with the specified
reason
primary
secondary
vserver fpolicy show-engine -disconnect-reason

text
Disconnect can be due to multiple reasons. The following are common
reasons for disconnect:
Disconnect command received from CLI.

Error encountered while parsing notification
response from FPolicy server.
FPolicy Handshake failed.
SSL handshake failed.
TCP Connection to FPolicy server failed.
The screen response message received from the
FPolicy server is not valid.
There are additional optional parameters for this command. For more information about the
command, see the man pages.
This example displays information about FPolicy servers (external engines) on Vserver vs1:
cluster1::> vserver fpolicy show-engine -vserver vs1
FPolicy
ServerVserver Policy
Node
Server
status
------- --------- ------------ ------------- ----------vs1
policy1
node1
1.1.1.1
connected
Servertype
--------primary
This example displays information about connected FPolicy servers (external engines):
cluster1::> vserver fpolicy show-engine -fields server -server-status
connected

node
vserver policy-name server
---------- ------- ----------- ------node1
vs1
policy1
1.1.1.1
563
Glossary
To understand the file access and protocols management concepts in this document, you might need
to know how certain terms are used.
A
ACL
Access control list.
adapter
A SCSI card, network card, hot-swap adapter, serial adapter, or VGA adapter
that plugs into an expansion slot. Sometimes called expansion card.
address resolution
The procedure for determining an address corresponding to the address of a

LAN or WAN destination.
agent
A process that gathers status and diagnostic information and forwards it to

network management stations, for example, SNMP agent.
appliance
A device that performs a single, well-defined function and is simple to install

and operate.
ATM
Asynchronous Transfer Mode. A network technology that combines the

features of cell-switching and multiplexing to offer reliable and efficient
network services. ATM provides an interface between devices such as
workstations and routers, and the network.
AutoSupport
A storage system daemon that triggers email messages from the customer
site to technical support or another specified email recipient when there is a
potential storage system problem.
B
big-endian
A binary data format for storage and transmission in which the most
significant byte comes first.
C
CIFS
See Common Internet File System (CIFS).
client
A workstation or PC in a client-server architecture; that is, a computer

system or process that requests services from and accepts the responses of
another computer system or process.
cluster monitor
The software that administers the relationship of nodes in a cluster.
community
A logical relationship between an SNMP agent and one or more SNMP

managers. A community is identified by name, and all members of the
community have the same access privileges.

console
The physical or virtual terminal that is used to monitor and control a storage
system.
Copy-On-Write
(COW)
The technique for creating Snapshot copies without consuming excess disk
space.
D
degraded mode
The operating mode of a storage system when a disk in the RAID group fails
or the batteries on the NVRAM card are low.
disk ID number
The number assigned by the storage system to each disk when it probes the
disks at startup.
disk shelf
A shelf that contains disk drives and is attached to a storage system.
E
Ethernet adapter
An Ethernet interface card.
expansion card
A SCSI card, NVRAM card, network card, hot-swap card, or console card
that plugs into a storage system expansion slot. Sometimes called an adapter.
expansion slot
The slots on the storage system board into which you insert expansion cards.
F
FDDI adapter
A Fiber Distributed Data Interface (FDDI) interface card.
FDDI-fiber
An FDDI adapter that supports a fiber-optic cable.
FDDI-TP
An FDDI adapter that supports a twisted-pair cable.
G
GID
See Group ID (GID).
Group ID (GID)
The number used by UNIX systems to identify groups.
H
heartbeat
A repeating signal transmitted from one storage system to the other that
indicates that the storage system is in operation. Heartbeat information is
also stored on disk.
hot spare disk
A disk installed in the storage system that can be used to substitute for a
failed disk. Before the disk failure, the hot spare disk is not part of the RAID
disk array.
hot swap
The process of adding, removing, or replacing a disk while the storage

system is running.
hot swap adapter
An expansion card that makes it possible to add or remove a hard disk with
minimal interruption to file system activity.
Glossary | 565
inode
A data structure containing information about files on a storage system and

in a UNIX file system.
interrupt switch
A switch on some storage system front panels used for debugging purposes.
L
LAN Emulation
(LANE)
The architecture, protocols, and services that create an Emulated LAN using
ATM as an underlying network topology. LANE enables ATM-connected
end systems to communicate with other LAN-based systems.
local storage
system
The system you are logged in to.
M
magic directory
A directory that can be accessed by name but does not show up in a directory
listing. The .snapshot directories, except for the one at the mount point or at
the root of the share, are magic directories.
mail host
The client host responsible for sending automatic email to technical support
when certain storage system events occur.
Maintenance mode An option when booting a storage system from a system boot disk.
Maintenance mode provides special commands for troubleshooting hardware
and configuration.
MIB
Management Information Base. ASCII files that describe the information

that the SNMP agent sends to network management stations.
MIME
Multipurpose Internet Mail Extensions. A specification that defines the

mechanisms for specifying and describing the format of Internet message
bodies. An HTTP response containing the MIME Content-Type header
allows the HTTP client to invoke the application that is appropriate for the
data received.
MultiStore
In Data ONTAP operating in 7-Mode, an optional software product that

enables you to partition the storage and network resources of a single storage
system so that it appears as multiple storage systems on the network.
N
NDMP
Network Data Management Protocol. A protocol that allows storage systems

to communicate with backup applications and provides capabilities for
controlling the robotics of multiple tape backup devices.
network adapter
An Ethernet, FDDI, or ATM card.
network
management
station
See NMS.

NMS
Network Management Station. A host on a network that uses third-party

network management application (SNMP manager) to process status and
diagnostic information about a storage system.
null user
The Windows NT machine account used by applications to access remote

data.
NVRAM cache
Nonvolatile RAM in a storage system, used for logging incoming write data
and NFS requests. Improves system performance and prevents loss of data in
case of a storage system or power failure.
NVRAM card
An adapter that contains the storage systems NVRAM cache.
NVRAM mirror
A synchronously updated copy of the contents of the storage system

NVRAM (nonvolatile random access memory) contents kept on the partner
storage system.
P
panic
A serious error condition causing the storage system or V-Series system to

halt. Similar to a software crash in the Windows system environment.
parity disk
The disk on which parity information is stored for a RAID4 disk drive array.
In RAID groups using RAID-DP protection, two parity disks store the parity
and double-parity information. Used to reconstruct data in failed disk blocks
or on a failed disk.
PCI
Peripheral Component Interconnect. The bus architecture used in newer

storage system models.
POST
Power-on self-tests. The tests run by a storage system after the power is
turned on.
PVC
Permanent Virtual Circuit. A link with a static route defined in advance,

usually by manual setup.
Q
qtree
A special subdirectory of the root of a volume that acts as a virtual

subvolume with special attributes.
R
RAID
Redundant Array of Independent Disks. A technique that protects against

disk failure by computing parity information based on the contents of all the
disks in an array. Storage systems use either RAID4, which stores all parity
information on a single disk, or RAID-DP, which stores all parity
information on two disks.
RAID disk
scrubbing
The process in which a system reads each disk in the RAID group and tries
to fix media errors by rewriting the data to another disk area.
Glossary | 567
SCSI adapter
An expansion card that supports SCSI disk drives and tape drives.
SCSI address
The full address of a disk, consisting of the disks SCSI adapter number and
the disks SCSI ID, such as 9a.1.
SCSI ID
The number of a disk drive on a SCSI chain (0 to 6).
serial adapter
An expansion card for attaching a terminal as the console on some storage

system models.
serial console
An ASCII or ANSI terminal attached to a storage systems serial port. Used

to monitor and manage storage system operations.
share
A directory or directory structure that has been made available to network

users and can be mapped to a drive letter on a CIFS client. Also known as a
CIFS share.
SID
Security identifier used by the Windows operating system.
Snapshot copy
An online, read-only copy of an entire file system that protects against

accidental deletions or modifications of files without duplicating file
contents. Snapshot copies enable users to restore files and to back up the
storage system to tape while the storage system is in use.
SVC
Switched Virtual Circuit. A connection established through signaling. The

user defines the endpoints when the call is initiated.
system board
A printed circuit board that contains a storage systems CPU, expansion bus
slots, and system memory.
T
trap
An asynchronous, unsolicited message sent by an SNMP agent to an SNMP

manager indicating that an event has occurred on the storage system.
tree quota
A type of disk quota that restricts the disk usage of a directory created by the
quota qtree command. Different from user and group quotas that restrict disk
usage by files with a given UID or GID.
U
UID
user identification number.
Unicode
A 16-bit character set standard. It was designed and is maintained by the

nonprofit consortium Unicode Inc.
V
VCI
Virtual Channel Identifier. A unique numerical tag defined by a 16-bit field

in the ATM cell header that identifies a virtual channel over which the cell is
to travel.
VGA adapter
An expansion card for attaching a VGA terminal as the console.

volume
VPI
For Data ONTAP, a logical entity that holds user data that is accessible
through one or more of the supported access protocols, including
Network File System (NFS), Common Internet File System (CIFS), Fibre
Channel (FC), and Internet SCSI (iSCSI). V-Series treats an IBM volume
as a disk.
For IBM, the area on the storage array that is available for a V-Series
system or non V-Series host to read data from or write data to. The VSeries documentation uses the term array LUN to describe this area.
Virtual Path Identifier. An eight-bit field in the ATM cell header that
indicates the virtual path over which the cell should be routed.
W
WAFL
Write Anywhere File Layout. A file system designed for the storage system
to optimize write performance.
WINS
Windows Internet Name Service.
569
Copyright information
Copyright 19942013 NetApp, Inc. All rights reserved. Printed in the U.S.
No part of this document covered by copyright may be reproduced in any form or by any means
graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an
electronic retrieval systemwithout prior written permission of the copyright owner.
Software derived from copyrighted NetApp material is subject to the following license and
disclaimer:
THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE,
WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
NetApp reserves the right to change any products described herein at any time, and without notice.
NetApp assumes no responsibility or liability arising from the use of products described herein,
except as expressly agreed to in writing by NetApp. The use or purchase of this product does not
convey a license under any patent rights, trademark rights, or any other intellectual property rights of
NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents,
or pending applications.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).
Trademark information
NetApp, the NetApp logo, Network Appliance, the Network Appliance logo, Akorri,
ApplianceWatch, ASUP, AutoSupport, BalancePoint, BalancePoint Predictor, Bycast, Campaign
Express, ComplianceClock, Cryptainer, CryptoShred, CyberSnap, Data Center Fitness, Data
ONTAP, DataFabric, DataFort, Decru, Decru DataFort, DenseStak, Engenio, Engenio logo, E-Stack,
ExpressPod, FAServer, FastStak, FilerView, Flash Accel, Flash Cache, Flash Pool, FlashRay,
FlexCache, FlexClone, FlexPod, FlexScale, FlexShare, FlexSuite, FlexVol, FPolicy, GetSuccessful,
gFiler, Go further, faster, Imagine Virtually Anything, Lifetime Key Management, LockVault, Mars,
Manage ONTAP, MetroCluster, MultiStore, NearStore, NetCache, NOW (NetApp on the Web),
Onaro, OnCommand, ONTAPI, OpenKey, PerformanceStak, RAID-DP, ReplicatorX, SANscreen,
SANshare, SANtricity, SecureAdmin, SecureShare, Select, Service Builder, Shadow Tape,
Simplicity, Simulate ONTAP, SnapCopy, Snap Creator, SnapDirector, SnapDrive, SnapFilter,
SnapIntegrator, SnapLock, SnapManager, SnapMigrator, SnapMirror, SnapMover, SnapProtect,
SnapRestore, Snapshot, SnapSuite, SnapValidator, SnapVault, StorageGRID, StoreVault, the
StoreVault logo, SyncMirror, Tech OnTap, The evolution of storage, Topio, VelocityStak, vFiler,
VFM, Virtual File Manager, VPolicy, WAFL, Web Filer, and XBB are trademarks or registered
trademarks of NetApp, Inc. in the United States, other countries, or both.
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. A complete and current list of
other IBM trademarks is available on the web at www.ibm.com/legal/copytrade.shtml.
Apple is a registered trademark and QuickTime is a trademark of Apple, Inc. in the United States
and/or other countries. Microsoft is a registered trademark and Windows Media is a trademark of
Microsoft Corporation in the United States and/or other countries. RealAudio, RealNetworks,
RealPlayer, RealSystem, RealText, and RealVideo are registered trademarks and RealMedia,
RealProxy, and SureStream are trademarks of RealNetworks, Inc. in the United States and/or other
countries.
All other brands or products are trademarks or registered trademarks of their respective holders and
should be treated as such.
NetApp, Inc. is a licensee of the CompactFlash and CF Logo trademarks.
NetApp, Inc. NetCache is certified RealSystem compatible.
571
How to send your comments

You can help us to improve the quality of our documentation by sending us your feedback.
Your feedback is important in helping us to provide the most accurate and high-quality information.
If you have suggestions for improving this document, send us your comments by email to
doccomments@netapp.com. To help us direct your comments to the correct division, include in the
subject line the product name, version, and operating system.
You can also contact us in the following ways:
NetApp, Inc., 495 East Java Drive, Sunnyvale, CA 94089 U.S.

Telephone: +1 (408) 822-6000
Fax: +1 (408) 822-4501
Support telephone: +1 (888) 463-8277
Index
8.3-format file names
creating 33
A
absolute symbolic links
how SMB clients can access UNIX 361
access
controlling based on IP address on Infinite Volumes
480
controlling with file permissions on Infinite Volumes
482
how authorization provides security for CIFS 114
role authentication plays for secure SMB 113
access cache
explained 89
access checks
Infinite Volumes 469
security trace, types monitored 306
access control entries
See ACEs
access control lists
commands for managing SMB 201
See also ACLs
access control lists (ACLs)
NFSv4, benefits of enabling 98
NFSv4, managing 98
access control lists)
See ACLs
access events
file and folder, that can be audited 499
access levels
how security types determine client 53, 216
access requests
mapping to anonymous 51, 214
access tokens
user, how they are constructed 231
access-based enumeration
defined 405
enabling or disabling from Windows clients 407
enabling or disabling on SMB shares 406
use to secure shares 405
accounts
changing or resetting domain passwords 178
ACEs
adding to security descriptor DACLs 280

adding to security descriptor SACLs 293
defined 275
limit for NFSv4 ACLs 100
ACLs
defined 275
enabling or disabling NFSv4 100
file permissions, SMB 472
limit of ACEs for NFSv4 100
modifying NFSv4 99
NFSv4, how they work 98
share
See also access control lists
ACLs (access control lists)
NFSv4, benefits of enabling 98
NFSv4, managing 98
ACLs)
how Data ONTAP uses share-level 200
adding
CIFS preferred domain controllers 175
CIFS share properties on existing shares 197
DACL access control entries to a security descriptor
280
default gateways and static routes to routing groups
on the Vserver 135
home directory search paths 353
home directory shares 352
preferred domain controllers, command for 175
privileges to local or domain groups 253
privileges to local or domain users 253
rules to export policies 57
SACL access control entries to a security descriptor
293
SMB access rules to export policies 220
SMB share properties, enabling BranchCache by 376
tasks to the security policy 284, 297
users to local groups 248
users to local UNIX groups 80
administrator accounts
considerations when using local 233
aggregates
when staging volumes are created with enabled
auditing subsystem 497
anonymous
mapping clients to 51, 214
Index | 573
how to troubleshoot staging volume space issues 521
list of NFS events 500
NFS and CIFS file and folder access 495
on Infinite Volumes 465, 466
planning the configuration 501
requirements and considerations for configuring 498
revert process when there are audit-enabled Vservers
anonymous access
how to configure with export rules 55, 218
APIs
supported VMware vStorage, for NFS 108
applying
audit policies to NTFS files and folders, tasks for
290
file security to NTFS files and folders, tasks for 276
architectures
typical NAS namespace 20
assign
local privileges, how to 233
asynchronous
FPolicy applications 524
FPolicy communication notifications, defined 523
audit policies
adding tasks to security 284, 297
considerations when managing NTFS 274
display information about 257
displaying using the Windows Security tab 512
monitoring jobs 288, 301
NTFS, how to configure using the Data ONTAP CLI
511
tasks for configuring and applying on NTFS files
and folders 290
verifying applied 301
audit-enabled Vservers
revert process for 520
auditing
commands for modifying configuration 519
completing the configuration worksheet 504
configuring for NFS 511
consolidation and conversion tasks 495
creating configuration 505
creating file and directory, configuration 504
deleting configuration 520
displaying information about configuration 517
displaying information about NFSv4, policies 271
displaying information about NTFS, policies 268,
513
enabling and disabling on a Vserver 516
enabling on a Vserver 506
file and folder access events that can be audited 499
how implementing is a two-step process 500
how staging volumes are created on aggregates 497
how the Data ONTAP process works 496
how to determine whether aggregates have staging
volumes 507
how to troubleshoot event log volume space issues
521
520
staging files and volumes 495
supported audit event log formats 498
verifying applied policies 301
verifying configuration 506
verifying that it is enabled 517
auditing for NFS 511
auditing policies
creating 283, 296
authentication
how Data ONTAP handles NFS client 34
Kerberos 62, 114
local user, how it works 230
NTLM 114
role it plays in securing SMB access 113
authentication-based
restrictions 17
authorization
role in securing CIFS file access 114
automatic node referrals
how client response time is improved by SMB 399
how to monitor using a Windows client 405
support for SMB 401
using statistics counters to monitor 403
verifying that they are disabled for Hyper-V over
SMB configurations 437
B
backups
use remote VSS to perform share-based backups of
virtual machines 413
best practices
FPolicy setup 532
BranchCache
about using to cache CIFS shares at branch offices
366
changing the server key 380
configuration recommendations 369
configuring to automatically enable per-share or on
all SMB shares 370

considerations when choosing hash store location
368
Data ONTAP version requirements 367
disabling on single SMB shares 388
displaying information about configurations 379
displaying information about defined and applied
GPOs 386
displaying statistics 383
enabling on existing SMB shares 376
enabling or disabling 390
enabling when creating SMB shares 374
flushing hashes from the hash store 382
GPO support 385
increasing volume size for hash store directory 377
introduction to enabling on SMB shares 374
modifying hash store directory path 377
modifying hash store maximum directory size 377
modifying operating mode 377
modifying the configuration 377
modifying version support 377
network protocol support requirements 367
overview of disabling on SMB shares 387
pre-computing hashes 381
prerequisites 369
reasons Data ONTAP invalidates hashes 368
stopping automatic caching on all SMB shares 389
supported SMB 2.1 functionality 146
versions supported 366
what happens when reverting 392
what happens when you delete the configuration 391
what happens when you disable 390
where to find information about remote office
configuration 374
Windows hosts version requirements 367
BranchCache hashes, reasons for
invalidating 368
breaking
locks 96, 325
BUILTIN groups
considerations when using 233
C
caches
enabling CIFS metadata 320
caching
how it works for CIFS metadata 320
introduction to using offline files to allow file 336
caching servers
where to get information about configuring

BranchCache on 374
case-sensitivity
of file names 32
change notifications
changing
local user account passwords 241
CIFS
about using BranchCache for caching at branch
offices 366
access control lists, creating 201
adding default gateways and static routes to routing
groups on the Vserver 135
adding or removing share properties 197
adding preferred domain controllers 175
advantages of using roaming profiles to store user
profiles 341
applying GPOs to CIFS servers 167
BranchCache configuration recommendations 369
BranchCache GPO support 385
changing the BranchCache server key 380
commands for managing access control lists 201
commands for managing CIFS servers 180
configuring BranchCache to automatically enable on
all shares 370
configuring CIFS options 139
configuring DNS on the Vserver 126
configuring folder redirection 343
configuring lifetime of metadata cache entries 321
configuring name services on the Vserver 129
configuring offline files support on SMB shares 338
configuring UNIX symbolic link support on SMB
shares 362
configuring VSS shadow directory depth 443
considerations for using ODX 396
considerations when creating security traces 306
considerations when deploying offline files 337
creating a Snapshot configuration to enable Previous
Versions access 348
creating CIFS servers 127
creating data LIFs for the CIFS server 133
creating routing groups on the Vserver 135
creating security trace filters 308
creating shares 193
creating Vserver for hosting a CIFS server 124
deleting all security trace records 315
deleting security trace filters 313
determining Snapshot copy availability for Previous
Versions use 347
Index | 575
differences between Data ONTAP and Windows
handling of locks on share path components 323
disabling BranchCache on single share 388
displaying continuously available protection
information 326, 457, 460
BranchCache GPOs 386
displaying information about discovered LDAP and
domain controller servers 173
displaying information about open continuously
available files 329
displaying information about open files 329
displaying IPv6 session information 167
displaying security setting information 144
displaying security trace filters 310
displaying session information 326, 457, 460
enabling BranchCache on existing SMB shares 376
enabling BranchCache when creating SMB shares
374
enabling IPv6 on the cluster for 166
enabling or disabling automatic node referrals 402
enabling or disabling local user authentication 237
enabling or disabling local users and groups 236
enabling or disabling ODX 398
enabling or disabling oplocks when creating shares
158
enabling or disabling required password complexity
for local users 142
enabling or disabling required SMB signing 141, 154
enabling or disabling the VSS shadow copy 447
enabling the metadata cache 320
export policies, how used with 209
file locking 92, 322
file naming dependencies 32
file security on mixed volumes, displaying 262
file security on NTFS volumes, displaying 258
file security on UNIX volumes, displaying 265
files
configuring support on SMB shares for offline
338
files, accessing from NFS clients 34
flushing hashes from the BranchCache hash store
382
how authorization provides security for access 114
how CIFS servers use IPv6 when connecting to
external servers 165
how Data ONTAP enables dynamic home directories
350
how Data ONTAP uses share-level ACLs 200
how metadata caching works for 320

how name mapping is used for access 115
how SMB automatic node referrals improve
response time 399
how to disable IPv6 on the cluster 167
information needed when creating SMB shares 192
introduction to enabling BranchCache on SMB
shares 374
introduction to using folder redirection to store data
on a CIFS server 342
IPv6 network supported for CIFS access 163
IPv6 requirements 163
IPv6 support with 164
list of CIFS options 137
local user password requirements 234
modifying protocols for Vservers 45, 176
modifying security settings 140
monitoring SMB signing statistics 155
NFSv4 audit information, displaying 271
NTFS audit information, displaying 268, 513
ODX use cases 397
performing security traces 307
pre-computing BranchCache hashes 381
read-only bits explained 93, 322
recover files and folders with Microsoft Previous
Versions 345
requirements for using folder redirection 343
requirements for using ODX 395
requirements for using offline files 337
requirements for using Previous Versions 345
requirements for using roaming profiles 341
resetting and rediscovering LDAP servers and
domain controllers 174
role authentication plays in securing access 113
role export policies play with SMB access 115
security trace filters, modifying 312
security trace records, deleting 314
security trace results, displaying 311
security trace results, how to interpret 315
security trace results, list of effective security styles
in 316
security traces, list of reasons and locations for
allowing access 317
security traces, list of reasons and locations for
denying access 318
security traces, types of access checks monitored by
306
security tracing, how it works 305
share naming considerations on Vservers 191

statistics, determining which counters and objects
are available 333, 448
stopping automatic BranchCache caching on all
SMB shares 389
stopping or starting CIFS servers 177
support for SMB automatic node referrals 401
supported clients 118
supported domain controllers 118
using the Previous Versions tab to view and manage
Snapshot copy data 346
what happens to BranchCache when reverting 392
CIFS access
share ACLs 469
CIFS options
verifying settings for Hyper-V over SMB
configurations 436
CIFS server
prerequisites for setting up 119
use remote VSS for share-based backups of virtual
machines 413
CIFS server setup
decisions to make prior to 119
CIFS servers
commands for managing 180
configuring DNS on the Vserver 126
considerations when modifying required SMB
signing with multiple data LIFs 153
decisions to make prior to setting up network access
for 130
how export policies for SMB are handled after Data
ONTAP upgrade 210
how SMB signing policies affect SMB
communication 151
how they use IPv6 connections to external servers
165
information to gather for network setup 130
information to gather for setup 120
moving to different OUs 178
what happens to local users and groups when
deleting 231
what happens to SMB shares when deleting 190
CIFS shares
how volume junctions are used with 20
CIFS-NDO subsystems
displaying health monitor configuration information
for 451
client access
Infinite Volumes 467, 473
Infinite Volumes with storage classes 494

mixed state of Infinite Volumes 487
NFS access to Infinite Volumes 475
preparing Infinite Volumes for 473
size of Infinite Volumes 488
SMB access to Infinite Volumes 477
with export policies 468
client authentication
how Data ONTAP handles 34
client schema templates
commands for managing LDAP 88
clients
CIFS, supported 118
requirements for using folder redirection on
Windows 343
requirements for using roaming profiles on Windows
341
that support Previous Versions 345
clusters
role with FPolicy implementations 524
commands
for enabling or disabling oplocks on volumes or
qtrees 161
for managing LDAP client schema templates 88
for managing NTFS SACL ACEs 303
for managing search paths 360
for managing security policies 304
for managing security policy jobs 304
for managing security policy tasks 304
for modifying Vserver auditing configurations 519
name mapping management 84, 190
commands for managing
NTFS DACL ACEs 303
NTFS security descriptors 302
computer accounts
Hyper-V server, verifying mapping to default UNIX
user 433
Computer Management MMC
using to configure offline files support on shares 340
concepts
NDO for Hyper-V over SMB 409
Remote VSS, defined 414
configuration
when to create a native FPolicy 529
configuration requirements
LIF file access management 18
configuration types
FPolicy, defined 529
configurations
creating home directories using %w and %d 354
Index | 577
creating Kerberos realm 67
home directories using %u 356
home directories, additional 359
configure
NTFS file permissions using the Data ONTAP CLI,
how to 207
configuring
audit policies on NTFS files and folders, tasks for
290
auditing 505
BranchCache to automatically enable caching on all
SMB shares 370
BranchCache to enable caching on a per-share basis
370
CIFS options 139
default users 77
DNS on the Vserver 126
file security on NTFS files and folders, tasks for 276
folder redirection 343
lifetime of CIFS metadata cache 321
local UNIX users and groups 77
name services on the Vserver 129
NIS domains 87
NTFS advanced file permissions using the Windows
Security tab 204
NTFS file permissions using Windows Security tab
202
offline files support on shares using the Computer
Management MMC 340
offline files support on SMB shares 338
roaming profiles 342
SACLs using the Windows Security tab 508
security style on FlexVol volumes 44, 181
security style on qtrees 44, 182
security style on Vserver root volumes 43, 181
the default UNIX user 176
UNIX symbolic link support on SMB shares 362
Vservers to use LDAP 67
VSS shadow copy directory depth 443
connecting
external FPolicy servers 559
connection credentials
for FPolicy privileged data access channels 525
considerations
auditing configuration 498
for FPolicy before reverting 532
for SMB automatic node referrals 400
for using ODX 396
Hyper-V over SMB configuration 422
revert, when there are local users and groups 232
share naming on CIFS Vservers 191

when choosing BranchCache hash store location 368
when creating security traces 306
when deploying offline files 337
when reverting export policies for SMB 227
when reverting Hyper-V over SMB configurations
443
when using BUILTIN groups and local administrator
accounts 233
consolidation task
auditing 495
constituents
determining state of Infinite Volumes 487
continuously available shares
creating for Hyper-V over SMB configurations 441
creating NTFS data volumes for 440
verifying configuration of Hyper-V SMB 453
control channels
how FPolicy uses 525
controllers
adding CIFS preferred domain 175
commands for managing preferred domain 175
conversion task
auditing 495
copy offload
how it is used with Hyper-V over SMB
configurations 417
See also ODX
copying
export policies 91, 226
LDAP client schema templates 88
counters
statistics, determining which are available 333, 448
using to monitor automatic node referrals 403
creating
BranchCache-enabled SMB shares 374
CIFS servers 127
CIFS shares, command for 200
continuously available shares for Hyper-V over
data LIFs for Hyper-V configurations 438
data LIFs for the CIFS server 133
Data ONTAP configurations for Hyper-V over SMB
430
export rules 92, 226
file and directory auditing configuration 504
file names 33
FPolicy events 552

FPolicy external engines 552
FPolicy policies 553
FPolicy scopes 553
home directory configuration using %u 356
home directory configuration using %w and %d 354
Kerberos realm configurations 67, 91
LDAP client configurations 70
LDAP client configurations, command for 87
LDAP configurations 88
local groups 245
local UNIX groups 79, 85
local UNIX users 77, 85
local user accounts 238
name mappings 76, 189
new LDAP client schema 69
NFS servers 47
NIS domain configuration 81
NIS domains 87
NTFS data volumes for continuously available
shares 440
routing groups on the Vserver 135
security trace filters 308
SMB share access control lists 201
SMB shares 193
symbolic link mappings for SMB 364
Vserver for hosting CIFS server 124
D
DACL ACEs
commands for managing NTFS 303
DACLs
adding access control entries to security descriptors
280
commands for managing ACEs in NTFS 303
defined 275
See also NTFS file permissions
data LIFs
considerations when modifying required SMB
signing with multiple 153
creating for Hyper-V configurations 438
for Hyper-V over SMB configurations, information
to gather for setting up 425
Data ONTAP
difference with Windows handling of locks on share
path components 323
how the auditing process works 496
requirements for using Previous Versions 345
supported versions for SMB automatic node referrals
400
Data ONTAP CLI
how to configure NTFS audit policies using 511
Data ONTAP upgrades
how export policies for SMB are handled after 210
data volumes
NTFS, creating for continuously available shares
440
default ACL
SMB shares 190
default gateways
adding to routing groups on the Vserver 135
default UNIX user
configuring the 176
default UNIX users
verifying that Hyper-V computer accounts map to
the 433
default users
configuring 77
default Windows users
definition
local privileges 232
local users and groups 228
SMB shares 190
definitions
FPolicy 523
delegations
on Infinite Volumes 465
delete
BranchCache configuration, what happens when you
391
deleting
all security trace records 315
audit configuration 520
Kerberos realm configurations 91
local groups 250
local UNIX groups 85
local UNIX users 85
Index | 579
name mappings, command for 84, 190
NFS servers 84
NIS domains 87
security trace records 314
users from local UNIX groups 85
directories
how Data ONTAP enables dynamic CIFS home 350
directory structures
used by Remote VSS, example of 415
disable
BranchCache, what happens when you 390
disabling
access-based enumeration on SMB shares 406
auditing on a Vserver 516
BranchCache 390
export policies for SMB 211
FPolicy policies 555
GPO support 169
local user accounts 240, 241
NFSv3 46
NFSv4 46
NFSv4 referrals 106
NFSv4.1 46
ODX 398
parallel NFS 47
pNFS 47
required password complexity for local users 142
required SMB signing 141, 154
rquota support 109
SMB 2.x on Vservers with FlexVol volumes 148
SMB 3.0 on Vservers with FlexVol volumes 149
SMB automatic node referrals 402
SMB local user authentication 237
VSS shadow copy 447
vStorage over NFS 108
disconnecting
from external FPolicy servers 559
discretionary access control lists
See DACLs
discretionary Access Control Lists 202
Discretionary Access Control Lists
See NTFS file permissions
display
audit policy information 257
file security information 257
displaying
audit policy information using the Windows Security

tab 512
BranchCache statistics 383
CIFS and audit statistics 335
CIFS security setting information 144
CIFS session information 326, 457, 460
CIFS session open file information 329
CIFS statistics 335
continuously available open file information 329
continuously available protection information 326,
457, 460
file security on mixed security-style volumes 262
file security on NTFS security-style volumes 258
file security on UNIX security-style volumes 265
FPolicy configuration, commands for 556
FPolicy configuration, how show commands work
when 556
GPOs applied to CIFS server 171
GPOs defined in Active Directory 171
group membership for local users 243
health monitor status for Hyper-V over SMB 451
information about auditing configurations 517
information about BranchCache configurations 379
information about connections to FPolicy servers
560
information about defined and applied BranchCache
GPOs 386
information about discovered LDAP and domain
controller servers 173
information about enabled FPolicy policies 558
information about FPolicy policy status 557
information about local groups 247
information about local users 242
information about locks 93, 323
IPv6 CIFS session information 167
local UNIX users 85
members of local groups 249
NetBIOS over TCP information 179
NFS Kerberos configurations, information about 89
NFS servers 84
NFS statistics 107

NFSv4 audit information on FlexVol volumes 271
NIS domains 87
NTFS auditing information on FlexVol volumes
268, 513
privilege overrides 256
security trace results 311
SMB statistics 450
traditional and lease oplock status 161
volume mount and junction point information 42,
186
DNS
configuring on the Vserver 126
domain accounts
changing or resetting passwords for 178
domain controllers
adding preferred 175
CIFS, supported 118
commands for managing preferred 175
displaying information about discovered 173
durable handles
E
effects on file permissions 24
enabled policies
displaying information about FPolicy 558
enabling
access-based enumeration on SMB shares 406
auditing on a Vserver 506, 516
BranchCache 390
BranchCache automatic caching on all SMB shares
370
CIFS metadata cache 320
export policies for SMB 211
FPolicy policies 554, 555
GPO support 169
IPv6 for NFS 82
IPv6 on the cluster for CIFS 166
LDAP on a Vserver 72
local user accounts 240, 241
NFSv3 46
NFSv4 46
NFSv4 referrals 106
NFSv4.1 46
ODX 398
parallel NFS 47
pNFS 47
required password complexity for local users 142
required SMB signing 141, 154
rquota support 109
SMB 2.x on Vservers with FlexVol volumes 148
SMB 3.0 on Vservers with FlexVol volumes 149
SMB automatic node referrals 402
SMB local user authentication 237
VSS shadow copy 447
vStorage over NFS 108
enumeration
access-based, enabling or disabling from Windows
clients 407
enabling or disabling access-based on SMB shares
406
eternal engines
information to gather for configuring FPolicy 538
event log formats
support for XML file format 498
events
creating FPolicy 552
file and folder access, that can be audited 499
information to gather for configuring FPolicy 545
planning the configuration for FPolicy 539
supported combinations of file operations and filters
that FPolicy can monitor for CIFS 543
that FPolicy can monitor for NFSv3 543
that FPolicy can monitor for NFSv4 544
exchanging
export policies
adding rules 57
adding rules for SMB access 220
associating with a FlexVol volume 61, 224
considerations when reverting for SMB 227
creating 57, 212
default for a Vserver 49, 210
enabling or disabling SMB 211
how to control client access to volumes 48
how used with SMB access 209
Infinite Volume default 470
managing 91, 226
restrictions and nested junctions 62, 226
role in SMB access 115
setting index numbers for rules 60, 224
export policies for SMB
Index | 581
how handled after Data ONTAP upgrade 210
export rules
how they work 49, 212
how to configure anonymous access 55, 218
how to configure superuser access 55, 218
managing 92, 226
external engines
external FPolicy servers
configuration type defined 529
connecting to 559
disconnecting from 559
displaying information about connections to 560
when to create FPolicy configurations that use 530
breaking 96, 325

displaying information about 93, 323
file names
case-sensitivity 32
creating 33
dependencies for NFS and CIFS 32
valid characters for 32
file operations
for CIFS FPolicy events 543
for NFSv4 FPolicy events 544
supported combinations with filters for NFSv3
FPolicy events 543
file permissions
CIFS ACLs 479
configuring NTFS advanced, using the Windows
Security tab 204
configuring NTFS file, using Windows Security tab
features
unsupported Windows 118
file access
how Data ONTAP controls 17
See also client access
LIF configuration requirements for managing 18
NFS, managing 83
setting up for NFS 38
file access events
that can be audited 499
file and directory auditing
creating configuration on Vservers 504
file and folder access
auditing NFS and CIFS 495
file and folder security
how security descriptors are used 275
limitations for using the CLI to set 275
use cases for using the CLI to set 275
file and record locking
NFSv4, described 104
file caching
introduction to using offline files for offline use 336
file delegations
enabling or disabling NFSv4 read 102
enabling or disabling NFSv4 write 103
how they work for NFSv4 101
NFSv4, managing 101
file locking
explained 92, 322
file locks
202
configuring on Infinite Volumes 482
effect of security styles on 24
how to configure NTFS, using the Data ONTAP CLI
207
Infinite Volume defaults 470
mixed security style 27, 489
NFS clients setting NFSv4.1 ACLs 485
NFSv4 ACLs 479
NFSv4.1 ACLs 472
SMB ACLs 472
SMB clients setting for UNIX users 485
types 469
unified security style 27, 489
UNIX clients setting mode bits 483
Windows clients setting NTFS file permissions on
file security
considerations when managing NTFS 274
display information about 257
displaying for mixed security-style volumes 262
displaying for NTFS security-style volumes 258,
278, 291
displaying for UNIX security-style volumes 265
tasks for configuring and applying on NTFS files
and folders 276
verifying applied 288
file security policies
adding tasks to 284, 297
creating 283, 296

file-based
restrictions 18
files
considerations when deploying offline 337
displaying information about open CIFS 329
displaying information about open continuously
available CIFS 329
introduction to using to cache files for offline use
336
requirements for using offline 337
filters
creating security trace 308
displaying security trace 310
for CIFS FPolicy events 543
for NFSv4 FPolicy events 544
supported combinations with file operations for
NFSv3 FPolicy events 543
FlexVol volumes
associating export policy to 61, 224
configuring security style on 44, 181
folder access events
that can be audited 499
folder redirection
configuring 343
introduction to using to store data on a CIFS server
342
requirements for using 343
FPolicy
commands for displaying configuration information
556
commands for modifying configurations 554
configuration setup process 530
configuration types defined 529
connecting to external FPolicy servers 559
connection credentials for privileged data access
channels 525
creating events 552
creating external engines 552
creating policies 553
creating scopes 553
definition 523
disconnecting from external FPolicy servers 559
displaying information about enabled policies 558
displaying information about policy status 557
displaying information about server connections 560
enabling or disabling policies 555
enabling policies 554
events, supported combinations of file operations

and filters for CIFS 543
and filters for NFSv3 543
and filters for NFSv4 544
how communications are managed with node
failovers 528
how control channels are used 525
how data LIF migrations and failovers are handled
528
how FPolicy manages policy processing 526
how multiple assigned FPolicy policies are
processed 526
how privileged data access channels are used 525
how services work across Vserver namespaces 528
how show commands work when displaying
configuration information 556
important revert considerations 532
information to gather for event configuration 545
information to gather for external engine
configuration 538
information to gather for FPolicy policy
configuration 547
information to gather for scope configuration 550
overview of configuration planning 533
parts explained 523
planning event configurations 539
planning FPolicy policy configurations 545
planning FPolicy scope configurations 548
planning the external engine configuration 533
protocols that can be monitored 523
roles that cluster components play with 524
setup best practices and recommendations 532
setup requirements 531
super user credentials for privileged data access 526
synchronous and asynchronous applications 524
synchronous and asynchronous communication
defined 523
what the node-to-FPolicy server communication
process is 527
when to create a native FPolicy configuration 529
when to create configurations that use external
FPolicy servers 530
FPolicy event configuration
information to gather for 547
FPolicy external servers
what they do 523
FPolicy framework
Index | 583
what it does 523
FPolicy on clustered Data ONTAP
role in establishing communications with FPolicy
servers 525
FPolicy policies
displaying information about enabled 558
how FPolicy manages processing multiple 526
FPolicy policy
information to gather for configuration 547
FPolicy policy status
displaying information about 557
FPolicy scope
configuration information to gather 550
FPolicy servers
connecting to 559
disconnecting from 559
displaying information about connections to 560
what the communication process to nodes is 527
when to create FPolicy configurations that use
external 530
fsecurity
considerations when using BUILTIN 233

considerations when using SnapMirror on Vservers
with local 231
creating local 245
deleting CIFS servers, what happens to local 231
deleting local 250
displaying information about local 247
displaying list of members of local 249
how user access tokens are constructed for local 231
local, UNIX, configuring 77
modifying description for local 246
predefined local 234
removing privileges from local or domain 254
removing users from local 248
renaming local 246
resetting privileges for local or domain 255
revert considerations when there are local 232
UNIX, adding users to local 80
UNIX, creating local 79
UNIX, loading local from URIs 79
updating names in the local databases for domain
251
glossary 563
GPOs
applying to CIFS servers 167
BranchCache 386
displaying, applied to CIFS server and defined in
Active Directory 171
enabling or disabling support for 169
how updated on the CIFS server 170
manually updating settings 170
requirements for using with CIFS servers 169
support for BranchCache 385
supported 168
group IDs
limitation for NFS RPCSEC_GSS 63
group mappings
configuring on Infinite Volumes 479
group memberships
displaying local user 243
Group Policy Objects
See GPOs
groups
adding privileges to local or domain 253
adding users to local 248
hard mounts 33
hash stores
considerations when choosing location for
BranchCache 368
hashes
flushing from the BranchCache hash store 382
pre-computing BranchCache 381
reasons Data ONTAP invalidates BranchCache 368
home directories
adding search paths 353
additional configurations 359
creating configurations using %u 356
creating configurations using %w and %d 354
how Data ONTAP enables dynamic CIFS 350
home directory shares
adding 352
Hyper-V
configurations, creating data LIFs for 438
configuring existing shares for continuous
availability over SMB configurations 444
example of directory structure used by Remote VSS
415
over SMB configurations, creating continuously
available shares for 441
over SMB, concepts 409

over SMB, creating Data ONTAP configurations for
430
over SMB, information to gather for data LIF and
network configuration 425
over SMB, protocols that enable NDOs 409
over SMB, supported nondisruptive operations 408
use remote VSS for share-based backups of virtual
machines 413
verifying continuously available SMB share
configuration 453
verifying LIF status 455
verifying that automatic node referrals are disabled
437
verifying that computer accounts map to the default
UNIX user 433
verifying that Kerberos and NTLMv2 authentication
are permitted 431
verifying that volume creation uses NTFS security
style 435
where to find information about configuring 408
Hyper-V over SMB
configuration planning tasks 424
considerations when configuring 422
considerations when reverting 443
how ODX copy offload is used with 417
how SnapManager for Hyper-V manages Remote
VSS-based backups 416
how to use system health monitor to determine NDO
status 451
nondisruptive operations for, defined 408
protocols that enable NDOs 409
recommendations when configuring 423
requirements when configuring 419
support for stand-alone and clustered configurations
408
supported nondisruptive operations 408
verifying CIFS option settings for 436
what you need to configure 408
I
implement
auditing, two-steps to implement 500
Infinite Volumes
access location 467
CIFS servers 477
CIFS support 466
client access 465, 467
configuring file permissions 482
configuring group mappings 479
controlling access with share ACLs 481

controlling client access 467
data policies for filtering data into storage classes
494
See also Infinite Volumes with storage classes
default permissions 470
default user 475
export policy, default 470
file access 465
file permissions
NFS clients setting NFSv4.1 ACLs 485
set by Windows clients 484
SMB clients setting for UNIX users 485
UNIX clients setting mode bits 483
file permissions, default 470
group mappings 472
how locks work on 489
IP-based access control 480
Kerberos 475
LDAP 475
local UNIX users and groups 475
local Windows users and groups 475
mixed state 487
mode bits 485
mounts 475
multiprotocol access 465
name mapping 475
NFS servers 475
NFS support 465
NFSv4.1 ACLs 485
NIS name services 475
NTFS file permissions 485
on NFSv4.1 clients 487
preparing for client access 473
setting up file access 473
share ACL,default 470
share ACLs 469, 481
shares 477
storage classes, with 494
See also Infinite Volumes with storage classes
unified security style 26, 470
user name mapping 475
why size appears smaller 488
Infinite Volumes with storage classes
impact on client access 494
inserting
interpreting
security trace results 315
Index | 585
IPv6
displaying information about CIFS sessions 167
enabling for NFS 82
enabling on the cluster for CIFS 166
how CIFS servers use, when connecting to external
servers 165
how to disable on the cluster 167
monitoring CIFS sessions for 167
NFS support for 82
requirements for CIFS 163
support with CIFS 164
supported network for CIFS access 163
J
jobs
commands for managing security policy 304
monitoring security policy jobs 288, 301
junction path
junction points
creating volumes with specified 38, 183
creating volumes without specified 39, 184
displaying information about volume 42, 186
junctions
considerations with Previous Versions restores for
folders with 349
defined 19
for Vservers with Infinite Volumes 467
volume, how used in CIFS and NFS server
namespaces 20
K
Kerberos
authentication 62, 114
creating configuration for Vservers 69
creating realm configurations 67
displaying configuration information for NFS 89
how export policies are used with SMB access for
authentication 209
modifying configuration for NFS servers 90
realms, managing 91
requirements for configuring with NFS 63
verifying that authentication is permitted with
Hyper-V configuration 431
L
LDAP
commands for managing client configurations 87
commands for managing client schema templates 88
configuring Vservers to use 67
creating client configurations 70
creating new client schema 69
displaying information about discovered servers 173
enabling on a Vserver 72
lease oplocks
improving client performance with 157
monitoring 161
lifetime
configuring CIFS metadata cache 321
LIFs
configuration requirements for file access
management 18
creating data, for Hyper-V configurations 438
data, role with FPolicy implementations 524
how FPolicy handle migrations and failovers for data
528
verifying status for Hyper-V configuration 455
limitations
for using the CLI to set file and folder security 275
of Data ONTAP support for NFSv4 35
of group IDs for NFS RPCSEC_GSS 63
limits
of ACEs for NFSv4 ACLs 100
when configuring UNIX symbolic links for SMB
access 362
links
configuring support for UNIX symbolic, on SMB
shares 362
guidelines for configuring UNIX symbolic, for SMB
access 362
how SMB clients can access UNIX symbolic 361
list
of CIFS options 137
of predefined local privileges 232
loading
local UNIX groups from URIs 79
local UNIX users from URIs 78
local administrator accounts
considerations when using 233

local groups
considerations when using SnapMirror on Vservers
with 231
creating 245
deleting 250
displaying list of members of 249
predefined 234
reasons for creating 229
local links
how SMB clients can access UNIX symbolic links
361
local privileges
defined 232
how to assign 233
local user authentication
enabling or disabling SMB 237
local users
displaying information about local group
membership 243
enabling or disabling accounts 241
how authentication works 230
modifying, renaming, enabling, or disabling 240
password requirements 234
local users and groups
defined 228
deleting CIFS servers, what happens to 231
how they are used 228
how user access tokens are constructed 231
revert considerations when there are configured 232
view from the Microsoft Management Console 232
local Windows users and groups 475
locations
list of, for allowing access 317
list of, for denying access 318
locking grace period
NFSv4, specifying 105
locking lease period
specifying NFSv4 104
locks
breaking 96, 325
differences between Data ONTAP and Windows
handling of, on share path components 323
displaying information about 93, 323
how they work on Infinite Volumes 489
M
manage
NTFS file security and audit polices using the CLI,
considerations 274
managing
CIFS servers, commands for 180
CIFS shares, commands for 200
LDAP client configurations, commands for 87
local group memberships 248
local UNIX users 85
name mappings, commands for 84, 190
NFS servers 84
preferred domain controllers, commands for 175
symbolic link mapping, commands for 365
metadata cache
configuring lifetime of CIFS metadata cache 321
metadata caches
enabling CIFS 320
metadata caching
how it works in CIFS 320
Microsoft Management Console
view information about local users and groups from
the 232
what management tasks you can perform on local
users and groups 232
mixed security style
compared to unified security style 27, 489
MMC
using to configure offline files support on shares 340
mode bits
set by UNIX clients on Infinite Volumes 483
modifying
auditing configurations, commands for 519
BranchCache configuration 377
CIFS security settings 140
existing shares for continuous availability 444
export rule index numbers 60, 224
FPolicy configurations, commands for 554
Index | 587
local group descriptions 246
local UNIX users 85
local user's full name or description 240
name mapping patterns, command for 84, 190
NFS Kerberos configuration 90
NFS servers 84
NFSv3 TCP maximum read and write size 111
NFSv4 ACLs 99
NIS domains 87
protocols for Vservers 45, 176
server implementation ID 97
monitor
automatic node referrals using a Windows client 405
monitoring
SMB signing statistics 155
traditional and lease oplocks 161
mount points
mount requests
controlling NFS, from nonreserved ports 83
mounting
NFS exports using nonreserved ports 84
volumes in NAS namespaces 40, 185
mounts
N
name mapping
configuring Vservers to use LDAP 67
explained 74, 116
name mappings
commands for managing 84, 190
conversion rules 74, 187
creating 76, 189
how used 73
how used with CIFS access 115
verifying that Hyper-V computer accounts map to
the default UNIX user 433
name services
configuring on the Vserver 129
configuring Vservers to use LDAP 67
names
valid characters for file 32

namespace
namespaces
defined 19
how FPolicy works across Vserver 528
how volume junctions are used in CIFS and NFS
server 20
mounting or unmounting volumes within NAS 40,
185
typical architectures for NAS 20
NAS
creating volumes with specified junction points 38,
183
creating volumes without specified junction points
39, 184
displaying volume mount and junction point
information 42, 186
mounting or unmounting volumes in the namespace
40, 185
typical namespace architectures 20
native FPolicy configuration
when to create 529
native FPolicy servers
configuration type defined 529
NDO for Hyper-V over SMB
displaying health monitor status for 451
NDOs
available protocols for enabling for Hyper-V over
SMB 409
for Hyper-V over SMB, displaying health monitor
status for 451
for Hyper-V over SMB, how SMB functionality
supports 411
Hyper-V over MSB, how to use system health
monitor to determine status of 451
See also nondisruptive operations
NDOs for Hyper-V
over SMB, concepts 409
NetBIOS
over TCP, displaying information 179
netgroups
loading into Vservers from URIs 81
verifying status of definitions 86
network access
decisions to make prior to setting up CIFS server
130
network setups
information to gather for CIFS server 130
NFS

benefits of enabling v4 ACLs 98
clients, accessing CIFS files 34
configuring auditing 511
controlling requests from nonreserved ports 83
enabling IPv6 for 82
enabling or disabling v3 46
enabling or disabling v4 46
enabling or disabling v4 ACLs 100
enabling or disabling v4 read file delegations 102
enabling or disabling v4 write file delegations 103
enabling or disabling v4.1 46
events that can be audited 500
file locking 92, 322
file naming dependencies 32
file security on mixed volumes, displaying 262
file security on NTFS volumes, displaying 258
file security on UNIX volumes, displaying 265
group ID limitation for RPCSEC_GSS 63
how Data ONTAP handles client authentication 34
how v4 ACLs work 98
Kerberos configuration, displaying information
about 89
Kerberos configuration, modifying 90
managing file access 83
managing v4 ACLs 98
modifying protocols for Vservers 45, 176
mounting exports using nonreserved ports 84
NFSv4 audit information, displaying 271
NTFS audit information, displaying 268, 513
process to access NTFS security style data 37
process to access UNIX security style data 37
read-only bits explained 93, 322
requirements for configuring with Kerberos 63
setting up file access for 38
specifying user ID domain for v4 66
support for parallel 36
support for Vservers with Infinite Volumes 465
support for, over IPv6 82
supported versions and clients 35
using with Kerberos 62
v4 file and record locking described 104
v4 support 35
v4, determining file deletion 100
v4, how file delegations work 101
v4, limitations of Data ONTAP support 35
v4, managing file delegations 101
v4, specifying locking grace period 105
v4, specifying locking lease period 104
v4.1 36
NFS access
NFS clients
setting NFSv4.1 ACLs 485
NFS exports
how volume junctions are used with 20
NFS servers
creating 47
managing 84
NFSv3
improving performance for TCP 110
modifying TCP maximum read and write size 111
NFSv4
enabling or disabling referrals 106
how referrals work 105
modifying ACLs 99
NFSv4.1 ACLs
set by NFS clients 485
NFSv4.1 clients
showing ACLs 487
NIS domain
configuring 87
creating 81, 87
deleting 87
displaying 87
modifying 87
NIS name services
node referrals
how client response time is improved by SMB
automatic 399
nodes
creating data LIFs for Hyper-V configurations 438
how FPolicy handles communications with failovers
528
verifying LIF status for Hyper-V configuration 455
what the communication process is for FPolicyenabled 527
nondisruptive operations
Hyper-V over SMB configuration considerations
422
Hyper-V over SMB configuration requirements 419
Hyper-V over SMB, defined 408
See also NDOs
nondisruptive operations (NDO)
NTFS
Index | 589
configuring advanced file permissions using the
Windows Security tab 204
creating security descriptors 278, 291
DACL ACEs, commands for managing 303
data volumes, creating for continuously available
shares 440
SACL ACEs, commands for managing 303
security descriptors, commands for managing 302
security style, verifying that Hyper-V volumes are
created with 435
appearance on NFSv4.1 clients 487
configuring using Windows Security tab 202
how to configure using the Data ONTAP CLI 207
set by Windows clients on Infinite Volumes 484
NTLM
authentication 114
how export policies are used with SMB access for
authentication 209
NTLMv2
verifying that authentication is permitted with
Hyper-V configuration 431
O
objects
statistics, determining which are available 333, 448
ODX
considerations for using 396
how it is used with Hyper-V over SMB
configurations 417
how it works 393
improving remote copy performance with 393
use cases for 397
offline
constituents 487
offline files
configuring on a share using the Computer
Management MMC 340
configuring on SMB shares 338
considerations when deploying 337
introduction to using to cache files for offline use
336
Offloaded Data Transfer
See ODX
operations
and mixed state of Infinite Volume 487
oplocks
commands for enabling or disabling for volumes or
qtrees 161
enabling or disabling on existing shares 159
enabling or disabling when creating CIFS shares 158
monitoring 161
write cache data-loss considerations 157
options
configuring CIFS 139
list of CIFS 137
organizational units
See OUs
OUs
moving CIFS servers to different 178
overrides
displaying privilege 256
P
parallel NFS
passwords
changing domain account 178
changing local user 241
requirements for local users 234
resetting domain account 178
paths
commands for managing search 360
performance
how SMB automatic node referrals improve client
399
improving for NFSv3 TCP 110
improving remote copy performance with ODX 393
using oplocks to improve client 157
performing
security traces 307
permissions
effect of security styles on file 24
how Data ONTAP preserves UNIX 31, 116
UNIX, how to manage using Windows Security tab
31
planning
FPolicy configuration overview 533
FPolicy event configuration 539
FPolicy external engine configurations 533

FPolicy policy configurations 545
FPolicy scope configurations 548
tasks for Hyper-V over SMB configurations 424
pNFS
support for 36
policies
adding rules to export 57
adding tasks to security 284, 297
commands for managing security 304
considerations when reverting export, for SMB 227
creating export 57, 212
creating security 283, 296
displaying information about enabled FPolicy 558
displaying information about NFSv4 audit 271
displaying information about NTFS audit 268, 513
enabling FPolicy 554
enabling or disabling FPolicy 555
how FPolicy manages processing multiple FPolicy
526
monitoring jobs, file security and auditing 288, 301
security, applying to Vservers with FlexVol volumes
287, 300
security, commands for managing tasks 304
verifying applied audit 301
policy
FPolicy, information to gather for configuration 547
policy status
displaying information about FPolicy 557
ports
controlling NFS mount requests from nonreserved
83
pre-computing
BranchCache hashes 381
predefined
local groups 234
preferred domain controllers
adding 175
prerequisites
BranchCache 369
for setting up CIFS server 119
Previous Versions
considerations when restoring folders with junctions
349
creating a Snapshot configuration to enable access
348
determining whether Snapshot copies are available

for use 347
recover files and folders with, Microsoft 345
Previous Versions tab
using to view and manage Snapshot copy data 346
priorities
how FPolicy manages processing FPolicy policy 526
privileged data access
super user credentials for FPolicy 526
privileged data access channels
FPolicy connection credentials for 525
how FPolicy uses 525
privileges
adding to local or domain users or groups 253
defined, local 232
displaying overrides 256
how to assign local 233
list of supported local 232
removing from local or domain users or groups 254
resetting for local or domain users or groups 255
profiles
advantages of storing user profiles on roaming 341
configuring roaming 342
requirements for using roaming 341
protocols
how Witness works 412
modifying for Vservers 45, 176
support requirements for BranchCache 367
supported 17
that enable NDOs for Hyper-V over SMB 409
that FPolicy can monitor 523
Q
qtrees
commands for enabling or disabling oplocks on 161
configuring security style on 44, 182
R
read file delegations
read-only bits
explained 93, 322
realm configurations
creating Kerberos 67
reasons
list of, for allowing access 317
list of, for denying access 318
Index | 591
recommendations
for Hyper-V over SMB configurations 423
FPolicy setup 532
SMB signing configuration 152
recover files and folders
Previous Versions 345
redirection
introduction to storing data on a CIFS server using
folder 342
requirements for using folder 343
referrals
enabling or disabling SMB automatic node 402
how they work for NFSv4 105
relative symbolic links
remote copy offload
remote offices
where to find information about configuring
BranchCache at 374
Remote VSS
backups, how SnapManager for Hyper-V manages
416
concepts defined 414
defined 414
example of directory structure used by 415
process when using SnapManager for Hyper-V 416
use for share-based backups of Hyper-V virtual
machines 413
removing
CIFS share properties on existing shares 197
privileges from local or domain groups 254
users from local groups 248
renaming
local groups 246
required password complexity
enabling or disabling for local users 142
required SMB signing
enabling or disabling 141, 154
requirements
BranchCache network protocol support 367
Data ONTAP version requirements for BranchCache
367
for IPv6 with CIFS 163

for SMB automatic node referrals 400
for using folder redirection 343
for using GPOs with CIFS servers 169
for using ODX 395
for using offline files 337
FPolicy setup 531
Kerberos with NFS configuration 63
Previous Versions use 345
when using BUILTIN groups 233
Windows host version requirements for
BranchCache 367
resetting
privileges for local or domain groups 255
privileges for local or domain users 255
resetting and rediscovering
LDAP servers and domain controllers 174
restore
considerations when restoring folders with junctions
with Previous Versions 349
restrictions
authentication-based 17
file-based 18
revert
considerations when there are local users and groups
configured 232
revert considerations
reverting
important FPolicy considerations before 532
process when there are audit-enabled Vservers 520
what happens to BranchCache when 392
roaming profiles
advantages of using to store user profiles 341
configuring 342
root volumes
configuring security style on Vserver 43, 181
routing groups
creating on the Vserver 135
rquotas
S
SACL ACEs
SACLs
adding access control entries to security descriptors
293

commands for managing ACEs in NTFS 303
configuring using the Windows Security tab 508
defined 275
schema templates
commands for managing LDAP client 88
schemas
creating new LDAP client 69
scope
FPolicy, information to gather for configuration 550
scopes
search paths
for home directories, adding 353
security
how security tracing works 305
Kerberos with NFS 62
limitations for using the CLI to set file and folder
275
use cases for using the CLI to set file and folder 275
security access
role authentication plays for 113
security descriptors
adding DACL access control entries to 280
adding SACL access control entries to 293
creating NTFS 278, 291
how used to apply file and folder security 275
security policies
applying to Vservers with FlexVol volumes 287, 300
creating 283, 296
security policy jobs
security policy tasks
security settings
displaying information about CIFS 144
modifying CIFS 140
security style
displaying file security on mixed volumes 262
displaying file security on NTFS volumes 258
displaying file security on UNIX volumes 265
how UNIX file permissions provide access control
over SMB 208
security styles
compared 27, 489

configuring on FlexVol volumes 44, 181
configuring on qtrees 44, 182
configuring on Vserver root volumes 43, 181
how inheritance works 25
how they affect data access 23
how to choose 25
list of in security trace results, effective 316
mixed compared to unified 27, 489
unified 26, 470
when and where to set 25
security trace filters
creating 308
deleting 313
displaying 310
modifying 312
security trace records
deleting 314
deleting all 315
security trace results
displaying 311
security traces
considerations when creating 306
list of effective security styles in trace results 316
list of reasons and locations for allowing access 317
list of reasons and locations for denying access 318
performing 307
results, how to interpret 315
types of access checks monitored 306
security tracing
how it works 305
security types
how client access levels are determined by 53, 216
how to handle clients with unlisted 51, 214
server implementation ID
modifying 97
server key
changing the BranchCache 380
server setup
decisions to make prior to CIFS 119
servers
creating CIFS 127
creating NFS 47
decisions to make prior to setting up network access
for CIFS 130
displaying information about discovered LDAP and
domain controller 173
resetting and rediscovering LDAP and domain
controller 174
Index | 593
when to create FPolicy configurations that use
external FPolicy 530
sessions
displaying information about CIFS 326, 457, 460
displaying information about continuous availability
326, 457, 460
setup
decisions to make prior to CIFS server 119
shadow copies
configuring directory depth of VSS 443
shadow copy
defined 414
shadow copy set
defined 414
share ACLs
Infinite Volume default 470
share configurations
information to gather for SMB over Hyper-V 428
share-based backups
use remote VSS to backup virtual machines 413
shares
adding home directory 352
adding or removing properties on existing CIFS 197
commands for managing CIFS 200
configuring existing, for continuous availability 444
configuring offline files support on 340
configuring offline files support on SMB 338
configuring UNIX symbolic link support on SMB
362
continuously available, creating for Hyper-V over
continuously available, verifying configuration of
Hyper-V SMB 453
creating NTFS data volumes for continuously
available 440
creating SMB 193
default ACL for SMB 190
disabling BranchCache on single SMB 388
enabling BranchCache on existing SMB 376
enabling BranchCache when creating SMB 374
enabling or disabling access-based enumeration on
SMB 406
enabling or disabling oplocks on existing 159
enabling or disabling oplocks on when creating CIFS
158
how to secure with access-based enumeration 405
information needed when creating SMB 192
introduction to enabling BranchCache on SMB 374
naming considerations on CIFS Vservers 191

overview of disabling BranchCache on SMB 387
SMB, configuring BranchCache to enable caching
on a per-share basis or on all shares 370
stopping automatic BranchCache caching on all
SMB 389
what happens if CIFS servers or Vservers are deleted
190
show commands
how they work when displaying FPolicy
configuration 556
SMB
access control lists, creating 201
adding export policy rules for access 220
commands for managing access control lists 201
concepts 113
configuring BranchCache to enable caching on a
per-share basis 370
configuring existing shares for continuous
availability 444
considerations when reverting export policies for
227
creating continuously available shares for Hyper-V
configurations 441
creating Data ONTAP configurations for Hyper-V
over 430
creating shares 193
creating symbolic link mappings 364
enabling or disabling 2.x on Vservers with FlexVol
volumes 148
enabling or disabling 3.0 on Vservers with FlexVol
volumes 149
enabling or disabling export policies 211
enabling or disabling local user authentication 237
how automatic node referrals improve client
response time 399
how Data ONTAP uses share-level ACLs 200
how export polices are used for access 209
how signing policies affect communications 151
how UNIX file permissions provide access control
208
information needed when creating shares 192
Kerberos authentication 114
limits when configuring UNIX symbolic links for
access using 362
monitoring signing statistics 155
NTLM authentication 114
recommendations when configuring Hyper-V over
423

requirements for using folder redirection 343
requirements for using offline files 337
requirements for using roaming profiles 341
requirements when configuring Hyper-V over 419
signing, performance impact of 152
SMB
unsupported 2.0 functionality 145
support for automatic node referrals 401
supported 1.0 functionality 145
supported 2.0 durable handle functionality 145
supported 3.0 nondisruptive operations 147
supported versions for automatic node referrals 400
versions supported on Vservers with FlexVol
volumes 145
versions supported on Vservers with Infinite
Volumes 145
versions that support Previous Versions 345
See also CIFS
SMB 1.0
SMB 2.x
SMB 3 over Hyper-V
SMB 3.0
how functionality supports NDOs for Hyper-V over
SMB 411
SMB access
role export policies play with 115
SMB clients
setting permissions of UNIX users 485
SMB node referrals
considerations and requirements when using 400
SMB over Hyper-V
information to gather for share configuration 428
information to gather for volume creation 427
SMB over Hyper-V configurations
information to gather for volume creation 427
SMB shares
default ACL 190
defined 190
enabling or disabling access-based enumeration on
406
overview of disabling BranchCache on 387

what happens if CIFS servers or Vservers are deleted
190
SMB signing
about using to enhance network security 150
considerations when there are multiple data LIFs 153
Data ONTAP support for 150
enabling or disabling required 141, 154
monitoring statistics 155
recommendations for configuring 152
SnapManager for Hyper-V
how to use to manage Remote VSS-based backups
for Hyper-V over SMB 416
where to find information about configuring 408
SnapMirror
considerations when using on Vservers with local
groups 231
Snapshot copies
configuring to enable Previous Versions access 348
determining availability for Previous Versions use
347
using the Previous Versions tab to view and manage
data in 346
soft mounts 33
staging files
auditing 495
staging volumes
auditing 495
starting
CIFS servers 177
states
mixed state of Infinite Volumes 487
static routes
adding to routing groups on the Vserver 135
statistics
determining which CIFS counters and objects are
available 333, 448
displaying CIFS 335
displaying CIFS and audit 335
displaying NFS 107
displaying SMB 450
using counters to monitor automatic node referral
activity 403
stopping
CIFS servers 177
storage classes
impact on client access to Infinite Volumes 494
requirements for setting up client access 494
Index | 595
super user credentials
for FPolicy privileged data access 526
superuser access
how to configure with export rules 55, 218
support
for IPv6 with CIFS 164
supported
GPOs 168
local privileges 232
supported protocols 17
supported versions
SMB on Vservers with FlexVol volumes 145
SMB on Vservers with Infinite Volumes 145
symbolic link mappings
symbolic links
configuring support for UNIX, on SMB shares 362
creating mappings for SMB 364
limits when configuring for SMB access 362
symlinks
See symbolic links
synchronous
FPolicy applications 524
FPolicy notifications, defined 523
system access control lists
See SACLs
System Access Control Lists
See SACLs
system health monitor
how to determine status of NDOs for Hyper-V over
T
tasks
adding to security policies 284, 297
commands for managing security policy 304
TCP
modifying maximum read and write size for NFSv3
111
modifying NFSv3 maximum read and write size 110
templates
commands for managing LDAP schema 88
trace filters
creating 308
deleting 313
displaying 310
modifying 312
trace records
deleting all 315

deleting security 314
trace results
displaying 311
traces
how to interpret results 315
list of effective security styles in trace results 316
list of reasons and locations for allowing access 317
list of reasons and locations for denying access 318
performing security 307
security, how it works 305
types of security access checks monitored 306
traditional oplocks
transparent failover
how Witness protocol enhances 411
troubleshooting
auditing event log volume space issues 521
issues where aggregates do not have staging volumes
507
staging volume space issues 521
U
unified security style
compared to mixed security style 27, 489
UNIX
adding users to local groups 80
configuring local users and groups 77
creating local groups 79
creating local users 77
how to manage permissions using Windows security
tab 31
loading local groups from URIs 79
loading local users from URIs 78
managing local groups 85
managing local users 85
UNIX clients
setting mode bits 483
UNIX file permissions
how they provide access control over SMB 208
UNIX permissions
how Data ONTAP preserves 31, 116
UNIX symbolic links
configuring support for, on SMB shares 362
guidelines for configuring for SMB access 362
UNIX users
setting permissions in SMB clients 485

unmounting
volumes in NAS namespaces 40, 185
unsupported features
Windows 118
updates
how performed for GPOs on a CIFS server 170
updating
domain user and group objects in the local databases
251
GPO settings manually 170
URIs
loading local UNIX groups from 79
loading local UNIX users from 78
loading netgroups into Vservers from 81
use cases
for using the CLI to set file and folder security 275
user access tokens
how they are constructed 231
user accounts
deleting local 244
user ID domains
specifying for NFSv4 66
user mapping
users
adding privileges to local or domain 253
adding to local UNIX groups 80
changing local account passwords 241
creating local accounts 238
deleting CIFS servers, what happens to local 231
deleting local accounts 244
displaying information about local 242
enabling or disabling local accounts 241
how access tokens are constructed for local 231
local, displaying information about local group
membership 243
local, how authentication works 230
local, UNIX, configuring 77
modifying, renaming, enabling, or disabling local
accounts 240
password requirements for local 234
removing privileges from local or domain 254
resetting privileges for local or domain 255
revert considerations when there are local 232
UNIX, creating local 77
UNIX, loading local from URIs 78
updating names in the local databases for domain
251
users and groups
local, defined 228
using
Previous Versions tab to view and manage Snapshot
copy data 346
V
verifying
applied audit policies 301
applied file security 288
auditing configuration 506, 517
automatic node referrals are disabled for Hyper-V
over SMB configurations 437
CIFS option settings for Hyper-V over SMB
configurations 436
continuously available configuration of Hyper-V
SMB shares 453
Hyper-V computer accounts map to the default
UNIX user 433
Hyper-V configurations, volumes are created with
NTFS security style 435
Kerberos and NTLMv2 authentication are permitted
with Hyper-V configuration 431
LIF status for Hyper-V configuration 455
status of netgroup definitions 86
versions
supported BranchCache 366
view
local users and groups from the Microsoft
Management Console 232
VMware
enabling or disabling vStorage over NFS 108
supported vStorage APIs for NFS 108
volume junctions
defined 19
how used in CIFS and NFS server namespaces 20
volumes
associating export policy to FlexVol 61, 224
commands for enabling or disabling oplocks on 161
creating continuously available shares for NTFS data
440
creating with specified junction points 38, 183
creating without specified junction points 39, 184
display information about NTFS, UNIX, and mixed
security-style FlexVol 257
displaying mount and junction point information 42,
186
how to control client access with export policies 48
mounting and unmounting in NAS namespaces 40,
185
Index | 597
verifying that they are created with NTFS security
style for Hyper-V 435
Vservers
adding CIFS preferred domain controllers 175
adding default gateways and static routes to routing
groups on 135
applying GPOs to CIFS servers 167
commands for modifying auditing configurations
519
configuring security style on root volume 43, 181
creating a file and directory auditing configuration
on 504
creating data LIFs for CIFS server 133
creating for CIFS server 124
creating Kerberos configuration for 69
creating routing groups on 135
default export policy for 49, 210
enabling and disabling auditing on 516
enabling auditing on 506
enabling LDAP on 72
how FPolicy works across namespaces 528
loading netgroups into 81
modifying protocols 45, 176
moving CIFS servers to different OUs 178
NIS domain configuration, creating 81
revert process when there are audit-enabled 520
stopping or starting the CIFS server s 177
what happens to SMB shares when deleting 190
applying security policies to 287, 300
default export policy for 49, 210
Vservers with Infinite Volume
export policies 468
Vservers with Infinite Volumes
CIFS support 466
default junction for 467
file permissions 469
mount point 467
namespace 467
NFS support 465
See also Infinite Volumes
VSS shadow copies
configuring directory depth 443

VSS shadow copy
vStorage
enabling or disabling over NFS 108
supported APIs for NFS 108
W
widelinks
how SMB clients can access UNIX symbolic links
361
Windows
unsupported features 118
Windows clients
how SMB signing policies affect SMB
communication 151
where to get information about configuring
BranchCache on 374
Windows groups
deleting local 250
Windows user accounts
creating local 238
Windows users
setting NTFS file permissions on Infinite Volumes
484
Witness protocol
how it enhances transparent failover 411
how it works 412
worksheet
completing the auditing configuration 504
worksheets
completing CIFS server network setup 130
completing CIFS server setup configuration 120
write cache
data loss considerations when using oplocks 157
write file delegations
X
XML
supported audit event log file format 498

Clustered Data ONTAP 82 File Access and Protocols

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Clustered Data ONTAP 82 File Access and Protocols

Transféré par

Droits d'auteur :

Formats disponibles

Clustered Data ONTAP 8.

Telephone: +1(408) 822-6000

Part number: 215-07968_A0

How Data ONTAP supports file access using NFS ................................. 34

4 | File Access and Protocols Management Guide

Setting up file access using NFS ................................................................ 38

Managing file access using NFS ................................................................ 83

6 | File Access and Protocols Management Guide

SMB file access concepts .......................................................................... 113

Configuring CIFS servers ........................................................................ 118

Setting up file access using SMB ............................................................. 181

8 | File Access and Protocols Management Guide

Managing file access using SMB ............................................................. 228

10 | File Access and Protocols Management Guide

Deploying CIFS client-based services ..................................................... 336

Deploying CIFS server-based services ................................................... 350

12 | File Access and Protocols Management Guide

File access to Infinite Volumes ................................................................ 465

14 | File Access and Protocols Management Guide

Using FPolicy for file monitoring and management on Vservers with

16 | File Access and Protocols Management Guide

Glossary ..................................................................................................... 563

Considerations before configuring file access

File protocols that Data ONTAP supports

How Data ONTAP supports file access using NFS on page 34

How Data ONTAP controls access to files

18 | File Access and Protocols Management Guide

LIF configuration requirements for file access management

Considerations before configuring file access | 19

How namespaces and volume junctions affect file access on

What namespaces in Vservers with FlexVol volumes are

What volume junctions are

20 | File Access and Protocols Management Guide

What the typical NAS namespace architectures are

Namespace with single branched tree

Considerations before configuring file access | 21

Namespace with multiple branched trees

22 | File Access and Protocols Management Guide

Namespace with multiple stand-alone volumes

Considerations before configuring file access | 23

How security styles affect data access

Configuring security styles on page 43

24 | File Access and Protocols Management Guide

What the security styles and their effects are

Clients that can

NFSv3 mode bits

NFS and CIFS

NFSv3 mode bits

NFSv3 mode bits

Considerations before configuring file access | 25

Where and when to set security styles

How to decide on what security style to use on Vservers with FlexVol

The file system is managed by a UNIX administrator.

The file system is managed by a Windows administrator.

How security style inheritance works

26 | File Access and Protocols Management Guide

How unified security style supports multiprotocol access to Infinite

Displaying permissions on all files

Support for UNIX principals in NTFS file permissions

Considerations before configuring file access | 27

Comparison of unified and mixed security styles

Of a file that uses NTFS file permissions Of a file that has

The outcome is the same: the user's

The outcome is the same: the user's