1820072
Members
2655
Online
109608
Solutions
Hi Marc,
Since the server is not an HP-UX system, a network trace is probably the easiest way to determine why the mount is failing. Please collect a network packet trace of the failing mount command using whatever tool you're comfortable with (ethereal, nettl, tcpdump). Try using the default mount options, as it doesn't seem like any combination of mount options you've tried has made a difference.
You can either post the raw trace file here or email me a copy and I'll take a look at it.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Since the server is not an HP-UX system, a network trace is probably the easiest way to determine why the mount is failing. Please collect a network packet trace of the failing mount command using whatever tool you're comfortable with (ethereal, nettl, tcpdump). Try using the default mount options, as it doesn't seem like any combination of mount options you've tried has made a difference.
You can either post the raw trace file here or email me a copy and I'll take a look at it.
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Marc,
Sorry, I was meaning for you to attach the raw trace as an attachment so that I can load it into ethereal and look at it there. Trying to decode the raw hexidecimal trace is not something I typically enjoy (although I've had to do it a number of times :).
Please attach the full tcpdump trace to your next post so that I can download it and analyze it in ethereal.
Thanks,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Sorry, I was meaning for you to attach the raw trace as an attachment so that I can load it into ethereal and look at it there. Trying to decode the raw hexidecimal trace is not something I typically enjoy (although I've had to do it a number of times :).
Please attach the full tcpdump trace to your next post so that I can download it and analyze it in ethereal.
Thanks,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
One other thing - when collecting the trace, please don't filter it based on any specific port number.
I am not only interested in the communication with the AIX mountd daemon, but all of the RPC packets in the trace. Most of the time when an NFS mount fails, it has nothing to do with the server's rpc.mountd daemon.
I'd like an unfiltered trace of the mount attempt that is started before the mount command is launched and stopped after the resulting error message. That way it will be sure to contain all relevant RPC packets.
Thanks,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
I am not only interested in the communication with the AIX mountd daemon, but all of the RPC packets in the trace. Most of the time when an NFS mount fails, it has nothing to do with the server's rpc.mountd daemon.
I'd like an unfiltered trace of the mount attempt that is started before the mount command is launched and stopped after the resulting error message. That way it will be sure to contain all relevant RPC packets.
Thanks,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Marc,
If you want to load up your system with patches first, by all means do so. I'm more than happy to look at a trace of the problem and tell you why the mount is failing. I used to do that every day for 8 years when I was an NFS engineer in the WTEC team, so I kinda miss it. :)
Anyway, your choice.
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
If you want to load up your system with patches first, by all means do so. I'm more than happy to look at a trace of the problem and tell you why the mount is failing. I used to do that every day for 8 years when I was an NFS engineer in the WTEC team, so I kinda miss it. :)
Anyway, your choice.
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Hi Marc,
From what I can see here, the AIX system is choking on the MOUNT request and returning a bogus error message. Here is a snippet of the formatted trace (heavily edited for content):
No. Time Source Destination Protocol Info
1 0.000000 198.212.202.39 198.212.202.120 Portmap V2 GETPORT Call (Reply In 2) MOUNT(100005) V:3 UDP
2 0.046269 198.212.202.120 198.212.202.39 Portmap V2 GETPORT Reply (Call In 1) Port:32892
3 0.046331 198.212.202.39 198.212.202.120 MOUNT V3 NULL Call (Reply In 4)
4 0.046404 198.212.202.120 198.212.202.39 MOUNT V3 NULL Reply (Call In 3)
5 0.046457 198.212.202.39 198.212.202.120 MOUNT V3 MNT Call (Reply In 6) /mwb
6 0.046520 198.212.202.120 198.212.202.39 MOUNT V3 MNT Reply (Call In 5) Error:Unknown (0xFFFFFFFF)
Frame 5 (142 bytes on wire, 142 bytes captured)
Remote Procedure Call, Type:Call XID:0x43ae3486
XID: 0x43ae3486 (1135490182)
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: 52
Stamp: 0x43a0697e
Machine Name: chartmax.yumaregional.org
length: 25
contents: chartmax.yumaregional.org
fill bytes: opaque data
UID: 0
GID: 3
Auxiliary GIDs
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Mount Service
Program Version: 3
V3 Procedure: MNT (1)
Path: /mwb
length: 4
contents: /mwb
Frame 6 (70 bytes on wire, 70 bytes captured)
Remote Procedure Call, Type:Reply XID:0x43ae3486
XID: 0x43ae3486 (1135490182)
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.000063000 seconds
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Mount Service
Program Version: 3
V3 Procedure: MNT (1)
Status: Unknown (4294967295)
Frames 5 and 6 are the key packets. Frame 5 shows the HP-UX client sending what appears to be a perfectly valid MOUNT request to the AIX server. Frame 6 shows the mountd daemon/thread on the AIX server processed the RPC call successfully but returned a bizarre status to the client, which is why the mount command fails. The status appears to be a -1 (0xffffffff).
Can any other NFS clients successfully mount this same filesystem from this specific AIX server?
Is this a production AIX system or can you try rebooting it to see if the problem clears? If it is a production system, can you try stopping and restarting the mount daemon/thread on the AIX system and see if that clears up the problem? Have you contacted anyone in AIX support to see if this is a known problem for them (mount returning a -1 status)?
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
From what I can see here, the AIX system is choking on the MOUNT request and returning a bogus error message. Here is a snippet of the formatted trace (heavily edited for content):
No. Time Source Destination Protocol Info
1 0.000000 198.212.202.39 198.212.202.120 Portmap V2 GETPORT Call (Reply In 2) MOUNT(100005) V:3 UDP
2 0.046269 198.212.202.120 198.212.202.39 Portmap V2 GETPORT Reply (Call In 1) Port:32892
3 0.046331 198.212.202.39 198.212.202.120 MOUNT V3 NULL Call (Reply In 4)
4 0.046404 198.212.202.120 198.212.202.39 MOUNT V3 NULL Reply (Call In 3)
5 0.046457 198.212.202.39 198.212.202.120 MOUNT V3 MNT Call (Reply In 6) /mwb
6 0.046520 198.212.202.120 198.212.202.39 MOUNT V3 MNT Reply (Call In 5) Error:Unknown (0xFFFFFFFF)
Frame 5 (142 bytes on wire, 142 bytes captured)
Remote Procedure Call, Type:Call XID:0x43ae3486
XID: 0x43ae3486 (1135490182)
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: 52
Stamp: 0x43a0697e
Machine Name: chartmax.yumaregional.org
length: 25
contents: chartmax.yumaregional.org
fill bytes: opaque data
UID: 0
GID: 3
Auxiliary GIDs
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Mount Service
Program Version: 3
V3 Procedure: MNT (1)
Path: /mwb
length: 4
contents: /mwb
Frame 6 (70 bytes on wire, 70 bytes captured)
Remote Procedure Call, Type:Reply XID:0x43ae3486
XID: 0x43ae3486 (1135490182)
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.000063000 seconds
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Mount Service
Program Version: 3
V3 Procedure: MNT (1)
Status: Unknown (4294967295)
Frames 5 and 6 are the key packets. Frame 5 shows the HP-UX client sending what appears to be a perfectly valid MOUNT request to the AIX server. Frame 6 shows the mountd daemon/thread on the AIX server processed the RPC call successfully but returned a bizarre status to the client, which is why the mount command fails. The status appears to be a -1 (0xffffffff).
Can any other NFS clients successfully mount this same filesystem from this specific AIX server?
Is this a production AIX system or can you try rebooting it to see if the problem clears? If it is a production system, can you try stopping and restarting the mount daemon/thread on the AIX system and see if that clears up the problem? Have you contacted anyone in AIX support to see if this is a known problem for them (mount returning a -1 status)?
Regards,
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
The only other suggestion I can make is to collect another tcpdump of the AIX client successfully mounting the same filesystem and posting it here for me to look at. I can compare the MOUNT requests from the HP-UX client and the AIX client and see if there is anything different in the two MOUNT requests that would cause the server to treat them differently.
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Dave
I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]