On Mon, 3 Jan 2000, Bruce Pea wrote:
> Below I have included the diagnostics from the last message I tried to send
> myself. Could someone please have a look at it and see if you can tell me
> what I'm doing wrong?
Here's your problem, which should also show up on the log files:
> LOG: 0 MAIN
> == pea@??? <pea@???> T=local_delivery defer (13):
> Permission denied: creating lock file hitching post
From the FAQ:
Q0201: Why do I get the error "Permission denied: creating lock file hitching
post" when Exim tries to do a local delivery?
A0201: Your configuration specifies that local mailboxes are all held in
single directory, via configuration lines like these (taken from the
default configuration):
local_delivery:
driver = appendfile
file = /var/mail/${local_part}
and the permissions on the directory probably look like this:
drwxrwxr-x 3 root mail 512 Jul 9 13:48 /var/mail/
Using the default configuration, Exim runs as the local user when doing
a local delivery, and it uses a lock file to prevent any other process
from updating the mailbox while it is writing to it. With those
permissions the delivery process, running as the user, is unable to
create a lock file in the /var/mail directory. There are two solutions
to this problem:
(A) Set the "write" and "sticky bit" permissions on the directory, so
that it looks like this:
drwxrwxrwt 3 root mail 512 Jul 9 13:48 /var/mail/
The "w" allows any user to create new files in the directory, but
the "t" bit means that only the creator of a file is able to remove
it. This is the same setting as is normally used with the /tmp
directory.
(B) Arrange to run the local_delivery transport under a specific group
by changing the configuration to read
local_delivery:
driver = appendfile
file = /var/mail/${local_part}
group = mail
The delivery process still runs under the user's uid, but with the
group set to "mail". The group permission on the directory allows
the process to create and remove the lock file.
The choice between (A) and (B) is up to the administrator. If the
second solution is used, users can empty their mailboxes by updating
them, but cannot delete them.
If your problem involves mail to root, see also Q0507.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
