You still need to set AllowOverride none in the <Directory> block to prevent .htaccess files from interfering.
As for the index file being downloaded, if it's static content, see: http://httpd.apache.org/docs/current/mod/mod_mime.html#addtype If it's a php file, see: http://wiki.apache.org/httpd/php Lastly, read about context here: http://httpd.apache.org/docs/current/mod/directive-dict.html#Context On Fri, Sep 28, 2018 at 7:56 PM Jack M. Nilles <jnil...@jala.com> wrote: > Frank, > > Sorry for the typos. I've corrected the code below to be consistent. The > error message was, and is (I am anonymizing the directory details): > > [Fri Sep 28 15:15:39.301689 2018] [autoindex:error] [pid 17591] [client > 1.2.3.4:45731] AH01276: Cannot serve directory /home/data/site1/htdocs/: > No matching DirectoryIndex (index.html,index.html.var) found, and > server-generated directory index forbidden by Options directive > > Anywhere I put the DirectoryIndex line in the vhosts.conf file it results > in apache downloading the html of the index page but not displaying it. So > I've commented it out at present. > > Please explain what you mean by 'vhost context'. I am unfamiliar with the > FallbackResource directive. > Thanks for our help; I'm still head scratching here. > > Jack Nilles > > On 28 Sep 2018, at 15:14, Frank Gingras <thu...@apache.org> wrote: > > There is no reference to "webdir" anywhere in your configuration, so you > effectively munged it to the point that we cannot help you. > > Further, I would recommend setting AllowOverride none in every single > <Directory> block - the last thing you want is for a rogue .htaccess file > to interfere. If the sole purpose of said .htaccess file is to set up > permalinks, all you need is likely a single FallbackResource in the vhost > context instead. > > Also, set the DirectoryIndex in the vhost context instead. > > On Thu, Sep 27, 2018 at 1:29 PM Jack M. Nilles <jnil...@jala.com> wrote: > >> Two days ago I upgraded my SUSE server. It serves three websites as >> virtual sites. All of the sites run php. Upon restarting apache 2.4 I got >> the following error message: >> >> [Wed Sep 26 07:36:55.666104 2018] [autoindex:error] [pid 12345] [client >> 1.2.3.4:50430] AH01276: Cannot serve directory /webdir/htdocs/: No >> matching DirectoryIndex (index.html,index.html.var) found, and >> server-generated directory index forbidden by Options directive >> >> I have visited many help pages and forums on apache, tried most of the >> suggested remedies, such as adding DirectoryIndex index.php, to no avail. >> >> Here is the vhosts.conf code for one of the sites: >> >> <VirtualHost 1.2.3.4:443> >> >> ServerAdmin webmas...@site1.com >> ServerName www.site1.com >> ServerAlias site1.com *.site1.com >> DocumentRoot "/home/data/site1/htdocs" >> SSLEngine on >> SSLProtocol all -SSLv2 >> SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt >> <http://www.site1.com.crt/> >> SSLCertificateKeyFile /etc/apache2/ssl.key/www.site1.com.key >> SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt >> RewriteEngine On >> RewriteOptions Inherit >> > # DirectoryIndex index.php > > >> <Directory "/home/data/site1/htdocs"> >> DirectoryIndex index.php >> # To make the blog work with pretty permalinks use the next 2 >> uncommented lines. >> # Otherwise use 'Options None' and 'AllowOverride None' >> Options FollowSymlinks >> AllowOverride all >> Require all granted >> </Directory> >> >> AccessFileName .htaccess >> >> ErrorLog /var/log/apache2/site1.com-error_log >> CustomLog /var/log/apache2/site1.com-access_log combined >> >> ScriptAlias /cgi-bin/ "/home/data/site1/cgi-bin/" >> <Directory "/home/data/site1/cgi-bin"> >> AllowOverride None >> Options +ExecCGI -Includes >> Require all granted >> </Directory> >> >> Include /etc/apache2/conf.d/*.conf >> >> </VirtualHost> >> >> Adding the DirectoryIndex line has the strange result that, if I click >> twice on the site in a browser, the page gets downloaded but the error >> message remains! >> >> Any help would be appreciated. I have already spent two days in a >> fruitless search for a solution. The sites had worked perfectly before the >> "upgrade". >> >> >
