WordPress “Failed to Open Stream: Permission Denied” — Ownership Before chmod

What matters first: WordPress attempted to read, create, rename or include a path and the operating system refused. The exact path and operation matter more than a generic 755/644 recommendation.

What this symptom actually tells you

This can follow migrations, root-run deployments, container volume changes or security hardening. Recursive chmod may mask ownership errors and expose writable code.

Capture evidence before changing anything

• Record the exact path, function and operation from the warning or fatal error.
• Identify the effective PHP-FPM user and the file owner, group and ACL.
• Check whether the filesystem or container mount is read-only.
• Compare a neighbouring working file or directory created by WordPress.

Most common causes

• Wrong owner: Files were copied or extracted by root or another deployment user.
• Missing group access: The PHP user is not in the group expected by the deployment model.
• Read-only mount: The container or network filesystem intentionally prevents writes.
• Security policy: ACL, SELinux, AppArmor or hosting rules override Unix mode bits.

Safe diagnostic and repair sequence

1. Restore the documented ownership model rather than broadening every permission.
2. Make only required runtime directories writable; keep plugin, theme and core code read-only where possible.
3. Apply ACL or group strategy consistently so the next deployment does not reverse the fix.
4. Re-run the exact write or include operation and inspect the resulting owner.

How to choose between the likely causes

Do not treat Wrong owner and Missing group access as interchangeable. Files were copied or extracted by root or another deployment user. By contrast, the PHP user is not in the group expected by the deployment model. Use two checks to separate them: Record the exact path, function and operation from the warning or fatal error; and identify the effective PHP-FPM user and the file owner, group and ACL. Those observations usually show whether the next safe move is to restore the documented ownership model rather than broadening every permission or to preserve the current state and widen the investigation.

On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.

What not to do

Never apply chmod -R 777 to WordPress. It creates a writable-code surface and often leaves the actual owner mismatch unresolved.

How to verify the repair

• The original file operation succeeds under the intended PHP user.
• New files receive the correct owner and group automatically.
• Code directories are not more writable than the deployment requires.

A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.