11.23 NFS and AutoFS

[Pete Randall]

I spent some time looking over logs with the network guy and we found where the mount request is coming in to the Novell server. Interestingly enough, the Novell server says it is "unable to resolve 130:1:0:236 to a name". That's my own very loose translation, but the key, I think, is the colons in place of periods in the IP address. Of course it can't find it!!

The only problem is where the heck it's coming up with this colon'ated name. If anyone has any thought on that subject, I'd love to hear them.


Pete

[Dave Olker]

Pete,

That could just be the way the Novell box formats the IP address. It doesn't necessarily mean it's receiving the IP address that way. Again, a network trace would prove what the 11.23 system is sending.

It certainly sounds like this is a hostname resolution issue on the Novell side. Can they confirm the Novell box can resolve the 11.23 IP address to the hostname and vice versa?

Dave

[Pete Randall]

Yes, resolution appears to be working - both nslookup and ping work just marvelously.


Pete

[Dave Olker]

I've seen cases where hostname resolution changes were made after daemons were running and the only way to get the daemons to see those changes is to restart them.

Any chance the hostname resolution stuff changed recently, like since the mountd on the Novell box was started? If you terminate/re-start the mountd daemon on the Novell box that would force it to reinitialize any hostname resolution stuff.

Dave

[Pete Randall]

The ping and nslookup lead me to believe that resolution is OK on the Novell side. We'll consider restarting DNS and mountd if we can't come up with anything else.

Here's the exact error messages from the Novell log:

2-18-2009 6:19:57 am:Warning:Could not resolve 130:1:0:236 to a name /prod1/common. Mount will fail
2-18-2009 6:19:57 am:Warning:130.1.0.236 Failed to mount /prod1/common using Mount version 3. Permission denied.

I'm not sure whether that means that it can't resolve 130:1:0:236 - or it can't associate that client with /prod1/common.


Pete

[Dave Olker]

Sure sounds like the mountd can't resolve that IP address to a hostname. If it were my system my next step would be restarting the mount daemon.

[Steven E. Protter]

Shalom again,

"unable to resolve 130:1:0:236 to a name".

That screams software bug.

I know what you think of patches. But perhaps now is the time for a fat SEP depot.

SEP

[Pete Randall]

We're going to reboot the Novell server this evening and we'll see where that gets us. I'll update after I check things in the morning.


Pete

[Dave Olker]

> I know what you think of patches. But
> perhaps now is the time for a fat SEP depot.

You maintain depots for Novell systems?

[Pete Randall]

I think Steve was referring to patching the living daylights out of the HP machine.

;^)


Pete

[Dave Olker]

I haven't seen any indication of this being an HP problem. So far everything you've provided points to a Novell problem. If someone sees something different please point it out.

[Pete Randall]

I have to agree with Dave. Besides, I already put the latest NFS and automount patches on, so the HP side should be in pretty good shape.


Pete

[Patrick Wallek]

Pete,

I found the following in Novell's forums. It is somewhat old, but it might help.

http://forums.novell.com/novell-product-support-forums/native-file-access/163691-nfs-client-mount-failed.html

[Pete Randall]

Well, rebooting the Novell server didn't make any difference, so I guess it's time for a nettl trace. Not having any familiarity with nettl tracing, how would I go about this?


Pete

[Pete Randall]

I'll take that back, the Novell serer won't be rebooted until tonight. However, it might be a good idea to go ahead with the nettl trace if anyone wanted to help me out with syntax.


Pete

[T G Manikandan]

Doc.

[Pete Randall]

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

[Dave Olker]

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

[Pete Randall]

Dave,

The trace is in the mail.


Pete

[Dave Olker]

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

[Pete Randall]

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

[Dave Olker]

Pete,

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

Dave

[Dave Olker · Accepted solution]

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

[Pete Randall]

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

[HP-FMS]

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?