I'm about two steps from abandoning my SuSE linux install to my whizzy linuxfromscratch setup but I've hit a dead end. Exim just won't deliver mail properly...
Everytime it gets mail it moans about not being able to get a lock on /var/mail/<whatever> (where I *plan* to store my messages), because of the 'permissions' and defers them. When installing exim I set up an 'exim' user and group and chown/chgrp 'ed /var/mail to that user (and the subdirectories) and in a fit of desparation did a chmod 666 without any success (that is the chmod worked but exim still didn't ::grin::)
So....arrrggghhh! I've tried disabling locking altogether with no luck and I'm desperate. Can anyone help me pretty please?
Cheers,
BenE
(also pine moans about /var/mail/<whatever> not being a 'selectable folder'. Maybe it's related??)
::sob::
On Tue, 14 Jan 2003, BenEBoy wrote:
I'm about two steps from abandoning my SuSE linux install to my whizzy linuxfromscratch setup but I've hit a dead end. Exim just won't deliver mail properly...
Everytime it gets mail it moans about not being able to get a lock on /var/mail/<whatever> (where I *plan* to store my messages), because of the 'permissions' and defers them. When installing exim I set up an 'exim' user and group and chown/chgrp 'ed /var/mail to that user (and the subdirectories) and in a fit of desparation did a chmod 666 without any success (that is the chmod worked but exim still didn't ::grin::)
So....arrrggghhh! I've tried disabling locking altogether with no luck and I'm desperate. Can anyone help me pretty please?
Cheers,
BenE
I've had this problem before... very easy to fix
See the text below from the Exim website (www.exim.org)
HTH
Chris
Q0036: Why do I get the error Permission denied: creating lock file hitching post when Exim tries to do a local delivery?
A0036: 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:
(1) 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.
(2) 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 (1) and (2) 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.
On Wednesday 15 January 2003 21:57, Chris Glover wrote:
I've had this problem before... very easy to fix
See the text below from the Exim website (www.exim.org)
HTH
Chris
Q0036: Why do I get the error Permission denied: creating lock file hitching post when Exim tries to do a local delivery?
A0036: 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:
<snip>
(1) 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.
Cheers for the help...
I tried this before. I've just checked again and /var/mail is set for write access to all with the sticky bit set.
(2) 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.
Tried this too. I set the group = exim and chown 'ed /var/mail to group exim (and the subdirectories too). The group 'mail' isn't somesort of special group that behaves differently is it??
Well, that is certainly the error I'm getting though. Think I'll do the sensible thing and go through it step by step tmrw (unless anyone has any other suggestions ::grin::)
cheers,
BenE
BenEBoy mail@psychoferret.freeserve.co.uk wrote:
I tried this before. I've just checked again and /var/mail is set for write access to all with the sticky bit set.
You also said you 666'd it, which is the wrong permissions, as it would miss the x bits and deny permission to list it in a sort of way (it's late and I'm fuzzy on the exact meaning of the x bit for directories). I think it should be 0775 and owned by exim.exim, from what you've said. Is it? Paste lines if you can.
If you su to exim, can you make a file in that directory? touch an existing one? Paste lines and let us know what you find.
MJ Ray markj@cloaked.freeserve.co.uk writes:
(it's late and I'm fuzzy on the exact meaning of the x bit for directories).
The 'w' bit affects the following operations: * creation of files in the directory * removal of files in the directory * renaming of files into or out of the directory * linking of files into the directory ... you get the idea. That's simple enough.
The 'r' bit affects open() on a directory, and thus opendir(). So to list a directory you need 'r' permission on it (but see below).
It _doesn't_ affect access to files in the directory - but you may have to guess their names.
The 'x' bit affects looking up names in a directory (for instance, to open them) and also chdir to the directory; IIRC the spec calls it "search" permission. So to access files within a directory you need 'x' permission on it.
This results in inconsistent effects, because some of the things that you think are listing the directory actually involve accessing a file within it:
t@rollercoaster$ ls -ld . ls: .: Permission denied t@rollercoaster$ ls -ld `/bin/pwd` drw-rw-r-- 2 rjk rjk 4096 Jan 16 11:28 /home/rjk/junk/t t@rollercoaster$
... the ls command can't lstat "." because that involves looking up the name "." in the current directory, and that has no 'x' bit. A UNIX implementation that special-cased "." and ".." might plausibly behave differently here.
But the second ls is fine, as it's looking up the name "t" in "junk", which _does_ have an 'x' bit.
On Thursday 16 January 2003 11:41, Richard Kettlewell wrote:
MJ Ray markj@cloaked.freeserve.co.uk writes:
(it's late and I'm fuzzy on the exact meaning of the x bit for directories).
<snippety snip>
Yep, it was the permissions. Exim now works perfectly. Also, the pine problem I thought may have been related (the INBOX folder 'not being selectable') was down to the fact that pine wants it's 'folders' to have a header at the top (oh, and the fact it needs to be a file, rather than a folder...d'oh). Quickly sorted by copying one of the folders it's creates into /var/mail and renaming it. Just thought I'd mention that for future reference :-)
cheers all,
BenE
(now on to fetchmail, I suppose)
-
BenEBoy -
BenEBoy -
Chris Glover -
MJ Ray -
Richard Kettlewell