WordPress file permissions determine which operating-system users can read, modify, or traverse files and folders. On many Linux hosts, 644 for ordinary files and 755 for directories are common starting points, but ownership and the PHP execution model matter. Confirm your host’s requirements before applying any site-wide change.
Last updated: September 6, 2026. Skill level: intermediate; Linux hosting focus.
This guide explains permissions and a cautious diagnostic workflow for self-hosted WordPress. It is not a universal repair script or a malware-removal procedure. Windows hosting uses a different access-control model, and managed deployments may enforce settings you should not change manually.
What do the numbers 644 and 755 mean?
The three digits describe access for the file owner, the owning group, and other operating-system users. Each digit combines read, write, and execute permissions. These categories are filesystem identities, not WordPress roles such as administrator or editor. A user with administrator privileges in WordPress does not automatically own the site’s Linux files.
| Value | Permissions represented |
|---|---|
| 4 | Read |
| 2 | Write |
| 1 | Execute or directory traversal |
| 6 | Read and write |
| 5 | Read and execute or traversal |
| 7 | Read, write, and execute or traversal |
For a normal file, 644 allows the owner to read and write while the group and others can read. For a directory, 755 gives the owner full access and lets the group and others read and traverse it. Directory traversal is necessary to access items along a path; it does not mean a PHP file needs an executable bit merely to be served by PHP.
The WordPress file-permission handbook, reviewed September 5, 2026, describes common modes and how hosting ownership affects them. Treat those examples as a starting point for discussion with your host, not permission to override an intentional deployment policy.
Why does ownership matter as much as the mode?
Ownership determines which permission category applies to a process accessing a file. If PHP runs as the file owner, owner permissions govern its access. If it runs as a different user, group membership and other controls may matter instead. The same numeric mode can therefore behave differently across two hosting environments.
Consider an uploads directory that looks writable to your SFTP account but rejects image uploads from WordPress. The SFTP account and PHP process may not be the same identity. Adding broader write permissions without understanding that difference can hide the symptom while making access unnecessarily permissive.
Ask the host which account owns the files, which account runs PHP for this site, and whether ACLs or managed deployment rules apply. Do not guess an ownership command using a familiar username from another server. A recursive ownership change can disrupt updates, backups, and deployment even when page delivery initially looks normal.
How do you inspect permissions without changing them?
Use the hosting file manager or a read-only terminal listing to inspect a small set of relevant paths. Compare their modes and ownership with the host’s documented expectations. Start with the exact failing operation, such as an upload or update, rather than treating every folder as broken and recursively changing the entire installation.
For Linux or macOS-style shell listings, replace the path below with your WordPress root:
ls -ld /path/to/wordpress
ls -ld /path/to/wordpress/wp-content
ls -ld /path/to/wordpress/wp-content/uploads
ls -l /path/to/wordpress/index.php
These commands list metadata; they do not change permissions. In a typical listing, the leading characters show the file type and permission bits, followed by ownership information. A host’s file manager may display the same information in separate columns.
Record the current mode, owner, group, and error before changing anything. If you need help, share the minimum relevant output privately. Do not include the contents of wp-config.php or a database password in a support request about file access.
What permissions do different WordPress paths need?
Different paths have different operational requirements. Uploads need appropriate write access for the process storing media, while application code can often be more restricted in a managed deployment. Configuration files need careful protection without preventing PHP from reading required settings. Use the host’s supported policy for each path instead of one rule for everything.
| Path or component | Question to resolve before changing access |
|---|---|
| wp-content/uploads | Which PHP process must create directories and save media? |
| Plugin and theme files | Are changes made by WordPress, SFTP, or a deployment system? |
| WordPress core | Who is responsible for installing official updates? |
| wp-config.php | Which identity must read configuration, and who may edit it? |
| .htaccess, where used | Does the host or WordPress manage rewrite changes? |
The WordPress hardening guidance explains why writable application files and ownership need deliberate control. More restrictive configuration-file modes may be suitable on some hosts and break the site on others. Confirm readability for the actual runtime before adopting a number from a tutorial.
If the problem is a public folder index, follow our directory-listing guide. Directory browsing is a server setting; making the uploads directory inaccessible can break public images without solving the underlying configuration question correctly.
How do you fix a confirmed permission problem safely?
Change the smallest confirmed scope after recording its original state and agreeing on the required mode with the host. Test one affected operation immediately afterward. Keep an independent file-management session available so you can restore the prior setting if WordPress becomes inaccessible. Do not use a recursive command as a substitute for diagnosis.
- Reproduce the failure and identify its exact path from the relevant error or host report.
- Rule out disk quota, read-only storage, ownership, and host policy before assuming the numeric mode is wrong.
- Record the original settings and confirm the correct owner and required access with the host.
- Apply the approved change to the affected path through the supported file manager or deployment process.
- Repeat the failed action, then check a normal page and the relevant administrative workflow.
- Record the final setting and remove any temporary access granted for troubleshooting.
Avoid using 777 as a general fix. It grants broad write access under ordinary Unix permission rules and often signals that ownership or process identity has not been understood. If a host proposes an exception, ask for the exact path, reason, and duration rather than extending it across the site.
For update-related failures, use the separate safe plugin-update workflow. Permission changes do not address an incompatible plugin release or an incomplete database migration.
How can you verify that the final settings are appropriate?
Verify both the operation that previously failed and the access that should remain restricted. A successful upload is only one observation; it does not establish that broader write access was necessary. Compare the final ownership and modes with the approved policy, then repeat the check after the next relevant deployment or hosting change.
If files keep returning to unexpected modes, investigate the process changing them. Your deployment tool, restore process, or file-creation defaults may be responsible. Document that source of change instead of repeatedly applying manual fixes without understanding why they do not persist.
For suspected changes to core file contents, use our WordPress checksum tutorial. Permissions describe who can access files; checksums compare their contents. Passing one check does not replace the other.
Frequently asked questions
Should every WordPress file use 644?
No. It is a common baseline for ordinary files on some Linux hosts, but configuration files, managed deployments, ACLs, and ownership models can require different settings.
Are WordPress administrator roles the same as file owners?
No. WordPress roles govern application capabilities. Filesystem owners and groups belong to the operating system and determine a different layer of access.
Does 755 mean everyone can edit a folder?
No. Under ordinary Unix mode bits, the owner has write access while group and other users have read and traversal access. Other access controls can also affect the final result.
Can permissions alone remove malware?
No. Changing access does not remove malicious content or identify how it arrived. Investigate file integrity, accounts, credentials, and the entry point through a separate recovery process.

Leave a Reply