Problem with Suse Ent 9 apache2 and perl

I am having a problem with Suse Enterprise 9 with apache2 and perl. The error message from the error_logs is:

1) Logs
[error] [client] Premature end of script headers:
[error] [client] (13)Permission denied: exec of '/home/www/fh/v2/Perl/' failed

2) Script is a simple hello perl script:

print "Content-type: text/html\r\n\r\n\n";
print "<HTML>\n";
print "<HEAD><TITLE>Hello World!</TITLE></HEAD>\n";
print "<BODY>\n";
print "<H2>Hello World!</H2>\n";
print "</BODY>\n";
print "</HTML>\n";

exit (0);

3) The command perl -wc reported syntax ok.
4) The command perl looks fine and reports:
perl  /home/www/fbo/Perl/
Content-type: text/html

<HEAD><TITLE>Hello World!</TITLE></HEAD>
<H2>Hello World!</H2>

5) May be the problem with my config. They are as below:


AddHandler cgi-script .cgi .pl

<Directory "/home/www/fbo/Perl">
        Options FollowSymLinks +ExecCGI
        AllowOverride None
        Order allow,deny
        Allow from all
<Directory "/home/www/fh/v2/Perl">
        Options FollowSymLinks +ExecCGI
        AllowOverride None
        Order allow,deny
        Allow from all
    DocumentRoot /home/www/fh
    Options ExecCGI Includes FollowSymlinks
    DirectoryIndex index.php index.html index.htm

ScriptAlias /Perl "/home/www/fh/v2/Perl"

6) /etc/apache2/conf.d/mod_perl.conf
<IfModule mod_perl.c>
    PerlRequire "/etc/apache2/"

    ScriptAlias /Perl/ "/home/www/fh/v2/Perl"
    <Location /home/www/fh/v2/Perl/>
        # mod_perl mode
        SetHandler perl-script
        PerlResponseHandler ModPerl::Registry
        PerlOptions +ParseHeaders
        Options +ExecCGI +Indexes +FollowSymlinks

Permission is already 777. Only thing to point out is /home/www is an nfs mount but shudnt ve permission problems. Another thing is shown in logs is the load balancer while the server is /home/www/fh/v2/Perl is a soft link to /home/www/fbo/Perl

What is the problem with my perl config?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The premature end of script headers error is frequently caused by the file having the wrong line endings for the server's OS.  Were the files created or saved in Windows?  Are you uploading them to the server in ASCII mode (or are the files being created in Linux)?

What is your fstab entry that mounts the volume?  What are the permissions of the directory to which it is mounted?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
pajiaoAuthor Commented:
i create the in vi and there were no weird characters nor spacing. Furthermore running perl on the script is fine and syntax is also reported ok. The fstab entry is using no_root_squash with rw. No problems with the whole mount point as i have tested read and write.
Curious...  I tried your code on my server, and it worked fine (see  I first tried the following code, as I usually use to write these things:

use strict;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);

my $q = new CGI;

print $q->header (-type => 'text/html'),
$q->start_html('Hello World!'),
$q->h2('Hello World!'),

When this code worked without error (see, I tried your code exactly as you posted it  and found that it, too, worked fine.

So, there's nothing wrong with your Perl script.  The errors must be due to a server misconfiguration.  I am running Apache 2.0.52 and Perl 5.8.5 under Fedora Core 3 kernel 2.6.12-1.1372 (yeah, I ought to get around to upgrading...).

There's nothing special in my httpd.conf.  Do note, however, that my setup is quite a bit simpler than yours.  I do not use an AddHandler line, no +ExecCGI options, and the only line not commented out in my /etc/httpd/conf.d/perl.conf  is "LoadModule perl_module modules/" (a copy of my perl.conf is at

ScriptAlias /cgi/ "/var/www/cgi-bin/"
ScriptAlias /cgi "/var/www/cgi-bin/"

     DocumentRoot /var/www/html/growlerz
     XBitHack on

I do load mod_cgi from /etc/httpd/httpd.conf ("LoadModule cgi_module modules/").

These files are owned by root, permissions are set to 755, and there's no impact by filename:

-rwxr-xr-x   1 root   root      218 Jan  1 10:12 ee_test_CGI.cgi
-rwxr-xr-x   1 root   root      218 Jan  1 10:48
-rwxr-xr-x   1 root   root      230 Jan  1 10:17 ee_test_CGI-org.cgi
-rwxr-xr-x   1 root   root      230 Jan  1 10:48

Have you ever had CGI scripts running on your set up?  Can you try running one from a directory that is not an nfs mount, just to rule that out?  What user does Apache run under?  Try setting the owner & group of the mount point's directory and the Perl file to whatever user Apache is running as...

Try eliminating some of the options and stuff you have set up -- I'll bet something is conflicting.
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

What happens when you run the script from the command line with:


pajiaoAuthor Commented:
Thanks guys for the reply.

I used to use Redhat/Fedora and everything works like a charm on default installation. Right now Suse is giving me headache. I tried changing to a non NFS mount point for the script directory but same error is returned. Some of the configurations were included by Suse just like Fedora included perl.conf

As described in my question, i have done that and also checked the syntax with perl -wc and everything is fine.

Regretted being so gungho over migrating to Suse, shud ve done more safer contigency plans :(
pajiaoAuthor Commented:
Note that i have a permission denied which leads to think of User and Group directives which Suse by default has wwwrun and www respectively, thus if the script and the directory is 777 there shudnt be a problem rite?

There's a world of difference in doing



perl /home/www/fbo/Perl/

In your original post, you only mentioned that you did the second one (ie: invoked with perl).

Running the script by itself can pick up any potential permission or similar problems.
It is curious that the error is logged as ocurring on the load balancer ( rather than the machine on which the script is executed (

Can you give us a bit more detail on your network configuration?
pajiaoAuthor Commented:

Running as what u mentioned did report : -bash: /home/www/fbo/Perl/ /usr/bin/perl: bad interpreter: Permission denied

My network setup is: firewall
----------------------- load balancer
------------------------------ www    www2

There is only 1 public addr of the web serv and it is NATed to the load balancer so no public addr actually maps to the web servers directly.

pajiaoAuthor Commented:
By the way my nfs mount is:        /home/www       nfs     user 0 0
pajiaoAuthor Commented:
Another small progress made: added 'exec' on the export of my nfs server, did a mount -a on my www server and executing '/home/www/fbo/Perl/' leaves me with 'Permission denied' only. Bad intepreter solved. Strangely Redhat/Fedora doesnt mind without 'exec'.
I thought fstab might assume noexec unless told otherwise...

Who owns perl at /usr/bin/perl?  Who owns the mounted directory?  I agree that setting everything to 777, it shouldn't matter, but this is behaving suspiciously like a user/group mismatch...

Do you have SELinux running (from a terminal command line: sestatus -v) on either machine?  If so, try temporaily turning it off (setenforce 0), then see if it'll work without the 'Permission denied' message.  You might also check /var/log/messages.  If that's your problem, we can create a policy that'll overcome it, and set it on the nfs mount.
pajiaoAuthor Commented:
Just found out 'exec' is not recognised on /etc/export by Suse. /usr/bin/perl is owned by root. In fact changing it to 777 didnt help either. Mount directory is owned by root as well but is 777 too.

I believe you are speaking in reference to Redhat, but i am using Suse and SeLinux is not found.
Oh -- didn't realize SuSE didn't include SELinux...  What does it have -- AppArmor?  Could this be interferring?
pajiaoAuthor Commented:
Solved! It is a freaking NFS and perl ascii format problem. Somehow NFS config ported from Redhat worked differently from Suse though it appeared fine. After i solved the NFS problems, tested the perl scripts and found 'No such file or directory' which prolly meant the format. I used dos2unix and change all their permissions to 755 and everything worked without the stability problems!

Thanks to all for the comments!
So it turned out to be both an ASCII line ending problem *and* an fstab entry problem.  We took a long circuitous route from my first post...:)
I made three points in my first post -- ASCII line endings, filesystem mounting, and file permissions.  The problems turned out to be ASCII line endings, filesystem mounting, and file permissions...
The ping above was to see if someone feels they should have the points. After there was no answer, and after I see a solution from the Asker, the recommendation was clear.

You may find that it is a good idea to answer to the cleanup messages - not only after you loose points.  ;)
You could not determine from my post following pajiao's "Solved!" post that I felt his solution was related to my suggestions?  Okay, no problem...
Well.. depends :))
But on second reading I agree with you

Changed recommendation: Points to  mjcoyne {http:#15586270}
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Scripting Languages

From novice to tech pro — start learning today.