NFS export "Read-only" only on one server

[Clay Jones_2]

We have an export that is read-write with about 10 servers mounting it. Here's the line in /etc/exports:

/dir/sysadmin -anon=0,rw=host1:host2:host3:host4:.....

One server is mounting this export "read only", and we can't figure out why:

$ rm outfile
rm: outfile not removed. Read-only file system

The mount command shows what other server's mount commands show:

/dir/sysadmin on host0:/dir/sysadmin soft,rsize=32768,wsize=32768,NFSv3,dev=44000001 on Thu May 13 14:20:06 2004

Running 11.23 on client and 11.11 on server, other 11.23 box shows no such issues. Any ideas?

[Sanjay Kumar Suri]

What is the entry in /etc/fstab for mounting file system on this system? Is it mounted with ro?

sks

[Clay Jones_2]

I should have mentioned, but the answer is no:

$ mount -p
share:/dir/sysadmin /dir/sysadmin nfs soft,rsize=32768,wsize=32768,NFSv3,dev=44000001

[Robert-Jan Goossens]

Can you ping the hosts from each other ?

Are all the names in DNS or the hosts files.

Regards,
Robert-Jan

[Clay Jones_2]

The hosts can be pinged, and the filesystem is mounted--just read only. All hosts resolve correctly via DNS on both server and client.

[SS_6]

Try to re-export the file system.
#exporfs -i -o rw=host1 /dir/sysadmin
It will ignor the option from /etc/exports

[A. Clay Stephenson]

The next thing that I would try is mounting this filesystem with an explicit -o rw option. I know that rw is supposed to be the default but ...


I would also see if I could modify "outfile" as opposed to rm'ing it.

I would also check to see if all your 11.23 boxes have the same patch levels. Do a swlist of a good box and compare it to your bad box.

[A. Clay Stephenson]

One more thing to check is the permission of the client's mountpoint. It may be very restrictive. You will need to umount the filesystem to check this.

[Brian Hackley]

Hi,
Usually this issue is caused by the mapping of the IP address of the incoming NFS reqest to a hostname that does not match up in /etc/exports.

To find out that name:
telnet from NFS client to NFS Server
issue who -mR
The name that the IP maps to will be in parans. Example
$ who -mR
netest pts/0 May 18 07:59 (tbox.atl.hp.com)
You should use a fully-qualified hostname if using DNS. You might want to use both the fully-qualified hostname and the short hostname to be sure.

Or you could actually have a typo in the file. I have seen that quite a few times.
To check out that theory, move the hostname with a problem closer to the front of the list. Also do a "set list" command in vi to look for special characters.

Hope all that helps,
-> Brian Hackley

[Clay Jones_2]

Thanks everyone for the suggestions, but this problem still lingers....

It's in HP's hands now. We tried:

1) Re-exporting filesystem
2) Mounting explicity rw
3) changing hostnames to IP Addresses
4) Google
5) UID's and GID's match
6) Rebooting the box
7) Checked /etc/services to make sure tcp/udp defined for nfs

Probably a bunch of other stuff as well....I'll reply when we figure it out.

[Brian Hackley · Accepted solution]

Clay,

One other note, I recently heard of an 11.0 user who increased # NFS daemons in /etc/rc.config.d beyond the default
NUM_NFSD=16

Also you may need to make further kernel tunables e.g. max_thread_proc to 1024 or larger.

Dave Olkers book, "optimizing NFS performance" Appendix A for further details. Older doc on the web by Dave before he wrote is book is avail at http://docs.cup.hp.com/hpux/onlinedocs/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdf

Looking forward to hearing of your progress,
-> Brian Hackley

[Clay Jones_2]

Brian, your 'who -mR' did the trick. It turns out the client had a new alias (meant to move during failover), and the box was connecting via that interface, different IP, different hostname.

We added the host for that IP to /etc/exports and success.

I gave your last post 10 points, because I had already rated your successful answer at 1 point (yikes, sorry).

I had recommended early on that we sniff the connection setup, but we never got around to it. We would have instantly seen the source IP was different.

Thanks again to all who helped!