How to Use the File Permissions Checker to Fix 403 Forbidden Errors

A "403 Forbidden" error is one of the more confusing messages a website owner can encounter — your site was working fine, and suddenly a page (or the whole site) refuses to load, with no obvious explanation. Very often, the cause is incorrect file or folder permissions. StackCP includes a built-in File Permissions Checker that scans for exactly this kind of issue and fixes it for you.

What Causes a 403 Forbidden Error?

Every file and folder on your hosting account has a set of permissions controlling who can read, write to, or execute it. Web servers rely on specific, recommended permission levels to serve your content correctly and securely. When a file or folder's permissions are set incorrectly — too restrictive, or in some cases too permissive in a way that trips a security check — the server may refuse to serve it, resulting in a 403 Forbidden error for visitors trying to access that page.

This can happen for a number of reasons: a manual permissions change gone wrong, a file uploaded via a script or tool that sets permissions differently than expected, or a migration from another host with different default conventions.

Step 1: Open the File Permissions Checker

1. Log in to StackCP.
2. Go to Manage Hosting, then select Manage on the affected hosting package.
3. Select the File Permissions Checker icon.

Step 2: Run a Scan

Select Scan Permissions to begin. The tool checks your files and folders against StackCP's recommended permission settings.

Step 3: Review the Results

If any files or folders are found with permissions that differ from the recommended settings, they're presented in a list showing:

• The current permission level.
• The recommended permission level.

This gives you a clear, side-by-side view of exactly what's misconfigured, rather than needing to inspect files individually to spot the problem yourself.

Step 4: Fix the Issues

You have two options:

• Fix Selected — select multiple flagged files/folders and correct them all in a single action.
• Fix Permission — correct an individual file or folder one at a time, useful if you want to review and address issues individually rather than in bulk.

Step 5: Confirm the Error Is Resolved

After fixing the flagged permissions, revisit the page that was previously showing the 403 error and confirm it now loads correctly. If the issue persists, it's worth checking your access/error logs (covered in a separate guide) for more specific detail, since a small number of 403 errors can stem from causes other than file permissions — such as directory indexing settings, IP blocking rules, or a .htaccess rule explicitly denying access to that specific file or folder.

Understanding Permission Notation (Optional but Useful)

If you want to understand what the numbers and letters mean rather than just trusting the tool's recommendations:

• Permissions are commonly shown in numerical notation (e.g., 755, 644) or alphabetical notation (e.g., rwxr-xr-x).
• Each permission controls Read, Write, and Execute access, separately for the file's owner, group, and everyone else.
• As a general (not universal) convention on web hosting, folders commonly use 755 and files commonly use 644 — though the File Permissions Checker's specific recommendations for your account are the authoritative reference to follow, rather than relying on general conventions alone, since exact recommended values can vary by hosting configuration.

You don't need to memorize this to use the tool effectively — it's included here simply to demystify what "current" and "recommended" actually refer to in the scan results.

When Permissions Issues Are Likely to Happen

A few common scenarios where you might want to proactively run a scan, even without an active 403 error:

• After migrating a site from another host, since permission conventions can differ between hosting environments.
• After manually adjusting permissions yourself via the File Manager (see our companion guide) for a specific reason, then wanting to confirm you haven't inadvertently affected something else.
• After restoring a backup, particularly one created outside StackCP's own Backup/Restore tool, where permission metadata may not have transferred as expected.
• After a bulk file upload via FTP or a script, where the uploading tool's own default permission settings might not match StackCP's recommendations.

Common Mistakes Beginners Make

• Manually guessing at permission values instead of using the checker. Since the checker compares directly against StackCP's actual recommended settings, it removes the guesswork entirely.
• Assuming every 403 error is a permissions issue. While permissions are a common cause, also consider directory indexing settings, .htaccess rules, or IP/country blocking configured via the Block Visitors tool if the checker doesn't find or fix the issue.
• Not re-scanning after a bulk fix, to confirm nothing was missed or newly introduced by a subsequent change.

Troubleshooting

"I ran Fix Selected but the error is still showing." Clear your browser cache or test in a private/incognito window, since a cached version of the error page can persist briefly after the underlying fix. If it still doesn't resolve, check your access/error logs for a more specific cause.

"The scan didn't flag anything, but I'm still seeing a 403 error." The cause may not be permissions-related — check for a .htaccess rule explicitly denying access, an active IP or country block via the Block Visitors tool, or directory indexing settings affecting that specific path.

"I'm not sure which files to select for a bulk fix." It's generally safe to select all flagged items and use Fix Selected, since every item shown has already been compared against StackCP's own recommended settings — you're not guessing, just applying the tool's verified recommendation.

A Worked Example

Imagine you've just migrated a WordPress site from another hosting provider using a manual file transfer via FTP. Everything appears to have copied over correctly, but when you visit certain pages, you get a 403 Forbidden error, while other pages load fine. This pattern — some content working, some not — is a classic sign of inconsistent permissions carried over from the previous host's different conventions, rather than a single global problem.

Running a scan in this scenario typically surfaces a handful of specific files or folders (often within wp-content or a specific plugin's directory) where the permission level doesn't match StackCP's recommendations. Selecting Fix Selected corrects all of them in one action, and revisiting the previously broken pages usually confirms the issue is resolved immediately.

Why This Matters More Than It Might Seem

For a non-technical site owner, a 403 error with no visible cause can be genuinely stressful — nothing in the visible content changed, yet the site (or part of it) stopped working. Understanding that file permissions are a common, fixable cause — and having a tool that diagnoses and corrects it without needing to understand the underlying technical detail — turns a potentially confusing troubleshooting process into a two-click fix. It's worth remembering this tool exists specifically for this scenario, since it's easy to assume a website error requires developer help when, in many cases, it doesn't.

Permissions in the Context of Your Wider Security Setup

It's worth briefly connecting this tool to the broader security picture covered elsewhere in this series. Incorrect permissions aren't just a functional problem (a 403 error visitors see) — overly permissive settings can, in some circumstances, make it easier for a compromised file to affect others around it. Running the File Permissions Checker periodically, alongside the Malware Scan tool and sensible use of the File Manager's permission controls, forms a small but genuinely useful part of keeping a website both functional and reasonably secure, without requiring deep technical expertise to maintain.