Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If several WordPress domains suddenly show “You do not have permission to access this resource” or a 403 Forbidden response, start outside WordPress. The web server is usually refusing the request before PHP runs. Check the server error log at the failure time, then inspect permissions and ownership on the shared virtual-host or document-root directories. If only one URL, one site, or one visitor is affected, use a narrower branch: that site’s .htaccess, virtual-host rules, rewrites, or a security policy.
What the message means
“You do not have permission to access this resource” is the standard wording shown in an Apache HTTP Server 2.4 error example. In practical terms, the server has decided that the request is not allowed to reach the requested resource. A 403 can therefore be generated before WordPress, a plugin, or a theme executes.
Apache’s directory configuration controls whether a request can enter a directory and whether a per-directory .htaccess file is read. The AllowOverride setting determines which groups of directives are permitted in that file. With AllowOverride None, Apache ignores .htaccess files; with restricted override classes, some directives may be rejected or unavailable. A host can also deny a request in a virtual-host rule, an Nginx rule, or a web-application firewall.
Plesk documents the same symptom when Apache cannot read a virtual-host or document-root .htaccess file. Its all-domain example includes the error pcfg_openfile: unable to check htaccess file, indicating that the Apache service lacks the required access to the virtual-host or httpdocs directory.
First, classify the failure
Do this before changing files. The pattern tells you whether to investigate a shared server layer or a single WordPress installation.
| What you observe | Most likely branch | First place to look |
|---|---|---|
| Every domain and every tested path returns 403 | A shared virtual-host or document-root access problem, service-user access failure, parent-directory search permission, or provider-wide policy | Common parent directories, ownership and group membership, web-server error log |
| Only one domain fails | That domain’s virtual host, document root, ownership, or local .htaccess |
Compare its configuration and permissions with a working site |
| Home page works but pretty URLs fail | Rewrite handling or .htaccess override policy |
Apache overrides, rewrite configuration, and WordPress permalink rules |
Only wp-admin fails |
A path-specific rule, access-control policy, or permissions issue | The request-specific log entry and rules affecting wp-admin |
Only names such as readme.html or wp-config.php fail |
An intentional hosting security block may be working as designed | Generated Nginx/Apache security rules and the exact requested filename |
| Only one visitor, IP address, or network fails | CDN, WAF, reputation, or access-control policy | Provider or edge-security logs for that client |
Run a safe five-minute triage
- Test more than one domain. Use at least two affected domains if you have them. On each, request the home page, a harmless static file that should be publicly readable, and
/wp-admin/. Record the exact status and timestamp. This distinguishes a universal denial from a rewrite or path-specific failure. - Test from a second connection. A different network or device helps identify a client-specific block. If only one network fails, do not begin by changing WordPress file modes; obtain the CDN, WAF, or host access-policy log.
- Read the web-server error log at that timestamp. Look for permission-denied messages, inability to check
.htaccess, the affected virtual host, and the requested path. The Plesk all-domain example’spcfg_openfileentry is especially significant because it points to server access to the directory or file, not to a WordPress setting. - Check whether the sites share a parent. After a migration or a domain addition, several document roots may sit beneath one directory whose owner, group, or mode changed. The web-server account needs search (execute) permission on every parent directory and read access to files it must serve.
- Compare a failing site with a working site. Compare the virtual-host definition, document-root path,
.htaccess, ownership, group, directory modes, rewrite settings, and security rules. Change only the difference that explains the logged denial, and keep a backup of shared configuration first.
When every WordPress site fails
Simultaneous failure is the strongest clue that the fault is above an individual installation. Prioritize the shared virtual-host and filesystem path before editing WordPress.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check the shared directory path
Trace each affected document root upward to its parent directories. A directory can appear correctly configured while a parent lacks execute/search permission for the web-server service account. That prevents Apache or Nginx from entering the directory and can produce a 403 for every domain beneath it. Check the account’s effective group membership as well as the owner and group shown on each directory.
Check service-user access to virtual hosts
The account running the web server must be able to inspect the virtual-host directory and read the files needed to answer requests. After a move, restore, or bulk ownership change, the files may belong to the account used for deployment while the service account no longer has the required group or access. Use the hosting provider’s documented ownership and permission repair procedure rather than applying a blanket mode change.
Check the error log before restarting
Restarting can hide the timing of the original failure and does not repair ownership. Preserve the log entry, identify the exact path named in it, correct the relevant access issue, and then reload or restart the web server using the host’s supported method. Confirm the result on more than one domain and on all three test paths.
Consider a provider-wide policy
If directory access is correct and all domains still fail, ask the host whether a global Apache, Nginx, WAF, or account policy changed. A provider may have tightened access to a parent directory or deployed a rule to multiple virtual hosts. The provider’s server-side logs are required to confirm that branch.
When only one site or URL fails
Compare the local .htaccess
Copying an old file during a migration can introduce a rule that denies a path or uses a directive not allowed by the current host. Compare the failing file with a known-good WordPress file from the same hosting model. Temporarily move the suspect file out of the document root only if you have a backup and a provider-approved recovery plan; then test a harmless static file before restoring or rebuilding rewrite rules.
Inspect virtual-host directory rules
A virtual-host <Directory> block can deny access independently of WordPress. Confirm that the block targets the actual document-root path and that it does not apply a deny rule inherited from a parent. Apache’s AllowOverride setting also matters: if it is None, changing .htaccess cannot affect the request; if override classes are limited, a rewrite or access directive may be rejected.
Rank #3
Separate rewrites from basic access
If a static file and the home page work but a pretty permalink fails, the filesystem is probably readable and the rewrite chain is the useful lead. Verify that the required rewrite module and server configuration are enabled, that .htaccess is actually processed, and that WordPress permalinks were regenerated after the move. Do not treat a rewrite-only failure as evidence that every file needs a new permission mode.
Repair permissions without creating a security hole
There is no universal WordPress mode that fits every host. WordPress’s permission guidance says files should normally be owned by the account that manages the installation, while .htaccess must be readable by the web server when rewrite features use it. The correct owner, group, and mode depend on whether the host uses a separate service account, a shared group, or a suexec-style model.
Recommended Free Tools
| Item | General guidance documented by WordPress | Qualification |
|---|---|---|
| Directories in suexec examples | 755 or 750 |
Use only when those modes match the host’s service-account and group model |
| Regular files in suexec examples | 644 or 640 |
The web server still needs the required read access |
wp-config.php |
440 or 400 |
Tighten it only if the hosting model and management workflow support that access |
| Any directory, including uploads | Never 777 |
World-writable directories let other users or compromised processes alter site data |
Use the least change that fixes the logged denial
- Correct the owner or group when the service account has no legitimate access.
- Restore search permission on parent directories when the log points to an inaccessible path.
- Make only the required files readable by the web server; do not make the whole installation world-writable.
- Confirm that
.htaccessis readable if Apache rewrite features depend on it. - Back up shared configuration and record the original values before changing them.
WordPress explicitly warns that recursively applying 777 is unsafe, including on upload directories. A broad chmod may make the symptom disappear while allowing another account or a compromised process to modify PHP code. If you cannot identify the service account or the host’s expected group, stop and ask the provider to apply its documented repair method.
Check WordPress Multisite routing
WordPress Multisite lets several WordPress instances run within one installation. The WordPress Developer Resources handbook, updated July 7, 2025, documents both path-based networks and domain or subdomain-based networks. A domain change can therefore break routing even when the files themselves are readable.
Identify the network type
Determine whether the network uses subdirectories or domains/subdomains. The requested host must map to the intended network, and the server must send that host to the installation’s document root. A domain pointed at the wrong root can expose a different configuration or trigger a server-level denial.
Verify rewrites
Multisite relies on rewrite rules to route site paths and administrative URLs. Confirm that the web server’s rewrite support is enabled, that its override policy permits the required directives, and that the network’s generated rules match the current path or domain model. Test the network home page, a known site path, and /wp-admin/ separately.
Check domain mapping after a move
When domains were added or changed, compare the mapped domain, virtual-host document root, and network configuration. A mismatch can make every URL on one mapped domain fail while the original network domain still works. Fix the mapping at the layer where the mismatch appears instead of changing permissions on unrelated sites.
Recognize intentional hosting 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 protection rather than evidence of a broken installation.
Check the exact requested filename and the active virtual-host configuration before disabling such a rule. Plesk warns that turning off the measure reduces WordPress security. A successful home page combined with a 403 only for one of these sensitive names is not the same failure as a 403 on every path.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When the block affects only one visitor
A denial limited to one IP address, network, or client usually points away from local WordPress permissions. Investigate the CDN, web-application firewall, IP reputation service, or an access-control policy. Capture the client IP, timestamp, host name, and URL, then request the provider’s edge and origin logs. Do not weaken filesystem permissions to solve a policy decision made before the request reaches the server.
Recovery sequence after a migration or domain change
- Preserve evidence. Save the exact response, URL, client network, and timestamp. Keep a copy of the current virtual-host and
.htaccessfiles. - Establish scope. Test two domains, a static file, the home page, and
/wp-admin/. Record which combinations fail. - Read the matching log entry. Use the web-server log, not only the WordPress dashboard. A 403 can occur before PHP and leave no WordPress application entry.
- Repair shared access first. For an all-domain outage, verify parent-directory search permission, virtual-host and document-root ownership, group membership, and service-user access.
- Repair local configuration second. For a single-site outage, compare the site’s virtual host, document root,
.htaccess, rewrites, and security rules with a working site. - Validate Multisite mapping. Confirm the network type, domain or path mapping, and rewrite rules when several sites share one installation.
- Reload safely and retest. Use the host’s supported reload or restart procedure, then repeat every test from the first step.
Common mistakes that make the outage worse
- Editing WordPress first: A server-generated 403 may occur before WordPress runs, so plugin and theme changes cannot correct it.
- Recursively setting
777: This grants write access to other users and compromised processes and violates WordPress’s security guidance. - Deleting
.htaccesswithout a backup: You can lose network or permalink rules and make diagnosis harder. - Disabling generated security rules: A deliberate block on sensitive files may be protecting configuration and documentation files.
- Changing only the visible site: If multiple domains fail, the shared parent or service account is a more efficient lead than repeating local edits.
- Ignoring parent directories: Correct file modes cannot help when the web-server account cannot search an ancestor directory.
When to contact the host or server administrator
Escalate when you do not control the virtual-host configuration, cannot identify the web-server service account, or the error log shows a provider-level policy. Include the affected domains, paths, timestamps, client network, the exact 403 text, and the relevant log lines. Ask the administrator to check service-user access to each virtual-host and document-root parent, AllowOverride and <Directory> policy, generated security rules, and any CDN or WAF decision.
A useful escalation distinguishes the branch: “all domains and all paths,” “one domain,” “pretty URLs only,” “sensitive filenames only,” or “one visitor.” That description directs the administrator to the shared filesystem, local configuration, rewrite handling, intentional security block, or edge policy respectively.
Quick Recap
Key points to retain
- A 403 permission message is commonly emitted by the web server before WordPress PHP executes.
- When several sites fail at once, investigate shared virtual-host and document-root access before individual WordPress files.
.htaccessmatters only when Apache is configured to read it and permit its directives.- Use the least-privilege owner, group, and modes that fit the hosting model; never make the installation world-writable.
- Multisite needs correct domain or path mapping plus working rewrites.
- A 403 for a sensitive filename may be an intentional hosting security control.
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.
