cPanel 403 Forbidden? Fix File & Folder Permissions Fast

You open your site and instead of your homepage you get a plain “403 Forbidden — You don’t have permission to access this resource” page. Or you try to edit a file in cPanel’s File Manager and it just won’t save. Nine times out of ten, this comes down to file and folder permissions — and it’s a five-minute fix once you know what to look for.

Symptom: what a permissions-related 403 actually looks like

A permissions issue can show up in a few different ways, and it helps to know which one you’re dealing with:

• The whole site returns 403 Forbidden in the browser, with no PHP error at all.
• Only one page or one image is broken, everything else loads fine.
• cPanel File Manager shows a red padlock icon or refuses to open/save a file.
• WordPress admin loads, but uploading media or updating a plugin fails silently.
• Your error log (cPanel → Metrics → Errors) shows lines like client denied by server configuration or Permission denied.

All of these point to the same root cause: Apache (or the PHP handler) isn’t allowed to read a file or list a directory because the permission bits, or the file ownership, are wrong.

Cause: how permissions get broken in the first place

Permissions rarely break on their own. Usually one of these happened:

• A zip extract or migration tool set files to 777 or 000 instead of the standard values.
• An FTP client uploaded new files with the wrong default mask (some tools default to 644 for folders too, which breaks directory listing).
• A backup restore brought back files owned by a different cPanel user than the one currently running the account.
• Someone chmod’d a whole tree to 777 to “fix” an upload error — this actually makes things worse, because most hosts (including Getwebup) run mod_security/suPHP rules that block execution of world-writable files as a security measure.

That last point trips up a lot of people. Setting everything to 777 feels like it should fix permission errors, but on a properly hardened server it does the opposite — Apache will refuse to serve files it considers insecure.

Fix: the permission numbers that actually work

Linux permissions are three digits: owner, group, world. For shared/VPS hosting under cPanel, stick to this standard:

Fixing it through cPanel File Manager (no terminal needed)

1. Log in to cPanel → File Manager.
2. Navigate to public_html (or your domain’s document root).
3. Right-click the folder, choose Change Permissions, and set it to 755. Do NOT tick “Recurse into subdirectories” yet — folders and files need different values.
4. Select all files in the root (Ctrl+A), right-click → Change Permissions → set to 644.
5. For subfolders, repeat step 3 one level at a time, or use the terminal method below if you have SSH access — it’s much faster for large sites.

Fixing it via SSH (faster for big sites)

If your Getwebup plan includes SSH access, this pair of commands resets an entire WordPress install in one shot. Run it from inside public_html:

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

Want to confirm the current state before you change anything? Run ls -la inside public_html first — the permission string on the left (like drwxr-xr-x for a folder or -rw-r--r-- for a file) tells you exactly what’s set right now, so you’re not guessing.

That’s it — no recursive 777, no guesswork. The two find commands separate directories from files automatically so each gets the right permission class.

Check ownership too, not just permissions

Permission numbers only matter if the ownership is correct. If a backup restore or a migration script left files owned by root or by a different cPanel account, Apache running as your user still can’t touch them even with 644/755 set. Fix ownership with:

chown -R youruser:youruser public_html/

Replace youruser with your actual cPanel username — you can find it in cPanel’s top-right corner or under Account Information. On shared hosting you generally won’t have root to run chown yourself; open a support ticket and we’ll fix ownership from the backend in a couple of minutes.

Prevention: stop this from happening again

• Never chmod 777 as a first fix. If something isn’t writable, find out why before opening it up — it’s almost always the wrong ownership, not the wrong number.
• Set your FTP client’s default upload permissions to 644 for files and 755 for folders (FileZilla: Transfer Settings → “Apply to files/directories”).
• After every migration or restore, run the two find commands above once as a matter of routine — it takes seconds and rules out permissions as a suspect.
• Keep wp-config.php at 600/640. It’s the single file attackers scan for first if it’s left world-readable.
• Check mod_security logs if a 403 shows up right after you edit .htaccess — sometimes it’s a blocked rule, not a permission problem, and the fix is different (a rule exception, not a chmod).

If you’ve set 755/644 correctly and ownership matches your cPanel user but the 403 is still there, it’s worth ruling out a mod_security rule or a stray Deny from all line in .htaccess before digging further. On Getwebup hosting, our support team can pull the Apache error log for your domain and tell you exactly which line is triggering the block — just open a ticket with the URL that’s failing.