SOLVED AllowOveride None to Home Directories

Hi guys,

As I understand it, this directive below (in httpd.conf) allows .htaccess in root directory and below - so everywhere?

<Directory "/">
AllowOverride All
Options FollowSymLinks Indexes SymLinksIfOwnerMatch
</Directory>

That was already like that so I presume it's a default but I'd like to disable .htaccess for users unless explicitly allowed.

To do it, I believe I need to make a new directory block with "/home/user" and set AllowOverride to None. But where? :p

The Documentation for Advanced Apache Configuration has been quite helpful, so if I put it in httpd.conf and distiller the file it could work, right? But *should* it instead go in one of the Include Editor field in WHM? And if so, which one is the appropriate one?

Apologise for the beginner question. I sift through a fair few related threads before I hassle you guys with another one.

 

Hi @cPanelMichael,

The solution looked promising, but upon editing ea4_main.local and rebuilding httpd conf (definitely has changed in /usr/local/apache/conf/httpd.conf), I can still use .htaccess files in my user accounts. Shouldn't the below have disabled that?

<Directory "/">
AllowOverride None
Options FollowSymLinks Indexes SymLinksIfOwnerMatch
</Directory>

 

Hi Michael,

I just set "Options Includes" in .htaccess in /home/user/public_html and put an local_date SSI in my index and it showed up. Without it in htaccess though, it's disabled by default thanks to your help in another thread (unticked it in the WHM's Apache Configuration).

I thought that AllowOverride None would prevent any overrides?

Theoretically, I shouldn't have to completely disable .htaccess with AllowOverrideList, should I?

 

Thanks for replying, Michael. Here's a screenshot of the output:

 

Hi @cPanelMichael,

All sorted!

I believe there must have been some failure in the rebuilding of the conf file (maybe on my part, not sure). The good news is that I can't seem to replicate the error anymore as of today (I hadn't actually tried since 11th Nov when I first posted the odd behavior in this thread).

I can only assume that it was fixed when the upcp cron ran between then and now (which it does every night).

Thanks very much for the help as always!