Problems with elm

[TheJuiceman]

When I run elm as root, I am cannot access mail due to the following error:

Error encountered while attempting to reopen mailbox /var/mail/root for lock;
** Permission denied. **

Any ideas? This is on a 11i box. Thanks.

[sachit patil]

Remove the lockfile from /tmp/mbox.root.


Regards
Sachit Patil

[TheJuiceman]

There is no /tmp/mbox.root file

[Dennis Handly]

Is /var/mail/ over NFS?

[Steven E. Protter]

Shalom,

If the folder Dennis refers to is on NFS and the system does not have root NFS permissions it would explain the error.

Many shops including my own do not provide root user full read-write permissions on NFS. That is left to a few trusted servers if any.

SEP

[TheJuiceman]

/var/mail is NOT over NFS.

[OldSchool]

/var/mail/loginname
Incoming mailbox for user; it must have mode 660 and group ID mail

/var/mail/loginname.lock
Lock for mail directory

check both of the above

[TheJuiceman]

The security on the mailbox is correct (660 in group "mail" and owned by the user). I am still having the problem.

No /var/mail/userID.lock file exists

I'm at a loss. Any ideas?

[TTr]

Check a few more things

How big is /var/mail/root

Is /var/mail a mount point or a folder under /var? What are the permissions of /var/mail

Is /var/mail full?

Run "fuser /var/mail/root". There may be a hung sendmail process keeping the file locked.

Try opening the mail by using the command
"elm -f /var/mail/root"

[TheJuiceman]

What permissions and ownership should be on /var/mail itself?

[TTr]

/var/mail should be

mode: 775
group: mail
(user: bin)

[TheJuiceman]

Currently /var/mail/root is empty. As long as it is empty, elm will work. Once there is a message in /var/mail, elm comes up with the error message.

/var/mail is a folder under /var

/var/mail has perms of 775 and bin:mail as the owner:group

/var/mail is not full

fuser shows nothing holding the file (the file has been removed and the server has been rebooted)

I'm still at a loss

[Dennis Handly]

>Currently /var/mail/root is empty. As long as it is empty, elm will work. Once there is a message in /var/mail, elm comes up with the error message.

You could just give up on new-fangled mailers like elm and go back to the tried and true mailx(1). :-)

At least see if mailx has the same lock issue:
$ mailx
...
? x

(Use "x" to exit without changing anything.)

[TTr]

Running out of ideas here...

Check if there is something wrong with the root account in /etc/passwd

Does it open other mailboxes (other than root)

run "ls /var/mail | od -c " to see if there are any special hidden characters in /var/mail, also /var/mail itself.

[TTr]

One last thing

What are the permissions of elm itself?

they should be
mode: 2555
user: bin
group: mail

[TheJuiceman]

I have discovered that there is NO root mail writing to /var/mail. Mail is sending however. There are messages populating /var/tmp/dead.letter, but nothing in /var/mail/root

I'm getting occassional messages in my /var/adm/syslog/mail.log as follows:

Feb 15 18:32:29 Server sendmail[29985]: m1F5KLq00589: timeout waiting for inpu
t from local during Draining Input

Nothing looks unusual about root in /etc/passwd. It matches what we have on our other systems that are working fine.

Running the "ls /var/mail | od -c" command did not reveal any hidden characters.

/usr/bin/elm has the proper perms and ownership.

I appreciate all of the help. I'm really stumped on this.

[TTr]

Your problem is not with elm, it is with sendmail. I think sendmail is keeping the /var/mail/root locked to receive mail but it does not receive anything until it times out. And all this time the /var/mail/root is kept locked that's why elm can not open it.

In fact the problem may not be with sendmail either. If you are running some kind of mail preprocessing such as procmail or spam filtering the problem may be there as it is kept and never gates to sendmail. Eventually sendmail times out waiting.

Is any mail delivered to sendmail in the mail.log or is it all trappped and sendmail times out?

Can you email locally within the server from one account to another? Use mailx to send a test message. (mailx can run in sending mode only, to just send a message, as opposed to elm which starts in reading and sending mode that's why it tries to open the mailbox).

Create two test accounts if you have to, say test1, test2.

[TheJuiceman]

I agree with your assessment in that this looks like a sendmail issue. However, testing between servers is not permitted as to how the systems are set up. There is no spam filtering occurring since outside mail is not accepted.

The mail.log looks clean as the mail does get sent out.

I'm not sure where to go from here

[TTr]

Some more things to look at

What are the permissions of sendmail itself?
/usr/sbin/sendmail
mode:7555 (that is -r-sr-sr-t)
user: root
group: mail

Do some more comparison between servers.

Look in /etc/mail and into sendmail.cf, sendmail.cw and see if you notice anything unusual.

mail the following locally
echo TEST | sendmail -v root
and check the mail.log

[TheJuiceman]

I did find something odd with the sendmail.cf file. The DH setting for local traffic is set to go to another server. Here is the entry below...

# who gets all local email traffic ($R has precedence for unqualified names)

DHserver2.$m

If I take this entry out for DH and restart sendmail, when I attempt to send mail to root (or anybody) on this box, sendmail hangs. When I put the entry back, it begins working again. All mail that would normally to THIS server is going to SERVER2.

I'm not sure who made the change. I'm sure it was in an attempt to get this working. But I would like to resolve why I'm having the original problem. Any other thoughts?

PS - The perms/ownership for sendmail are correct.

[TTr · Accepted solution]

The comment says that along with the DH cahnge the R rule may have been modified. Do a diff of this server's sendmail.cfwith that of another server.

Also do a diff of /etc/mail/sendmail.cf with /usr/newconfig/etc/mail/sendmail.cf to see what changes have been made.

Temporarily save your /etc/mail/sendmail.cf and copy over the /usr/newconfig/etc/mail/sendmail.cf file. Remember to shutdown/restart sendmail as you change the cf file. Sendmail should be functioning properly with the generic file from /usr/newconfig/etc/mail/sendmail.cf

Then you take it from there...

[TheJuiceman]

The problem is a sendmail issue. Sendmail has become corrupted from a bad upgrade from a third party software install. Thank you for the help.