WordPress needs to write to specific directories and must not be able to write to others. When permissions drift, uploads fail, updates cannot install, and caching breaks. The temptation is to make everything writable, which fixes the symptom and opens a security hole. Correct permissions are narrower than that and just as functional.
Before you buy, one quick look
Read-only.
Try uploading a small image in the media library and note the exact error text. WordPress distinguishes between a directory it cannot create, a file it cannot move, and a size limit it cannot exceed — and those are three different problems.
If the error mentions a file size rather than permissions, you need the upload limit fix instead.
File permission errors blocking uploads
Uploads fail or files cannot be written because permissions are wrong. We set them correctly and securely, and find what changed them.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Uploads fail with a permissions error | This fix covers it |
| Uploads fail with a size error | Upload limit fix |
| Updates cannot install | This fix covers it |
| Site asks for FTP details to update | This fix covers it |
| 500 error across the site | HTTP 500 internal server error |
What you are seeing
- Media uploads failing with a directory or permissions error
- Plugin and theme updates failing, or asking for FTP credentials
- Caching plugins reporting they cannot write their cache
- It may have started after a migration or a host-side change
Common causes
- A migration that transferred files with the wrong ownership
- Permissions set too restrictively by a security plugin or a hardening script
- The web server running as a different user than the files belong to
- A host-side change to how PHP executes
- Directories created manually with different permissions than the rest
What we do
- Take a full backup before touching anything
- Establish which user the web server runs as and who owns the files
- Set directory and file permissions to correct, secure values
- Fix ownership where that is the actual problem rather than permissions
- Verify uploads, updates and cache writes all succeed
- Confirm nothing is left more permissive than it needs to be
What is included
- Working uploads, updates and cache writes
- Permissions set securely rather than simply loosely
- A note on what was wrong and, where determinable, what changed it
- The pre-fix backup, kept for 30 days
Not included
- Changing the user the web server runs as, which only your host can do
- Full security hardening, which is a separate service
- Recovering files that failed to upload before we were involved
- Design changes or content work
Questions about this fix
Someone told me to set everything to 777. Should I?
No. That makes every file writable by anyone with any access to the server, and it is one of the most reliable ways to turn a small compromise into a total one. It also usually is not necessary — correct permissions are narrower and work just as well.
Why does WordPress ask for FTP details when I try to update?
Because it cannot write to the plugin or theme directory itself, so it falls back to asking for another way in. Fixing the permissions removes the prompt entirely, which is both easier and safer than entering credentials each time.
It worked yesterday. What changed?
Usually a host-side change, a security plugin applying a hardening rule, or a migration. We look for the cause rather than just correcting the values, because permissions that drifted once will drift again.
Is this a security problem or a functionality one?
Both, in opposite directions. Too restrictive and the site cannot function; too permissive and it is exposed. Correct permissions sit between the two, and that is what we set.
Could a recent host change have caused this without me doing anything?
Yes — some hosts adjust how PHP executes as part of routine maintenance, which changes what user your files need to be owned by. It looks like nothing changed on your end because, from WordPress's perspective, nothing did.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.