Hello, I am having a very strange problem NFS mounting exports from a SLES 9 machine on some (but not all) of my SUSE Linux 10.1 machines. This is a summary of the problem, though there are many more details to be had once I figure out what forum is most appropriate for trying to get it solved. For two out of five 10.1 machines, we cannot NFS mount filesystems exported from SLES 9 machines under a specific setup. On the SLES 9 NFS server, the filesystem is exported as follows (in /etc/exports and applied with "exportfs -a": /home bad101host.domain.name(rw,no_root_squash,sync) When sitting on bad101host, I issue: mount -t nfs sles9host.domain.name:/home /tmp_mnt On sles9host I see "rpc.mountd: authenticated mount request from bad101host" appear in the /var/log/messages. But on bad101host, the mount command hangs, never to return until "kill -9" is applied. (Ctrl-c and lesser kills have no effect.) ========= However, if the filesystem is exported on sles9host as follows: /home ##.##.##.0/24(rw,no_root_squash,sync) [The "#" are replaced with our subnet numbers.] and the same mount command is issued on bad101host, I see the same authenticated message logged on sles9host and the mount succeeds on bad101host. ========= Additionally, we have three other 10.1 machines that successfully mount the filesystems regardless of how they are exported. ------------------- All five of the 10.1 machines have: nfs-utils-1.0.7-36 nfsidmap-0.12-16 [Though I don't know if this is involved.] The SLES9 machines have: nfs-utils-1.0.6-103.23 [And no version of nfsidmap.] Any help, guidance, pointers would be greatly appreciated. -- Anthony Vealé National Snow and Ice Data Center E-Mail: veale@nsidc.org Phone: (303)735-5069
On Wednesday 09 August 2006 16:42, Anthony Veale wrote:
Hello,
I am having a very strange problem NFS mounting exports from a SLES 9 machine on some (but not all) of my SUSE Linux 10.1 machines.
This is a summary of the problem, though there are many more details to be had once I figure out what forum is most appropriate for trying to get it solved.
For two out of five 10.1 machines, we cannot NFS mount filesystems exported from SLES 9 machines under a specific setup.
On the SLES 9 NFS server, the filesystem is exported as follows (in /etc/exports and applied with "exportfs -a":
/home bad101host.domain.name(rw,no_root_squash,sync)
When sitting on bad101host, I issue:
mount -t nfs sles9host.domain.name:/home /tmp_mnt
On sles9host I see "rpc.mountd: authenticated mount request from bad101host" appear in the /var/log/messages.
But on bad101host, the mount command hangs, never to return until "kill -9" is applied. (Ctrl-c and lesser kills have no effect.)
=========
However, if the filesystem is exported on sles9host as follows:
/home ##.##.##.0/24(rw,no_root_squash,sync) [The "#" are replaced with our subnet numbers.]
and the same mount command is issued on bad101host, I see the same authenticated message logged on sles9host and the mount succeeds on bad101host.
=========
Additionally, we have three other 10.1 machines that successfully mount the filesystems regardless of how they are exported.
------------------- All five of the 10.1 machines have:
nfs-utils-1.0.7-36 nfsidmap-0.12-16 [Though I don't know if this is involved.]
The SLES9 machines have:
nfs-utils-1.0.6-103.23 [And no version of nfsidmap.]
Any help, guidance, pointers would be greatly appreciated.
Is portmap running on the erratic (bad101host) box? -- /Rikard ----------------------------------------------------------------------------- email : rikard.j@rikjoh.com web : http://www.rikjoh.com mob: : +46 (0)763 19 76 25 ------------------------ Public PGP fingerprint ---------------------------- < 15 28 DF 78 67 98 B2 16 1F D3 FD C5 59 D4 B6 78 46 1C EE 56 >
I am having a very strange problem NFS mounting exports from a SLES 9 machine on some (but not all) of my SUSE Linux 10.1 machines.
Is portmap running on the erratic (bad101host) box?
Yes, all the 10.1 machines (good and bad) have portmap-5beta-747 installed and portmap is running. rpcinfo -p reports udp and tcp ports for status (1 each) and nlockmgr (3 each). The ports reported are semi-random high order ports. E.g. Bad host 1: program vers proto port 100024 1 udp 32768 status 100021 1 udp 32768 nlockmgr 100021 3 udp 32768 nlockmgr 100021 4 udp 32768 nlockmgr 100024 1 tcp 58601 status 100021 1 tcp 58601 nlockmgr 100021 3 tcp 58601 nlockmgr 100021 4 tcp 58601 nlockmgr Good host 1: program vers proto port 100024 1 udp 32771 status 100021 1 udp 32771 nlockmgr 100021 3 udp 32771 nlockmgr 100021 4 udp 32771 nlockmgr 100024 1 tcp 49637 status 100021 1 tcp 49637 nlockmgr 100021 3 tcp 49637 nlockmgr 100021 4 tcp 49637 nlockmgr Possible red herring, but both the bad 10.1 hosts chose 32768 for their udp port, though they chose different numbers for their tcp ports. -- Anthony Vealé National Snow and Ice Data Center E-Mail: veale@nsidc.org Phone: (303)735-5069
I am having a very strange problem NFS mounting exports from a SLES 9 machine on some (but not all) of my SUSE Linux 10.1 machines.
This is a summary of the problem, though there are many more details to be had once I figure out what forum is most appropriate for trying to get it solved.
For two out of five 10.1 machines, we cannot NFS mount filesystems exported from SLES 9 machines under a specific setup.
On the SLES 9 NFS server, the filesystem is exported as follows (in /etc/exports and applied with "exportfs -a":
/home bad101host.domain.name(rw,no_root_squash,sync)
When sitting on bad101host, I issue:
mount -t nfs sles9host.domain.name:/home /tmp_mnt
On sles9host I see "rpc.mountd: authenticated mount request from bad101host" appear in the /var/log/messages.
But on bad101host, the mount command hangs, never to return until "kill -9" is applied. (Ctrl-c and lesser kills have no effect.)
Here is a fascinating followup to this issue. As I stated above, two of my five 10.1 machines were exhitibing this behavior. I had the opprotunity today to rename one of the two bad hosts and the NFS mount failures went away. Returning it to its original name brought back the NFS mount failures. A coworker had a brainstorm and I have now tested out his suggestion. With a sample size of ten host names I have found that every hostname whose length is 8 or fewer characters works. With lengths of 9 or more they fail. Summary: Length Fail? 5 No 6 No 7 No, three names 8 No 9 Yes, two names 10 Yes, two names (Remember this is only 10.1 trying to mount exports from SLES 9.) I really don't want to have to return to the world of 8 character limits on things. Does anyone have a clue whether there is a patch either for 10.1 or SLES 9 to deal with this? (I still can't tell whether this is an openSUSE 10.1 or a SLES 9 issue.) -- Anthony Vealé National Snow and Ice Data Center E-Mail: veale@nsidc.org Phone: (303)735-5069
I am reposting this with a changed subject because it might not end up being an NFS specific problem and people not having NFS problems might not have noticed it. It began as an NFS mounting problem and now appears to be caused by hostnames longer than 8 characters.
I am having a very strange problem NFS mounting exports from a SLES 9 machine on some (but not all) of my SUSE Linux 10.1 machines.
This is a summary of the problem, though there are many more details to be had once I figure out what forum is most appropriate for trying to get it solved.
For two out of five 10.1 machines, we cannot NFS mount filesystems exported from SLES 9 machines under a specific setup.
On the SLES 9 NFS server, the filesystem is exported as follows (in /etc/exports and applied with "exportfs -a":
/home bad101host.domain.name(rw,no_root_squash,sync)
When sitting on bad101host, I issue:
mount -t nfs sles9host.domain.name:/home /tmp_mnt
On sles9host I see "rpc.mountd: authenticated mount request from bad101host" appear in the /var/log/messages.
But on bad101host, the mount command hangs, never to return until "kill -9" is applied. (Ctrl-c and lesser kills have no effect.)
Here is a fascinating followup to this issue. As I stated above, two of my five 10.1 machines were exhitibing this behavior. I had the opprotunity today to rename one of the two bad hosts and the NFS mount failures went away. Returning it to its original name brought back the NFS mount failures. A coworker had a brainstorm and I have now tested out his suggestion. With a sample size of ten host names I have found that every hostname whose length is 8 or fewer characters works. With lengths of 9 or more they fail. Summary: Length Fail? 5 No 6 No 7 No, three names 8 No 9 Yes, two names 10 Yes, two names (Remember this is only 10.1 trying to mount exports from SLES 9.) I really don't want to have to return to the world of 8 character limits on things. Does anyone have a clue whether there is a patch either for 10.1 or SLES 9 to deal with this? I still can't tell whether this is an openSUSE 10.1 or a SLES 9 issue. Addendum: The SLES 9 machines have nfs-utils-1.0.6-103.23. The Suse 10.1 machines have nfs-utils-1.0.7-36 and nfsidmap-0.12-16, though I don't know if the latter is involved. -- Anthony Vealé National Snow and Ice Data Center E-Mail: veale@nsidc.org Phone: (303)735-5069
participants (2)
-
Anthony Veale
-
Rikard Johnels