Nutanix File and NFS Mount Examples

  • 25 May 2019
  • 2 replies

Userlevel 2
Badge +1
The objective of this post is to provide inputs on requirement of using NFS exports. Nutanix Files implemented NFSv4 Support from Files and since then Nutanix Files has come as a long way. Along with the release of Files 3.5, it now supports NFSv3 as well. They are enabled by default and depends on the NFS Client.

In order to configure and utilize NFSv4 exports minimum required files version is 3.0.x
In order to configure and utilize NFSv3 exports minimum required files version is 3.5.x

From 3.5 onward, V4 and V3 both are enabled by default. However, if you want to disable a specific version support based on requirement. It is achievable from UI.
Self Service Restore is supported on NFS based exports from Files 3.5 onward for legacy and new exports.

Protocol Management → “Directory Services” → “Use NFS Protocol” → “Show NFS Advanced Options”

If V3 is disabled and client tries to access it using v3, we see Permission denied Error
Permission denied
mount.nfs: trying xx.xx.xx.xx prog 100005 vers 3 prot TCP port 20048
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting files35ea.xxxx.xx:/pnfs

Basic Information

  1. NFSv4 Protocol is supported from 3..x on-wards. NFSv4 protocol is not supported on 2.x branches.
  2. To know more about Client Support (NFSv4), Nutanix recommend to refer Release Notes page Supported Configurations section.
  3. We support SMB and NFS protocol based share and export configuration on same File Server but not on the same share. This Feature is coming in Files 3.5.1 version known as Multi-Protocol ( Concept of Primary and secondary Protocol Support on Same Share/Export).
User Management Options :-
  • Unmanaged
  • Active Directory and LDAP configuration.
User Authentication Options:
  • NONE - No Authentication
  • SYSTEM - Server implicitly trusts the UID (User ID) and GID (Group) of the User/Group presented by the client.
  • Kerberos based (Version 5): Only available when Active Directory and LDAP configuration options are selected under user management.
  • Kerberos 5 - DES symmetric key encryption, and an MD5 one-way hash for Nutanix Files credentials.
  • Kerberos 5i - In addition to Kerberos 5, uses MD5-based MAC on every request and response. Performs integrity checking of NFS operations using secure checksums to prevent data tampering
  • Kerberos 5p - On top of Kerberos 5 and 5i, makes the connection between client and server private by applying DES encryption to prevent traffic sniffing. Most secure setting but has the most performance overhead.
NFSv3 Protocol is supported from 3..5.x on-wards. NFSv4 protocol is not supported on 2..2.x branches.
NFSv3 is a simple stateless protocol where the server does not keep state of individual files being accessed by clients.

No NFSv3 support for Kerberos exports.
No UDP support for V3.


Mount NFS exports on NFS Client

Example taken here is on CentOS 7.3.1611. For Supported Clients OS and version please refer Release Notes Supported Configurations section.

Step 1 — Downloading and Installing the Components

On the client server, we need to install a package called nfs-common, which provides NFS functionality without including unneeded server components. Again, we will refresh the local package index prior to installation to ensure that we have up-to-date information:

sudo yum check-update
sudo yum install nfs-utils

Step 2 — Creating the Mount Points on the Client
Files is already configured and hosting its export, Now we’ll prepare our client.

In order to make the remote exports available on the client, we need to mount the NFS exports on an empty client directory.

We’ll create two directories for our mounts:

sudo mkdir -p /nfs/general
sudo mkdir -p /nfs/home

Step 3 — Mounting the Directories on the Client
We can mount the shares by addressing our Files server IP address or using Files Server FQDN .

For say:
sudo mount xx.xx.xx.xx:/  /nfs/home/
sudo mount xx.xx.xx.xx:/general-1 /nfs/general/

These commands should mount the exports from the Files onto the client machine.

You can double-check that they mounted successfully in several ways. You can check this with a mount command, but df -h will give you more human readable output illustrates how disk usage is displayed differently for the nfs shares:

Step 4 — Testing NFS Access
Next, let’s test access to the shares by writing something to each of them.

Example 1: The Non-Distributed Export

First, write a test file to the /nfs/general share.
sudo touch /nfs/general/general.test

Then, check its ownership:
root@0be61a516d4a:/# ls -lah /nfs/general/general.test
-rw-r--r--. 1 4294967294 4294967294 0 Mar 12 2018 /nfs/general/general.test

Created the file as the client machine’s root user via the sudo command, ownership of the file defaults to -2, -2

Lets create a user AFS_TestUser and perform same operation
touch /nfs/general/AFS_TestUser_general.test

Then, check its ownership:

$ ls -lah /nfs/general/AFS_TestUser_general.test
-rw-rw-r--. 1 AFS_TestUser AFS_TestUser 0 Mar 12 2018 /nfs/general/AFS_TestUser_general.test

Example 2: The Distributed export

First, Create a TLD

mkdir /nfs/home/home1/AFS_TestUser

Then, check its ownership:

$ ls -lah  /nfs/home/home1/AFS_TestUser
total 512
drwxrwxr-x. 2 AFS_TestUser AFS_TestUser 2 Mar 12 2018 .

2 replies

Userlevel 2
Badge +1

What is root squash?

Root squash basically remaps the root UID from 0 to an anonymous user with no privileges. This means that root is stripped of all privileges and is not able to read any files which are not world read or write to any paths that are restricted.
[root@NFSClient ~]# id -u

There are two directories in this example.

# ls -ltrh /mnt/nfs
total 1.0K
drwxr-xr-x. 2 root root 7 Nov 24 2018 files
drwxrwxr-x. 2 piyush piyush 3 Nov 24 2018 Piyush

So the permission to root is not there, which is because of following setting.
Squash Type : ROOT_SQUASH, which is by default.

For example, root cannot create file in the dir owned by user piyush.

[root@NFSClient piyush]# touch root.txt
touch: cannot touch ‘root.txt’: Permission denied

But once it's changed to "Squash Type : NONE", root user starts behaving like super user again.

[root@NFSClient ~]# touch /mnt/nfs/piyush/root.txt
[root@NFSClient ~]# ls -ltrh /mnt/nfs/piyush/
total 1.0K
-rw-rw-r--. 1 piyush piyush 0 Nov 24 2018 piyush.txt
-rw-r--r--. 1 root root 0 Nov 24 2018 root.txt

This option is available as per Export basis and can be updated under Advanced NFS Settings.



I mounted a distributed share/export NFS resource, with File System Compression enabled, with System Authentication  and with advanced NFS Settings  (Squash None).


The problem is that I can create a root folder (prueba) and create files inside and other folders without problem. But If i want to remove  the root folder created with the command rm -rf  I allways get the message “Device or resource busy” and I can’t remove the root folder.


It only happens in distributed NFS share. In standard share works perfectly.


Attached is a screen capture.


Any help?


Thank you.