Web Server Intermediate

Apache AllowOverride None: Resolving .htaccess Ignored in Subdirectories on Ubuntu 20.04 LTS

Fix Apache ignoring .htaccess files in subdirectories on Ubuntu 20.04 LTS by correctly configuring the AllowOverride directive in your VirtualHost.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Fix Apache ignoring .htaccess files in subdirectories on Ubuntu 20.04 LTS by correctly configuring the AllowOverride directive in your VirtualHost.

Apache's .htaccess files are a powerful way to enable decentralized directory-level configuration. However, a common pitfall, especially for new server administrators or when migrating sites, is encountering situations where .htaccess rules simply don't take effect, leading to unexpected website behavior or broken functionality. This guide will walk you through diagnosing and resolving the "Apache AllowOverride None" issue, specifically when .htaccess files in subdirectories are being ignored on an Ubuntu 20.04 LTS server.

Symptom & Error Signature

The primary symptom is a lack of expected functionality driven by .htaccess rules. You won't typically see an explicit error message in your browser or Apache logs directly stating ".htaccess ignored." Instead, the application or website will behave as if the rules defined in the .htaccess file do not exist.

Common manifestations include:

  • URL Rewriting failures: mod_rewrite rules defined in .htaccess (e.g., for pretty URLs, redirecting HTTP to HTTPS) do not work, resulting in 404 errors or incorrect page loads.
    # Example .htaccess rule for forcing HTTPS that would be ignored
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    
  • Authentication/Authorization failures: Password protection (AuthType Basic, AuthUserFile) defined in .htaccess does not prompt for credentials, allowing unauthorized access.
    # Example .htaccess rule for password protection that would be ignored
    AuthType Basic
    AuthName "Restricted Area"
    AuthUserFile /var/www/html/secure/.htpasswd
    Require valid-user
    
  • Custom Error Pages not loading: ErrorDocument directives in .htaccess are ignored, and Apache serves its default error pages.
  • Missing MIME types or PHP settings: AddType, php_value, php_flag directives don't apply.
  • Directory browsing: If Options -Indexes is set in .htaccess, but directory listings are still visible.

You might check Apache's error logs (/var/log/apache2/error.log), but in this specific scenario, they often remain silent about .htaccess files being ignored, as Apache is simply following its primary configuration to not process them.

Root Cause Analysis

The underlying reason for .htaccess files being ignored is almost always the AllowOverride directive within Apache's server configuration. By default, and for security reasons, Apache is often configured to disable .htaccess processing using AllowOverride None.

Here's why this happens:

  1. AllowOverride None Default: In Apache's main configuration file (/etc/apache2/apache2.conf on Ubuntu), the <Directory> block for the default web root (e.g., /var/www/) typically includes AllowOverride None.

    <Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
    

    This directive explicitly tells Apache to ignore any .htaccess files found within this directory and its subdirectories.

  2. VirtualHost Inheritance: When you define a VirtualHost for your domain (e.g., in /etc/apache2/sites-available/yourdomain.conf), if you don't explicitly set AllowOverride within a <Directory> block inside that VirtualHost definition, it inherits the AllowOverride None setting from the parent <Directory /var/www/> block or other global configurations.

  3. Performance and Security: AllowOverride None is a security and performance best practice.

    • Security: It prevents arbitrary users from overriding critical server configurations (like mod_rewrite rules that could lead to open redirects) or injecting malicious directives.
    • Performance: Apache has to search for, parse, and apply .htaccess files in every directory segment for every request. Disabling them reduces I/O and processing overhead. It's generally recommended to move all .htaccess directives directly into the main Apache configuration (e.g., VirtualHost blocks) when possible. However, for shared hosting or specific application requirements (like CMSes such as WordPress), .htaccess files are indispensable.

In summary, the server is behaving exactly as configured; it's simply that the configuration explicitly tells it not to read your .htaccess files.

Step-by-Step Resolution

To resolve this issue, you need to modify the AllowOverride directive within your Apache configuration to permit .htaccess files to be processed for your specific website directory.

Modifying Apache's configuration can impact server security and stability. Always back up configuration files before making changes. Incorrectly configured AllowOverride All can expose your server to security risks if untrusted users can upload .htaccess files.

1. Identify Your Virtual Host Configuration File

First, determine which Apache configuration file is responsible for your website. On Ubuntu, these are typically found in /etc/apache2/sites-available/.

List the available sites:

ls -l /etc/apache2/sites-available/

Your primary site will often be named 000-default.conf if it's the default, or yourdomain.conf if you've set up a custom Virtual Host.

For example, if your domain is example.com, your configuration file might be example.com.conf.

2. Edit the Virtual Host Configuration

Open the identified Virtual Host configuration file using a text editor like nano or vim. Replace yourdomain.conf with your actual file name.

sudo nano /etc/apache2/sites-available/yourdomain.conf

Inside this file, you'll find a <VirtualHost *:80> or <VirtualHost *:443> block (or both). Within this block, locate the <Directory> directive that points to your website's document root (e.g., /var/www/html or /var/www/yourdomain.com).

A typical configuration might look like this:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/yourdomain.com/public_html
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    <Directory /var/www/yourdomain.com/public_html>
        # This is the section you need to modify
        # It might be missing, or have AllowOverride None
        Options Indexes FollowSymLinks
        AllowOverride None # <--- THIS IS THE PROBLEM
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

3. Change AllowOverride None to AllowOverride All (or specific directives)

Modify the AllowOverride directive within the <Directory> block for your website's document root.

To enable all .htaccess directives, change:

AllowOverride None

to:

AllowOverride All

While AllowOverride All is the simplest solution, for production environments, it's generally more secure to specify only the directives you need. For instance, if you only use mod_rewrite and authentication, you could use:

AllowOverride AuthConfig FileInfo Indexes Limit Options

FileInfo covers directives like RewriteEngine, RewriteRule, ErrorDocument, AddType. AuthConfig covers authentication directives. Refer to the Apache documentation for a full list of directives covered by each AllowOverride keyword.

If the <Directory> block for your DocumentRoot is missing entirely within your VirtualHost configuration, you will need to add it, ensuring it encloses your DocumentRoot path.

Example after modification:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/yourdomain.com/public_html
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    <Directory /var/www/yourdomain.com/public_html>
        Options Indexes FollowSymLinks
        AllowOverride All # <--- MODIFIED TO ALLOW .htaccess
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Save the file and exit the text editor (e.g., Ctrl+X, then Y, then Enter for nano).

4. Enable mod_rewrite (if necessary)

Many .htaccess files rely heavily on the mod_rewrite module for URL rewriting. Ensure this module is enabled:

sudo a2enmod rewrite

If it's already enabled, you'll see a message like "Module rewrite already enabled".

5. Test Apache Configuration Syntax

Before restarting Apache, always test your configuration files for syntax errors. This can prevent Apache from failing to restart.

sudo apache2ctl configtest

You should see Syntax OK. If you see errors, review your recent changes carefully.

6. Restart Apache Service

Apply the changes by restarting the Apache service:

sudo systemctl restart apache2

If Apache fails to restart, check the output of sudo journalctl -xe | grep apache2 for specific error messages that can guide you to the problem.

7. Verify .htaccess Functionality

After the restart, clear your browser cache and test the functionality that was previously failing.

  • If you had RewriteRules, check if your URLs are now resolving correctly.
  • If you had AuthType, verify that password protection prompts appear.
  • If you had ErrorDocument, test by navigating to a non-existent page to see if your custom error page loads.

Your .htaccess files in subdirectories should now be processed as expected.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.