TLDR: I learned the hard way that incorrect file permissions can break uploads, open backdoors, or lock you out of your site. This guide explains what file permissions are, why they matter for WordPress security and functionality, how to check and fix ownership and permission settings safely, common pitfalls to avoid, and quick recovery steps when things go wrong.
How I learned to treat permissions like a habit, not a one-time task
I remember the afternoon I accidentally made my uploads folder unreadable. I had been trying to lock down the site after a security alert. Images stopped appearing, and the media library looked empty. That day taught me that permissions are both a security control and a practical setting that affects everyday tasks like uploading images, installing plugins, and updating themes. I want you to avoid that same panic. In this guide I will walk you through the concepts, the commands I use, the safe defaults I trust, and the checks I run after changes.
What file permissions actually are
At a basic level, file permissions define who can read, write, or execute files and folders on your server. On Linux systems, each file and directory has three permission sets: owner, group, and others. Each set can allow reading, writing, and executing. The numeric representations like 755 or 644 are compact ways to express those rules. Understanding these basics helps you choose safe defaults for WordPress files and directories.
Why permissions matter for WordPress
Permissions impact two big things: security and functionality. If permissions are too permissive, attackers can upload malicious scripts or edit files. If they are too restrictive, WordPress cannot write to folders and features break. For example, plugin updates and image uploads require write access to specific directories. You want a balance that lets WordPress run smoothly while minimizing attack surface.
Common default recommendations I use
I follow simple numeric rules because they are predictable and widely recommended. These are safe starting points for most shared and VPS hosting environments:
- Files: 644 — owner read/write, group readable, others readable
- Directories: 755 — owner read/write/execute, group readable/executable, others readable/executable
- wp-config.php: 600 or 640 — restrict access to the owner, allow group if needed
These settings let the web server read files, and let PHP write where needed when ownership is set correctly. Speaking of ownership, that’s the other half of the story.
Ownership: the thing most guides forget to explain
Permissions only matter relative to who owns the file. On many hosts the webserver runs as www-data, www, nginx, or nobody. Files owned by your SSH user while the webserver runs as a different user can lead to write issues. I always check ownership with ls -la and set it with chown when necessary. A common pattern is to set the owner to the user account and the group to the webserver group, for example user:www-data, then use group permissions to allow PHP to write safely.
How do you check current permissions and ownership
Use these commands from the server shell to inspect your WordPress root and key folders. I run them before any change so I can revert if something breaks.
- ls -la /path/to/wordpress — view files and owner/group
- stat wp-config.php — see detailed file info
If you do not have SSH access, your hosting control panel often shows file permissions and ownership in the file manager. Be careful: GUIs can hide exact numeric values.
How I safely change permissions
When I need to make changes, I follow a reproducible process so I can audit what I did. This sequence works on most servers:
- Back up your site and database first
- Set directories to 755: find /path/to/wordpress -type d -exec chmod 755 {} \;
- Set files to 644: find /path/to/wordpress -type f -exec chmod 644 {} \;
- Restrict wp-config.php: chmod 600 wp-config.php
- Adjust ownership if needed: chown -R user:www-data /path/to/wordpress
After this, try common actions: upload an image, update a plugin, visit the site. If something fails, check error logs and revert changes with your backup. If you are uncomfortable with shell commands, your host support can usually apply these safely.
Special cases: writable folders and caching
Some folders must be writable by WordPress for normal operations. Common writable targets include:
- wp-content/uploads — user media files
- wp-content/cache — caching plugins write cache files
- wp-content/plugins and wp-content/themes during updates
If your site uses a caching plugin and you change permissions, you may need to purge cache WordPress to see the effect immediately. I always purge cache after permission changes to avoid stale results.
Permissions and automated tools
Security plugins sometimes attempt to harden file permissions. These can help, but they can also break functionality if they set overly strict values. I let automated tools propose changes, then I review commands and test in a staging environment before applying them to production.
Recovering if you break something
If uploads stop working, or if your admin area shows permission errors, follow this recovery checklist I use:
- Restore from backup if you made a known-bad change
- Check the ownership: ls -la and correct with chown if needed
- Reset directories to 755 and files to 644 for the WordPress install
- Temporarily set wp-config.php to 644 only if it was inaccessible, then lock it again after recovery
- Check webserver error logs for clues
These steps solve most issues. If you cannot fix it, contact your host. Some hosts provide permission repair tools in the dashboard.
Common mistakes you should avoid
Here are the traps I fell into and now warn others about:
- Setting everything to 777 thinking it will fix write errors. It opens a huge security hole.
- Making wp-config.php world readable. That leaks database credentials.
- Mixing up owner and group so PHP cannot write despite permissive bits.
- Running recursive chown or chmod from the wrong directory and changing system files.
- Not testing after changes, leaving the site in a partially broken state.
How permissions tie into broader security hardening
Permissions are one layer of defense. I combine them with these measures:
- Strong passwords and two factor authentication for admin accounts
- Keeping WordPress, themes, and plugins updated
- Removing unused plugins and themes
- Using a reputable web application firewall and monitoring file changes
When I prepare for a migration or a major update, I also audit file permissions as part of my checklist. That way I reduce the chance of downtime during transfers like when I had to migrate WordPress site recently and wanted a clean, predictable environment.
Permissions for managed WordPress and special hosting
Managed hosts sometimes impose stricter ownership models or use containers. In those cases, follow host-specific guidance. If you cannot change ownership because of container isolation, ask support to make the necessary changes. I have seen hosts recommend 775 instead of 755 to accommodate a different group account. Read host docs before applying blanket rules.
Media library and metadata considerations
When WordPress cannot write to uploads, media functions fail and you cannot add alt text WordPress or edit image metadata. Always verify uploads folder ownership and permissions after migrating or restoring a backup. In my process I upload a small test image and edit its alt text to confirm everything works.
Quick checklist before you run any commands
- Backup files and database
- Note current permission and ownership via ls -la
- Test permission changes in staging if possible
- Apply changes to directories and files with find + chmod
- Verify site operations and purge caches
What should you avoid at all costs
In short, avoid giving write access to everyone. Never set permissions to 777 on production. Avoid blindly trusting a plugin that changes file permissions without letting you review the commands. Do not change system directories outside your WordPress path. Finally, do not skip backups before mass changes.
Frequently asked questions
Can I set all files to 644 and directories to 755 automatically?
Yes. Running the find commands I listed will set those values recursively. That is a good baseline. However, some plugins require special writable folders. After the bulk change, test uploads, plugin updates, and theme installs. Reopen specific folders to 775 only if a plugin explicitly needs group write access and you understand ownership implications.
What permissions should wp-config.php have?
I recommend locking wp-config.php to 600 so only the owner can read and write it. On some hosts you might use 640 if the webserver runs under the same group. If you ever set it to 644 to recover access, switch it back to 600 or 640 afterwards.
Is 755 always safe for directories?
755 is safe in most shared hosting and VPS setups because it prevents others from writing to your directories. If your host requires group write access for processes, they may suggest 775. Always follow host guidance when it conflicts with these general recommendations.
How do I fix permissions without SSH?
If you lack SSH, use your hosting file manager. Many providers let you change permissions numerically. If the control panel cannot adjust ownership, open a support ticket asking them to set owner and group correctly. I used host support twice to fix ownership after a migration and it was resolved quickly.
Do file permissions prevent all attacks?
No. Permissions reduce risk but cannot block every attack. You still need secure code, updated components, strong credentials, and intrusion detection. Permissions are one important layer in a multi layered security strategy.
Summary and final advice
To summarize, file permissions control who can read and write your WordPress files. They matter for both security and day to day functionality. Use 644 for files and 755 for directories as a starting point, lock wp-config.php, ensure ownership is correct, and avoid 777. Test changes carefully and keep backups. When in doubt, reach out to your host or test in a staging site first. Think of permissions as routine maintenance that keeps your site secure and reliable.