How to fix "permission denied" errors

A "permission denied" message — whether it's an FTP client refusing to upload, a script failing to write a file, or a page returning a 403 Forbidden — means the server checked who was asking for access to a file and correctly said no. This is the server working as designed, not a fault. The fix is to grant the specific access that's actually needed, not to remove the check.

How permissions actually work

Every file and folder on a Linux server — which is what almost all web hosting runs on — carries a permission value made up of three digits, one each for the file's owner, the group it belongs to, and everyone else. Each digit is a number from 0 to 7 representing some combination of read, write and execute access.

A small number of specific files are an exception — wp-config.php, for instance, is sometimes tightened to 600 or 640 because it contains database credentials and doesn't need to be readable by anything except the owner.

Where this shows up, and what it means in each case

An FTP upload fails with "permission denied"

The destination folder's permissions don't allow your FTP user to write into it. Check the folder is set to 755, and confirm the FTP account you're using is the correct owner for that account — a developer or secondary FTP account without the right ownership can be refused even when the permission value itself looks correct.

A page returns 403 Forbidden

The web server tried to read a specific file to serve it and was refused. Check that file's permissions are 644 (or 755 if it's a folder being browsed directly). This is distinct from a 403 caused by an .htaccess rule deliberately blocking access — if the permissions look correct, check .htaccess next.

A script can't write a file — uploads, cache files, logs

PHP scripts need a folder to be writable in order to save something into it — an upload directory, a cache folder, a log file. If the folder is set to a stricter value than 755, or is owned by a different user than the one PHP runs as, the write fails silently or with an explicit permission error in the log.

A CMS update or install fails, citing permissions

Installing plugins, themes or core updates requires writing new files into existing folders. If those folders are too restrictive, the install stalls partway or asks for FTP credentials to complete manually. Confirm the relevant content folders are 755 and their files 644.

Checking and changing permissions

1. Open the file manager in your control panel

   Most file managers show the current permission value alongside each file and folder, or reveal it in a right-click properties menu.

2. Identify the specific file or folder causing the error

   The error message or log entry usually names it directly — use that rather than guessing.

3. Set folders to 755 and files to 644

   Most file managers offer a numeric permissions field where you can type the value directly.

4. Apply recursively only when you mean to

   A "apply to all subfolders and files" option is useful for fixing a whole directory tree at once, but be certain you want every file in that tree changed before using it — it will also reset any file that was deliberately set differently.

If correct permissions don't fix it

Two things worth checking next: whether the file or folder's owner matches the account the web server or your FTP user runs as — correct permission numbers on a file owned by the wrong user still fail — and whether a security module or .htaccess rule is blocking the request independently of file permissions altogether.

If you've confirmed the permission values are correct and it's still failing, send support the exact file or folder path and the error message. Ownership issues in particular are often easiest to confirm and correct from the server side.