Hi all,

I'll try to post as many details as possible so people don't have to reply back thousands of times asking for more info and what the permissions are for this or that. Basically here's what happens, the mail() function in PHP doesn't work, the outgoing mail doesn't go anywhere.

The sendmail error log shows:
Here are the details you should need:
Httpd is running as apache/apache.
I have added apache as part of the smmsp group in /etc/group.

Permissions for /var/spool/clientmqueue:
For some reason, even though httpd should be running as apache/apache, but apache is also part of the smmsp group, it should have write permissions on the clientmqueue directory. If I just make the directory permissions 0777 then I get these errors in the log:
If anyone needs more info, or needs to see my submit.cf or something I can post further details. I've seen this problem posted about 100 different times on different forums but I have yet to find a solution. Most people just go "oh, I forgot to check permissions on clientmqueue, now it works!" But my permissions match the sendmail install, and also apache is part of the smmsp group as I have it configured so permissions of 770 should allow httpd running as apache/apache to write to that directory, but it can't even chdir to it. Permissions of 777 will allow httpd to chdir, but it can't write anything. It makes no sense whatsoever. I figure it probably has something to do with my submit.cf, so if someone needs to see a part of that I'll post it, but I haven't messed with it from the initial install I don't think.

Oh, also here's a snippet from my /etc/passwd and /etc/group files unless you don't believe my configuration posted above or something:

Thanks for your replies,
Ross

Ok I solved my problem, I'll try to provide as much details as I can about what was happening. First let me preface this by saying that in the process I upgraded sendmail, httpd, and php (in that order) to their newest versions and then replaced the conf files with the original backed-up ones to make sure it wasn't a version mismatch. With stuff like this though (and the errors I was getting) it almost never turns out to be an error mismatch.

Basically what it came down to seemingly was a combination of three things:
SELinux Security Policy was messed up on /usr/sbin/sendmail...solution: #restorecon /usr/sbin/sendmail
SELinux Security Policy was messed up on /var/spool/clientmqueue and /var/spool/mqueue...solution: #restorecon /var/spool/clientmqueue /var/spool/mqueue

Permissions for clientmqueue should still be exactly as in my previous post (at least for RH Fedora Core 3, but probably other distro's too), and permissions for mqueue should not need to be modified unless you are specifically using mqueue for your apache mail delivery system. Permissions on that folder are (and should remain):

Basically what I found out from all this is that the file permissions are not the only thing controlling file permissions. I know that sounds like it doesn't make any sense, and it doesn't at first, which is why I said it made absolutely no sense in my previous post that even with 0777 permissions on clientmqueue, apache still could not write to it. Apparently SELinux is another security policy system, other than just the basic file permissions, that controls access as well. I'm not familiar with SELinux at all, otherwise I probably would have figured this out right away. Apparently just doing a #restorecon /path/to/file/or/folder will reset the security policy to whatever it needs to be. I don't know how to manually go in and set the security policy in the same way you can do a chmod with file permissions, and I'm also not sure how the security policy got changed. I don't think I ever tried to send mail via php on this system before though, so maybe the policy with my RH Fedora Core 3 install was just bad to begin with. If not then it's curious that the policy just changed on me. I saw other users mention that you can download an RPM with the newest security policy as well, but instead of doing that I just opted to repair the individual files in question with restorecon, and it worked for me.

If anyone has this same problem and hasn't found help in any of the other numerous discussions on this particular php/apache/sendmail permissions problem, I would be willing to help as much as I can. Since I've spent about two days on and off on this problem I feel pretty qualified to help other people with the same issues that I had. If you need help just reply to this post and I'll get an email because I'm subscribed to this post.

Thanks,
Ross

you rule.. i've been trying to figure this out on and off for about a week.

i still have other problems- but in all that I read this was the first thing that solved those permission denied queue errors right away.

I too wondered how it was possible to get permission denied on a directory that was set to +777....

thanks again.

Run the following command
What is the result? It looks like selinux blocks access to sendmail for apache.

1 members found this post helpful.

When I ran that command it returned an error that it couldn't find an active rule for httpd_can_sendmail. That's probably though because after the issue in my original post I just turned off SELinux completely. I don't really run a multi-user system so I don't have any need for fancy security policies that just serve to confuse me because it's not at all apparent what's happening with permissions behind the scenes. In Windows anyway I can always right-click and choose "Security" to see what the specific security policy is governing the file/folder in question. I'm willing to bet SELinux has a similar interface in Fedora but I'm command-line only so that doesn't help me much. I just like to keep things simple so I don't confuse myself.

Yup it was the SEbool.

Thanks for the help!

Thank you guys. your discussion solved my problem. Thanks again.