WordPress File Permissions: Safe 644/755 Defaults and How to Fix Errors

You click Update, wait for the usual refresh, and the task stops. A WordPress media upload may be rejected instead, or a 403 or 500 may replace the page you expected. Then WordPress points to a file and asks you to make it writable. You open the file settings and find a three-digit number, with no clear fix.

That is when WordPress file permissions become more than a technical detail. A larger number may expose more of the WordPress site file structure than WordPress needs. A smaller one can stop the right process from reading configuration or writing an update.

You do not need Linux expertise to get unstuck. Keep the failed path in view and treat the warning as a clue: check the mode, owner, PHP account, or server rule. The next sections give a safe baseline, show how to inspect it, and explain when a targeted change is reasonable, or your host should take over.

TL;DR: Start with 644 for ordinary files and 755 for folders, while treating those values as a baseline rather than a universal fix. Before changing anything, create a restorable backup, then check the owner and the account running WordPress.

The common WordPress permission baseline

Use these values as starting points, not a blanket reset:

From a security perspective, the goal is to secure a website from hackers: give the process only the access it needs, and keep other accounts from modifying site files.

🛡️ Note: The safest setting is not always the lowest number. A setting that stops WordPress from reading its configuration or writing a required update is too restrictive for that site.

Never make the entire installation 777. That gives the owner, group, and every other account read, write, and access rights. It can hide an ownership problem and let more server processes modify site files than WordPress needs.

What the three numbers mean

Each number describes access for the owner, the group, and others, meaning every other account:

• Read: 4
• Write: 2
• Access or execute: 1

Add the values for each audience. With 644, the owner can read and change a file, while the group and others can only read it. With 755, the owner can read, change, and enter a folder, while the group and others can read and enter it without changing its contents.

For files, execute can mean run. For folders, it means an account may enter and move through them. A folder is not a program simply because it has this permission.

A WordPress Administrator or Editor is a dashboard role for a person. It does not make that person the owner of the site files, and it does not give the server process permission to read or change a file.

Diagnose the failed action first

The error message is a starting clue, not a complete diagnosis. Before changing a permission number:

1. Decide whether a change is necessary. If the site works and there is no specific problem, leave the permissions alone.
2. Record the exact action, path, and message. Note whether the failure involves a plugin folder, theme, upload folder, temporary folder, configuration file, or rewrite file.
3. Check the mode, owner, and group together. The mode is the number such as 644. The owner and group identify the accounts that receive the first and second sets of rights.
4. Find the account running WordPress. The PHP runtime used by WordPress may use a different account from the one you use in a hosting panel or file-transfer program.
5. Check the server layer if those details look correct. Storage limits, read-only storage, firewall rules, SELinux, a server access-control system, and deployment settings can deny access even when the three numbers look right.

Confirm the backup can be restored, and record the current mode, owner, group, and path before testing.

🔎 Note: A permission change is not a repair plan until you know how you will undo it. Record the original settings before testing a new one.

Inspect the affected path

Hosting File Manager or SFTP

• File Manager: Open the site’s document root, then open the properties for the path named in the error. Record its permissions, owner, and group if they are shown.
• SFTP: Its properties panel usually shows the permission mode and may show ownership. Show hidden files if the problem involves .htaccess.
• Compare accounts: The file-transfer account may differ from the PHP account. A file can be editable in SFTP while WordPress still cannot update it.

SSH

Use SSH only after confirming the site path. This shows the mode, owner, and group:

ls -ld /confirmed/path/to/file-or-folder

Inspect the parent folders too. WordPress must be able to move through each one before reaching the path named in the error.

Apply the smallest safe repair

Use this repair sequence:

• Target only the affected path. In a hosting panel or file client, use the value approved by your host. In SSH, use a mode-change command only when the path and required mode are confirmed.
• Resolve ownership separately. If the owner or group is wrong, ask the host which accounts and ownership model it supports. Names such as www-data, apache, and nobody are examples, not universal answers. Giving the web process ownership of the entire site can increase damage from a compromised process.
• Retest the failed action. Repeat the update, plugin installation, media upload, WordPress permalink reset, or dashboard action itself. A command completing successfully does not prove that WordPress can now perform the required operation.

For a confirmed single path, the targeted SSH forms are:

chmod 644 /confirmed/path/to/file
chmod 755 /confirmed/path/to/folder

Use the mode your host or developer has confirmed for that path. These commands do not repair an owner, group, or server-policy problem.

If a host or developer has approved a controlled reset for a confirmed WordPress root, keep file and folder changes separate:

find /confirmed/path/to/wordpress -type f -exec chmod 644 {} +
find /confirmed/path/to/wordpress -type d -exec chmod 755 {} +

These commands change every matching item below that path. Review hidden settings, cache, deployment-managed files, and host-managed folders first. Do not use them when the document root or PHP execution model is uncertain, and never pair them with a blanket ownership change.

Match the fix to the symptom

Updates, plugin installs, or theme installs fail

Inspect the folder WordPress tried to write to. It may be a plugin destination folder or theme folder, wp-content, a temporary folder, or a host-controlled location. If mode and ownership are correct, ask the host about storage limits, read-only storage, security policies, and the PHP account.

If WordPress asks for connection information during an installation, treat that as another sign to check the filesystem access method, ownership, and hosting configuration. Do not make the whole installation writable because one extension cannot update.

Media uploads fail

Inspect wp-content/uploads and the year-and-month folder where WordPress stores the file. WordPress must access every parent folder; otherwise, it may show a WordPress “failed to write file to disk” error. The same 755 mode may work when PHP owns the folder and fail when another account owns it.

If 755 fails, check these separately:

• Owner and group, including the account that runs PHP.
• Storage limits and whether the filesystem is read-only.
• Server rules and the security policy for the uploads directory.
• Script execution: Do not allow PHP scripts to run in the uploads folder as a way to solve an upload error. Blocking script execution there is a separate server or security-rule task, and the correct setup differs between Apache and Nginx.

📁 Note: Uploads are a common writable area, not a reason to make every WordPress file writable. Keep the exception limited to the folder that must receive media.

A page returns 403 or 500

A 403 means the server refused access. A restrictive mode or parent folder may cause it, but a firewall or server rule can also be responsible. A wp-admin admin-ajax.php 500 error may involve PHP, configuration, ownership, or .htaccess. Check the error logs and correct the smallest confirmed cause. Apache can use .htaccess for folder-level rules, while Nginx uses server configuration instead.

WordPress says a file must be writable

Treat that message as a clue, not as an order to give everyone write access. Confirm the named file, why WordPress needs to change it, and which account is making the request. A plugin may need one settings or cache folder to be writable while its other files remain protected.

The site breaks after hardening

If the problem began after a permission change, use the backup or recorded settings to restore the last known working state. Then test one path at a time. A restriction that prevents WordPress from loading its configuration or writing a required cache is not a successful security improvement.

Protect special files and writable folders

Protect special paths separately:

• wp-config.php: It contains database connection details and authentication keys, so it deserves tighter access than an ordinary file. Values such as 600, 640, 400, and 440 can fit different hosting setups. Choose the most restrictive host-supported value that still lets PHP and required management or deployment accounts read it.

• After a change: Load the site and test the dashboard. If PHP cannot read wp-config.php, WordPress may fail to load. Ask the host first if you cannot identify the accounts that need access.
• New files: The server’s default-file setting, sometimes called a umask, can affect permissions assigned to new files.
• Host controls: Shared hosting, PHP running under a separate account, SELinux, and deployment workflows can change the result of a mode that looks correct on paper.

⚙️ Note: File permissions limit access to site files. They do not detect or remove malware. Keep backups, update WordPress and its extensions, and use suitable scanning, firewall, and monitoring protection as separate safeguards.

Know when to contact your host

Ask your host or a developer for help when you do not control any of these:

• The owner, group, or account running PHP
• The server configuration or security policy
• The document root or deployment process

Managed hosting may prevent customers from changing these settings directly. Give support the failed action, path, error, current mode, visible owner and group, and time. Ask which account runs PHP and which ownership model it supports.

If you are worried that malicious code is already present, treat that as a separate issue. Permissions will not clean a compromised site or replace backups, updates, scanning, cleanup, firewall protection, and monitoring. MalCare can complement this work with website malware scanning and removal, cleanup, firewall protection, and monitoring, but it cannot fix server ownership or hosting configuration.

Conclusion

For most WordPress sites, 644 for ordinary files and 755 for folders are sensible starting points. The result also depends on ownership, the PHP account, writable paths, and the host.

When an error appears, back up the site, identify the path, inspect its mode and ownership, make one targeted change, and retest. Avoid 777 and blanket ownership changes. If your web host controls the site’s security settings, provide the exact error and path so it can repair them safely.