We are moving our fileserver from CentOS 6 to CentOS 7, but I have a problem with the client running on HPUX 11.00 .
With the CentOS 6 fileserver, the NFS shares works fine, but when I tried to mount a NFS share from the CentOS 7 fileserver, I got this error :
bash-2.04# mount 10.24.116.6:/data/infra /u
nfs mount: getaddr_nfs: 10.24.116.6: NFS service not responding(retry delay=5s)
nfs mount: retry: retrying(1) for: /u after 5 seconds
nfs mount: retry: giving up on: /u
My network is the following :
a client running on HPUX 11.00 , IP = 10.24.116.5
an old fileserer on CentOS 6, IP = 10.24.116.4
the new fileserver on CentOS 7, IP = 10.24.116.6
Here are the controls I have made following results of my search with google :
The CentOS 7 shares folder without any problem with other NFS client running on CentOS
ping beetween client and server is OK in both direction
the client and the server have the same domainname
I have activated NFS v2 on the CentOS 6 server to be similar to CentOS 6 (in /etc/nfs.conf, I have set "vers2=y" in section [nfsd] ). Checked on the client that NFS is visible with protocol v2, v3 and v4:
I thought 11.00 was no more supported?
Why are you using IP and not hostname?
Is the server found in /etc/hosts file of the HP-UX box?
Is the nfs-client module running on th HP-UX?
On the CentOS 7 NFS server, there are a couple of things you could check and try.
Firstly, is the rpcbind service enabled and running on the CentOS 7 server ? If it isn't, then NFS v2/v3 won't be able to work when clients try to connect using those versions, though 4.x will work fine.
Secondly, you could try configuring NFS on the CentOS 7 box to explicitly disable everything except (for example) NFS v2, and see if your old HPUX client can then connect. You'd do this by putting a line like the following in /etc/sysconfig/nfs :
RPCNFSDARGS="-V 2 -N 3 -N 4 -N 4.1 -N 4.2 -N 4.3"
and then re-starting the NFS services. That should make the kernel NFS server start up with only support for v2, which (if version compatibility is the issue) might make your HPUX box able to connect. Of course this would also prevent more modern clients from being able to use a more modern version of NFS, but at least for debugging purposes you'd then know for sure you were on the right track with regard to what the problem was.
Hope this helps ! If neither of these suggestions help you get closer to a solution, let us know and we can take things from there.
using IP is not a problem (it was just because during this test I was looking if there is no problem with name resolution). The new fileserver is correctly define in /etc/hosts and ping with its hostname. I have tried to mount with IP address or hostname and I have exactly the same result.
the nfs-client is running : I can mount folders from the old NFS server without any problem.
the rpcbind is active. I was thinking that seen result of "rpcinfo -p nfsserver" on client side was sufficient, but since you asked, I check it on the server with systemctl. It indicates a syntax error in the hosts.allow file, but after correction and restart of rpcbind and nfs-server services, the problem is still here. Is there another service I need to restart ?
For the test with only NFS v2 protocol, the file server is already in use, so I will configure a VM for test purpose and I let you know the results.
Well., I have tried with a fileserver giving only NFS v2, but I still get the same error.
Some facts, I have noted (I don't know if it can help or not) :
with your options, nfs v3 and v4 are still visible in rpcinfo results, while I think they will disappear.
Regarding the versions: if you have re-started the NFS services after making the change (systemctl restart nfs should in theory bounce all required services), then the version change should be in effect. You can double check by looking at the contents of /proc/fs/nfs/versions, where you should see output like the following if all you have enabled is v2:
However, in carrying out some more detailed testing myself (i.e. setting up an NFS server and trying to mount stuff from it), I have discovered something: NFS v2 is entirely unsupported in RHEL/CentOS 7, as per Red Hat's own docs here:
Yes, I have the same output from /proc/fs/nfs/versions.
Then, this file said that only v2 protocol is activated. In that case, what if RHEL 7 doesn't support v2 : all output are saying that I use protocol v2 , but nothing is really activated ? (sorry if it is explained in the link, but I have no access to Redhat Support)
It seems very strange to me to mislead users in this way, I would find it more logical to display an error to indicate that v2 protocol is disabled.
If it is a limitation of CentOS 7, I will look another way to shares the data (maybe with samba, or keeping a fileserver with CentOS 6).
It is a bit odd, I agree. But I think it comes down to a difference between what the NFS server can be configured to advertise, versus what it is actually capable of supporting. In other words, we can tell the CentOS 7 NFS server to advertise NFSv2 support, but that doesn't mean that the supplied binaries actually are compiled to support it.
And from my own testing at least, that seems to be the case. I cannot successfully mount anything using NFSv2 from a CentOS 7 test NFS server, even though I can configure it to advertise NFSv2 support (and indeed, to advertise nothing but NFSv2 support). But I can connect and mount exports with NFSv3 and NFSv4 without any problems.
So unfortunately I do think you are probably out of luck with this one. Unless there is support for at least NFSv3 at the HP side, then you will either need to use a different NFS server that does support NFSv2, or as you say, find another way of connecting the HP client up to the server altogether.
You should enable all NFS versions on the server, and trust that the negotiation works.
Check with mount or nfsstat -m which version is in use - of course only if it works!
Yes, kernel.org warns that NFSv2 is no longer supported, meaning the code is not entirely removed but no longer tested.
On the other hand, a patched HP-UX 11.0 should have NFSv3.
Try to mount with v3 and v2 mount -o vers=2,proto=udp ... mount -o vers=3,proto=tcp ...
Try the same on the CentOS 6 server (NFS-export accordingly).
Thanks for you suggestion, with this tests I add more informations and finally found the solution. In CentOS 7, there is 2 different services defined for nfs in the firewall :
nfs : which I have open initially and I sufficient for CentOS client (only TCP port are used)
nfs3 : which open TCP and UDP port. This one was blocked by firewall. Once open, I can mount my shared folder on my old HPUX client.
Only for information purposes, here are the tests I have made :
with NFS serveur on CentOS 7 , only NFS v2 activated :
NFS client on HP-UX can't open the shared folder, whatever the options "vers". Surprisingly, the option "proto" accept the "udp" value but give an error message with "tcp" value (while this value is described in documentation) : nfs mount: set_args: invalid value for option: "proto=tcp"
NFS client on CentOS 6 mount the shared folder without problem with the option "vers=2" (nfsstat -m confirm that protocol v2 is used and test with "vers=3" fails ). Then it seems that CentOS 7 is able to activate NFS v2 on server side.
NFS client on CentOS 7 : can't mount the shared folder (with and without the option "vers=2". Then, NFS v2 is unsupported on RHEL/CentOS 7 only for client side.