Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 11431 - mutt cannot lock NFS mounted mailfiles
mutt cannot lock NFS mounted mailfiles
Product: Red Hat Linux
Classification: Retired
Component: mutt (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2000-05-15 23:47 EDT by benjamin-redhat
Modified: 2014-03-16 22:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-16 12:09:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description benjamin-redhat 2000-05-15 23:47:24 EDT
First, I doubt that this is a problem with mutt, but rather with the NFS
locking, but I was not able to verify this yet, so am starting with mutt,
which is the only program with which I had this problem until now.

The /home/common partition is mounted via NFS. With a plain RedHat 6.1
install, if I access any mailbox which resides within this partition, mutt
is unable to lock it:

If no NFS daemon is started on the local host (my default), I get the
following strace:

open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3
SYS_175(0, 0x80a1320, 0, 0x8, 0)        = 0
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1
ENOLCK (No locks available)

and mutt writes out an appriopriate error message (sometimes it gets
overwritten at once by some other status messages, so it is not always
visible, but you can hear the bell, too).

If I start /etc/rc.d/init.d/nfs (I tried this, due to some seemingly
unrelated tips to other NFS problems) the behaviour changes: I can see the
status line "Waiting for fcntl lock... 1" which counts in second-steps up
to 5 and finally I get the message "Timeout exceeded while attempting fcntl
lock", which corresponds with the following strace:

open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3
SYS_175(0, 0x80a8848, 0, 0x8, 0)        = 0
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1
EACCES (Permission denied)
fstat(3, {st_mode=0, st_size=0, ...})   = 0
brk(0x80c5000)                          = 0x80c5000
write(1, "\r\33[30m\33[47mWaiting for fcnt"..., 53^MESC[30mESC[47mWaiting
for fcntl lock... 1ESC[KESC[39;49mESC[m^O) = 53

Some notes:
- the problem seems to be NFS related: if I do
  sudo cp -a /home/common/benjamin /home/common, the problem is gone
- the rights on my mailboxes seem to be ok:
  I have no problem to read the same folder with the same version of mutt
with a RedHat 5.2 (somewhat updated, but no core packackes, I think)
- this also seems to show, that the server does it job correctly.

- RedHat 6.1 with minor updates (but also tried it with a plain install), I
think I also already tested it with 6.2 (with same symptom), but I am not
sure anymore, so if this important, say so and I will try again. Also, if
you need more infos about versions / packages - maybe because they are not
as obvious as I think - please just say what I should provide.
- the NFS server has knfsd-1.2.2-4 installed and is based on RedHat 6.1, I
- mutt is 1.0.1i-6 installed from RedHat 6.2 (but also tested with earlier
version... upgraded to check whether the problem was already fixed)
Comment 1 Bill Nottingham 2000-05-16 12:09:59 EDT
You need to have the nfslock service started
on both the client and the server for NFS locking
to work correctly.
Comment 2 benjamin-redhat 2000-06-04 07:47:15 EDT
Sorry to come back to you so late, but I partially had to wait for feedback from
my administrator. By the way, I think the resolution "NOTABUG" is not correct,
because nfslock was not only not started, but also not installed at all,
although I have several NFS mounted devices.

The problem that I have now is that the server does not run a knfsd, but a user
space one (because it had stability problems which the user space one solved,
AFAIK), and nfslock seem to only be thought for knfsd.

Well, the server administrator refuses to switch back to knfsd. But I guess, it
must be possible somehow to "connect" also with a 6.1 system, when a 5.2 system
has no problem at all. If I am not wrong, the "solution" of the 5.2. system was
that locking did not really lock the stuff. Am I correct? If so, I would be
happy with a similar solution for 6.1, because there will be no concurrent
accesses. Do you have any suggestions for me? Thank you for your attention.

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