PowerStore file supports SMB1 through 3.1.1. SMB3 enhancements such as continuous availability, offload copy, protocol encryption, multichannel, and shared VHDX in Hyper-V are supported on PowerStore.
The SMB option on the NAS server enables or disables SMB connectivity to the file systems. The SMB version that is negotiated depends on the client operating system:
Due to the age of the protocol and potential security vulnerabilities, client access using SMB1 is disabled by default. If client access using SMB1 is required, it can be enabled by modifying the cifs.smb1.disabled parameter. Using SMB2 at a minimum is recommended as it provides security enhancements and increases efficiency compared to SMB1.
NAS servers use SMB2 to communicate with the domain controllers for operations such as authentication, SID lookups, Group Policies, and so on. If SMB2 is not available, the NAS server attempts to use SMB1 as a backup option. Therefore, any domain controllers that are running older operating systems that only support SMB1 can continue to function.
When enabling SMB support on a NAS server, the SMB server can either be stand-alone or Active Directory domain-joined. Domain-joined NAS servers require DNS to be configured, but this configuration is optional for stand-alone SMB servers. Domain-joined NAS servers are placed in the CN=Computers container, by default. When joining an SMB server to the domain, the computer object can be configured to be stored in a different OU location in the advanced settings.
Support for advanced SMB protocol options is also available. Table 2 shows a list of SMB protocol options, where they are configured, and the default setting for each option.
Protocol option | Level | Default |
Sync Writes Enabled | File system | Disabled |
Oplocks Enabled | File system | Enabled |
Notify on Write Enabled | File system | Disabled |
Notify on Access Enabled | File system | Disabled |
Continuous Availability | Share | Disabled |
Protocol Encryption | Share | Disabled |
Access-Based Enumeration | Share | Disabled |
Branch Cache Enabled | Share | Disabled |
Offline Availability | Share | None |
UMASK (Multiprotocol) | Share | 022 |
Synchronous writes enable the storage system to perform immediate synchronous writes for storage operations, regardless of how the SMB protocol performs write operations. Enabling synchronous writes operations allow you to store and access database files (for example, MySQL) on storage system SMB shares. This option guarantees that any write to the share is done synchronously and reduces the chances of data loss or file corruption in various failure scenarios, for example, loss of power. If SMB3 Continuous Availability (CA) is enabled, all write operations are automatically synced to satisfy the requirements for CA. This option can have a big impact on performance. It is not recommended unless you intend to use Windows file systems to provide storage for database applications.
Opportunistic file locks (oplocks) allow SMB clients to buffer file data locally before sending it to a server. SMB clients can then work with files locally and periodically communicate changes to the storage system rather than having to communicate every operation over the network to the storage system. Unless your application handles critical data or has specific requirements that make this mode or operation unfeasible, leaving the oplocks enabled is recommended.
The following oplocks implementations are supported:
This option only applies to client access over SMB1 since oplocks are always enabled for client access over SMB2 and SMB3. However, disabling this option also invalidates the SMB2.1 file and directory lease feature. Leasing serves the same purpose as oplocks, but provides greater flexibility and enhancements, increasing performance and reducing network utilization.
This option enables notifications when a file system is written to or accessed. Applications that run on Windows platforms, and use the Win32 API, can register with the SMB server to be notified of file and directory content changes, such as file creation, modify, or rename. For example, this feature can indicate when a display must be refreshed (Windows Explorer) or when the cache must be refreshed (Microsoft Internet Information Server), without having to constantly poll the SMB server.
Continuous availability is a share-level SMB3 feature. In a client or storage processor failure, CA allows persistent access to file systems without loss of the session state. This ability is useful for critical applications such as Microsoft Hyper-V or SQL, where constant availability to files is of the upmost importance. SMB3 uses persistent handles to enable the NAS server to save specific metadata that is associated to an open handle on disk. In a node failure, applications accessing open file content are not affected if the NAS server and file system failover to the peer node completes within the timeout of the application. This action results in clients transparently reconnecting to the peer node after the NAS server failover without affecting client access to files.
Continuous availability is also available on the client side, which is independent from storage CA. Client CA transparently preserves access in a node failure within a client application cluster. When a failure of one node in the cluster occurs, the application is moved to the other node and reopens its content on the share from that node using its originally assigned ApplicationID without an interruption in access. The CA option on the share does not need to be enabled to use client CA.
SMB 3.1.1 adds a reliability enhancement for Continuous Availability for Hyper-V Cluster Client Failover by adding an ApplicationInstanceVersion tag in addition to the ApplicationID. The ApplicationInstanceVersion tag is incremented each time that an application is restarted on a new node within the cluster. In situations where network access is lost, but storage access remains available, the application may be restarted on a new node without the cluster knowing due to the lack of network access. The ApplicationInstanceVersion tag enables the storage system to easily identify which node in the cluster is the correct owner of the application. The storage system can safely close any locks that were opened with a lower ApplicationInstanceVersion number, which allows the application to restart without any conflicts.
Protocol encryption is a share-level SMB3 feature, which provides in-flight data encryption between SMB3 clients and the NAS server. The client or NAS server encrypts the data before sending it to the destination. It is then decrypted upon reaching its destination, whether that is the NAS server or SMB client. The protocol encryption is enforced at user session level, ensuring the whole SMB traffic is encrypted once the user session is established.
The following setting can be configured in the NAS server registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\RejectUnencryptedAccess: Determines if clients that do not support encryption (pre-SMB3.0) have access to the share.
SMB 3.1.1 also provides improved security and encryption traffic performance for SMB3 by changing the encryption algorithm from AES-CCM-128 to AES-GCM-128. This change improves performance under certain conditions such as large file transfers. It also improves security against man-in-the-middle attacks.
Access-based enumeration is a share-level option that restricts the display of files and folders based on the access privileges of the user attempting to view them. Without access-based enumeration, all users can view all files and folders within a directory. However, they cannot open or view these files and folders without the appropriate access privileges. When access-based enumeration is enabled on a share, users can only see files or folders for which they have at least read access.
For example, without access-based enumeration, a user could see all files in a directory, regardless of whether they can open them. However, with access-based enumeration, the inaccessible files are hidden from the user view. Administrator users are always able to see all files and folders, even when access-based enumeration is enabled on a share.
BranchCache is a share-level option that allows users to access data that is stored on a remote NAS server locally over the LAN without being required to traverse the WAN to access the NAS server. This ability is useful in a remote or branch office environment, where branch offices are required to access data stored on PowerStore at the main office. BranchCache allows this data to be cached locally at the branch, either by a designated Windows BranchCache server or distributed across Windows clients. This ability can reduce WAN bandwidth that is used by many clients constantly and repeatedly traversing the WAN for the same data.
With BranchCache enabled, the client uses the WAN to retrieve the hash of the file from the NAS server at the main office. The client searches the local file cache to look for a file with a matching hash. If all or some of the data is available locally, either on the designated Windows BranchCache server or another Windows client system, the data is retrieved locally. The data is validated using a hash function to ensure that the file is the same. Any data that is not cached locally is retrieved from the NAS server over the WAN, and then cached locally for future requests. BranchCache works best for data that does not change often, allowing files to be cached for longer periods of time at the branch offices.
Offline availability is a share-level option that allows administrators to determine if and how files and programs in a share are available when offline. This ability allows users to access shares on a server even when they are not connected to the network by storing a version of the share in a local cache on the client system. For offline availability to function, it must be configured on both the share and the individual client systems accessing the share.
SMB shares support four options for offline availability:
PowerStore also supports the Microsoft Distributed File System (DFS) namespace. This ability enables the administrator to present shares from multiple file systems through a single mapped share. PowerStore SMB servers can be configured as a stand-alone DFS root node or as a leaf node on an Active Directory DFS root. DFS-R (replication) is not supported on PowerStore SMB servers.
File extension filtering enables restricting specific file extensions from being stored on an SMB share. Traditionally, this feature has been used to prevent users from storing non-business data on a share. It can also be used to block malicious extensions from being written to a share.
Disallowing known ransomware extensions from being written to the file system can be a simple and effective mechanism to deter or prevent ransomware. File extension filtering can be leveraged in conjunction with other features such as CEPA to implement a ransomware strategy with multiple layers of defense.
To configure file extension filtering, go to the \\<SMB_Server>\c$\.etc\.filefilter directory as an administrator. To configure a filter, create an empty file using the naming convention extension@sharename. For example, to filter .wcry ransomware files on the FS1 share, create a file named wcry@FS1. To enable the filter on all shares on the SMB server, create the file with only the extension, such as wcry.
You can configure multiple filters by creating additional files in this directory. For ransomware prevention use cases, create additional filters for other known ransomware extensions. Each SMB server has its own independent file extension filtering configuration so each can be customized with its own configuration. The following figure shows an example of the configuration of the file extension filtering.
After configuring a file extension filter, you can permit exceptions for specific users or groups. This action is done by changing the ACL on the filter file to provide Full Control privileges to the users or groups that should be excluded. For example, if the Administrators group is provided Full Control permissions on the wcry filter file, then users in the Administrators group can store .wcry files on the share, while others cannot. Exceptions can be configured independently for each file filter being created, as shown in the following figure.
When users attempt to copy a file with a blocked extension, they receive an access denied error, as shown in the following figure.
SMB share permissions determine the permissions that are allowed on the root of the share. When a new SMB share is provisioned, the default permissions allow full control for everyone. These permissions can be modified by using Microsoft Management Console (MMC) – Computer Management on a Windows client to connect to the SMB server, as shown in Figure 16. However, this method requires the storage administrator to have access and credentials to a Windows client.
Starting with PowerStoreOS 3.5, SMB share permissions can also be configured directly from PowerStore Manager or REST API, enabling the storage administrator to set SMB share permissions without relying on external clients, tools, and Windows credentials. Depending on the organizational structure, it might also eliminate the need to engage with the Windows administration team.
This functionality is being added to the existing functionality to increase flexibility for the administrator. The existing functionality remains available and is unchanged. This feature only applies to SMB share-level permissions. Shares for individual files and folders in the share must still be set from within a Windows client.
SMB share permissions are controlled by Access Control Entries (ACEs) and an Access Control List (ACL). Each ACE contains a trustee and its respective permissions. The ACL is a collection of all the ACEs for the SMB share. Each ACE requires the following parameters:
By default, a new share has one ACE:
ACEs in the ACL are applied according to Microsoft Windows rules, meaning that denied permissions are applied first and allowed permissions are applied second. If a conflict occurs, the denial is enforced. For example, if a user belongs to two groups where one group is allowed and the other is denied, access is denied.
To view the ACL for an SMB share, go to Storage > File Systems > SMB Shares > Select an SMB share > More Actions > Access Control List. Figure 17 shows the ACL for an SMB share.
New ACEs can be created by clicking Add ACE. Figure 18 shows the fields required to add an ACE. Existing ACEs can be modified and deleted by clicking the respective buttons. Under More Actions, clicking Refresh ACL refreshes the listing and displays any changes that might have been made elsewhere, such as from MMC. Once all the necessary changes are made, click Apply to implement the updates and make them visible from other instances of PowerStore Manager, REST API, and MMC.
SMB share permissions can also be viewed, added, changed, and removed using REST API. Since REST API uses JSON formatting, certain special characters need to be escaped out using a backslash. Spaces and dashes are commonly used in names and SIDs and do not need to be escaped out. However, the backslash character that is used to identify users and groups needs to be escaped out. This action results in a double backslash in the REST API query body and response, as shown in the SwaggerUI example in Figure 19.