[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-17。"],[],[],null,["# Connect NFS clients\n\nThis page provides instructions for how to connect NFS clients.\n\nBefore you begin\n----------------\n\nInstall NFS client tools based on your Linux distribution type to prepare your\nclient: \n\n### RedHat\n\nRun the following command: \n\n```json\nsudo yum install -y nfs-utils\n```\n\n### SuSe\n\nRun the following command: \n\n```json\nsudo yum install -y nfs-utils\n```\n\n### Debian\n\nRun the following command: \n\n```json\nsudo apt-get install nfs-common\n```\n\n### Ubuntu\n\nRun the following command: \n\n```json\nsudo apt-get install nfs-common\n```\n\nVolume access control using export policies\n-------------------------------------------\n\nVolume access control in NFSv3 and NFSv4.1 is based on the client's IP address.\nThe volume's export policy contains export rules. Each rule is a comma-separated\nlist of IPs or network CIDRs which define **Allowed Clients** enabled to mount\nthe volume. A rule also defines the type of access the clients have such as\n**Read \\& Write** or **Read Only** . As an additional security measure, NFS\nservers remap access from root user (`UID=0`) to nobody (`UID=65535`), which\nmakes root an unprivileged user while accessing the files on the volume. When\nyou enable **Root Access** to **On** in the respective export rule, the root\nuser stays root. The order of export rules is relevant.\n\nWe recommend the following best practices for export policies:\n\n- Order the export rules from most specific to least specific.\n\n- Export only to the trusted clients, such as specific clients or CIDRs with\n the trusted clients.\n\n- Limit the root access to a small group of trusted administration clients.\n\nAfter a client mounts a volume, the file level access determines what a user is\nallowed to do. For more information, see [NFS file-level access control for UNIX-style volumes](/netapp/volumes/docs/before-you-begin/security-considerations#nfs_file-level_access_control_for_unix-style_volumes).\n\nMount instructions for NFS clients\n----------------------------------\n\nUse the following instructions to get mount instructions for NFS clients using\neither the Google Cloud console or Google Cloud CLI: \n\n### Console\n\n1. Go to the **NetApp Volumes** page in the Google Cloud console.\n\n [Go to NetApp Volumes](https://console.cloud.google.com/netapp/volumes)\n2. Click **Volumes**.\n\n3. Click more_vert **Show more**.\n\n4. Select **Mount instructions**.\n\n5. Follow the mount instructions shown in the Google Cloud console.\n\n6. Identify the mount command and use the mount options unless your workload\n has specific mount option requirements.\n\n **NFSv3 only** : if your application doesn't use locks or you didn't\n configure your clients to enable NSM communication, we recommend that you\n add the `nolock` mount option.\n\n### gcloud\n\nLook up the mount instructions for a volume: \n\n```bash\n gcloud netapp volumes describe VOLUME_NAME \\\n --project=PROJECT_ID \\\n --location=LOCATION \\\n --format=\"value(mountOptions.instructions)\"\n```\n\nReplace the following information:\n\n- \u003cvar translate=\"no\"\u003eVOLUME_NAME\u003c/var\u003e: the name of the volume.\n\n- \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: the name of the project the volume\n is in.\n\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the location of the volume.\n\nFor more information on additional optional flags, see\n[Google Cloud SDK documentation on volumes](/sdk/gcloud/reference/netapp/volumes).\n\nAdditional NFSv4.1 instructions\n-------------------------------\n\nWhen you enable NFSv4.1, volumes with service levels Standard, Premium, and\nExtreme automatically enable NFSv4.2 too. The Linux mount command always mounts\nthe highest available NFS version, unless you specify the version to mount. If\nyou want to mount with NFSv4.1, use the `-o vers=4.1` parameter in your mount\ncommand.\n\nIn NFSv3, users and groups are identified by user IDs (UID) and group IDs (GID)\nsent over the NFSv3 protocol. Its important to make sure that the same UID and\nGID represent the same user and group on all clients accessing the volume. NFSv4\nremoved the need for explicit UID and GID mapping by using security identifiers.\nSecurity identifiers are strings formatted as `\u003cusername|groupname\u003e@\u003cfull_qualified_domain\u003e`.\nAn example of a security identifier is [bob@example.com](mailto:bob@example.com).\nThe client needs to translate the UIDs and GIDs used internally into a security\nidentifier before sending an NFSv4 request to the server. The server needs to\ntranslate the security identifiers into UIDs and GIDs for an incoming request\nand the other way around for its response. The advantage of using translations\nis that every client and the server can use different internal UIDs and GIDs.\nHowever, the disadvantage is that all clients and the server need to maintain a\nmapping list between UIDs and GIDs, and user and group names. The mapping\ninformation on clients can come from local files like `/etc/passwd` and\n`/etc/groups` or an LDAP directory. The configuration of this mapping is managed\nby `rpc.idmapd`, which must run on your client.\n\nOn NetApp Volumes, the LDAP must provide mapping information,\nwith Active Directory being the only supported RFC2307bis compatible LDAP server.\nWhen using Kerberos for NFSv4, the security identifier stores Kerberos\nprincipals in the format `username@DOMAINNAME`, where DOMAINNAME (in capital\nletters) becomes the realm name.\n\n### Numeric IDs\n\nFor users that don't want to configure the name mappings and instead use NFSv4\nas a replacement for NFSv3, NFSv4 has introduced an option called `numeric ID`,\nwhich sends UID and GID encoded text strings as security identifiers. This\nsimplifies the configuration process for users.\n| **Note:** The latest Linux distributions enable `numeric ID` option by default.\n\nYou can check your client setting using the following command: \n\n```json\n cat /sys/module/nfs/parameters/nfs4_disable_idmapping\n \n```\n\nThe default value is **Y**, which enables numeric IDs. NetApp Volumes\nsupports the use of numeric IDs.\n\n### Configure rpc.idmapd on NFS client\n\nRegardless of the type of IDs or security identifiers you use, it is necessary\nto configure `rpc.idmapd` on your NFS client. If you followed the installation\ninstructions for client utilities in the [Before you begin](/netapp/volumes/docs/connect-clients/connect-nfs-clients#before_you_begin)\nsection, it should already be installed but might not be running. Some\ndistributions start it automatically using `systemd` when you mount the first\nNFS volumes. The minimum configuration required for `rpc.idmapd` is to set up\nthe domain setting. Otherwise, the user root will be displayed as nobody with\n`UID=65535 or 4294967295`.\n\nUse the following instructions to configure `rpc.idmapd` on your NFS client:\n\n1. On your client, open the file `/etc/idmapd.conf` and change the domain\n parameter to one of the following:\n\n - If your volume isn't enabled for LDAP, `domain = defaultv4iddomain.com`.\n\n - If your volume is enabled for LDAP, `domain = \u003cFDQN_of_Windows_Domain\u003e`.\n\n2. Activate the changes to `rpc.idmapd` by running the following command:\n\n ```json\n nfsidmap -c\n ```\n\nNFSv4.2 support\n---------------\n\nThe Standard, Premium, and Extreme service levels now support the NFSv4.2\nprotocol in addition to NFSv4.1 on volumes that already have NFSv4.1 enabled.\n\nWhen mounting an NFS volume, the Linux mount command automatically selects the\nhighest available NFS version. Mounting an NFSv4.1 enabled volume automatically\ndefaults to NFSv4.2 unless the `vers=4.1` mount option is explicitly specified.\n\nNetApp Volumes support NFS extended attributes `xattrs` with\nNFSv4.2. The usage and limitations of `xattrs`, as detailed in\n[TR-4962](https://www.netapp.com/pdf.html?item=/media/84595-tr-4962.pdf), are\nalso applicable.\n\nConnect Linux to LDAP\n---------------------\n\nIf you are using NFSv3 extended groups or NFSv4.1 with security identifiers,\nyou configured NetApp Volumes to use your Active Directory as\nLDAP server using an Active Directory attached to a storage pool.\n\nTo maintain consistent user information between NFS client and server, you might\nneed to configure your client to use Active Directory as LDAP name service for\nuser and group information.\n\nUse the following resources to configure LDAP:\n\n- [RedHat deployment guide](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sect-sssd-ad-ldap-proc)\n\n- [Ubuntu deployment guide](https://ubuntu.com/server/docs/service-sssd-ldap)\n\n- [SuSe deployment guide](https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-security-ad.html)\n\nWhen using Kerberized NFS, you might need to use the deployment guides mentioned\nin this section to configure LDAP and ensure consistency between the client and\nserver.\n\nWhat's next\n-----------\n\n[Connect large capacity volumes with multiple storage endpoints](/netapp/volumes/docs/connect-clients/connect-large-capacity-volumes)."]]
