NFS automount problems

We have a few older Tru64/Digital Unix 4.0F clients (needed for support
reasons - 5.1B clients work fine) on our network that are having some
issues connecting to newer Linux NFS fileservers.  Up until this point,
we've just been pointing them to older servers for their needs, but
we're coming under pressure to remove the legacy fileservers and the
problem has reared its ugly head again.  Hoping someone here has some
insight.  Thanks all!

Please direct replies to [email protected]; I will summarize and
post solutions to the list.

Problem:=20
v4.0F and below can't correctly automount NFS shares on newer Linux
servers.  Manual mounts work fine.

Steps to reproduce:
Set up a new Linux NFS server, share a directory via /etc/exports.  Try
mounting said share on a Tru64 4.0F or older machine using automount.

Details:
This problem seems to coincide with Linux kernels 2.6 and above; this
may be just a correlation with newer versions of nfs-utils.


------------------------------------------------------------------------
----------------

Client (Tru64) info:
Digital UNIX V4.0F  (Rev. 1229); Tue Jan 29 10:15:07 EST 2002
Patch Kits: DUV40FAS0006-20010620 OSF440 and DUV40FB22AS0008-20030730
OSF440 (different clients, same result)

> grep -i auto /etc/rc.config
AUTOMOUNT=3D"1"
export AUTOMOUNT
AUTOMOUNT_ARGS=3D"-M /.automount /net -hosts"
export AUTOMOUNT_ARGS

> showmount -e bengsh01
Exports list on bengsh01:
/users                              *
/data                               *

> cd /net/bengsh01/data
/net/bengsh01/data: No such file or directory.

> mount bengsh01:/data /mnt; mount | grep bengsh01
bengsh01:/data on /mnt type nfs (v3, rw, udp, hard, intr)

>cd /mnt; ls -al
total 50
drwxr-xr-x   3 root     system      4096 Sep 28 09:30 .
drwxr-xr-x  37 root     system      2048 Jul 20 10:38 ..
-rw-------   1 root     system      6144 Sep 28 09:30 aquota.group
-rw-------   1 root     system      6144 Sep 28 09:30 aquota.user
drwx------   2 root     system     16384 Sep 28 07:53 lost+found
-rw-r--r--   1 root     system         0 Sep 28 09:48 test

> cd /net/fry/riss; ls -al
total 97
dr-xr-xr-x  21 root     system      4096 Jul 27 15:23 .
dr-xr-xr-x   3 root     system       512 May  2 11:20 ..
drwx------   4 root     system      4096 Jul 22 13:47 .Trash-0
drwx--S---   4 1000     csm_cm      4096 May 11 17:42 .Trash-1000
drwx--S---   2 root     csm_cm      4096 Jun 22 15:40 .Trash-root
drwxrwsr-x   3 proulst  swcm        4096 Mar 31  2008 act
drwxr-xr-x   2 root     system      4096 Jul 27 15:23 archive_home
drwxrwxr-x  13 proulst  swcm        4096 Mar  3  2010 cm
-rwxr--r--   1 root     system      1685 May 14 15:27 daily.check
drwxrwxr-x  14 root     riss        4096 May 19 10:46 devel
dr-xr-xr-x   3 proulst  swcm        4096 Dec  4  2008 eoss

> mount | grep fry
fry:/riss on /.automount/net/fry/riss type nfs (v3, rw, udp, hard, intr)


------------------------------------------------------------------------
----------------

Non-working server info:
bengsh01:~> uname -a; cat /etc/redhat-release; rpm -qa | grep nfs=20
Linux bengsh01.amherst.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
nfs-utils-lib-1.0.8-7.6.el5
nfs-utils-1.0.9-44.el5

bengsh01:~> cat /etc/exports
/data   *(rw,sync,no_root_squash)
/users   *(rw,sync,no_root_squash)

No log messages pertaining to server access from the automount requests
that fail - it's like it never makes it that far.  I do see log messages
for the manual mount.

------------------------------------------------------------------------
----------------


Working server info:
fry:/> uname -a; cat /etc/redhat-release; rpm -qa | grep nfs=20
Linux fry 2.4.27 #4 Wed Oct 6 17:29:46 EDT 2004 i686 i686 i386 GNU/Linux

Red Hat Linux release 9 (Shrike)
nfs-utils-1.0.1-2.9

fry:/> cat /etc/exports
/riss   (rw,sync,no_root_squash)


---
Eric