apache downloads the php file instead of executing it

Hi again.. I think i screwed something else up. (i tried to correct this ticket by changing from FCGId to mod_php and back to FCGId to see if it would fix itself) re: ( https://virtualmin.com/node/34998 ) Well that made the site not work but wants to dl the php files!
Please help. i am at a loss on both issues.. thanks a lot!

(i temp set it back to mod_php so the site works in case you try to access)



Howdy -- did you by chance change to a version of PHP that comes from a third party repository? That can cause the problem you're describing now.

What is the output of this command:

rpm -qa | grep php-

I do not remember the repo but i need this version for certain scripts to run.. output attached as image (as i am on vmware console)

Ah, it looks like the Remi repository was enabled, which is a third party repository. Using packages from that can indeed cause a variety of problems (including websites not working).

There's information on that PHP issue (and how to work around it) here in the section "Why does PHP / ProFTPd no longer work after performing updates? (I'm using CentOS, and enabled third party repositories)":


OK great so i commented out as per: The issue is typically the result of a SetHandler line being added into one of the .conf files in /etc/httpd/conf.d -- often in the file php.conf. SetHandler application/x-httpd-php And then comment that out, and restart Apache using the command "/etc/init.d/httpd restart".

I set it back to FCGId and the site works again now. For the repository, is there no PHP version 5.4.34 or greater stable release? (I somewhat remember that it was not available. so i am going to disable that remi repo for now at least..)

The newest PHP version that CentOS provides is 5.3.3, unfortunately.

However, you can use the CentOS SCL repository to install a second PHP version. They provide PHP 5.4.x, though I think it's less than 5.4.34.

There are instructions on using the SCL repository to install a second PHP version here:


OK Thanks a lot. I will look into that this week. I disable the remi repo for now.

Thanks a lot - you are awesome support.

I have suddenly the same problem. CentOS 6.* + PHP7 - worked without flaw till maybe a few days ago (I don't check everyday, might not work for w few weeks).

It's a VPS with 3 domains, lets call them 1, 2 + 3

1 + 2 want to DL the PHP 3 works fine

http.conf has no SetHandler, but I commented it out in php.conf

Now it's the other way round,

1 + 2 are fine 3 want to DL the PHP

What can I try?

Mostafa's picture
Submitted by Mostafa on Wed, 02/22/2017 - 10:33

Try running the following command:

virtualmin modify-web --mode fcgid --all-domains

Here is what I get. I get this error only on the domain that is currently not working.

[root@vps ~]# virtualmin modify-web --mode fcgid --all-domains
Updating server domain3.com ..
Error: Failed to open /home/domain3/fcgi-bin/php7.0.fcgi.webmintmp.29141 : Permission denied
Failed to open /home/domain3/fcgi-bin/php7.0.fcgi.webmintmp.29141 : Permission denied

The download option stopped, I get internal server error 500 now.

Update: I set domain3/fcgi-bin/php7.0.fcgi both to 777 and the "virtualmin modify-web --mode fcgid --all-domains" ran without errors, problem is exactly the same (Apache was restarted).

Sorry that you're having problems with PHP!

You may want to take a peek at this here and see if this applies to your issue:


However, as this request is a few years old, and it looks like you're using Virtualmin GPL there -- you'd actually want to start a new Forum thread to discuss the issue you're seeing there. We monitor the Forums, along with lots of wonderful folks in the community. Thanks!

Mostafa's picture
Submitted by Mostafa on Fri, 02/24/2017 - 15:12

Try running virtualmin fix-domain-permissions --all-domains --subservers and then virtualmin modify-web --mode fcgid --all-domains

On Ubuntu 16.04 I just experienced the issue of being unable to serve PHP files and only download them. The fix was to comment out this line [ SetHandler application/x-httpd-php] as shown below snippet in the file


<FilesMatch ".+\.ph(p[3457]?|t|tml)$">
  #  SetHandler application/x-httpd-php
Mostafa's picture
Submitted by Mostafa on Mon, 02/27/2017 - 02:29

@martlam this is not a good fix, all your websites will be using mod_php in this case.

The command virtualmin modify-web --mode fcgid --all-domains should fix this problem in the correct way ( adding missing fcgid handlers to virtual servers).

That's actually our recommended fix; when that SetHandler line is active, it forces all websites to try and use mod_php, regardless of the Virtualmin setting.

Virtualmin comments out all SetHandler lines in the PHP config file during installation, but certain third party packages can re-add that (such as adding PHP from an alternate repo).

There's some additional details on that here:


When I ran:

virtualmin modify-web --mode fcgid --all-domains

Rather than fixing the domain that was downloading php files, it made all my sites download php files.

I noticed output Saving server details for each of the modified domains, during the execution of that command.

Is there some way to reverse this so I can get the websites working again?

PS: I found the /etc/apache2/sites-available/*.bak files but when I copied them to restore the sites, I got:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Apache/2.4.25 (Debian) Server at mydomain.com Port 80

jabowery, it sounds like you may be seeing the issue described above. For most of the folks here, they have a third party PHP version installed.

We've seen third party PHP versions causing some config issues though, including the issue you're describing.

What I'd suggest is to go to the URL in Comment #15 above, and try the solution mentioned there.

Let us know if that does the trick!

I executed virtualmin modify-web --mode mod_php --all-domains and got one site working again -- the site whose /etc/apache2/sites-available/*.bak I had restored (resulting in the 503 error reported above).

However, now all sites resolve to that site alone.

I do have deb.sury.org in my /etc/apt/sources.list.d/php.list file so that's probably it.

Although I don't have the spurious SetHandler suggested at that link:

# grep SetHandler /etc/apache2/conf.d/*
/etc/apache2/conf.d/git:   SetHandler cgi-script

I'm still a bit mystified by the fact that some of my sites worked prior to the execution of the "fix" and then they all went south -- and could not be made to work again even after restoring the backup files in /etc/apache2/available-sites