PDA

View Full Version : Need help with an NFS client



x0500hl
20-May-2013, 18:17
I have a SLES 11 SP2 server, kernel 3.0.58-0.6.6-default, that is having problems mounting an NFS share from a different SLES 11 SP2 server, kernel 3.0.38-0.5-default. The option to use nfs4 in /etc/sysconfig/nfs is set to 'yes'.

I have a script the mounts the share, at boot, as the client server has to start and initialize prior to the boot of the server that is hosting the share. The script does a ping test for the other server and issues "mount test:/xs2files_maint/DataExtracts /db2extract" once the ping is successful. I noticed that the filesystem is not being mounted at boot time so I began debugging as follows.

I get the following messages when I enter command: mount -vvv -o rw,port=2049,mountproto=tcp test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT

mount: fstab path: "/etc/fstab"
mount: mtab path: "/etc/mtab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: UID: 0
mount: eUID: 0
mount: no type was given - I'll assume nfs because of the colon
mount: spec: "test:/xs2files_maint/DataExtracts"
mount: node: "/db2extract/XSR010_DATA_EXTRACT"
mount: types: "nfs"
mount: opts: "(null)"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "test:/xs2files_maint/DataExtracts"
mount: external mount: argv[2] = "/db2extract/XSR010_DATA_EXTRACT"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw"
mount.nfs: timeout set for Mon May 20 10:58:25 2013
mount.nfs: trying text-based options 'addr=10.17.1.131'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.17.1.131 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.17.1.131 prog 100005 vers 3 prot UDP port 32767
mount.nfs: mount(2): Address already in use
mount.nfs: Address already in use


I get the following messages when I enter command: mount -vvv -o rw,port=2049,mountproto=tcp,vers=4 test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT
mount: fstab path: "/etc/fstab"
mount: mtab path: "/etc/mtab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: UID: 0
mount: eUID: 0
mount: no type was given - I'll assume nfs because of the colon
mount: spec: "test:/xs2files_maint/DataExtracts"
mount: node: "/db2extract/XSR010_DATA_EXTRACT"
mount: types: "nfs"
mount: opts: "port=2049,mountproto=tcp,vers=4"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "test:/xs2files_maint/DataExtracts"
mount: external mount: argv[2] = "/db2extract/XSR010_DATA_EXTRACT"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,port=2049,mountproto=tcp,vers=4"
mount.nfs: timeout set for Mon May 20 11:36:42 2013
mount.nfs: trying text-based options 'port=2049,mountproto=tcp,vers=4,addr=10.17.1.131, clientaddr=10.17.1.155'
test:/xs2files_maint/DataExtracts on /db2extract/XSR010_DATA_EXTRACT type nfs (rw,port=2049,mountproto=tcp,vers=4)


All I added to the command was ',vers=4' to the -o parameter and the mount was successful.

It appears that the nfs client is attempting to use version 3 of the nfs protocol based on the messages and forcing it to use version 4 causes the share to mount successfully:
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.17.1.131 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.17.1.131 prog 100005 vers 3 prot UDP port 32767

I've searched Google to see where the option to use nfs protocol 3 is but can't find it. Where is this option located?


Harley

ab
20-May-2013, 19:15
How about the 'type' option for the mount command?

mount -t nfs etc.etc.etc.

Good luck.

ab
20-May-2013, 19:18
As I re-read your post, I wonder if you're not asking how to make it use
nfs v3 as much as why it's trying it. Well, no idea, but if you want to
force it otherwise maybe use type but with 'nfs4' instead of just 'nfs'.
Personally I think commands that have a lot of power ('mount' does, of
course) should be as explicit as possible, and in this case should include
a type.

Good luck.

x0500hl
20-May-2013, 19:55
Thanks Ab, but all of my other SLES 11 SP2 servers are able to issue a mount for NFS without specifying the type '-t' switch. I would like to determine why this server is attempting to use NFS v3. It was cloned from the same base as each of the other SLES 11 servers. I've reviewed all of the changes that were documented as being made and couldn't see anything out of whack. I also ran a supportconfig on this server and one other one (where nfs v4 is being used) and subsequently compared all the files in the resulting .tgz file. Nothing looks out of place.

jmozdzen
23-May-2013, 11:55
Hi Harley,

could you please double-check the syntax of your options list? What catches the eye is:

> mount -vvv -o rw,port=2049,mountproto=tcp test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT
> [...]
> mount: opts: "(null)"
> [...]
> mount: external mount: argv[5] = "rw"

> mount -vvv -o rw,port=2049,mountproto=tcp,vers=4 test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT
> [...]
> mount: opts: "port=2049,mountproto=tcp,vers=4"
> [...]
> mount: external mount: argv[5] = "rw,port=2049,mountproto=tcp,vers=4"

According to my memories and documentation, both "port" and "mountproto" are valid v3 parameters, so why don't they turn up in the "v3 mount option list"?

Nevertheless, according to "man 5 nfs", SLES11SP2 should try to probe v4 first, so even without any options, you shouldn't see v3 requests first:

nfsvers=n The NFS protocol version number used to contact the server's NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client negociate a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.

vers=n This option is an alternative to the nfsvers option. It is included for compatibility with other operating systems.

Just my 0.02 $

Regards,
Jens

x0500hl
23-May-2013, 16:34
Jens,

I went back and tried the mount command without specifying options. The command is failing with 'address already in use' and appears to only be invoking nfsv3.

#mount -vvv test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT
mount: fstab path: "/etc/fstab"
mount: mtab path: "/etc/mtab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: UID: 0
mount: eUID: 0
mount: no type was given - I'll assume nfs because of the colon
mount: spec: "test:/xs2files_maint/DataExtracts"
mount: node: "/db2extract/XSR010_DATA_EXTRACT"
mount: types: "nfs"
mount: opts: "(null)"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "test:/xs2files_maint/DataExtracts"
mount: external mount: argv[2] = "/db2extract/XSR010_DATA_EXTRACT"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw"
mount.nfs: timeout set for Thu May 23 10:24:09 2013
mount.nfs: trying text-based options 'addr=10.17.1.131'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.17.1.131 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.17.1.131 prog 100005 vers 3 prot UDP port 32767
mount.nfs: mount(2): Address already in use
mount.nfs: Address already in use


I modified the mount command by adding '-o vers=4' and the mount was successful.

#mount -vvv -o vers=4 test:/xs2files_maint/DataExtracts /db2extract/XSR010_DATA_EXTRACT
mount: fstab path: "/etc/fstab"
mount: mtab path: "/etc/mtab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: UID: 0
mount: eUID: 0
mount: no type was given - I'll assume nfs because of the colon
mount: spec: "test:/xs2files_maint/DataExtracts"
mount: node: "/db2extract/XSR010_DATA_EXTRACT"
mount: types: "nfs"
mount: opts: "vers=4"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "test:/xs2files_maint/DataExtracts"
mount: external mount: argv[2] = "/db2extract/XSR010_DATA_EXTRACT"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,vers=4"
mount.nfs: timeout set for Thu May 23 10:27:06 2013
mount.nfs: trying text-based options 'vers=4,addr=10.17.1.131,clientaddr=10.17.1.155'
test:/xs2files_maint/DataExtracts on /db2extract/XSR010_DATA_EXTRACT type nfs (rw,vers=4)

I'm trying to figure out why this SLES 11 SP2 server requires the use of '-o vers=4' when a different SLES 11 SP2 server doesn't require this parameter (both of these servers are attempting to mount a different directory from the same nfs server). The server that is having the problem is running at a more current patch level than the server that doesn't require this parameter (the kernel versions are listed in my first post). Each of the client servers were upgraded to the most current patch level when they were cloned from a 'golden image' and they were cloned a few weeks apart.

Could this simply be maintenance related (where I need to open a SR with Novell)?


Harley

jmozdzen
23-May-2013, 17:37
Hi Harley,

if you have the option to open a SR, then I'd recommend to got that path: From what I can tell, the mount.nfs version shipped with SP2 should try to connect via nfsv4 first (and succeed in your case as the NFS server clearly supports this) before trying v3 or even v2.

Regards,
Jens

x0500hl
24-Jun-2013, 19:54
Jens,

I opened an SR and Novell found that I had specified the same port number for LOCKD and STATD. When I changed one of the port numbers, the nfs mount was successful.

The port settings are the same on all of my servers yet this one failed the nfs mount (this server is at a higher patch level than the other servers). Novell even went so far as to back-level the kernel and the nfs-client on their test server and still had the problem. I didn't think that it was worth pursuing so I asked them to close the SR.

Thank you for your assistance.


Harley

jmozdzen
25-Jun-2013, 09:52
Hi Harley,

great that your issue got resolved and thank you a lot to report back the results!

Regards,
Jens