Bug 4205 - nmh (and elm) can't handle /var/spool/mail over NFS
nmh (and elm) can't handle /var/spool/mail over NFS
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: nmh (Show other bugs)
6.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-26 17:16 EDT by martin
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-26 18:23:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description martin 1999-07-26 17:16:48 EDT
In our local network, we are sharing mailboxes via NFS-
mount of /var/spool/mail from a central mail server.

In Redhat 6.0, I was unable to read incoming mail with
nmh/exmh and elm. Obviously, file locking (elm said 'could
not lock /var/spool/mail/USER', something similar from
MH's inc) didn't work with these programs. Pine and
mail/mailx, on the other hand, work without problems. I
guess that elm and mh (I don't know about mutt, I have never
used it) use flock() system calls which are not compatible
with NFS, whereas pine/mail use ioctl().
Comment 1 Bill Nottingham 1999-07-26 17:38:59 EDT
What is the mail server running?
Comment 2 martin 1999-07-26 18:04:59 EDT
It's running AIX 4.1
$ uname -a
AIX mail 1 4 000015604600
$
However, I do not believe it's a server or general NFS-related
problem, as we are using NFS heavily for different filesystems
without problems.
Comment 3 Jeff Johnson 1999-07-26 18:23:59 EDT
The flock() locking is actually what NFS *does* understand. However,
dot-locking has been taken out of elm and mh because of the
security holes that are opened up by trying to permit both
mail delivery agents and user agents the ability to write into
/var/spool/mail to create dot-lock files. Probably the
best short term solution for you is to recompile the src.rpm
to permit dot-locking. The alternative is to run rpc.lockd
on both the client and server so that fcntl locking succeeds.

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