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 Managing the Trustee Rights in the NSS File System and rights in the OES 2018 SP1: 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. The CIFS access can be set up by using Novell CIFS or using Novell Samba, but OES does not support using both of these CIFS user access solutions on the same server. In this guide, Novell Samba access is referred to as SMB/CIFS. NCP Server is required to be installed and running even if all users access data via Novell CIFS or Novell Samba.
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 2018: SP1 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 2018: SP1 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.
NetStorage: NetStorage for Linux has limited use for accessing files on shadow volumes. NetStorage presents a merged view of the data, and the user can see, read, and write files. However, certain management functions (such as getting file properties, setting trustees, and salvaging files) work only if the files are on the primary volume. The user will find that the commands work for some files but not others because they are not aware of where the file is physically stored. For information about using NetStorage, see OES 2018 SP1: NetStorage Administration Guide for Linux.
Novell CIFS supports use of NSS volumes in a DST shadow volume configuration. It supports the following DST features:
Merged View: Novell 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 Novell 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 Novell 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.
Novell 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 Novell CIFS for use with DST volumes:
Novell CIFS supports only NSS volumes on Linux. Thus, Novell 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 Novell 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 Novell CIFS with a DST volume in a cluster, you need to add the Novell CIFS lines in the load/unload scripts for the DST cluster resource. The differences are described in Section 15.0, Configuring DST Shadow Volume Pairs with Novell Cluster Services.
You cannot configure Novell CIFS and the SMB/CIFS setup on the same server. This limitation is derived from the requirement that Novell Samba and Novell CIFS cannot be installed on the same server, and is unrelated to DST.
Novell Samba is supported for providing SMB/CIFS user access to shadow volumes. This Samba version is the standard Linux Samba that has been integrated with eDirectory. For information, see the OES 2018: Novell Samba Administration Guide.
In order for SMB/CIFS users to see a merged view of the shadow volume, you must also set up ShadowFS (Shadow File System) and FUSE (File System in Userspace). See Section 13.0, Using ShadowFS to Provide a Merged View for Novell Samba Users for installation and configuration requirements.
SMB/CIFS users must be Linux-enabled users of the OES server. The Linux Samba service must also be LUM enabled. For information, see the OES 2018 SP1: Linux User Management Administration Guide.
Enable the cross-protocol file locking parameter for NCP Server. For information, see Configuring Cross-Protocol File Locks for NCP Server
in the OES 2018: SP1 NCP Server for Linux Administration Guide.
Novell AFP (Apple Filing Protocol) does not support DST shadow volumes. AFP users are able to see only the data that is on the primary volume. Do not create AFP shares on the primary or secondary volumes that are used in a DST shadow volume.
Supported Linux file access protocols include SSH and Novell FTP (Pure-FTPd). You must use ShadowFS and FUSE on the system to provide a merged view for SSH and FTP users. In addition, the eDirectory users and the native Linux service must be enabled with Linux User Management (LUM). ShadowFS must be running in order for the users to access the data.
IMPORTANT:This configuration works best when you use only NCP for normal user access, or if you must allow CIFS access, you use Novell Samba instead of Novell CIFS.
User access to shadow volumes via all other native Linux protocols (such as HTTP, NFS, and others) is not supported.
The Shadow File System (ShadowFS) works with FUSE (File System in Userspace) to provide a merged view of the shadow volume tree for eDirectory users of native Linux file access protocols, including Novell Samba (SMB/CIFS) and supported Linux file access protocols, such as SSH and Novell FTP (Pure-FTPd). ShadowFS requires that eDirectory users and the native Linux service be enabled with Linux User Management (LUM). ShadowFS must be running in order for the SMB/CIFS users to access the data.
When ShadowFS is running, it automatically creates a shadow file system directory for each of the shadow volumes, not just the ones where you plan to allow SMB/CIFS access. SMB/CIFS users see only those volumes where they have file system trustee rights.
ShadowFS requires FUSE (File System in Userspace) to be installed and running. For information, see Section 13.0, Using ShadowFS to Provide a Merged View for Novell Samba Users.