I've run into a problem with RedHat Server 5 and NFS clients.

I have an HP-UX NFS server (ServiceGuarded, FWIW) that serves a few hundred clients of varying flavors of AIX, solaris, HP-UX and Linux. It has been working for years and continues to work for other flavors of Linux.

With some of the new RH Server 5 clients I've installed, I can't mount the home directories. I also have automounter running, and it works fine. To mix things up, I do have a couple of RH Server 5 boxes on which it *does* work, but I can't find any difference between the ones that work and the ones that don't.

The failure happens early in the mount process - if I try to mount to a non-existent directory, it doesn't even notice.

The relevant exportfs line from the server:
/export/home -access=all_ptc_sys

Yes, I've validated that I'm in the netgroup

Client /etc/fstab entry (and this entry is on every other linux box in the environment):
ovrhomes.rose.hp.com:/export/home /home/ptc-nfs nfs _netdev,soft 0 0

I've even tried to force it to NFS v3
# mount -o nfsvers=3 ovrhomes.rose.hp.com:/export/home /ptc-nfs/home
mount: ovrhomes.rose.hp.com:/export/home failed, reason given by server: Permission denied

The server seems to have lots of connections; I'm not seeing any errors, and other clients are able to mount just fine.

# uname -a
Linux ovresx2-vm2.rose.hp.com 2.6.23.12-io #1 SMP Tue Jan 8 11:08:57 PST 2008 i686

# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 811 status
100024 1 tcp 814 status
100007 2 udp 681 ypbind
100007 1 udp 681 ypbind
100007 2 tcp 684 ypbind
100007 1 tcp 684 ypbind
100011 1 udp 1022 rquotad
100011 2 udp 1022 rquotad
100011 1 tcp 614 rquotad
100011 2 tcp 614 rquotad
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 tcp 57031 nlockmgr
100021 3 tcp 57031 nlockmgr
100021 4 tcp 57031 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100005 1 udp 625 mountd
100005 1 tcp 639 mountd
100005 2 udp 625 mountd
100005 2 tcp 639 mountd
100005 3 udp 625 mountd
100005 3 tcp 639 mountd
300019 1 tcp 718
300019 1 udp 719

NFS by far always provides some of the best logs. Check those. Permission problems are usually caused by the exports file. Sometimes even if there is Reverse DNS in place, I've had to put in the actual IP to allow a client to mount an NFS share. But check the logs, it should give some insight to why these clients can't mount the NFS share.

ok done one thing
#getsebool -a | grep nfs
there u find the options
use_home_dirs=off
make it on
#setsebool -P use_home_dirs=on

i think ur problem will be solve
best of luck

Interesting approach, but it didn't work. It's not just the home directory that I can't mount - I can't mount anything from this server.

# getsebool -a | grep nfs
allow_ftpd_use_nfs --> off
allow_nfsd_anon_write --> off
nfs_export_all_ro --> on
nfs_export_all_rw --> on
nfsd_disable_trans --> off
samba_share_nfs --> off
use_nfs_home_dirs --> off
ovresx2-vm2:/var/log # setsebool -P use_home_dirs=on
libsemanage.dbase_llist_set: record not found in the database
libsemanage.dbase_llist_set: could not set record value
Could not change boolean use_home_dirs
Could not change policy booleans

Just a wag but on the client do a #ps -ef |grep nfs and make sure the nfs.client is running.

The server is a ServiceGuard cluster (system ovrhomes == ovrnfs1 + ovrnfs2), so the 'real' logs may not be where I think they are - still looking.

However, your remark about reverses led me to do some more snooping: there is definitely a disconnect between NIS and DNS. Interestingly, both of the names returned are in that netgroup, but my guess is NFS might suspect it's trying to be spoofed.

ovrnfs1:/etc/rc.config.d # cd /tmp
ovrnfs1:/tmp # nslookup ovresx2-vm2
...
Trying NIS
Trying DNS
Name: ovresx2-vm2.rose.hp.com
Address: 15.8.158.33

ovrnfs1:/tmp # nslookup 15.8.158.33
...
Trying NIS
Name: hpptc27.rose.hp.com
Address: 15.8.158.33
Aliases: hpptc27

So, I fixed the NIS map, but I still got the 'permission denied' error

For pure S&G, instead of using the 'front end' name (ovrhomes) for the mount, I tried using the cluster members directly (yeah, scold me later)

ovresx2-vm2:/var/log # mount ovrnfs1.rose.hp.com:/export/misc /tmp/misc
mount: ovrnfs1.rose.hp.com:/export/misc failed, reason given by server: Permission denied
ovresx2-vm2:/var/log # mount ovrnfs2.rose.hp.com:/export/misc /tmp/misc

Wow! It mounts like buttah!

So, I still have some sort of outstanding issue, I just don't know what it is yet. It appears that it's only the RH Server 5 clients doing this. I have 21 AIX, 132 HP-UX, 60 RedHat, 72 Solaris, 5 Solx86, 6 SuSE, 4 Tru64 and a couple of FreeBSD clients - that all work correctly.

I have other file NFS systems mounted - it's just that one server that was giving me fits.

# mount
/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext2 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
hpswnfs1:/export/IT_Tools on /tmp/junk type nfs (rw,addr=15.8.158.75)


ovresx2-vm2:/tmp # ps -ef |grep nfs
root 2547 2 0 Jan09 ? 00:00:00 [nfsd4]
root 2549 2 0 Jan09 ? 00:00:00 [nfsd]
root 2550 2 0 Jan09 ? 00:00:00 [nfsd]
root 2551 2 0 Jan09 ? 00:00:00 [nfsd]
root 2552 2 0 Jan09 ? 00:00:00 [nfsd]
root 2553 2 0 Jan09 ? 00:00:00 [nfsd]
root 2554 2 0 Jan09 ? 00:00:00 [nfsd]
root 2555 2 0 Jan09 ? 00:00:00 [nfsd]
root 2556 2 0 Jan09 ? 00:00:00 [nfsd]
root 22368 18992 0 07:24 pts/3 00:00:00 grep nfs

I just had a similar-ish issue to you - turns out I needed to add an entry for the name of the client server in the /etc/hosts file on the nfs server. The messages log is fairly useful for debugging purposes.

Fixing the NIS maps cleared up my problem..