Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have recently upgraded my Apache2 server, and am now unable to run a CGI app. My logs are showing

(13) Permission denied unable to connect to cgi deamon after multiple tries

I understand that the error message means Apache is being denied some permission to some file, and I'm stumped as to how to track down and solve the problem.

Is the file mentioned in the error message truly the blocked file? Or might the problem be caused by some other needed file? The .cgi file is right where it has always been, under /usr/share. The file ownership (root) and permissions (world readable/executable) are the same as they have always been for the file and its ancestors. The SELinux file labels are unchanged.

The SELinux audit log shows no denial associated with Apache nor the CGI program. In case of a donotaudit condition, I enabled audit, but still saw nothing. I switched SELinux into permissive mode briefly, to no avail. I even tried restarting Apache while in permissive mode. This did not solve the problem.

Any suggestions on how to solve this problem? I'm tempted to just revert to the older Apache.

share|improve this question
up vote 2 down vote accepted

may or may not work, seems highly unlikely, but someone had a similar problem, and this was the solution;

chmod 755 /var/log/httpd/ or whatever the directory for apache's logs is, on your server.

share|improve this answer
The permissions for the log directory were fine. However the permissions for its parent directory were not. Relaxing those permissions solved the problem. Yes, it seemed highly unlikely, but it worked. Thanks. It would be nice if Apache's error message wasn't misleading. It had nothing at all to do with the permissions of the .cgi file, as the message claimed (and as I suspected). – user43403 May 19 '10 at 23:38
Thank goodness I found this. I had this exact same issue and this was the only solution. To clarify for any future readers: the issue isn't logs per se but the directory containing the Unix socket used by CGID. The Apache user must have write access to this directory. – Dan Jun 28 '10 at 21:45
It worked like a charm. CGI sockets are created under that directory. By default parent directory has read, write, execute to only the user. If we grant 755 the web user is able to access the socket under /var/log/httpd/. – user298224 Jul 8 '15 at 5:23

I have had module behavior change across apache upgrades. It is possible that your apache conf directives may need some changes to properly serve up your cgi. Without knowing the apache conf and the details of the cgi and it's location on the filesystem, its really hard to do more than just speculate.

Also if you do suspect SELinux, try disabling it to see if apache starts serving the CGI again. If it does then you can start focusing your efforts on either adjusting the policy to allow what you're trying to do or bringing your system into compliance with the SELinux policy.

share|improve this answer
I was close to tracking down the cgi module's change log, as this had occurred to me. I had ruled out SELinux as the culprit by putting it into permissive mode. Permissive mode allows everything (like disabled), but still logs would-be violations (unlike disabled). – user43403 May 19 '10 at 23:41

AIX 7 had same problem. set permissions on /var/log/httpd directory to fix.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.