Manage the SMB protocol
The WEKA configuration of the SMB protocol for shared Windows clients.
SMB (Server Message Block) is a network file-sharing protocol that facilitates connections to shared file and print services from remote systems. WEKA's implementation features a modern SMB stack (SMB-W), with the option to use the legacy open-source Samba stack if required. Both WEKA SMB implementations fully support SMB versions 2 and 3.
WEKA's SMB implementation enables seamless access to storage services for both Windows and macOS clients. It facilitates shared access from multiple clients, supporting a multi-protocol approach that allows files to be accessed simultaneously through SMB, NFS, and WEKA native filesystem drivers.
Key features of SMB implementation in WEKA
The implementation of SMB in the WEKA system is characterized by scalability, resilience, and distribution.
Scalability: WEKA supports an SMB cluster ranging from 3 to 8 servers, with the SMB gateway service running on these servers. The backend filesystem can be any WEKA filesystem, making it unlimited in size and performance.
Resilience: WEKA's SMB implementation provides clustered access to files in a WEKA filesystem, allowing multiple servers to collaborate. In a server failure, another can seamlessly take over operations, ensuring failover support and high availability. The standard resiliency of WEKA against failures also extends to SMB filesystems, with SMB-W supporting transparent failover for enhanced resilience compared to legacy SMB.
Distribution: A WEKA implementation is distributed over a cluster, where all servers manage all SMB filesystems concurrently. This design allows the performance supported by SMB to scale with additional hardware resources, ensuring high availability. SMB-W introduces support for SMB Multichannel and SMB Direct, providing advanced capabilities compared to the legacy SMB.
Additional features of SMB-W
In addition to legacy SMB features, SMB-W introduces the following capabilities:
SMB multichannel: WEKA supports SMB clients configured with multichannel, enhancing performance in such configurations.
High availability and failover support: If a server running an SMB-W container becomes isolated from the cluster, the container stops. Other servers in the SMB cluster take over operations, ensuring continuous service availability (to manually recover a stopped SMB-W container, run: weka local restart smbw).
SMB Direct: SMB over Remote Direct Memory Access (RDMA). To enable SMB Direct, ensure the following prerequisites are met:
SMB-W servers are RDMA-enabled in both hardware and OS.
For Windows clients, configure the SMB client as multichannel.
When configuring a CIFS client to work with RDMA, perform the mounting on the host IP (not the floating IP).
SMB usage considerations
When working with SMB clusters, it's important to understand the following points to ensure smooth management and configuration:
The default SMB cluster configuration is SMB-W. Contact the Customer Success Team if you need to create a legacy SMB cluster.
When managing an SMB-W cluster through the GUI, any limitations in the CLI for SMB-W also apply.
You can manage, but not configure or delete, legacy SMB clusters through the GUI. For configuration and deletion, refer to Manage SMB using the CLI.
Use ASCII format when configuring name fields, such as domain and shares.
Public cloud requirements: Ensure Active Directory and DNS services are configured before installing the WEKA SMB protocol.
SMB user mapping in the WEKA system
Authentication in the WEKA SMB system is supported by a single Active Directory with multiple trusted domains. To enable SMB access, the Active Directory must resolve POSIX users (uid) and groups (gid) mapping.
ID mapping from Active Directory
The WEKA system automatically pulls user and group information from the Active Directory, supporting two types of id-mapping:
RFC2307: Requires
uidNumberandgidNumberto be defined in the AD user attributes.rid: Creates a local mapping with AD users and groups. Using rid mapping simplifies configuration as user IDs are automatically tracked. All domain user accounts and groups become available on the domain member without additional attribute settings. However, changes to the rid AD range configuration may result in altered user mapping and incorrect uid/gid resolution.
Active Directory attributes
For RFC2307, the following Active Directory attributes are relevant for users:
uidNumber
0-4290000000
gidNumber
0-4290000000; must correlate with a real group
For groups of users according to RFC2307:
gidNumber
0-4290000000
ID range configuration
The default configuration for the WEKA system's AD server IDs can be changed and serves as the primary AD range (if additional trusted domains are defined).
To avoid ID overlapping and collisions, set the range or ranges for multiple domains.
When joining multiple domains, the ID range must be set for each, ensuring they do not overlap. A configurable default mapping range exists for users not part of any domain.
For more details about Active Directory properties, refer to the Microsoft site.
Workflow overview: configure SMB support
Before you begin
Workflow
Configure SMB cluster: Set the WEKA system servers participating in the SMB cluster and the domain name.
In on-premises deployments, it is possible to configure a list of public IP addresses distributed across the SMB cluster. If a server fails, the IP addresses from that server are reassigned to another server.
Join the SMB cluster to the Active Directory (AD) domain: Connect and define the WEKA system in the AD domain. This process includes pre-configuration in the and post-configuration in the DNS Manager and Active Directory.
Create shares and folders and set permissions: By default, the filesystem permissions are root/root/755 and can initially only be set by a WekaFS/NFS mount.
Once these steps are completed, you can connect as an administrator and define permissions through the Windows operating system.
Round-robin DNS server configuration for SMB load balancing
For effective load balancing across multiple WEKA servers serving SMB, it is recommended to configure a round-robin DNS entry that resolves to the list of floating IPs.
Follow these steps to optimize the DNS configuration:
Configure round-robin DNS entry: Set the round-robin entry to distribute the load evenly among the WEKA servers. This entry must resolve to the list of floating IPs associated with the SMB servers. Ensure the cluster name matches the DNS name, with a maximum length of 15 characters.
Adjust TTL (Time to Live): To prevent caching of IP addresses by clients or DNS servers, set the TTL for all records assigned to the SMB servers to 0 (Zero). This ensures dynamic and real-time resolution of IPs for efficient load balancing.
Related information
For more details on round-robin DNS configurations, refer to the relevant documentation or resources related to round-robin DNS.
SMB share creation
After setting up the SMB cluster, you can create SMB shares. Each share must be assigned a name and a shared path to the filesystem, which can be either the filesystem's root or a sub-directory.
If a share is created without specifying a sub-directory, the root of the filesystem is automatically used, and creating a separate root folder is unnecessary.
To create sub-directories, mount the filesystem locally or through the shell, then create the desired sub-directories and adjust their permissions as needed.
Filesystem permissions and access rights configuration
When integrating the SMB cluster with Active Directory, administrators can configure permissions and access rights for SMB cluster filesystems, ensuring proper access control for users and groups. WEKA provides flexibility in managing these permissions through POSIX guidelines and Windows Access-Control Lists (ACLs), allowing seamless interoperability between systems.
POSIX permissions and Windows integration
Permissions for SMB shares in WEKA adhere to POSIX standards, with Windows permissions stored and translated within the POSIX system. Any modifications to Windows permissions are automatically synchronized with POSIX permissions, ensuring consistent access control across environments. Administrators can configure initial POSIX permissions through the driver/NFS interface.
Root access to SMB shares
To grant root-level access to specific users, assign an Active Directory user with a uidNumber and gidNumber both set to 0. This setup provides full administrative control over the shares.
Access Control Lists (ACLs)
The ACL feature enables administrators to manage more granular permissions for SMB shares on for SMB-W clusters only. Users can select one of the following options when configuring ACLs:
ACLs enabled: Enable or disable Windows Access-Control Lists (ACLs) for the share. When enabled, the Access Control Model option is applied.
Access control model: Defines the type of access control used for the share. The available options are:
POSIX: Adheres to POSIX permissions.
Windows: Follows Windows security models.
Hybrid (default: POSIX): Enables POSIX and Windows interoperability, with the most recent permission taking precedence across systems.
This enhanced flexibility allows administrators to choose the most appropriate model based on their environment and operational requirements, simplifying the management of permissions across mixed systems.
WEKA filesystem snapshots integration with Windows' previous versions
Generating WEKA filesystem snapshots and labeling the access point in the @GMT_%Y.%m.%d-%H.%M.%S format makes them accessible through the Windows previous versions mechanism.
To access a list of previous versions associated with the filesystem snapshots, right-click on a file or folder within the WEKA SMB share on the Windows client and navigate to Properties -> Previous Versions.
Example: Create snapshots using CLI with the required access point syntax.
Related topics
Last updated