Fix cPanel File Manager 403 & Permission Errors

You open your site and instead of your homepage, you get a bare "403 Forbidden" — no styling, no logo, just an error and a horizontal rule. Or maybe you're inside cPanel's File Manager trying to edit a file and it won't save, won't delete, won't do anything except throw a permission error at you. Both problems usually trace back to the same root cause: file and folder permissions that got changed, either by a bad plugin, a sloppy migration, or an overcautious "security fix" someone ran once and forgot about.

Here's how to find the broken permissions, fix them safely, and stop them from creeping back.

Symptom: What a Permissions 403 Actually Looks Like

There are two common flavors of this problem, and it helps to know which one you're dealing with before you touch anything.

• Site-wide 403 Forbidden — the whole domain returns 403 the moment you load it. This usually means the document root folder itself, or index.php/index.html inside it, has permissions the web server can't read.
• File Manager won't let you edit/save/delete — you're logged into cPanel, you open File Manager, and actions on specific files fail with "Permission denied" or just silently do nothing. This is usually ownership or permission mismatch on individual files, often after an FTP upload from a different tool or a restored backup.

Less commonly, you'll see a 403 only on specific pages or subfolders (like /wp-admin or an uploads directory) — that's almost always a folder-level issue rather than the whole site.

Cause: Why Permissions Break in the First Place

A handful of things cause this over and over:

• FTP client uploaded with wrong defaults. Some FTP clients preserve permissions from your local machine or apply their own defaults (like 644 for everything, including folders that need 755).
• A "security hardening" script went too far. Running chmod -R 000 or 644 recursively on an entire site is a common overcorrection after a hack scare — it locks the server out along with everyone else.
• Restoring from a backup made on a different server. Ownership (the user:group a file belongs to) doesn't always survive a restore cleanly, especially across different hosting environments.
• A plugin or script wrote files as the wrong user. If a cron job or script ran under a different system user, files it creates may not be readable by your main account.
• .htaccess rules blocking access. Not strictly a "permission" in the Unix sense, but it produces the exact same 403 symptom, so it's worth ruling out early.

Fix: Step by Step

Step 1 — Rule Out .htaccess First

Before touching any permissions, rename .htaccess in your document root (usually public_html) to something like .htaccess-bak using File Manager, then reload the site. If the 403 disappears, the problem is a bad rule inside .htaccess, not permissions — restore the file and edit the offending Deny/Require line instead of proceeding further.

Step 2 — Check the Correct Permission Values

Unix permissions on shared hosting follow a strict convention. Getting this wrong in either direction — too open or too closed — causes problems (too open is a security risk cPanel's own security scanner will flag).

If you see 777 anywhere on your site, fix it — that's world-writable and one of the first things a security scan (and an attacker) checks for.

Step 3 — Fix It Through cPanel File Manager

Log into cPanel > File Manager, navigate to public_html, right-click the folder or file, and choose Change Permissions (or Permissions depending on theme). Enter the numeric value from the table above. For a single folder, tick "Recurse into subdirectories" carefully — only do this if you're confident every file inside should get the same value, since recursing 755 onto files will make them executable when they shouldn't be.

Step 4 — Fix It via SSH (Faster for Bulk Fixes)

If you have SSH access, this is the safer and faster way to fix permissions in bulk without accidentally setting files to 755 like folders:

cd ~/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

This applies 755 only to directories and 644 only to files in one pass — exactly what you want, with no manual guesswork.

Step 5 — Check Ownership, Not Just Permissions

Permissions can be perfect and you'll still get a 403 if the file is owned by the wrong user. Run:

ls -la public_html/

The owner should match your cPanel username, and the group is usually the same or nobody/nogroup depending on your server's PHP handler. If ownership looks wrong (e.g., a numeric UID instead of your username, or a completely different account name), that's usually from a restore or migration — contact your host to have it corrected rather than guessing with chown, since getting it wrong can lock you out of your own files.

Prevention: Stop This From Happening Again

• Never run a blanket chmod -R 777 "just to make an error go away." It works by accident and creates a real security hole.
• Use SFTP, not plain FTP, and check your client's upload permission defaults before a big upload — most clients let you set default folder/file permissions in the connection settings.
• Run cPanel's built-in permission checker. Under Security in cPanel, some hosting setups include a "File Permissions" or ModSecurity audit tool that flags world-writable files.
• Keep a clean backup before mass edits. If you're about to recurse a permission change across your whole site, take a File Manager backup first — it's one click and saves you from an all-day cleanup if something goes wrong.
• After any migration or restore, spot-check permissions on wp-config.php, .htaccess, and your uploads folder specifically — these three are the most common casualties.

Frequently Asked Questions

Why does my site show 403 only on images or the uploads folder, not the whole site?

That's a folder-specific permission issue — the uploads directory itself, or files inside it, likely got set to something the web server can't read (often 600 or 700 after a restrictive backup restore). Fix that folder specifically with 755 for the directory and 644 for the files inside it.

Is it safe to set everything to 755 to make the error go away faster?

No — setting 755 on files (not just folders) makes them executable, which is unnecessary and increases your attack surface if any of those files can be reached directly by URL. Use 755 for directories and 644 for files, not one value for everything.

I fixed the permissions but I'm still getting 403. What else could it be?

Check for a leftover Deny from all or Require all denied rule in .htaccess, an IP block set in cPanel's IP Blocker, or a security plugin (like Wordfence) that's misfiring. Also confirm there's actually an index file in the folder — an empty directory with no index.php or index.html and directory listing disabled will also return 403.

Can I use File Manager's "Change Permissions" for the whole site at once?

You can, but it applies one numeric value to everything you select, which is wrong for a mixed folder/file tree. It's fine for a single file or a folder where you deliberately want uniform permissions; for a full-site fix, SSH with separate find commands for directories and files is safer and faster.

What permission should wp-config.php have?

640 or 600 is best. It contains your database credentials in plain text, so there's no reason for anything other than your own account (and possibly the web server group) to read it. Avoid 644 here even though it's the "default" for regular files.