Rehost an SMB volume
You can rehost a volume that serves data using the SMB protocol. To allow clients to continue accessing the data after the rehosting operation, you must manually configure policies and the associated rules.
-
Rehosting is a disruptive operation.
-
If the rehosting operation fails, you might need to reconfigure the volume policies and the associated rules on the source volume.
-
If the source SVM and destination SVM Active Directory domains differ, you might lose access to the objects on the volume.
-
Beginning in ONTAP 9.8, rehosting a volume with NetApp Volume Encryption (NVE) is supported. If you are using an onboard key manager, the encrypted metadata will be modified during the rehost operation. User data is not changed.
If you are using ONTAP 9.8 or early, you must unencrypt the volume before performing the rehost operation.
-
When the source SVM has local users and groups, the permissions for the files and directories (ACLs) that are set are no longer effective after volume rehost operation.
The same is true for audit ACLs (SACLs)
-
After the rehost operation, the following volume policies, policy rules, and configurations are lost from the source volume, and must be manually reconfigured on the rehosted volume:
-
Volume and qtree export policies
-
Antivirus policies
-
Volume efficiency policy
-
Quality of service (QoS) policies
-
Snapshot policies
-
Quota rules
-
ns-switch and name services configuration export policy and rules
-
User and group IDs
-
-
Volume must be online.
-
Volume management operations, such as volume move or LUN move, must not be running.
-
Data access to the volume that is being rehosted must be stopped.
-
The ns-switch and name services configuration of the target SVM must be configured to support data access of the rehosting volume.
-
The source SVM and destination SVM must have the same Active Directory and realmDNS domain.
-
The user ID and group ID of the volume must be either available in the target SVM or changed on the hosting volume.
If local users and groups are configured, and if there are files and directories on that volume with permissions set for those users or groups, these permissions are no longer effective.
-
Record information about the CIFS shares to avoid losing information on CIFS shares in case volume rehost operation fails.
-
Unmount the volume from the parent volume:
volume unmount
-
Switch to the advanced privilege level:
set -privilege advanced
-
Rehost the volume on the destination SVM:
volume rehost -vserver source_svm -volume vol_name -destination-vserver destination_svm
-
Mount the volume under the appropriate junction path in the destination SVM:
volume mount
-
Create CIFS shares for the rehosted volume:
vserver cifs share create
-
If the DNS domains differ between the source SVM and destination SVM, create new users and groups.
-
Update the CIFS client with the new destination SVM LIFs and junction path to the rehosted volume.
You must manually reconfigure the policies and the associated rules on the rehosted volume.