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 -- ---------------------------------------------------------------------------------------------- www.norwich-anarchists.org.uk Officially the best norwich based anarchist web site that has overly large jpegs

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. -- http://www.greenend.org.uk/rjk/