If every WordPress domain on a server suddenly returns “You do not have permission to access this resource” or a 403 Forbidden page, the fault is usually above WordPress: Apache or Nginx cannot read a shared virtual-host directory, document root, or .htaccess file. Start with the web-server error log at the time of the failure, then check service-user access and parent-directory permissions before changing WordPress files.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the 403 message actually means
A 403 is an authorization response. The server received the request but refused to serve the resource. Apache’s documented example body uses the wording “You do not have permission to access this resource.” That response can be generated before PHP starts, so WordPress plugins, themes, and the WordPress dashboard may never run.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When several unrelated sites fail at the same time, treat them as one infrastructure incident first. Shared virtual-host configuration, a common parent directory, the web-server account, a provider-wide access policy, or a recently changed security rule is more likely than identical WordPress bugs in every installation.
A 403 is different from a 404 (the resource was not found), a 500 (the application or server failed), and a PHP error. The status alone does not identify the cause; the exact URL, server type, and error-log line do.
#1 Best Overall
Classify the failure before changing anything
Use two or more affected domains and test the same small set of URLs. Record the result, response code, and timestamp in UTC or the server’s local time.
| Test | What to request | What the result tells you |
|---|---|---|
| Home page | https://example.com/ |
Checks the normal document root and front-controller path. |
| Harmless static file | A known public image, favicon, or temporary text file | If this also returns 403, the problem is probably server access, directory traversal, or a vhost rule rather than WordPress rewrites. |
| Administration | https://example.com/wp-admin/ |
Separates a site-wide denial from a front-end rewrite problem. |
| Pretty URL | An ordinary post or page permalink | If only this fails while the home page works, investigate rewrite and .htaccess handling. |
| Sensitive filename | Only if you have a legitimate reason, such as /readme.html |
A deliberate 403 may be a hosting security rule, not damage. |
Interpret the pattern rather than guessing:
- All domains and all paths fail: inspect shared vhost or
httpdocspermissions, parent-directory search permission, service-user access, and provider policy. - One domain fails: compare that domain’s vhost, document-root ownership, mode bits, and local
.htaccesswith a working site. - Only pretty URLs fail: check Apache override policy, rewrite modules, and the network’s WordPress rewrite block.
- Only protected filenames fail: confirm whether a security rule intentionally denies them.
- Only one visitor, office, VPN, or ISP fails: investigate CDN, WAF, IP reputation, or access-control logs instead of changing file permissions.
Read the error log first
Do this before running recursive ownership or permission commands. The log identifies which layer rejected the request and prevents you from weakening a secure installation to solve the wrong problem.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Note the exact time and URL from a fresh request to an affected site.
- Open the Apache or Nginx error log for that virtual host and the server-wide error log if the vhost log is empty.
- Search around that timestamp for the domain, requested path, client address, and status.
- Save the relevant lines before making a change so you can compare the next request.
On Plesk-managed servers, an all-domain failure commonly appears as pcfg_openfile: unable to check htaccess file. Plesk documents that message when Apache cannot access the vhost or httpdocs directory with the permissions it needs. A similar “permission denied” line from Nginx, a WAF, or a filesystem audit points to a different layer.
If you do not have log access, ask the host for the error-log entry at the precise timestamp and for the service account used by Apache or Nginx. A hosting provider can correct a shared vhost permission or policy that an individual WordPress administrator cannot safely repair.
Fix shared directory and service-user access
For simultaneous failures, verify the entire path from the filesystem root to each document root. A web server needs search (execute) permission on every parent directory, read permission on files it serves, and the ability to inspect directories. Correct ownership and group membership are more important than simply adding broad write permission.
Check the path and identities
On a Linux server, an administrator can inspect each path component with commands such as:
namei -l /var/www/example/httpdocs/index.php
ls -ld /var /var/www /var/www/example /var/www/example/httpdocs
stat /var/www/example/httpdocs/.htaccessUse the actual document-root path shown in the vhost configuration. Identify the account that runs the web server (for example, a distribution-specific Apache or Nginx user) and the account that owns the site. Do not assume they are the same, and do not guess from an Internet example.
Correct access with the host’s supported method
Change only the owner, group, or mode that the hosting model requires. On shared hosting, use the control panel’s “repair permissions” or subscription-repair function if one is provided. On a server you administer, grant the service account the required read and directory-search access through the documented owner/group arrangement, ACLs, or hosting panel settings.
After the correction, reload or restart the web server using the operating system or hosting panel procedure, then repeat the static-file and WordPress tests. A reload is preferable when it applies; a full restart is appropriate only when the provider’s instructions require it.
Why parent directories matter
A file can be mode 644 and still return 403 if a parent directory denies traversal. Conversely, making every directory world-writable does not solve a missing service-user group and creates a security risk. Check each parent directory’s execute/search bit and ownership rather than changing the entire tree blindly.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Use least-privilege WordPress permissions
WordPress documentation says permissions depend on the host and deployment model. A common suexec-style baseline is directories 755 or 750, and files 644 or 640. The configuration file is often tightened to 440 or 400 when updates and the hosting model permit it. These are examples, not universal values.
- Files should normally be owned by the account that manages the installation, with a group arrangement that lets the web process read what it must read.
.htaccessmust be readable by Apache when rewrite features depend on it.- Upload directories need the ability to receive uploads only when the application requires it; they do not need to be writable by every local user.
- Keep backups of shared configuration and verify the current owner and group before editing.
Never recursively set a WordPress installation to 777. WordPress explicitly warns that no directories should be given 777, including upload directories. World-writable code lets other users or compromised processes alter PHP files and can turn a 403 incident into a full site compromise.
If a permissions command is necessary, limit it to the affected document root and use the values prescribed by your host. Avoid commands copied from a different control panel, PHP handler, or multi-tenant setup. A provider may use ACLs, per-subscription users, or a special group that ordinary mode bits do not show.
Check Apache .htaccess and override policy
An .htaccess file has no effect unless Apache is configured to read it. The AllowOverride setting in the relevant <Directory> block controls whether Apache processes per-directory configuration and which directive classes are allowed. With AllowOverride None, Apache ignores .htaccess; with restricted override classes, some directives can trigger errors or be rejected.
Free tools Windows power users keep installed
One-click scans. No signup required.
Find the applicable directory block
Inspect the vhost serving the failing domain and locate the <Directory> block that covers the document root. Confirm that:
Rank #4
- the path exactly matches the real document root;
- the block permits the required override class for WordPress rewrites;
- access is not denied by a broader or more-specific rule;
- the rewrite module and any required includes are enabled; and
- the vhost loaded successfully after the last configuration change.
Do not paste a random AllowOverride All into a production server. It grants more per-directory control than many sites need. Enable only the override classes required by the rules in that site’s .htaccess, following the Apache version and host configuration.
Validate the file safely
- Make a dated backup of the current
.htaccess. - Temporarily rename it, for example to
.htaccess.disabled, and request a harmless static file. - If the 403 disappears, inspect the file for an invalid directive, an unconditional deny rule, or rules copied from another server.
- Regenerate the minimal WordPress rewrite block from the Permalinks screen or the network settings, then test again.
If renaming the file has no effect and the log says Apache cannot open it, repair filesystem access instead. If Apache reports an unknown directive or configuration error, fix the directive or enable the required module rather than loosening permissions.
Verify WordPress Multisite routing
WordPress Multisite lets several WordPress instances run from one installation. Its network can be path-based (subdirectories) or domain-based (subdomains or mapped domains). The rewrite rules and domain mapping must match the network type.
Recommended Free Tools
Path-based networks
For a subdirectory network, confirm that the main installation’s document root is correct, the network rewrite block is present, and requests such as /site-two/ are not being sent to a different vhost. A missing rewrite module or an incorrect base path can make every child-site permalink fail while the main home page still loads.
Domain-based networks
For subdomain or mapped-domain networks, verify DNS, each domain’s vhost, and the mapping recorded in WordPress. Every domain must resolve to the intended server and document root. A newly added domain pointing at a directory without the expected access rules can produce a 403 even though the original network works.
Best Value
Regenerate and test rewrites
- Confirm the network type in the Network Admin settings.
- Check that the web server’s rewrite support is enabled and that the correct network rules are in the active vhost or
.htaccess. - Visit the main site, one child-site home page, one child-site post, and
/wp-admin/for each affected domain. - Review the error log after each test; a rewrite loop, denied directory, and missing file produce different entries.
Recognize intentional security blocks
Plesk WP Toolkit documents generated Apache and Nginx rules that return 403 for sensitive names such as readme.html, license.html, changelog.html, and wp-config.php. Blocking those files can be expected hardening, not a broken installation.
Check the requested path and the active vhost configuration before disabling such a rule. Removing it exposes version or configuration information and can reduce WordPress security. Test a normal page and a harmless static asset; do not use a protected filename as your only health check.
When only one network or visitor is blocked
If the sites work from another connection but fail for one office, VPN, or ISP, the filesystem is unlikely to be the root cause. Ask the CDN, WAF, or hosting provider for the decision log and check:
- the client IP and whether it is on a reputation or rate-limit list;
- country, ASN, bot, or authentication policies;
- recent firewall changes and expiration times;
- whether the proxy is forwarding the original host and protocol; and
- any difference between cached and origin responses.
Do not disable all security controls to make one test pass. Permit the verified client or correct the rule narrowly, then retest through both the proxy and the origin path.
Common mistakes and safer recoveries
| Mistake | Why it fails | Safer recovery |
|---|---|---|
Recursive chmod 777 |
Creates world-writable code and may still leave the service account unable to traverse a parent directory. | Restore the documented owner, group, and least-privilege modes for the actual hosting model. |
| Editing WordPress before reading logs | A pre-PHP 403 is not caused by a plugin or theme. | Capture the web-server error at the failure timestamp first. |
Deleting .htaccess permanently |
May hide a rewrite problem and break permalinks or multisite routing. | Back it up, rename it briefly for diagnosis, then regenerate the minimal rules. |
Setting AllowOverride All everywhere |
Allows unnecessary per-directory directives and can weaken server control. | Permit only the override classes required by the site. |
| Disabling a sensitive-file block | Exposes files that the host intentionally protects. | Confirm whether the requested filename is supposed to be denied. |
| Restarting without checking configuration | A syntax error can take additional sites offline. | Run the server’s configuration test, then reload or restart through the supported method. |
A complete recovery sequence
Use this order when several sites are down:
- Confirm scope: test home, static, admin, and permalink URLs on at least two domains.
- Capture evidence: record timestamps, response headers, and the exact error-log lines.
- Check shared access: inspect vhost roots, parent-directory search permission, owner/group, ACLs, and the Apache/Nginx service identity.
- Repair narrowly: use the host’s supported permission-repair method or apply the documented owner/group change; do not make the tree world-writable.
- Validate server configuration: confirm the vhost,
<Directory>rules, override policy, rewrite support, and syntax. - Reload and retest: repeat the same URLs and compare new log entries.
- Branch by scope: for one site, compare its local files and vhost with a working site; for pretty URLs, regenerate rewrites; for one client network, investigate WAF or CDN policy.
- Escalate with evidence: provide the provider the domains, UTC timestamps, requested paths, log excerpts, recent changes, and whether static files also fail.
What to preserve after service is restored
- Keep a backup of the working vhost and
.htaccessconfiguration. - Document the expected document root, owner, group, service account, and permission model for each subscription or network.
- Record whether the network is subdirectory or domain-based and which domains map to it.
- Monitor for recurrence after automated panel updates, migrations, domain additions, or security-policy changes.
- Remove temporary diagnostic files and restore any deliberately renamed configuration after testing.
When to contact the host or server administrator
Escalate immediately when all domains fail, you cannot read the error log, the document roots are managed by a control panel, or the fix requires changing a shared vhost, service account, ACL, or provider firewall. Give the administrator reproducible tests and timestamps rather than only the browser wording. That lets them distinguish a filesystem denial from an Apache override issue, an intentional security block, or a network policy.
The central rule is simple: a simultaneous 403 is normally a web-server or hosting access problem first. Fix the layer that emitted the response, preserve least privilege, and only then adjust WordPress rewrites or application settings.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
