SUMMARY: /var/mail files disappeared!

From: Carolyn Mayr <>
Date: Tue Mar 19 2002 - 12:36:43 EST
Unfortunately, I never found an answer but on the flip side, the problem seems
to have gone away.  For how long, I'm not sure but I've been watching carefully
and maintaining good backups of /var/mail.  I followed a number of suggestions 
but I did not find anything that would cause the files to disappear.  I thank 
the following people and their suggestions:

-- "Mike's List"  <>
Try ps -ef | grep map (looking for imap processes) and determine any from
wcbrown and try terminating it...if still doesn't work, try init 6 during
maintenance hours (but since mail isn't working right now) or immediately
and see if it'll help.

Ask the user to download his mail instead of leaving it on the server...
70MB is huge, perhaps some sort of quota is reach and cause the problem?

-- Gert-Jan Hagenaars <>
You might want to install lsof to find out which process has the mailbox
open.  You might have to do some funky stuff (like tail your log file
for the imapd message below, and use that as a trigger to send you the
output of lsof).

-- William Yodlowsky <>
Is /var/mail an NFS mount?  If so, network problems or NFS server
problems might be at work...

Do dmesg / syslog show anything about media errors on the disks?

You might want to run ps and ls through the Sun fingerprint database (on
Sunsolve) if you don't run tripwire, just to be sure nothing funny has
happened to your binaries...

-- Fabrice Guerini <>
I don't know if this will apply to your particular problem, but do you 
happen to be mounting /var/mail from a "trans" type SDS partition? I have 
seen similar strange occurrences at another site before (although the 
mailboxes didn't all disappear), but was never able to track down the root 

-- "Steve Moccio" <
Is /var/mail mounted locally or is it an nfs mount from a mail server? If so
is your nfs mount being killed?

-- Ric Anderson <ric@Opus1.COM>
The error you mention can be caused if multiple things go for the same
mailbox.  e.g., you decided to read your mail from a lab, while your
mail client on your dorm machine still had the mailbox open.  Its
a fairly frequent happening on my IMAP server.

Check the permissions on /var/mail.  It should be 0775, group
mail, user root, e.g.
 drwxrwxr-x   3 root     mail         512 Mar 12 13:01 /var/mail
or maybe mode 1777 drwxrwxrwt (like /tmp).  If its mode 0777, then
any logged in user can "rm /var/mail/*".  If you have process accounting
enabled, then 
    lastcomm rm
might shed some light on things, if you find an "rm" executed around the
time mail vanished.

Sorry I don't know the answer, do you think the news group comp.mail.imap
  might be worth a try?

-- "Bara Zani" <>
check to see if there's no automount to mount something on /var
also see if there's no clean up scripts in /etc/init.d
check cron entries for user root .

-- "Jay Chembakassery" <>
I dont think the file size is the culprit. I have mail boxes with with size
more than 150MB !!
Looks like a hack. Check the /var/mail/syslog for the IP addresess from
which the requests came for 'wcbrown'.
What`s the version of your IMAP ?
Why can`t you implement the secure IMAP ?

-- Jay Lessert <>
Yow.  It seems *very* unlikely that imapd did this, but you never know.

Are permissions on /var/mail correct?

    % ls -ld /var/mail
    drwxrwxrwt   2 root         1536 Mar 14 09:28 /var/mail

Check all crontab and at entries.

Check all currently running processes.  Even though you're sure you
haven't been cracked, be paranoid.  Check your ls and ps binaries
against Sun md5 fingerprints:

If *still* nothing, then turn on auditing:

Also AnswerBook has a good non-manpage section.

My old audit_control file back in a day when I had some minor problems
to chase down (not as bad as yours, thank goodness) was:


...which logs *successful* ("+") file writes and file deletes.

-- Chris <>
Uwash Imap has a driver called "mbox" which generally copies
a users mail to their $HOME/mbox when connecting via imap.  Has
any configuration (update, etc) changed that may have caused that?
Does this folder ($HOME/mbox) exist for the affected users.

I *believe* the default behavior for this driver is not to move
the mail unless a file exists in their home directory called mbox. 

This is a compiled in option w/ uwash imap, and the only way to
completely disable it is to recompile the imap server.  

Hope this helps,

-- "Hugo Jose C C Dias" <>
        I would check how is the locking strategies used by the mailer program
(procmail, mailx, etc..). As this software write at the same file the IMAP
or POP, its need to compiled with the same lock system (lock at bellow).

        If you are using sendmail lock at Mlocal parameters at to 
see what mailer are you using.

procmail v3.21 2001/06/29
    Copyright (c) 1990-1999, Stephen R. van den Berg    <>
    Copyright (c) 1997-2001, Philip A. Guenther

Submit questions/answers to the procmail-related mailinglist by sending to:

And of course, subscription and information requests for this list to:

Locking strategies:     dotlocking, lockf()
Default rcfile:         $HOME/.procmailrc
        It may be writable by your primary group
Your system mailbox:    /var/spool/mail/root

##################### Original message

I have a Sun E450 filserver running Solaris7.  All my users mailboxes
are in /var/mail.  Users read their mail mostly by IMAP connections
and one logs in and uses Pine.  Things have been working fine for two
years until two days ago.  Two days in a row at two different times, 
everyone's mailboxes disappeared from /var/mail.  I'm the only administrator.  
I haven't changed anything on the server and don't see signs of foul play.  
The only clue I have about the time the mailbox files disappeared was the 
following message:

Mar 12 13:41:20 csb imapd[1844]: Fatal mailbox error user=wcbrown mbx=/var/mail/wcbrown: Mailbox modified by 
another process. Cannot continue!
Mar 13 15:45:54 csb imapd[1005]: Fatal mailbox error user=wcbrown mbx=/var/mail/wcbrown: Mailbox modified by 
another process. Cannot continue!

What process could be causing this all of a sudden?  The users' "wcbrown"
mailbox is 70MB if that makes a difference.  I'm theorizing the mailbox size 
or an IMAP configuration is the culprit.  I did read some things about pine 
but I don't believe pine was being used in the first incident.  All users 
mailboxes are rw------- and owned only by the mailbox owner...


Carolyn A. Mayr (UNIX System Administrator) Voice: (410) 293-6808 (sec-6800)
Computer Science Department, DivMath&Sci    Email:     
572 Holloway Road, Chauvenet Hall, Stop 9F  FAX:   (410) 293-2686
U.S. Naval Academy                          WWW:
Annapolis, MD  21402-5002                   USNA:  (410) 293-1000
sunmanagers mailing list
Received on Tue Mar 19 11:37:37 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:37 EST