> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/additional-protocols/nfs-support/supported-nfs-client-mount-options.md).

# Supported NFS client mount parameters

Configure mandatory and recommended NFS client mount options, based on real-world testing and validation for optimal performance and reliability.

To ensure optimal performance and reliability when using NFS clients, it is essential to configure specific mandatory and recommended mount parameters. These parameters have been tested and validated in various real-world scenarios.

## **Mandatory parameters**

The following parameters **must** be included alongside the client's default mount options:

* **NFSv3** and **NFSv4**: `proto=tcp`

## Recommended parameters

For enhanced performance and stability, include the following parameters in addition to the mandatory ones:

* **NFSv3**:
  * `hard`
  * `vers=3`
* **NFSv4**:
  * `hard`
  * `vers=4`

## Additional information

* **Specifying NFS Client Version:** Always explicitly define the NFS client version (`vers=3` or `vers=4`) to prevent unexpected protocol negotiation during server configuration changes.
* **Resiliency to network interruptions:** Use the `hard` option to ensure the client retries operations during temporary network interruptions, maintaining data integrity and operation continuity.
* **Improving NFS performance:** Set the `nconnect` parameter to a value greater than `1` to open multiple TCP connections per mount. Supported for NFSv3, NFSv4.0, and NFSv4.1 on any supported WEKA version, and requires a Linux client kernel 5.3 or later. The maximum is `nconnect=16`, which is the Linux client's own limit. The practical ceiling is the per-server connection limit, which the cluster sizes automatically — see `max-client-connections` in [Manage NFS networking using the CLI](/additional-protocols/nfs-support/nfs-support-1.md).
* **Default NFS client options:** Beyond the parameters listed above, the default options negotiated by the NFS client at mount time are suitable for most use cases. For advanced configurations or additional NFS client options, refer to the documentation provided by your operating system.

## Mounting a tenant export

When NFS multi-tenancy is enabled, exports belonging to a tenant are reached through the tenant's floating IP addresses. Mounting works the same way, and no extra parameters are required:

```bash
mount -o vers=3,proto=tcp,hard,sec=sys <tenant-floating-ip>:/<export> /mnt/point
```

Each tenant floating IP runs its own portmapper on port 111, so no port overrides are needed.

The following differences apply to tenant exports and not to the root organization. They affect client compatibility, so check them before planning a migration.

<table><thead><tr><th width="297.2109375">Behavior</th><th>On a tenant export</th></tr></thead><tbody><tr><td>Security flavor</td><td><code>sec=sys</code> only. Kerberos flavors (<code>krb5</code>, <code>krb5i</code>, <code>krb5p</code>) are available only in the root organization. A client attempting Kerberos is rejected with <code>AUTH_TOOWEAK</code>.</td></tr><tr><td>NFSv3 file locking</td><td>Not available. The NLM lock service is not offered on tenant floating IPs, so NFSv3 clients cannot take locks. Use NFSv4.1, where locking works.</td></tr><tr><td>User and group names on NFSv4</td><td>Always numeric. <code>ls -l</code> shows numeric UIDs and GIDs rather than names, because NFS name resolution is available only in the root organization. Unknown names map to <code>anon</code>. Clients that perform their own local mapping are unaffected.</td></tr><tr><td>ACLs</td><td>Not enforced. An export created without an explicit ACL type is set to <code>NONE</code>.</td></tr><tr><td><code>showmount -e</code> and <code>rpcinfo -p</code></td><td>Return only the data for the tenant that owns the floating IP you query.</td></tr></tbody></table>

{% hint style="warning" %}
The two items most likely to break an existing client are NFSv3 locking and numeric UIDs. An application relying on NFSv3 byte-range locks, or on `ls -l` resolving names, behaves differently after moving from a root-organization export to a tenant export.
{% endhint %}

**Related topics**

[Mount filesystems](/weka-filesystems-and-object-stores/mounting-filesystems.md)

[Manage NFS for tenants](/operation-guide/weka-native-multi-tenancy-management/manage-nfs-for-tenants.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.weka.io/additional-protocols/nfs-support/supported-nfs-client-mount-options.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.