W E K A
4.3
4.3
  • WEKA v4.3 documentation
    • Documentation revision history
  • WEKA System Overview
    • WEKA Data Platform introduction
      • WEKA system functionality features
      • Converged WEKA system deployment
      • Optimize redundancy in WEKA deployments
    • SSD capacity management
    • Filesystems, object stores, and filesystem groups
    • WEKA networking
    • Data lifecycle management
    • WEKA client and mount modes
    • WEKA containers architecture overview
    • Glossary
  • Planning and Installation
    • Prerequisites and compatibility
    • WEKA cluster installation on bare metal servers
      • Plan the WEKA system hardware requirements
      • Obtain the WEKA installation packages
      • Install the WEKA cluster using the WMS with WSA
      • Install the WEKA cluster using the WSA
      • Manually install OS and WEKA on servers
      • Manually prepare the system for WEKA configuration
        • Broadcom adapter setup for WEKA system
        • Enable the SR-IOV
      • Configure the WEKA cluster using the WEKA Configurator
      • Manually configure the WEKA cluster using the resource generator
      • Perform post-configuration procedures
      • Add clients to an on-premises WEKA cluster
    • WEKA Cloud Deployment Manager Web (CDM Web) User Guide
    • WEKA Cloud Deployment Manager Local (CDM Local) User Guide
    • WEKA installation on AWS
      • WEKA installation on AWS using Terraform
        • Terraform-AWS-WEKA module description
        • Deployment on AWS using Terraform
        • Required services and supported regions
        • Supported EC2 instance types using Terraform
        • WEKA cluster auto-scaling in AWS
        • Detailed deployment tutorial: WEKA on AWS using Terraform
      • WEKA installation on AWS using the Cloud Formation
        • Self-service portal
        • CloudFormation template generator
        • Deployment types
        • AWS Outposts deployment
        • Supported EC2 instance types using Cloud Formation
        • Add clients to a WEKA cluster on AWS
        • Auto scaling group
        • Troubleshooting
      • Install SMB on AWS
    • WEKA installation on Azure
    • WEKA installation on GCP
      • WEKA project description
      • GCP-WEKA deployment Terraform package description
      • Deployment on GCP using Terraform
      • Required services and supported regions
      • Supported machine types and storage
      • Auto-scale instances in GCP
      • Add clients to a WEKA cluster on GCP
      • Troubleshooting
      • Detailed deployment tutorial: WEKA on GCP using Terraform
      • Google Kubernetes Engine and WEKA over POSIX deployment
  • Getting Started with WEKA
    • Manage the system using the WEKA GUI
    • Manage the system using the WEKA CLI
      • WEKA CLI hierarchy
      • CLI reference guide
    • Run first IOs with WEKA filesystem
    • Getting started with WEKA REST API
    • WEKA REST API and equivalent CLI commands
  • Performance
    • WEKA performance tests
      • Test environment details
  • WEKA Filesystems & Object Stores
    • Manage object stores
      • Manage object stores using the GUI
      • Manage object stores using the CLI
    • Manage filesystem groups
      • Manage filesystem groups using the GUI
      • Manage filesystem groups using the CLI
    • Manage filesystems
      • Manage filesystems using the GUI
      • Manage filesystems using the CLI
    • Attach or detach object store buckets
      • Attach or detach object store bucket using the GUI
      • Attach or detach object store buckets using the CLI
    • Advanced data lifecycle management
      • Advanced time-based policies for data storage location
      • Data management in tiered filesystems
      • Transition between tiered and SSD-only filesystems
      • Manual fetch and release of data
    • Mount filesystems
      • Mount filesystems from Single Client to Multiple Clusters (SCMC)
    • Snapshots
      • Manage snapshots using the GUI
      • Manage snapshots using the CLI
    • Snap-To-Object
      • Manage Snap-To-Object using the GUI
      • Manage Snap-To-Object using the CLI
    • Quota management
      • Manage quotas using the GUI
      • Manage quotas using the CLI
  • Additional Protocols
    • Additional protocol containers
    • Manage the NFS protocol
      • Supported NFS client mount parameters
      • Manage NFS networking using the GUI
      • Manage NFS networking using the CLI
    • Manage the S3 protocol
      • S3 cluster management
        • Manage the S3 service using the GUI
        • Manage the S3 service using the CLI
      • S3 buckets management
        • Manage S3 buckets using the GUI
        • Manage S3 buckets using the CLI
      • S3 users and authentication
        • Manage S3 users and authentication using the CLI
        • Manage S3 service accounts using the CLI
      • S3 rules information lifecycle management (ILM)
        • Manage S3 lifecycle rules using the GUI
        • Manage S3 lifecycle rules using the CLI
      • Audit S3 APIs
        • Configure audit webhook using the GUI
        • Configure audit webhook using the CLI
        • Example: How to use Splunk to audit S3
      • S3 supported APIs and limitations
      • S3 examples using boto3
      • Access S3 using AWS CLI
    • Manage the SMB protocol
      • Manage SMB using the GUI
      • Manage SMB using the CLI
  • Operation Guide
    • Alerts
      • Manage alerts using the GUI
      • Manage alerts using the CLI
      • List of alerts and corrective actions
    • Events
      • Manage events using the GUI
      • Manage events using the CLI
      • List of events
    • Statistics
      • Manage statistics using the GUI
      • Manage statistics using the CLI
      • List of statistics
    • Insights
    • System congestion
    • Security management
      • Obtain authentication tokens
      • KMS management
        • Manage KMS using the GUI
        • Manage KMS using the CLI
      • TLS certificate management
        • Manage the TLS certificate using the GUI
        • Manage the TLS certificate using the CLI
      • CA certificate management
        • Manage the CA certificate using the GUI
        • Manage the CA certificate using the CLI
      • Account lockout threshold policy management
        • Manage the account lockout threshold policy using GUI
        • Manage the account lockout threshold policy using CLI
      • Manage the login banner
        • Manage the login banner using the GUI
        • Manage the login banner using the CLI
      • Manage Cross-Origin Resource Sharing
    • User management
      • Manage users using the GUI
      • Manage users using the CLI
    • Organizations management
      • Manage organizations using the GUI
      • Manage organizations using the CLI
      • Mount authentication for organization filesystems
    • Expand and shrink cluster resources
      • Add a backend server
      • Expand specific resources of a container
      • Shrink a cluster
    • Background tasks
      • Set up a Data Services container for background tasks
      • Manage background tasks using the GUI
      • Manage background tasks using the CLI
    • Upgrade WEKA versions
  • Licensing
    • License overview
    • Classic license
  • Monitor the WEKA Cluster
    • Deploy monitoring tools using the WEKA Management Station (WMS)
    • WEKA Home - The WEKA support cloud
      • Local WEKA Home overview
      • Deploy Local WEKA Home v3.0 or higher
      • Deploy Local WEKA Home v2.x
      • Explore cluster insights and statistics
      • Manage alerts and integrations
      • Enforce security and compliance
      • Optimize support and data management
    • Set up the WEKAmon external monitoring
    • Set up the SnapTool external snapshots manager
  • Support
    • Get support for your WEKA system
    • Diagnostics management
      • Traces management
        • Manage traces using the GUI
        • Manage traces using the CLI
      • Protocols debug level management
        • Manage protocols debug level using the GUI
        • Manage protocols debug level using the CLI
      • Diagnostics data management
  • Best Practice Guides
    • WEKA and Slurm integration
      • Avoid conflicting CPU allocations
    • Storage expansion best practice
  • WEKApod
    • WEKApod Data Platform Appliance overview
    • WEKApod servers overview
    • Rack installation
    • WEKApod initial system setup and configuration
    • WEKApod support process
  • Appendices
    • WEKA CSI Plugin
      • Deployment
      • Storage class configurations
      • Tailor your storage class configuration with mount options
      • Dynamic and static provisioning
      • Launch an application using WEKA as the POD's storage
      • Add SELinux support
      • NFS transport failback
      • Upgrade legacy persistent volumes for capacity enforcement
      • Troubleshooting
    • Convert cluster to multi-container backend
    • Create a client image
    • Update WMS and WSA
    • BIOS tool
Powered by GitBook
On this page
  • Configure the NFS global settings
  • Configure the NFS cluster level
  • Create interface groups
  • Set interface group ports
  • Set interface group IPs
  • Configure the service mountd port
  • Configure user group resolution
  • Integrate the NFS and Kerberos service
  • Set the Kerberos service
  • Integrate Kerberos with AD
  • Integrate Kerberos with MIT
  • Show Kerberos LDAP setup information
  • Clear the Kerberos LDAP configuration
  • Show Kerberos registration information
  • Clear Kerberos configuration
  • Update Kerberos configuration during maintenance mode
  • Manage the NFS export level (permissions)
  • Define client access groups
  • Manage client access groups' rules
  • Manage NFS client permissions
  • View connected NFS clients
  1. Additional Protocols
  2. Manage the NFS protocol

Manage NFS networking using the CLI

This page describes how to configure the NFS networking using the CLI.

PreviousManage NFS networking using the GUINextManage the S3 protocol

Last updated 9 months ago

Using the CLI, you can:

Configure the NFS global settings

NFSv4 and Kerberos require a persistent cluster-wide configuration filesystem for the protocol's internal operations.

Use the following command line to set the NFS configuration on the configuration filesystem:

weka nfs global-config set [--mountd-port mountd-port] [--lockmgr-port lockmgr-port] [--statmon-port statmon-port] [--notify-port notify-port] [--config-fs config-fs] [--default-supported-versions default-supported-versions] [--enable-auth-types enable-auth-types]

  • To support NFS file-locking, ensure the system meets the prerequisites outlined in .

  • For the default published ports, see the .

Parameters

Name
Value
Default

mountd-port

Set the alternate port if the existing mountd service is not operating on the default published port. 0 means use the default published port.

0

lockmgr-port

Set the alternate port for the NFS lock manager used in NFSv3.

0 means use the default published port.

0

statmon-port

Set the alternate port for the NFS status monitor used in NFSv3. 0 means use the default published port.

0

notify-port

Set the alternate port for notification used in NFSv3. 0 means use the default published port.

0

config-fs*

default-supported-versions

Determines the default NFS version. Possible values: v3

v4

v3,v4

v3

enable-auth-types

A comma-separated list of authentication types that can be used when setting the NFS client permissions.

Possible values: none,sys,krb5,krb5i,krb5p Example: krb5,krb5i,krb5p

Depends on Kerberos configuration:

  • If not configured: none,sys

  • If configured: krb5

Show NFS global configuration

Command: weka nfs global-config show

Example

$ weka nfs global-config show
NFS Global Configuration
   mountd port: 0
     Config FS: .config_fs
Default Supported Versions: V3
Enabled Auth Types: KRB5, KRB5i, KRB5p
Default Auth Types: KRB5
Supported Auth Types: NONE, SYS, KRB5, KRB5i, KRB5p

The parameters Default Auth Types and Supported Auth Types are determined internally.

Configure the NFS cluster level

Create interface groups

Command: weka nfs interface-group add

Use the following command line to add an interface group:

weka nfs interface-group add <name> <type> [--subnet subnet] [--gateway gateway]

Example

weka nfs interface-group add nfsw NFS --subnet 255.255.255.0 --gateway 10.0.1.254

Parameters

Name
Value
Default

name*

Unique interface group name.

type*

Group type. Can only be NFS.

subnet

The valid subnet mask in the 255.255.0.0 format.

255.255.255.255

gateway

Gateway valid IP.

255.255.255.255

Set interface group ports

Commands:

weka nfs interface-group port add

weka nfs interface-group port delete

Use the following command lines to add or delete an interface group port:

weka nfs interface-group port add <name> <container-id> <port>

weka nfs interface-group port delete <name> <container-id> <port>

Example

The following command line adds the interface enp2s0 on the Frontend container-id 3 to the interface group named nfsw.

weka nfs interface-group port add nfsw 3 enp2s0

Parameters

Name
Value

name*

Interface group name.

container-id*

Valid frontend container ID on which the port resides. You can obtain the container ID by running the weka cluster container command.

port*

Valid port's device. Maximum 14 characters. Example: eth1.

Set interface group IPs

Commands:

weka nfs interface-group ip-range add

weka nfs interface-group ip-range delete

Use the following command lines to add/delete an interface group IP:

weka nfs interface-group ip-range add <name> <ips>

weka nfs interface-group ip-range delete <name> <ips>

Example

The following command line adds IPs in the range 10.0.1.101 to 10.0.1.118 to the interface group named nfsw.

weka nfs interface-group ip-range add nfsw 10.0.1.101-118

Parameters

Name
Value

name*

Interface group name

ips*

Valid IP range

Configure the service mountd port

The mountd service receives requests from clients to mount to the NFS server. It is possible to set it explicitly rather than have it randomly selected on each server startup. This allows an easier setup of the firewalls to allow that port.

Use the following command lines to set and view the mountd configuration:

weka nfs global-config set --mountd-port <mountd-port>

weka nfs global-config show

Configure user group resolution

NFS-W can authenticate more than 16 user groups, but it requires the external resolution of the user's groups, which means associating users with their respective group-IDs outside of the NFS protocol.

Procedure

  1. Configure interface groups:

  2. Configure NFS client permissions:

  3. Set up servers for group-IDs retrieval:

    • Configure relevant servers to retrieve user group-IDs information. This task is specific to NFS-W and does not involve WEKA management. See the following procedure.

Set up the servers to retrieve user's group-IDs information

For the servers that are part of the interface group, set the servers to retrieve the user's group-IDs information in any method that is part of the environment.

You can also set the group resolution by joining the AD and Kerberos domains or using LDAP with a read-only user.

Configure the sssd on the server to serve as a group IDs provider. For example, you can configure the sssd directly using LDAP or as a proxy to a different nss group IDs provider.

Example: set sssd directly for nss services using LDAP with a read-only user

[sssd]
services = nss
config_file_version = 2
domains = LDAP

[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com

# The DN used to search the ldap directory with. 
ldap_default_bind_dn = cn=ro_admin,ou=groups,dc=example,dc=com

# The password of the bind DN.
ldap_default_authtok = password

If you use another method than the sssd but with a different provider, configure an sssd proxy on each relevant server. The proxy is used for the WEKA container to resolve the groups by any method defined on the server.

To configure sssd proxy on a server, use the following:

# install sssd
yum install sssd

# set up a proxy for WEKA in /etc/sssd/sssd.conf
[sssd]
services = nss
config_file_version = 2
domains = proxy_for_weka

[nss]
[domain/proxy_for_weka]
id_provider = proxy
auth_provider = none
 
# the name of the nss lib to be proxied, e.g., ldap, nis, winbind, vas4, etc.
proxy_lib_name = ldap

All users must be present and resolved in the method used in the sssd for the group's resolution. In the above example, using an LDAP-only provider, local users (such as a local root) absent in LDAP do not receive their groups resolved and are denied. For such users or applications, add the LDAP user.

Integrate the NFS and Kerberos service

Integrating the NFS and Kerberos service is critical to setting up a secure network communication process. This procedure involves defining the Key Distribution Center (KDC) details, administrative credentials, and other parameters to ensure a robust and secure authentication process.

Before you begin

  • Ensure a configuration filesystem is set. See Configure the NFS global settings.

  • Ensure the NFS cluster is configured and running. see Configure the NFS cluster level.

  • For Active Directory (AD) integration, obtain the required information from the AD administrator. (WEKA handles the generation of the keytab file.)

  • For MIT integration, ensure the following:

    • Obtain the required information from the MIT Key Distribution Center (KDC) and OpenLDAP administrators.

    • A pre-generated keytab file in format stored in an accessible location is required.

In all KDC and LDAP parameters, use the FQDN format. The hostname part of the FQDN is restricted to a maximum of 20 characters.

Set the Kerberos service

Command: weka nfs kerberos service setup

Use the following command to set up NFS Kerberos Service information:

weka nfs kerberos service setup <kdc-realm-name> <kdc-primary-server> <kdc-admin-server> [--kdc-secondary-server kdc-secondary-server][--force] [--restart]

Example

weka nfs kerberos service setup WEKA-REALM kdc.primary.weka.io kdc.admin.weka.io --kdc-secondary-server kdc.secondary.weka.io

Parameters

Name
Value
Default

kdc-realm-name*

Specifies the realm (domain) used by Kerberos.

kdc-primary-server*

Identifies the server hosting the primary Key Distribution Center service.

kdc-admin-server*

Identifies the server hosting the administrative Key Distribution Center service.

kdc-secondary-server

Identifies the server hosting the secondary Key Distribution Center service.

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.

Not used

restart

When used, the command restarts the NFS-W containers after the changes are applied.

Not used

Show NFS Kerberos service setup information

Command: weka nfs kerberos service show

Example

$ weka nfs kerberos service show
REALM NAME          PRIMARY SERVER           SECONDARY SERVER   ADMIN SERVER           GENERATION ID     SERVICE STATUS
TEST.WEKALAB.IO     Zeus.test.wekalab.io                        Zeus.test.wekalab.io   1                 CONFIGURED

Integrate Kerberos with AD

Integrating Kerberos with AD involves the following:

Register Kerberos with AD

Command: weka nfs kerberos registration setup-ad

Use the following command to register the Kerberos with Microsoft Active Directory:

weka nfs kerberos registration setup-ad <nfs-service-name> <realm-admin-name> [realm-admin-passwd] [--force] [--restart]

Example

weka nfs kerberos registration setup-ad myservicename.test.example.com myrealmadmin

Parameters

Name
Value
Default

nfs-service-name*

This refers to the complete domain name for a specific NFS server.

realm-admin-name*

The username of an administrator who has access to the LDAP directory. This user manages the KDC within a realm.

realm-admin-passwd

This parameter is for the password of the administrative user who manages the KDC within a realm. It’s not stored in the configuration for security reasons. If it’s not provided during setup, the system asks for it. The entered password isn’t shown on the screen to protect privacy and security.

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.

Not used

restart

When used, the command restarts the NFS-W containers after the changes are applied.

Not used

Set up Kerberos to use AD LDAP

Command: weka nfs ldap setup-ad

Use the following command to set up NFS configuration to use AD LDAP:

weka nfs ldap setup-ad [--force] [--no-restart]

Example

weka nfs ldap setup-ad

Parameters

Name
Value
Default

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.

Not used

no-restart

When used, it prevents NFS-W containers from restarting to apply changes.

Not used

In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.

Integrate Kerberos with MIT

Integrating Kerberos with MIT involves the following:

Register Kerberos with MIT

Command: weka nfs kerberos registration setup-mit

Use the following command to register the Kerberos with MIT KDC:

weka nfs kerberos registration setup-mit <nfs-service-name> <keytab-file> [--force] [--restart]

To register the Kerberos service with MIT, a pre-generated , stored in an accessible location, is required.

Example

weka nfs kerberos registration setup-mit myservicename.test.example.com myservicename.keytab

Parameters

Name
Value
Default

nfs-service-name*

Fully Qualified Domain Name (FQDN) for the NFS Service. This refers to the complete domain name for a specific NFS server. The hostname part of the FQDN is restricted to a maximum of 20 characters.

keytab-file*

The path to the pre-generated keytab file containing the keys for the NFS service’s unique identity in format.

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured.

Not used

restart

When used, the command restarts the NFS-W containers after the changes are applied.

Not used

Set up Kerberos to use OpenLDAP

Command: weka nfs ldap setup-openldap

Use the following command to set up Kerberos to use OpenLDAP:

weka nfs ldap setup-openldap <server-name> <ldap-domain> <reader-user-name>[reader-user-password] [--base-dn base-dn] [--ldap-port-number ldap-port-number][--force] [--no-restart]

Example

weka nfs ldap setup-openldap myldapserver.test.example.com, myldapdomain.example.com, cn=readonly-user,dc=test,dc=example,dc=com

Parameters

Name
Value
Default

server-name*

Specifies the server hosting the Lightweight Directory Access Protocol service.

ldap-domain*

Defines the domain the Lightweight Directory Access Protocol service will access.

reader-user-name*

The username of an administrative user used to generate the keytab file.

reader-user-password

The administrative user's password. (It is maintained in a configuration file.)

base-dn

The base Distinguished Name (DN) for the Lightweight Directory Access Protocol directory tree.

ldap-port-number

The port number on which the Lightweight Directory Access Protocol server listens.

389

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered.

Not used

no-restart

When used, it prevents NFS-W containers from restarting to apply changes.

Not used

In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.

Show Kerberos LDAP setup information

Command: weka nfs ldap show

Example

$ weka nfs ldap show
SERVER TYPE      LDAP DOMAIN      SERVER NAME  SERVER PORT  BASE DN  READER NAME  READER PASSWORD  GENERATION ID  SETUP STATUS
ActiveDirectory  test.wekalab.io               0                                                   1              CONFIGURED

Clear the Kerberos LDAP configuration

Command: weka nfs ldap reset

Use the following command to clear the NFS LDAP configuration:

weka nfs ldap reset [--force] [--no-restart]

Parameters

Name
Value
Default

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured.

Not used

no-restart

When used, it prevents NFS-W containers from restarting to apply changes.

Not used

Show Kerberos registration information

Command: weka nfs kerberos registration show

Example

$ weka nfs kerberos registration show
NFS SERVICE NAME          NFS KDC TYPE        GENERATION ID      REGISTRATION STATUS
nfs.test.wekalab.io       ActiveDirectory     1                  REGISTERED

Clear Kerberos configuration

Command: weka nfs kerberos reset

Use the following command to clear the NFS Kerberos service configuration:

weka nfs kerberos reset [--force] [--no-restart]

Parameters

Name
Value
Default

force

When used, it forces the action to proceed without further confirmation. Typically used when the service is configured or registered. Use this flag only to clear the configuration created by a previous call to weka nfs kerberos service setup succeeded.

Not used

no-restart

When used, it prevents NFS-W containers from restarting to apply changes.

Not used

In a successful operation, the system automatically restarts the NFS containers, leading to a temporary disruption in the IO service for connected NFS clients. However, if you want to avoid restarting the NFS-W containers, add the --no-restart option to the command line.

Update Kerberos configuration during maintenance mode

Once the Kerberos integration with NFS is configured, there might be instances where the Kerberos setup is modified.

Changes to the Kerberos configuration in a production environment are rare. We recommend making any necessary updates during periods of low load from NFS clients, such as when the system are in maintenance mode. This approach helps to minimize potential disruptions to your operations.

Select the relevant tab to learn what to do for each scenario:

Use this procedure if you want to add or remove a secondary KDC server:

kdc-secondary-server

Procedure

  1. Run the command: weka nfs kerberos reset --no-restart --force

  2. Run the command: weka nfs kerberos service setup <options>

  3. Run one of the following commands:

    • For AD implementation: weka nfs kerberos registration setup-ad <options> --restart

    • For MIT implementation: weka nfs kerberos registration setup-mit <options> --restart

Use this procedure if one of the following is changed:

realm-admin-name
realm-admin-passwd

Procedure

Run the command: weka nfs kerberos registration setup-ad --restart --force

Use this procedure if one of the following is changed:

keytab-file

Procedure

Run the command: weka nfs kerberos registration setup-mit <options> --restart --force

Use this procedure if one of the following is changed:

reader-user-name
reader-user-password

Procedure

  • For AD implementation, run the following:

    1. weka nfs ldap reset --no-restart --force

    2. weka nfs ldap <setup-ldap> <options/params>

  • For MIT implementation, run the following:

    1. weka nfs ldap reset --no-restart --force

    2. weka nfs ldap <setup-openldap> <options/params>

Manage the NFS export level (permissions)

Define client access groups

Command: weka nfs client-group

Use the following command lines to add/delete a client access group:

weka nfs client-group add <name>

weka nfs client-group delete <name>

Parameters

Name
Value

name*

Valid group name.

Manage client access groups' rules

Clients are part of groups when their IP address or DNS hostname match the rules of that group. Similar to IP routing rules, clients are matched to client groups according to the most specific matching rule.

Command: weka nfs rules

Add DNS-based client group rules

Use the following command lines to add a rule that causes a client to be part of a client group based on its DNS hostname:

weka nfs rules add dns <name> <dns>

Example

weka nfs rules add dns client-group1 hostname.example.com

Delete DNS-based client group rules

Use the following command lines to delete a rule that causes a client to be part of a client group based on its DNS hostname:

weka nfs rules delete dns <name> <dns>

Example

weka nfs rules delete dns client-group1 hostname.example.com

Parameters

Name
Value

name*

Valid client group name.

dns*

DNS rule with *?[] wildcard rules.

Add IP-based client group rules

Command: weka nfs rules

Use the following command lines to add or delete a rule which causes a client to be part of a client group based on its IP and subnet mask (both CIDR and standard subnet mask formats are supported for enhanced flexibility):

weka nfs rules add ip <name> <ip>

Examples

weka nfs rules add ip client-group1 192.168.114.0/8 weka nfs rules add ip client-group2 172.16.0.0/255.255.0.0

Delete IP-based client group rules

weka nfs rules delete ip <name> <ip>

Examples

weka nfs rules delete ip client-group1 192.168.114.0/255.255.255.0 weka nfs rules delete ip client-group2 172.16.0.0/16

Parameters

Name
Value

name*

Valid client group name.

ip*

Valid IP address with subnet mask.

Both CIDR and standard subnet mask formats are supported for enhanced flexibility.

CIDR format: 1.1.1.1/16

Standard format: 1.1.1.1/255.255.0.0

Manage NFS client permissions

Command: weka nfs permission

Use the following command lines to add NFS permissions:

weka nfs permission add <filesystem> <group> [--path path] [--permission-type permission-type] [--squash squash] [--anon-uid anon-uid] [--anon-gid anon-gid] [--obs-direct obs-direct] [--manage-gids manage-gids] [--privileged-port privileged-port] [--supported-versions supported-versions] [--enable-auth-types enable-auth-types]

Use the following command lines to update NFS permissions:

weka nfs permission update <filesystem> <group> [--path path] [--permission-type permission-type] [--squash squash] [--anon-uid anon-uid] [--anon-gid anon-gid] [--obs-direct obs-direct] [--manage-gids manage-gids] [--privileged-port privileged-port] [--supported-versions supported-versions][--enable-auth-types enable-auth-types]

Use the following command lines to delete NFS permissions:

weka nfs permission delete <filesystem> <group> [--path path]

Parameters

Name
Value
Default

filesystem*

Existing filesystem name. A filesystem with Required Authentication set to ON cannot be used for NFS client permissions.

group*

Existing client group name.

path

The root of the valid share path.

/

permission-type

Permission type. Possible values: ro (read-only), rw (read-write)

rw

squash

Squashing type. Possible values: none, root, all

none

anon-uid*

Anonymous user ID. Relevant only for root squashing. Possible values: 1 to 65535.

65534

anon-gid*

Anonymous user group ID. Relevant only for root squashing. Possible values: 1 to 65535.

65534

obs-direct

on

manage-gids

Sets external group IDs resolution.

The list of group IDs received from the client is replaced by a list determined by an appropriate lookup on the server. Possible values: on, off.

off

privileged-port

Sets the share only to be mounted via privileged ports (1-1024), usually allowed by the root user. Possible values: on, off.

off

supported-versions

A comma-separated list of supported NFS versions. Possible values: v3, v4.

enable-auth-types

The default-auth-types in NFS global settings determine the default.

View connected NFS clients

Command: weka nfs clients show

Use the following command line to view insights of NFS clients connected to the NFS-W cluster in JSON output format.

weka nfs clients show [--interface-group interface-group] [--container-id container-id] [--fip floating-ip]

Parameters

Name
Value
Default

interface-group

Interface group name. A filter to show only the clients connected to the containers in the specified group.

The output shows all clients connected to any container in the NFS-W cluster regardless of the assigned interface group.

container-id

NFS-W container ID.

A filter to show only the clients connected to the specified container ID.

The output shows all clients connected to any container in the NFS-W cluster.

fip

Destination floating IP address.

The output shows all clients connected to all floating IP addresses.

The predefined filesystem name for maintaining the persisting cluster-wide protocols' configurations. Verify that the filesystem is already created. If not, create it. For details, see

See .

See .

See . Possible values: on, off.

The default-supported-versions setting in determines the default NFS version.

A comma-separated list of NFS authentication types. Possible values are determined by the enable-auth-types in .

Create interface groups
Set the NFS client permissions
Register Kerberos with AD
Set up Kerberos to use AD LDAP
Register Kerberos with MIT
Set up Kerberos to use OpenLDAP
NFS global settings
NFS global settings
Configure the NFS global settings
Configure the NFS cluster level
Integrate the NFS and Kerberos service
Configure the NFS export level (permissions)
NFS file-locking support
#dedicated-filesystem-requirement-for-persistent-protocol-configurations
Object-store Direct Mount
Required ports