Linux File Permissions for Web Hosting: 644, 755 and Beyond
Wrong file permissions are a common cause of hacked sites. Learn how Linux permissions work, safe values for web files, and how to fix permission errors.
On a Linux web server, every file and folder has permissions that control who can read it, change it or run it. Get them right and a compromised script can do limited damage. Get them wrong, for example by giving every file full access to everyone, and any vulnerable plugin can overwrite your whole site. Permissions are also behind many "403 Forbidden" and "cannot upload" errors, so it pays to understand them.
The basics: owner, group, others
Each file has an owner, a group and permissions for three classes of user: the owner, members of the group, and everyone else. For each class there are three permissions:
- Read (r): view the contents of a file, or list a folder.
- Write (w): change a file, or add and remove files in a folder.
- Execute (x): run a file as a program, or enter a folder.
When you list a directory with ls -l you see something like -rw-r--r--. The first character is the type (a dash for a file, d for a directory), followed by three triplets for owner, group and others.
Numeric values
Permissions are usually written as three digits. Each digit is the sum of read (4), write (2) and execute (1).
| Number | Meaning | Typical use |
|---|---|---|
| 644 | Owner read and write; group and others read only | Regular web files: HTML, PHP, CSS, images |
| 755 | Owner full access; others read and execute | Directories and scripts that must be run |
| 600 | Owner read and write only | Private files such as keys and some configuration files |
| 640 | Owner read and write; group read | Config files when the web server shares the group |
| 777 | Everyone can read, write and execute | Almost never. Avoid it. |
Why 777 is dangerous
Setting a folder to 777 is a common "fix" suggested for upload errors. It makes the folder writable by every account and process on the server that can reach it. On hosting platforms with isolation between accounts the risk is reduced, but a vulnerable plugin on your own site can still write malicious files into a 777 folder. If something says you must use 777, the real problem is almost always the wrong file owner.
Ownership: the usual real cause
Many permission problems come from files owned by the wrong user. If you upload files over SFTP as your account user but the web server runs scripts as a different user, uploads or updates can fail. If a root-level process created files in your site, your account may not be able to change them. On hosting platforms such as Plesk, PHP typically runs as the subscription's own system user, which means correct ownership and moderate permissions work without opening anything to everyone. If you need to correct ownership on a VPS you manage, the command is chown, and the support team can help if you are not sure; the knowledge base has step-by-step guides.
Recommended values for WordPress
- Directories:
755 - Files:
644 wp-config.php:640or600, depending on your server's setup, since it holds database credentials.- Do not make
wp-content/uploadsexecutable for PHP files. Where you can, configure the server to refuse to run PHP in the uploads folder.
To apply these recursively on a server where you have shell access, use the find command with chmod:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Run this only inside your site's folder, never at the root of a server, and take a backup first.
Principle of least privilege
Give every file the minimum access it needs. Code should usually not be writable by the web server at all, and only specific folders, such as uploads and cache, need write access. Some security-conscious setups make core files read-only and let updates run through a controlled process. The tradeoff is that automatic updates might need extra setup.
Protect sensitive files
- Keep backups, database dumps and logs outside the public web root, or deny web access to them.
- Do not leave files like
.env,.git,phpinfo.phpor old.ziparchives in public folders. - Deny directory listing, so visitors cannot browse folder contents.
- Protect configuration files with server rules, not just permissions.
Fixing common errors
- 403 Forbidden on a file: check that the file is readable (644) and its folder executable (755).
- 500 error after upload: a PHP file with 777 or a folder writable by others can trigger a block under some server settings. Reset to 644 or 755.
- Cannot upload or update: check the file owner matches the user PHP runs as.
- Permission denied via SFTP: the folder belongs to another user, so correct the ownership.
Special permission bits
Beyond the three digits you may see a fourth, leading digit or letters like s and t. The setuid and setgid bits make a program run with the permissions of its owner or group, and the sticky bit on a folder stops users deleting files they do not own. These are system-level features, and web content almost never needs them. If you find a setuid file inside a website folder, treat it as suspicious.
Umask: where default permissions come from
New files get their permissions from a setting called the umask. A common umask of 022 produces 644 files and 755 folders, which is what you want for most web content. If uploads or generated files regularly arrive with odd permissions, the cause is often the application or the process that created them, not your habit. Check the settings of your deployment script or FTP client, which may apply its own default permissions to uploaded files.
Where to set it
In Plesk, the File Manager lets you change permissions and view ownership without a terminal, and every Zebra Hosting Cloud hosting plan includes it. See the VPS plans if you want full shell access and control of file ownership.
