1753759 Members
4840 Online
108799 Solutions
New Discussion юеВ

Re: 11.23 NFS and AutoFS

 
SOLVED
Go to solution
T G Manikandan
Honored Contributor

Re: 11.23 NFS and AutoFS

Doc.
Pete Randall
Outstanding Contributor

Re: 11.23 NFS and AutoFS

Thanks, T.G., but that shows me how to run the trace on the server, which in this case is Novell Netware, so those instructions aren't going to apply.


Pete

Pete
Dave Olker
HPE Pro

Re: 11.23 NFS and AutoFS

Hi Pete,

TG's instructions are fine. Nettl syntax is the same on NFS clients and servers, so the typical instructions would be:

# nettl -tn pduin pduout -e ns_ls_ip -f /tmp/mntfail



# nettl -tf -e all

I'm sure you could script this to minimize the amount of time the trace is collecting - the less in the trace the easier it is to read it.

I'd also like to see a trace of the working mount command from the 11.11 client, so the instructions would be the same but hopefully you'd name the trace file something else, like:

# nettl -tn pduin pduout -e ns_ls_ip -f /tmp/mntgood



# nettl -tf -e all


I prefer to look at the raw trace files rather than a formatted ones, so please post or email me the resulting /tmp/mntfail.TRC000 and /tmp/mntgood.TRC000 (or whatever they end up being called) files.

As for netfmt, I haven't used that in a long time because Wireshark knows how to interpret HP netfmt trace files. If you want to look at the traces, I'd suggest firing up Wireshark either on the HP-UX system or a PC and load in the mntfail.TRC000 file and mntgood.TRC000 file. You can filter those traces on RPC or NFS, or you can filter based on the IP address of the Novell server, and see only that traffic.

Let me know when the trace files are ready.

Regards,

Dave
I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
Pete Randall
Outstanding Contributor

Re: 11.23 NFS and AutoFS

Dave,

The trace is in the mail.


Pete

Pete
Dave Olker
HPE Pro

Re: 11.23 NFS and AutoFS

Pete,

Got the traces. I never see a single MOUNT request in the failing trace. Did you actually issue the command:

# mkdir /test1
# mount 130.1.0.245:/prod1/common /test1

or were you trying to mount the filesystems via AutoFS while this trace was running? I see a number of cases where the client contacts the server's rpc.mountd and requests the list of exported filesystems (i.e. showmount -e) but never a single MOUNT request.

If you did not actually issue the manual mount commands then please collect a new trace on the 11.23 system where you issue the manual mount command.

Dave
I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
Pete Randall
Outstanding Contributor

Re: 11.23 NFS and AutoFS

Dave,

Honest, I really did run the mount command. To be absolutely sure, I re-did it this morning and sent you a new set of results.


Pete

Pete
Dave Olker
HPE Pro

Re: 11.23 NFS and AutoFS

Pete,

You used the wrong mount command syntax. I sent you another email with the exact commands I want you to run.

Dave
I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
Dave Olker
HPE Pro
Solution

Re: 11.23 NFS and AutoFS

Ok, here are the relevant packets:

Internet Protocol, Src: 130.1.0.236 (130.1.0.236), Dst: 130.1.0.245 (130.1.0.245)
User Datagram Protocol, Src Port: realm-rusd (688), Dst Port: search-agent (1234)
Remote Procedure Call, Type:Call XID:0x49ac3178
XID: 0x49ac3178 (1236021624)
Message Type: Call (0)
RPC Version: 2
Program: MOUNT (100005)
Program Version: 3
Procedure: MNT (1)
[The reply to this request is in frame 6]
Credentials
Flavor: AUTH_UNIX (1)
Length: 72
Stamp: 0x49a2bdcc
Machine Name: rdws2
length: 5
contents: rdws2
fill bytes: opaque data
UID: 0
GID: 3
Auxiliary GIDs
GID: 3
GID: 20
GID: 5
GID: 1
GID: 6
GID: 22
GID: 4
GID: 2
GID: 7
GID: 10
GID: 0
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Mount Service
[Program Version: 3]
[V3 Procedure: MNT (1)]
Path: /prod1/common
length: 13
contents: /prod1/common
fill bytes: opaque data



Internet Protocol, Src: 130.1.0.245 (130.1.0.245), Dst: 130.1.0.236 (130.1.0.236)
User Datagram Protocol, Src Port: search-agent (1234), Dst Port: realm-rusd (688)
Remote Procedure Call, Type:Reply XID:0x49ac3178
XID: 0x49ac3178 (1236021624)
Message Type: Reply (1)
[Program: MOUNT (100005)]
[Program Version: 3]
[Procedure: MNT (1)]
Reply State: accepted (0)
[This is a reply to a request in frame 5]
[Time from request: 0.002183000 seconds]
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Mount Service
[Program Version: 3]
[V3 Procedure: MNT (1)]
Status: ERR_NOENT (2)



This trace shows NFS client "rdws2" is requesting to mount /prod1/common from NFS server "130.1.0.245" and getting an ERR_NOENT, which is the NFS server telling the client "that mount point doesn't exist", but it can also mean "you're not allowed to mount this".

Is the client name "rdws2" correct? Are you positive the NFS server is allowing client "rdws2" to mount this filesystem? If so, this is nothing the HP-UX system can control.

Dave
I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
Pete Randall
Outstanding Contributor

Re: 11.23 NFS and AutoFS

Dave,

I just got a call from the NetAdmin. For some strange reason he decided to try explicitly adding to his mount list - it's now the only entry because previously, if DNS could resolve it, it was allowed.

Anyway, miracle of miracles, it now works. It's pretty much like we thought all along. The HP side was fine and the Novell side was rejecting.

Sorry to drag you through all this and thanks for all your efforts.


Pete

Pete
HP-FMS
Frequent Advisor

Re: 11.23 NFS and AutoFS

hi All,

I am also in similar type of problem from a very long time.

 

11iv3 (Unix Nfs server) .. upgraded to latest ONCplus software....

 

11iv2 (Unix nfs client)

 

autofs is misbehaving... One file having bigger size is not visible at Unix nfs client intermittently

 

Can anybody help?