SMB Support
SMB (Server Message Block) is a network file sharing protocol that allows remote systems to connect to shared file and print services. Weka's implementation is based on the open-source Samba package and provides support for SMB versions 2 and 3.
The Weka implementation of SMB makes storage services available to Windows and MacOS clients. Weka provides shared access from multiple clients, as well as multi-protocol access to the same files from SMB, NFS, and Weka native filesystem drivers.
Implementation of the SMB feature in the Weka system is scalable, resilient and distributed.
Scalable: The Weka system currently supports an SMB cluster of between 3 to 8 hosts. These hosts run the SMB gateway service, while the backend filesystem can be any Weka filesystem. Therefore, it is practically unlimited in size and performance.
Resilient: The Weka system implementation of SMB provides clustered access to files in a Weka file store, enabling multiple servers to work together. Consequently, if a server failure occurs, another server is available to take over operations, thereby ensuring failover support and high availability. Weka standard resiliency against failures also protects the SMB filesystems.
Distributed: A Weka implementation is distributed over a cluster, where all nodes in the cluster handle all SMB filesystems concurrently. Therefore, performance supported by SMB can scale with more hardware resources, and high availability is ensured.
Weka maps Windows users and groups to a UID’s and GID’s for access to the filesystem. Weka pulls users and groups information from Active Directory automatically.
Weka requires the users and groups accessing the filesystem to have uidNumber and gidNumber attributes populated in active directory.
The following are the Active Directory attributes relevant for users according to RFC2307:
AD Attribute | Description |
| 0-4290000000 |
| 0-4290000000; must correlate with real group |
The following are the Active Directory attributes relevant for groups of users according to RFC2307:
AD Attribute | Description |
| 0-4290000000 |
Read more about Active Directory properties here.
The Weka SMB support is established either through the Weka system GUI or a series of CLIs. When configuring SMB support, it is necessary to:
Define the Weka hosts to participate in the SMB cluster, i.e., configuration of the SMB cluster.
Join the SMB cluster to the Active Directory, i.e., connection and definition of Weka in the Active Directory.
Create shares and their folders, and set permissions. By default, the filesystem permission are root/root/755 and initially can only be set via a WekaFS/NFS mount.
After completing these steps, it is possible to connect as an administrator and define permissions via Windows.
Establishing an SMB cluster is performed as follows:
Select the Weka hosts that will participate in the SMB cluster and set the domain name.
In on-premises deployments, it is possible to configure a list of public IP addresses which will be distributed across the SMB cluster. If a node fails, the IP addresses from that node will be reassigned to another node.
Notes: Each Weka cluster can only support a single SMB cluster.
Note: The DNS "nameserver" of the hosts participating in the SMB cluster should be configured to the Active Directory server.
To ensure that the various SMB clients will balance the load on the various Weka hosts serving SMB, it is recommended to define a Round-robin DNS entry which will resolve to the list of floating IPs, ensuring that client loads will be equally distributed across all hosts.
Note: Make sure to set the TTL (Time to Live) for all A records assigned to the SMB servers to 0 (Zero), this ensures that the IP won't be cached by the client or the DNS server.
After establishing an SMB cluster, it is possible to declare SMB shares. Each share should have a name and a share path, i.e., the path into the Weka filesystem, which can be the root of the Weka filesystem or a subdirectory. This is created in the shell using either a WekaFS mount or an NFS mount.
If the share uses the root, it is not necessary to create a root folder (it already exists). If the share is declared without providing a sub-directory, the WekaFS root will be used. If sub-folders have to be created (an operation that is performed manually), the permissions have to be adjusted accordingly.
Once the SMB cluster is connected to the Active Directory, it is possible to assign permissions and access rights of SMB cluster filesystems to specific users or groups of users. This is performed according to POSIX permissions i.e., the Windows permissions system stored in the POSIX permissions system. Any change in the Windows permissions will be adapted in the POSIX permissions.
Note: The initial set of POSIX permissions is performed via the driver/NFS.
Note: To obtain root access to the SMB shares, assign an Active Directory user with uidNumber and gidNumber of 0.
Creating snapshots of the Weka filesystem and naming the access point in the @GMT_%Y.%m.%d-%H.%M.%S format will expose those to the windows previous versions mechanism. Right-click a file or a folder in the Weka SMB share in the windows client, select Properties->Previous Versions , and see a list of available previous versions that correspond to the filesystem snapshots.
For example, creating a snapshot via the CLI:
$ weka fs snapshot create fs_name snapshot_name --access-point `TZ=GMT date +@GMT-%Y.%m.%d-%H.%M.%S`
