sendmail problem: can not chdir(/var/spool/clientmqueue/)

[dcrandal]

Good morning,

I have installed sendmail as a null client, and mailx.
When I perform a simple test as the root user:
mail -s "test" dcrandal
I get an error:
can not chdir(/var/spool/clientmqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.

I have checked the permissions on /var/spool/clientmqueue/ and they are sufficient, and as I said, I'm performing the action as the root user.

I'm having a hard time discovering the problem.
Any insight would be highly apreciated.
_________________
Daniel

unix/net admin
TDHCA

[dcrandal]

I've learned some more...

Sendmail wants a gid of 407 (smmtp), but is emerged with ownership of root:root. So I changed that. (of course you have to stop and restart the sendmail daemon after making this adjustment)
Also, the group membership of /var/spool/mqueue and /var/spool/clientmqueue are not correct on instalation. They want to be in the smmtp group.

It seems to be working pretty well now.

Thanks for all of your valuable advice and kind words.
_________________
Daniel

unix/net admin
TDHCA

[philthedrill]

As a follow up, I had a similar problem. Pine wouldn't send mail through the localhost ("Error sending: SMTP greeting failure: 421 SMTP connection went away!").

Doing something like:

echo "blah"|mail -s "test" philp

would give me an error message like this:

WARNING: RunAsGid for MSP ignored, check group ids (egid=209, want=667)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0, required=209): Permission denied

It ends up that the smmsp user was uid 1000, gid 667, and added to the smmsp group in /etc/group (group 209).

I fixed it by changing the gid to 209 (and removing the smmsp user from /etc/group since it's redundant).

/var/spool/clientmqueue is at permission 770 (smmsp:smmsp).
/var/spool/mqueue is at permission 700 (owned by root).

the sendmail binary is at permission 2555 (root:smmsp).

[linuxkrn]

That fixed my problems too. Not sure why they had the user 'smmsp' in the group when the passwd file already specs out group 209 'smmsp'.

But I fixed the perms on the binary and directories. Thanks for the follow up post.