Mounting of NFS version 3 not possible

The remote machine has NFS server installed and running. The NFS shared directory is exported and there is no firewall blocking client IP access. We followed the procedure outlined in this article on an Ubuntu 20.04 system. To confirm the NFS share has been mounted, use the command “df -h”. Next, test the NFS shared directory on the client machine by accessing some files from the server.


Question:

My goal is to successfully mount an
NFS share
using NFS version 3. Interestingly, it works on one cluster of servers but not on the other. In the cluster where it works, I have achieved the desired outcome.


10.100.30.81:/var/lib/test /var/lib/test nfs hard,bg,intr,vers=3,noatime 0 0

The performance is satisfactory and upon utilizing the

rpcinfo

, the outcome is as follows.

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100024    1   udp  43989  status
    100005    2   tcp  20048  mountd
    100024    1   tcp  44845  status
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  56714  nlockmgr
    100021    3   udp  56714  nlockmgr
    100021    4   udp  56714  nlockmgr
    100021    1   tcp  44307  nlockmgr
    100021    3   tcp  44307  nlockmgr
    100021    4   tcp  44307  nlockmgr
You have new mail in /var/spool/mail/root
[root@test1 ~]# 

I have arranged the non-functional system.

10.200.100.80:/var/lib/test2 /var/lib/test2 nfs soft,bg,intr,vers=3,noatime 0 0

When I try to mount it I get

[root@mon2 ~]# mount -avvvvvvvv
/                        : ignored
/boot                    : already mounted
swap                     : ignored
mount.nfs: trying text-based options 'soft,bg,intr,vers=3,addr=10.200.100.80'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Program not registered
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Program not registered
mount.nfs: backgrounding "10.200.100.80:/var/lib/test2"
mount.nfs: mount options: "rw,noatime,soft,bg,intr,vers=3"
/var/lib/test2        : successfully mounted
[root@mon2 ~]

Upon executing

rpcinfo

, a response is returned.

[root@mon2 ~]# rpcinfo -p  10.200.100.80
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
[root@mon2 ~]#

It seems like there may be a configuration issue with my
NFS server
. Upon inspection, I noticed that

rpcbind

and other services are running similarly on both. What other areas should I investigate?


Solution:

[root@mon2 ~]# rpcinfo -p  10.200.100.80
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper

The 10.200.100.80 system’s

portmapper

service should know about the NFSv3 server that is expected to run

portmapper

,

nfs

,

nfs_acl

,

status

,

mountd

, and

nlockmgr

services, but it reports that none of them are currently running.

When the

mount

command encounters a filesystem type that it cannot handle internally, it utilizes other

/sbin/mount.<filesystem type>

utilities. In the case of NFS, the

/sbin/mount.nfs

utility is used to manage
NFS mount
s.

Upon mounting an NFSv3 share, the

mount.nfs

tool initially inquires the NFS server’s

portmapper

service regarding the available protocols and corresponding ports for their use.

mount.nfs: prog 100003, trying vers=3, prot=6

The

mount.nfs

tool is inquiring about the

nfs

service version 3 on TCP from the NFS server’s

portmapper

service. The program and protocol numbers can be verified from the respective

/etc/rpc

and

/etc/protocols

files.

mount.nfs: portmap query retrying: RPC: Program not registered

The server’s reply indicates that the service requested is unavailable by stating, “I’m sorry, the service is not available.

mount.nfs: prog 100003, trying vers=3, prot=17

Do you have NFS version 3 running on UDP protocol?

mount.nfs: portmap query failed: RPC: Program not registered

“Sorry, I don’t have that either.”

mount.nfs: backgrounding "10.200.100.80:/var/lib/test2"

By utilizing the

bg

mount option, a background process is established by

mount.nfs

for continual NFS mount retry attempts. This is done in anticipation of the server beginning its
NFS services
at a later time. As

mount.nfs

keeps attempting the mount, it cannot accurately inform the primary

mount

command of any failures since the mount operation may succeed at some point in the future. As a result,

mount.nfs

will return a “success” result code to the main

mount

command.

/var/lib/test2        : successfully mounted

The NFS mounting process details are unknown to the

mount

command, which interprets the “success” result code as indicating successful mounting of the filesystem. However, in this case, the result code merely signifies that the

mount.nfs

is still attempting the process.


It is evident that host 10.200.100.80 is the issue as per its

portmapper

which suggests that it is not equipped with the essential services to function as an NFS server.

Regrettably, you failed to mention the name and version of the OS running on the host, thus the process to initiate the NFS server services may differ slightly across various
Linux distributions
.

Although the NFS server services are set to start automatically, some distributions may skip starting them during the system’s boot if there are no NFS shares in the

/etc/exports

file. Therefore, it is crucial to verify that the

/etc/exports

file on the 10.200.100.80 host defines

/var/lib/test2

as an NFSv3 share before attempting to start the NFS server services. Additionally, you must determine how to initiate the NFS server services on the host and set them to start automatically during future boots.

The in-kernel server typically handles the services denoted as

nfs

,

nfs_acl

, and

nlockmgr

. A

/usr/sbin/rpc.nfsd

runs only once to configure the kernel components and exits afterwards. On the other hand, the user-space processes handle the services

status

and

mountd

, running

/usr/sbin/rpc.statd

and

/usr/sbin/rpc.mountd

respectively. Depending on your Linux distribution, you may have to start them individually or use a single script, service, or target to start all of them.

If you’re using Debian/Ubuntu, try using the command

systemctl start nfs-server.service

. For RHEL 7.x, starting both services

nfs-lock

and

nfs

is necessary to enable NFSv3 server support.

Frequently Asked Questions