• By: Andrew M McCall
• Published: November 1, 2026
• Updated: November 1, 2026

Fixing SELinux Apache “Forbidden” Errors with WordPress wp-env on Fedora

TL;DR: We need to tell SELinux it is okay for Docker containers to read and write to files related to our theme development.

The Problem

When running wp-env start on Fedora with SELinux enabled, browsing to http://localhost:8888 results in an Apache Forbidden (403) error:

“You don’t have permission to access this resource. Server unable to read htaccess file, denying access to be safe.”

Why This Happens

Fedora’s default setting for SELinux prevents Docker containers from interacting with files inside a user’s home directory (~/). Because wp-env maps both your local project directory and a hidden configuration folder (~/.wp-env) directly into the Apache Docker container, SELinux blocks the containerized Apache server from reading its own configuration and theme files.

The Solution

Instead of disabling SELinux all together, we can flag your development directories as safe for Docker containers to read and write to.

Step 1: Update SELinux Contexts

Run the following commands in your terminal to apply the svirt_sandbox_file_t security context recursively (-R) to both your theme project folder and the hidden wp-env application directory:

chcon -Rt svirt_sandbox_file_t ~/Projects/your-block-theme
chcon -Rt svirt_sandbox_file_t ~/.wp-env

• chcon: Changes the SELinux security context.
• -R: Recursive (applies to all subfiles, folders, and .htaccess assets).
• -t svirt_sandbox_file_t: Authorizes shared development sandbox access specifically for container engines like Docker/Podman.

Note: you can read more about chcon command via man chcon.

Step 2: Restart the Environment

Once the permissions are updated, restart your WordPress environment to make Docker recreate the mounts with the new permission rules intact:

wp-env stop
wp-env start

Troubleshooting & Maintenance Notes

Ensuring the Changes Persist

chcon applies a context change that can be wiped if your file system gets fully relabeled. If you need a permanent policy rule that survives a full system relabeling, use semanage:

sudo semanage fcontext -a -t svirt_sandbox_file_t "/home/andrew/Projects/your-block-theme-project(/.*)?"
sudo semanage fcontext -a -t svirt_sandbox_file_t "/home/andrew/.wp-env(/.*)?"
sudo restorecon -R -v ~/Projects/your-block-theme-project
sudo restorecon -R -v ~/.wp-env

Make A Backup Before wp-env destroy

If the local environment ever requires a reset, do not run wp-env destroy without creating a backup if you have modified database configuration or content.

• To safely export your database contents before destroying a container, run:

  wp-env run cli wp db export backup.sql
  

• To import it back into a freshly rebuilt container:

  wp-env run cli wp db import backup.sql