All user and administration access to data is intended to be through the merged view of DST shadow volume pair. Users should never have direct access to the secondary volume. Consider the guidelines in this section when planning how to provide access to the merged view of data in the DST shadow volume.
Administrators should manage files, directories, and authorization via the merged view of the DST shadow volume pair. Ensure that you use tools that support the merged view, such as the NCP client and tools described in Section 6.0, Management Tools for DST.
File system access rights are based on the OES Trustee Model just as they are for a single NSS volume. You must connect to the share on the primary volume by using the Client for Open Enterprise Server or similar NCP client tools, and then set permissions while working in the merged view of the data. The permissions for data on both locations are saved on the primary volume. Dynamic Storage Technology uses those permissions to control access to data stored on the secondary volume. The XML file that contains trustees and trustee rights settings is copied to the secondary volume.
All users (except the root user) of the DST volume pair must have User objects defined in eDirectory. NSS volumes by design are not visible to any locally defined user except the root user when accessing files natively from the server. The root user of the server is the only local user who has direct access to the Linux file structure view of the two volumes.
All the Active Directory users can now access the data on DST volumes via CIFS. To manage the rights of the Active Directory trustees on the DST volumes, you can use OES File Access Rights Management (NFARM) utility or rights utility. For more information, see OES File Access Rights Management (NFARM) in the OES 23.4: NSS File System Administration Guide for Linux.
Some management tasks are performed as the root user; they require direct access to the secondary volume:
Volume backup and restore
For information, see Section 9.13, Using Backup Utilities with DST Shadow Volume Pairs and Section 10.11, Backing Up DST Shadow Volumes.
Duplicate files management
For information, see Section 7.3, Resolving Instances of Duplicate Files.
All user file access to data on the DST volume pair is done via the merged view. Users connect to a share on the primary volume to see the merged view.
File system access rights are based on the OES Trustee Model just as they are for a single NSS volume. Trustees and trustee rights are set from the merged view of the DST shadow volume pair. DST enforces those settings whether the file resides on the primary volume or secondary volume.
All the Active Directory users can now access the data on DST volumes via CIFS. To manage the rights of the Active Directory trustees on the DST volumes, you can use OES File Access Rights Management (NFARM) utility or rights utility.
All eDirectory users (except the root user) of the DST volume pair must have User objects defined in eDirectory.
A merged user view of the file system is available for both NCP and CIFS users. OES CIFS is used to establish CIFS access. NCP Server is required to be installed and running for users to access data via OES CIFS.
This section describes the requirements and guidelines for file access protocols:
When users access the files via multiple protocols, you should enable the NCP Server Cross-Protocol File Locks option to protect against data corruption. For information, see Configuring Cross-Protocol File Locks for NCP Server
in the OES 23.4: NCP Server for Linux Administration Guide.
The DST Shadow Volumes engine supports file access for NCP users. Users access data via an NCP share on the primary storage location, by using the Client for Open Enterprise Server or other NCP clients. For information about configuring NCP Server for the OES server, see the OES 23.4: NCP Server for Linux Administration Guide.
Client for Open Enterprise Server: See the following resources for the latest release of the Client for Open Enterprise Server, which provides NCP access for users on Windows clients:
Only NCP client versions that are configured to receive broadcast messages are eligible to receive the duplicate file conflict messages. For information, see Section 7.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts.
OES CIFS supports use of NSS volumes in a DST shadow volume configuration. It supports the following DST features:
Merged View: OES CIFS works with NCP Server to provide a merged view of the two NSS volumes. CIFS users can access data on both volumes via a OES CIFS share on the primary NSS volume.
Duplicate Files: CIFS can handle duplicate files, but it does not support the broadcast message notification via NCP. It shows the instance of the file on the primary volume to users. The administrator or user can rename the file so that the secondary instance of the file is again visible. The user can then determine which instance to delete.
If the global policy is set to hide duplicate files, CIFS moves the files on the secondary volume to the /._DUPLICATE_FILES folder where the administrator can access them for recovery, if necessary.
Global DST Policies: When users access or modify files, CIFS honors the global DST policies for moving files from the secondary volume to the primary volume.
Setting up OES CIFS for use with a DST shadow volume is similar to setting up CIFS for an NSS volume. You create the CIFS share on the primary volume, but not on the secondary volume. Enable the cross-protocol file locking parameter for NCP Server on the DST server.
OES CIFS features should work as expected, including cross-protocol file locking. The key difference is that users access the merged view of data in both volumes via the CIFS share on the primary NSS volume. The users do not know that the data is stored on two different volumes.
For information, see the following:
Consider the following requirements when configuring OES CIFS for use with DST volumes:
OES CIFS supports only NSS volumes on Linux. Thus, OES CIFS can be used only with DST volumes built on NSS volumes.
CIFS users access a merged view of the DST shadow volume by using a OES CIFS share on the primary volume. Create a CIFS share on the Primary volume only; delete the share on the secondary (or do not give users rights to access the secondary share).
CIFS users don't see broadcast messages if the Broadcast Messages for Duplicate Files Conflicts feature is enabled for Duplicate Files errors. This DST option works only for Client for Open Enterprise Server users as described in Section 7.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts. If you have only CIFS users and no NCP users, you might as well disable the broadcasting option.
If you use OES CIFS with a DST volume in a cluster, you need to add the OES CIFS lines in the load/unload scripts for the DST cluster resource. The differences are described in Section 16.0, Configuring DST Shadow Volume Pairs with OES Cluster Services.