Web Server Intermediate

Fix Apache AllowOverride None Ignoring .htaccess in Subdirectories on WSL2 Ubuntu

Troubleshoot Apache AllowOverride None preventing .htaccess files from working in subdirectories on WSL2 Ubuntu environments.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Troubleshoot Apache AllowOverride None preventing .htaccess files from working in subdirectories on WSL2 Ubuntu environments.

Introduction

As an experienced administrator, you've likely encountered situations where your .htaccess files, crucial for per-directory configuration, seem to be completely ignored by Apache. This issue is particularly common in development environments like Windows Subsystem for Linux 2 (WSL2) running Ubuntu, where default configurations or inherited directives can inadvertently disable .htaccess processing. When Apache's AllowOverride directive is set to None, any .htaccess file within that directory (and its subdirectories) will be bypassed, leading to unexpected application behavior, broken URL rewrites, or failed authentication rules. This guide will walk you through diagnosing and resolving this specific configuration oversight.

Symptom & Error Signature

The primary symptom is that rules defined in your .htaccess files are simply not being applied. You won't typically see an explicit error code in your browser or Apache error logs directly related to .htaccess being ignored. Instead, the application or website will behave as if those rules don't exist.

Common manifestations include:

  • URL Rewrites Not Working: Pretty URLs defined via mod_rewrite in .htaccess result in 404 Not Found errors or display the original, unrewritten URL.
  • Authentication/Authorization Failing: Password protection or access restrictions defined in .htaccess are ineffective, allowing unauthorized access.
  • Custom Error Pages Not Displayed: ErrorDocument directives in .htaccess are ignored, and default Apache error pages are shown instead.
  • PHP Settings Not Applied: php_value or php_flag directives in .htaccess have no effect.

While there's no direct error signature, you might see related entries in your Apache access or error logs if the absence of a rule causes a problem. For example, a 404 for a rewritten URL:

# /var/log/apache2/access.log
127.0.0.1 - - [16/Oct/2026:10:30:00 +0000] "GET /non-existent-pretty-url HTTP/1.1" 404 459 "-" "Mozilla/5.0 (...)"

Root Cause Analysis

The core reason .htaccess files are ignored is the AllowOverride directive in your Apache configuration. This directive specifies which directives declared in .htaccess files are permitted to override earlier configuration directives. When AllowOverride is set to None for a given directory, Apache will completely ignore any .htaccess files it finds within that directory and its subdirectories.

The problem usually stems from one of the following:

  1. Default AllowOverride None in Global Configuration: Apache's main configuration (apache2.conf or httpd.conf) often has a <Directory /> block (representing the root of the filesystem) with AllowOverride None. If this is not explicitly overridden for your web root, it will propagate.
  2. Incorrect AllowOverride in Web Root Directory Block: Your virtual host's <VirtualHost> block or a global <Directory /var/www/> (or similar) might explicitly set AllowOverride None for your web content directory.
  3. Mismatched Directory Paths: The <Directory> block in your Apache configuration might not accurately point to the actual path of your web content, especially common in WSL2 where paths can be ambiguous (e.g., /mnt/c/Users/YourUser/www vs. /home/youruser/www).
  4. Missing or Disabled Apache Modules: While not directly causing AllowOverride None, modules like mod_rewrite (for URL rewriting) or mod_authz_core (for authentication) must be enabled for .htaccess rules relying on them to function, even if AllowOverride is correctly set.
  5. File System Permissions (Less Common for "Ignored"): While less likely to cause *.htaccess* ignored, incorrect file permissions could prevent Apache from reading the .htaccess file, potentially leading to a 500 Internal Server Error rather than silently ignoring it. However, it's a good practice to check permissions, especially when working with shared filesystems or Windows mounts in WSL2.

Step-by-Step Resolution

Follow these steps to correctly configure Apache to respect your .htaccess files on WSL2 Ubuntu.

1. Identify Your Apache Configuration Files

First, locate the main Apache configuration file and your virtual host configuration.

  • Main Configuration: Typically /etc/apache2/apache2.conf on Ubuntu.
  • Virtual Host Configurations: Usually found in /etc/apache2/sites-available/. Common files include 000-default.conf or custom .conf files for your specific domains.

You can list enabled sites with:

sudo a2query -s

Then, inspect the corresponding .conf file for your site.

2. Locate and Modify the AllowOverride Directive

Navigate to the correct <Directory> block that corresponds to your web root.

The AllowOverride directive must be placed within a <Directory> block, a <Location> block, or an <Files> block. It cannot be used in the global server configuration context.

Option A: For a specific Virtual Host (Recommended)

If you have a dedicated virtual host file (e.g., /etc/apache2/sites-available/your-site.conf), open it:

sudo nano /etc/apache2/sites-available/your-site.conf

Inside the <VirtualHost *:80> (or *:443 for SSL) block, locate the <Directory /var/www/html> (or whatever your web root path is) block. If it doesn't exist, you'll need to create it.

Change AllowOverride None to AllowOverride All.

Example:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All  # <--- Change this line
        Require all granted
    </Directory>

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

While AllowOverride All is the simplest solution for development, in production environments, it's better practice to specify only the directives you need (e.g., AllowOverride FileInfo AuthConfig) for security and performance reasons.

Option B: For the Global Default Web Root

If you're using the default Apache web root (/var/www/html) and don't have a specific virtual host configured, you'll modify the global Apache configuration file.

Open /etc/apache2/apache2.conf:

sudo nano /etc/apache2/apache2.conf

Look for the <Directory /var/www/> block. This block defines the default settings for the /var/www directory and its subdirectories.

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None  # <--- Change this line to All
        Require all granted
</Directory>

Change AllowOverride None to AllowOverride All.

3. Verify DocumentRoot and Directory Paths

Ensure that the path specified in your Apache <Directory> block (e.g., /var/www/html) precisely matches the actual path to your website's files. In a WSL2 environment, pay close attention to whether your files are on the native Linux filesystem (e.g., /home/youruser/mywebsite) or a mounted Windows drive (e.g., /mnt/c/Users/youruser/mywebsite).

While you can serve files from /mnt/c/ drives in WSL2, it's generally recommended to host your web content on the native Linux filesystem (e.g., within /home/youruser/) for better performance, file permissions consistency, and to avoid potential issues with certain Linux-specific file operations. If your web root is on /mnt/c, ensure the permissions are correctly set (see step 5).

4. Enable Necessary Apache Modules (e.g., mod_rewrite)

Many .htaccess rules rely on specific Apache modules. The most common one is mod_rewrite for URL rewriting. Ensure it's enabled.

sudo a2enmod rewrite

If your .htaccess uses other directives (e.g., for authentication), you might need to enable mod_authz_core, mod_authn_file, etc., though these are often enabled by default.

5. Check File Permissions

Ensure Apache has read access to your web root and .htaccess files. While less likely to cause "ignored" and more likely a "500 Internal Server Error", it's a good step.

The Apache user (typically www-data on Ubuntu) needs read and execute permissions for directories leading to your .htaccess file, and read permissions for the .htaccess file itself.

# Example for a web root at /var/www/html
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} ;
sudo find /var/www/html -type f -exec chmod 644 {} ;

If your files are on a /mnt/c/ drive within WSL2, permissions behave differently. WSL2 maps Windows permissions, and chmod on these filesystems is often faked or limited. In such cases, ensure the Windows user account owning the files has full read/write access. For Apache to read them, the www-data user needs to be able to access the /mnt/c mount point.

6. Restart Apache

After making any configuration changes, you must restart Apache for them to take effect.

sudo systemctl restart apache2

Always use systemctl restart apache2 or systemctl reload apache2 (if you are confident your changes are non-disruptive) rather than service apache2 restart as systemctl is the modern and preferred method on Ubuntu.

7. Test Your Configuration

Clear your browser cache and try accessing your website. Verify that your .htaccess rules are now being applied correctly. For example, if you had a rewrite rule, check if the pretty URL now works as expected.

If you encounter issues, check your Apache error logs (/var/log/apache2/error.log) for any new clues.

sudo tail -f /var/log/apache2/error.log

By following these steps, you should successfully enable .htaccess processing for your web applications running Apache on Ubuntu within WSL2.

👨‍💻

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.