A website can appear perfectly healthy one minute and return a 403 Forbidden error the next. Often, the cause is not the application, database or web server. It is Linux file permissions: the rules that decide who can read, change or run each file on your hosting account.

Getting them right protects customer data, prevents accidental changes and gives your website the access it needs to operate. Getting them wrong can expose configuration files, stop uploads working or leave a site inaccessible. The good news is that most website owners only need to understand a small set of sensible defaults and when they should be adjusted.

How Linux file permissions work

Every file and directory on a Linux server has three permission types: read, write and execute. These permissions are set separately for three groups: the file owner, the group, and everyone else.

Read allows someone to view a file’s contents. Write allows them to edit or delete it. Execute allows a file to be run as a program or script. For directories, execute has a slightly different but vital role: it allows a user or process to enter, or traverse, that directory.

You may see permissions displayed like this:

“`text -rw-r–r– index.php drwxr-xr-x public_html “`

The first character identifies the item. A dash means a regular file, while `d` means a directory. The remaining nine characters appear in three groups of three. In the example above, the owner can read and write `index.php`; the group and other users can read it. For `public_html`, the owner can read, write and enter the directory, while group and other users can read its contents and enter it.

For a typical website, this structure means your hosting user retains control while the web server can access the files required to display the site. The exact arrangement can vary according to the server configuration, particularly on shared hosting, managed WordPress hosting and VPS environments.

Read, write and execute in practice

Permission | Files | Directories — | — | — Read (`r`) | View the file contents | List the directory contents Write (`w`) | Edit or delete the file | Create, rename or delete items within it Execute (`x`) | Run a script or program | Enter and access items in the directory

A directory without execute permission can be confusing. You may be able to see its name in a listing, but neither you nor the web server may be able to access a file inside it. This is why website directories normally need execute permission even when the files they contain do not.

Linux file permissions as numbers

Permissions are commonly set using three digits, such as `644` or `755`. Each digit represents the combined permissions for owner, group and others.

Read has a value of 4, write has a value of 2, and execute has a value of 1. Add the values together to create each digit. Read and write is 6. Read and execute is 5. Read, write and execute is 7.

That makes the usual values easier to interpret:

• `644` means the owner can read and write, while group and others can read.
• `640` means the owner can read and write, the group can read, and others have no access.
• `755` means the owner has full access, while group and others can read and enter.
• `700` means only the owner has any access.

For most public website files, `644` is a sensible starting point. For website directories, `755` is commonly appropriate. These settings allow visitors to load the public parts of the site through the web server without giving every system user the right to alter content.

Do not treat these values as universal rules. A PHP file that is executed directly from the command line may need execute permission, while a PHP file processed by the web server usually does not. A carefully configured server may also use groups, access control lists or a dedicated PHP handler that changes what is required.

Ownership matters as much as permissions

Permission numbers are only half of the picture. Every item also has an owner and a group. If a deployment tool, backup process or FTP client creates files under the wrong account, correct-looking permissions may still fail to solve the problem.

For example, a WordPress update may be unable to write to its uploads directory because that directory belongs to a different user. Changing it to `777` might appear to fix the immediate error, but it introduces a larger security risk and does not address the underlying ownership issue.

On a VPS, an administrator can inspect ownership with:

“`bash ls -la “`

and, where appropriate, correct it with `chown`. This command should be used with care, especially when applied recursively. Assigning an entire website to the wrong system user can prevent the web server, scheduled tasks or deployment processes from working properly.

On shared hosting, customers do not normally have root access or need to manage system-level ownership themselves. If files repeatedly revert to the wrong owner after a migration, restore or application update, contact technical support rather than repeatedly widening permissions.

Safe permission settings for websites

Start with the principle of least privilege: give each file, directory and process only the access it genuinely needs. It is safer than applying broad permissions whenever an application reports an error.

Most standard website installations work well with directories set to `755` and files set to `644`. Private configuration files deserve more care. Database credentials, API keys and application environment files should not be world-readable. Depending on the application and server setup, `640`, `600` or a protected location outside the public web root may be suitable.

A few common scenarios need special attention:

• Upload folders need write access for the account or process handling uploads. They do not normally need to be writable by every user.
• Cache folders may need to be writable because plugins and frameworks generate temporary files there. Limit write access to that specific folder rather than changing the entire site.
• Script files should only be executable where direct execution is required. Making every file executable adds no benefit.
• Backup archives, `.env` files and old installation packages should not sit openly in a publicly accessible directory. Remove them when no longer needed or store them outside the web root.

A setting of `777` gives read, write and execute access to everyone. It is occasionally used as a quick diagnostic step, but it should not be a permanent website setting. On a multi-user system, it can allow other local processes to alter files they should not control. Some hosting platforms actively block it for this reason.

Changing permissions without breaking your site

Most hosting control panels include a file manager that lets you select a file or directory and change permissions through tick boxes or a numeric value. This is often the safest option for straightforward fixes because it makes the target item clear before changes are applied.

If you use SSH on a Linux hosting account or VPS, `chmod` changes permissions. For example:

“`bash chmod 644 index.php chmod 755 public_html “`

Use recursive commands cautiously. A command such as `chmod -R 755 public_html` applies execute permission to every file as well as every directory, which is usually unnecessary. A better approach separates files and directories:

“`bash find public_html -type d -exec chmod 755 {} ; find public_html -type f -exec chmod 644 {} ; “`

Before making bulk changes, take a backup or confirm that your hosting platform has a recent restore point. This gives you a clear route back if an application has non-standard requirements. It is particularly useful for ecommerce sites, membership platforms and custom-built applications, where selected cache, storage or deployment directories may need different access.

Troubleshooting common permission errors

A 403 Forbidden response often points to a directory that lacks the required read or execute access, although server rules and security software can also cause it. A 500 Internal Server Error after changing permissions may mean a script is no longer accessible to the handler that runs it, or that a server configuration file contains incompatible instructions.

If WordPress cannot upload media, install updates or create cache files, check the ownership and permissions of `wp-content`, `uploads`, and any plugin-specific cache directory. Avoid changing core WordPress files unless the error identifies them directly.

A 404 error is less likely to be caused by permissions, but it can occur where the web server cannot traverse a parent directory. Check every directory in the path, not just the file at the end. Also review the server error log where it is available. The log usually gives a more useful explanation than a browser message alone.

When you have migrated a site, compare the affected files with a working area of the same account. If the ownership, permission pattern and file location differ, correct the discrepancy rather than applying broad settings across the whole account.

Build security into everyday hosting tasks

Permissions are not a one-off setup task. New plugins, automated deployments, restores and file transfers can all create new files with unexpected access settings. A sensible maintenance routine checks writeable folders after major updates, removes unused installers and backup files, and keeps credentials out of publicly accessible locations.

Reliable hosting adds useful protection around those habits, including malware scanning, daily backups and support when a server-level issue needs investigation. Blended Hosts customers can use those safeguards alongside sensible file management rather than relying on permissive settings as a workaround.

The best permission setting is rarely the most open one. Give your website the access it needs, keep sensitive files tightly controlled, and investigate the specific cause when something fails. That approach keeps your site easier to maintain and far harder to compromise.