The safe baseline for a WordPress install is directories at 755 or 750, files at 644 or 640, and wp-config.php locked to 440 or 400. These numbers matter less than who owns the files: if your web server process and your file owner don't match, no chmod value fixes that — integrating AI voice agents for e-commerce customer support can help automate order lookup and support despite such permission complexities. Never set anything to 777, even temporarily, to solve an upload or update error.
TL;DR:
- Set directories to 755 or 750, files to 644 or 640, and the WordPress configuration file to 440 or 400 to protect credentials.
- Check file ownership against the PHP process user before changing modes, because incorrect ownership can block writes even when permissions appear open.
- Use 775 for directories and 664 for files only when a tightly controlled group needs write access, and limit exceptions to upload or cache folders.
- An FTP prompt during updates usually means WordPress cannot write as the file owner, so correct ownership instead of setting permissions to 777.
Table of Contents
- What file permissions actually control on your server
- Recommended permission values for WordPress files and folders
- Why ownership and the WP Filesystem API decide the real answer
- How to check and fix permissions without breaking your site
- Matching common errors to the right fix
- Hardening file permissions without breaking functionality
- How managed hosting removes most of this guesswork
- Diagnose ownership before you touch a single chmod value
- Let inSave Hosting handle the ownership layer for you
- FAQ
- Sources
What file permissions actually control on your server
Every file and folder on a Linux server carries three permission sets, owner, group, and everyone else, each with read, write, and execute bits. Those bits translate into octal numbers: read is 4, write is 2, execute is 1, and you add them to get values like 7 (full access) or 5 (read and execute). A folder's execute bit controls whether a process can enter it and list what's inside, which is why directories almost always carry an odd number like 755 while files use an even one like 644.
This is entirely separate from WordPress's own dashboard roles. An Administrator account inside wp-admin has no bearing on what the operating system lets PHP read or write.
- Read (4), write (2), and execute (1) combine into the octal digits you see in
ls -loutput. - Directories need the execute bit to be browsable; files never need it for normal WordPress operation.
- WordPress user roles (Administrator, Editor, Author) control the dashboard, not the filesystem.
Recommended permission values for WordPress files and folders
WordPress's own documentation sets directories at 755 or 750 and files at 644 or 640 as a starting baseline, with wp-config.php tightened further to 440 or 400 since it holds your database credentials and secret keys. These are starting points, not fixed law: the right number depends on your server's ownership setup.
- Directories: 755 (or 750 on stricter group-based hosts).
- Files: 644 (or 640 where group access is restricted).
- wp-config.php: 440 or 400, readable only by the owner and possibly the owning group.
Some shared environments run PHP under a group that needs write access alongside the owner, in which case 775 for directories and 664 for files make sense, but only when the group is tightly controlled. Looser permissions are sometimes unavoidable in wp-content/uploads or cache directories that WordPress writes to constantly, but scope that to the specific subfolder rather than loosening the whole install.
Why ownership and the WP Filesystem API decide the real answer
Numeric modes only work when the process writing to disk is also the file owner, or belongs to the owning group. When your webserver runs as www-data but files are owned by a different system user, write attempts fail no matter how open the permissions are, short of 777, which creates its own risk.
WordPress handles this uncertainty through get_filesystem_method(), which tests whether PHP can write directly as the file owner. When it can, WordPress uses the 'direct' method; when it can't, it falls back to credentialed transports like ssh2, ftpext, or ftpsockets, which is why you sometimes see an FTP credentials prompt during a plugin update.
The modes WordPress itself applies when writing files come from the FS_CHMOD_DIR and FS_CHMOD_FILE constants, defined in wp-config.php. Hosts can also override these, and WP_Filesystem_Direct::chmod applies them when WordPress creates or updates files, using 0644 for files and 0755 for directories by default. None of this fixes an ownership mismatch; it only governs what WordPress does once ownership is already correct.
How to check and fix permissions without breaking your site
Start by confirming what you're actually dealing with before changing anything.
- Run
ls -lin your WordPress root to see owner, group, and mode for each file and folder. - Use
stat filenamefor a fuller breakdown, or checkfileperms(__FILE__)from a PHP test script if you lack shell access. - Create a temporary test file (
echo test > testfile.txt) inwp-content/uploadsand check who owns it; compare that to the owner of your WordPress files. - Fix ownership with
chown -R youruser:yourgroup /path/to/wordpressbefore touching numeric modes. - Apply baseline permissions with
find /path/to/wordpress -type d -exec chmod 755 {} \;for directories and the equivalent-type f -exec chmod 644 {} \;for files.
Pro Tip: Run recursive chmod and chown commands on a staging copy first; a mistyped path can lock you out of the entire account.
If you don't have SSH, FileZilla and most cPanel file managers let you right-click a file or folder, set numeric permissions directly, and toggle "show hidden files" to reach .htaccess and wp-config.php. On managed or shared hosts running suexec, contact support before forcing ownership changes yourself: the platform may enforce specific owner mappings that a manual chown will break.
Matching common errors to the right fix
Most permission errors present the same handful of symptoms, and each points to a specific check rather than a blanket fix.
- Upload fails with no clear error: test-write to
wp-content/uploads, then check that directory's owner against your PHP process user. - Plugin or theme install/update asks for FTP credentials: WordPress couldn't confirm direct write access; this points to an ownership mismatch, not a permissions-too-low problem.
- wp-config.php edits won't save: it's likely locked to 440 or 400 correctly; temporarily raise it to 640 to edit, then revert.
- "Destination folder already exists" during update: often a leftover folder with the wrong owner from an interrupted previous update; remove it and retry rather than widening permissions.
In every case, resist the instinct to chmod 777 as a quick fix. It gets the task working for a moment and leaves every file writable by any process on the server, including a compromised script.
Hardening file permissions without breaking functionality
WordPress's official hardening guidance recommends tightening everything first, then loosening only where a specific feature demands it. Lock wp-config.php to 440 or 400, restrict .htaccess the same way directories are restricted, and disable the built-in theme and plugin file editors in wp-admin if you don't need them.
Apply the same discipline to teams managing several sites: standardize the baseline across every install, document any directory that needs an exception, and never hand out blanket write access to make one plugin happy.
- Set wp-config.php to 440 or 400 and keep it outside any directory with group-write access.
- Tighten first with the baseline, test the site, then loosen only the specific folder that errors out.
- Keep a current backup before any recursive chmod or chown, since a bad recursive run is hard to reverse by hand.
| Area | Recommended setting |
|---|---|
| Directories | 755 (750 on stricter group setups) |
| Files | 644 (640 on stricter group setups) |
| wp-config.php | 440 or 400 |
| Theme/plugin editor | Disabled in wp-config.php |
For broader protection beyond permissions, pairing this baseline with security headers and .htaccess rules closes off related attack paths.
How managed hosting removes most of this guesswork
Our team has written operational WordPress security and infrastructure guides covering exactly this kind of ownership and permissions troubleshooting. Managed WordPress plans often include properly configured file ownership at setup, avoiding mismatches that cause most permission errors. Daily backups, migrations, and staging environments provide a safe place to test any permission change before it affects a live site, supported by experienced SRE/DevOps personnel.
Diagnose ownership before you touch a single chmod value
Run a write test, check ls -l ownership against your PHP process user, and confirm which filesystem method WordPress is using before changing any numbers. If ownership looks wrong on a shared or managed account, escalate to your host rather than forcing a chown yourself.
— Ihor
Let inSave Hosting handle the ownership layer for you
Permission errors almost always trace back to a server configuration decision, not something you did wrong in the dashboard. Our WordPress-optimized hosting plans ship with correct file ownership out of the box, staging tools to test changes safely, free migrations if you're moving from a host where permissions are already a mess, and daily backups so a bad recursive command never costs you the site.
If you manage several WordPress installs and want the ownership and process-user layer handled for you, our managed servers with SRE/DevOps support take that off your plate entirely.
- Correct file ownership configured at setup, not left for you to diagnose.
- Staging environments to test permission or ownership changes before going live.
- Daily backups and free migrations if you're moving away from a problematic host.
Check our WordPress hosting plans or reach our support team if you're dealing with an ownership issue right now.
FAQ
What permissions should wp-config.php have?
wp-config.php should be set to 440 or 400, readable only by the file owner and, in the 440 case, the owning group. This file holds your database credentials and secret keys, so WordPress's own documentation treats it as the strictest exception to the general 644/640 file baseline.
Is it ever safe to use 777 permissions in WordPress?
No. Setting a directory or file to 777 makes it writable by any process on the server, including a malicious script, and WordPress explicitly warns against using it to fix upload or update errors. The real fix is almost always correcting ownership or using the narrower 775/664 variant for group-based setups.
Why does WordPress ask for FTP credentials during an update?
WordPress asks for FTP, SSH2, or FTP-extension credentials when its get_filesystem_method() check determines that PHP cannot write directly as the file owner. Forcing FS_METHOD to 'direct' in wp-config.php can bypass the prompt, but it only works safely once ownership is actually correct.
How do I check current file permissions on my WordPress site?
Run ls -l from SSH in your WordPress root directory to see the owner, group, and numeric mode for every file and folder. If you don't have shell access, most FTP clients and cPanel file managers display and let you edit the same permission values directly.
Should directories and files ever share the same permission number?
No, directories need the execute bit to be browsable, so they typically use an odd value like 755, while files don't need execute and use an even value like 644. The WP Filesystem API's chmod function warns against applying one blanket mode to both for this reason.