Connect NFS clients

This page provides instructions for how to connect NFS clients.

Before you begin

Install NFS client tools based on your Linux distribution type to prepare your client:

sudo yum install -y nfs-utils

sudo yum install -y nfs-utils

sudo apt-get install nfs-common

sudo apt-get install nfs-common

Volume access control using export policies

Volume access control in NFSv3 and NFSv4.1 is based on the client's IP address. The volume's export policy contains export rules. Each rule is a comma-separated list of IPs or network CIDRs which define Allowed Clients enabled to mount the volume. A rule also defines the type of access the clients have such as Read & Write or Read Only. As an additional security measure, NFS servers remap access from root user (UID=0) to nobody (UID=65535), which makes root an unprivileged user while accessing the files on the volume. When you enable Root Access to On in the respective export rule, the root user stays root. The order of export rules is relevant.

We recommend the following best practices for export policies:

• Order the export rules from most specific to least specific.

• Export only to the trusted clients, such as specific clients or CIDRs with the trusted clients.

• Limit the root access to a small group of trusted administration clients.

After a client mounts a volume, the file level access determines what a user is allowed to do. For more information, see NFS file-level access control for UNIX-style volumes.

Mount instructions for NFS clients

Use the following instructions to get mount instructions for NFS clients using either the Google Cloud console or Google Cloud CLI:

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

Additional NFSv4.1 instructions

When you enable NFSv4.1, volumes with service levels Standard, Premium, and Extreme automatically enable NFSv4.2 too. The Linux mount command always mounts the highest available NFS version, unless you specify the version to mount. If you want to mount with NFSv4.1, use the -o vers=4.1 parameter in your mount command.

In NFSv3, users and groups are identified by user IDs (UID) and group IDs (GID) sent over the NFSv3 protocol. Its important to make sure that the same UID and GID represent the same user and group on all clients accessing the volume. NFSv4 removed the need for explicit UID and GID mapping by using security identifiers. Security identifiers are strings formatted as <username|groupname>@<full_qualified_domain>. An example of a security identifier is bob@example.com. The client needs to translate the UIDs and GIDs used internally into a security identifier before sending an NFSv4 request to the server. The server needs to translate the security identifiers into UIDs and GIDs for an incoming request and the other way around for its response. The advantage of using translations is that every client and the server can use different internal UIDs and GIDs. However, the disadvantage is that all clients and the server need to maintain a mapping list between UIDs and GIDs, and user and group names. The mapping information on clients can come from local files like /etc/passwd and /etc/groups or an LDAP directory. The configuration of this mapping is managed by rpc.idmapd, which must run on your client.

On NetApp Volumes, the LDAP must provide mapping information, with Active Directory being the only supported RFC2307bis compatible LDAP server. When using Kerberos for NFSv4, the security identifier stores Kerberos principals in the format username@DOMAINNAME, where DOMAINNAME (in capital letters) becomes the realm name.

Numeric IDs

For users that don't want to configure the name mappings and instead use NFSv4 as a replacement for NFSv3, NFSv4 has introduced an option called numeric ID, which sends UID and GID encoded text strings as security identifiers. This simplifies the configuration process for users.

You can check your client setting using the following command:

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

The default value is Y, which enables numeric IDs. NetApp Volumes supports the use of numeric IDs.

Configure rpc.idmapd on NFS client

Regardless of the type of IDs or security identifiers you use, it is necessary to configure rpc.idmapd on your NFS client. If you followed the installation instructions for client utilities in the Before you begin section, it should already be installed but might not be running. Some distributions start it automatically using systemd when you mount the first NFS volumes. The minimum configuration required for rpc.idmapd is to set up the domain setting. Otherwise, the user root will be displayed as nobody with UID=65535 or 4294967295.

Use the following instructions to configure rpc.idmapd on your NFS client:

1. On your client, open the file /etc/idmapd.conf and change the domain parameter to one of the following:

   • If your volume isn't enabled for LDAP, domain = defaultv4iddomain.com.

   • If your volume is enabled for LDAP, domain = <FDQN_of_Windows_Domain>.

2. Activate the changes to rpc.idmapd by running the following command:

    nfsidmap -c
   

Connect Linux to LDAP

If you are using NFSv3 extended groups or NFSv4.1 with security identifiers, you configured NetApp Volumes to use your Active Directory as LDAP server using an Active Directory attached to a storage pool.

To maintain consistent user information between NFS client and server, you might need to configure your client to use Active Directory as LDAP name service for user and group information.

Use the following resources to configure LDAP:

• RedHat deployment guide

• Ubuntu deployment guide

• SuSe deployment guide

When using Kerberized NFS, you might need to use the deployment guides mentioned in this section to configure LDAP and ensure consistency between the client and server.

What's next

Connect large capacity volumes with multiple storage endpoints.