Bug 18097 - 7.0 cannot get locks on NFS-mounted filesystem served by a 6.2 system
Summary: 7.0 cannot get locks on NFS-mounted filesystem served by a 6.2 system
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-02 14:53 UTC by Ed Bailey
Modified: 2008-05-01 15:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-22 19:55:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ed Bailey 2000-10-02 14:53:17 UTC
A 7.0 system cannot lock files on an NFS-mounted system that is served by a
6.2 system.  This was originally discovered when emacs' movemail failed to
get a lock on an nfs-mounted mail spool, but Nalin was able to reproduce
the problem with a test program.  Nalin, feel free to chime in here... :-)

Comment 1 Arthur van Leeuwen 2000-10-05 13:49:54 UTC
The NFS locking bug between Red Hat Linux 7.0 and older versions of 
Red Hat Linux (6.2 in case of bug #18097, probably also 5.1, as it
is the most likely cause for bug #18075) may very well be the cause
of Pine hanging when trying to close a folder on a NFS-mounted partition
from a Red Hat Linux 5.1 server.

Comment 2 iimura 2000-10-11 20:00:36 UTC
My mail server is on a SUN/OS 4.1.4 system.  I see the same symptoms as
described in bug #18097 when I connect a RedHat 7.0 system to my network and
access mail with pine.

Comment 3 Ed Bailey 2000-10-18 18:12:16 UTC
As an FYI, I added a line to /etc/hosts containing my 7.0 system's IP address
and hostname, and then did a "service nfslock restart"; this allowed my system
to work as it did prior to the 7.0 upgrade...

Comment 4 Deepak Saraf 2000-11-15 16:31:57 UTC
we have simailar problem , we are trying to use RedHAt linux 7.0 as a nfs 
server.We are trying to mount the exported directory onto a SCO openserver 5.0.5
system.Read, write access is not a problem but file locking doesnot work even 
if we use no_auth_nlm or insecure_locks option

Comment 5 Eric Bourque 2000-11-24 05:40:31 UTC
I was able to use ed@redhat's suggestion of putting an explicit IP to hostname
mapping in /etc/hosts on the client and restarting lockd. File locking was not
working before, and now it is. In my case, the server was RH6.2, the client was

Comment 6 Arthur van Leeuwen 2000-12-05 08:33:49 UTC
ed@redhat.com and ericb@computer.org's suggestion of putting the hostname in the
/etc/hosts file on the client does not work for me. Situation: pine hangs on NFS
locking when *closing* folders, running on RH7.0. The home dir with the local
mail folders is mounted from a RH5.1 system (yes, it's old, yes it needs to be

Comment 7 John Gotts 2000-12-19 20:40:38 UTC
This is a duplicate of the incorrectly closed 18938 bug and the currently open
bugs 21723 and 21957.  /etc/hosts has nothing to do with this bug.  The problem
is that lockd in nfs-utils does not reliably start (and outputs no
diagnostic error messages when it fails).  For example, if you enable nfslock in
runlevel 5, the script will happily spit out "[ OK ]" following "Starting NFS
lockd:" though only rpc.statd continues to run while lockd dies when this bug
occurs.  Occasionally, lockd does start properly on boot, but I can reproducably
cause it to not start with "/etc/rc.d/init.d/nfslock stop" followed by
"/etc/rc.d/init.d/nfslock start".  As you can see, the presence or lack thereof
of the appropriate IP addresses in /etc/hosts is irrelevant at this stage;
however, I've always had all of my clients and servers' IP addresses in synch on
both clients and servers).

Comment 8 Eric Bourque 2001-01-09 19:59:41 UTC
More strangeness with the locking problem. After running up2date on my RH7 box,
I no longer have functional locking between it and the RH6.2 nfs server. The
/etc/hosts trick above which fixed my problem originally seems to now have no
effect. I haven't figured out which upgraded rpm has caused the problem ... (I
suspect it may be glibc {2.2-9})

Comment 9 Ed Bailey 2001-01-22 19:55:40 UTC
Sorry, but I have to disagree with jgotts -- for me, the problem most definitely
*was* fixed by adding the line to /etc/hosts (I tested it both with and without
the line several times, and it reliably failed without the line in /etc/hosts).

That said, I now seem to be in a similar situation as ericb, in that I recently
got the latest glibc update via up2date, and several days later had to reboot
the machine.  After the reboot, the line in the hosts file has no affect.  And
yes, lockd is running... :-)

Comment 10 Bill Nottingham 2001-03-08 04:27:23 UTC
This should be fixed with the rawhide nfs-utils, as rpc.statd no longer
runs chrooted.

Note You need to log in before you can comment on or make changes to this bug.