You clicked update, watched the progress bar move for a few seconds, and then it just… stopped. In its place, a box appeared asking for something called FTP credentials, a hostname, a username, a password you’re not sure you’ve ever set.
Your first instinct is probably to wonder if you’ve been hacked, or if you’ve somehow broken your own site by clicking a button you’ve clicked a hundred times before.
The good news is that you haven’t broken anything, and a WordPress plugin update asking for FTP isn’t a security breach announcing itself. It’s WordPress hitting a wall it can’t get around on its own, and asking you for a hand.
TL;DR: That FTP prompt just means WordPress can’t write files through its usual process, not that you’ve been hacked. Backup your site first, ideally with a backup plugin, then check ownership, permissions, and disk quota before touching anything else. Skip the 777 shortcut and don’t save credentials in your files.
What does it mean when a WordPress plugin update asks for FTP?
When that process hits a folder it can’t write to, WordPress doesn’t fail silently. It asks you for another way in, and FTP is the classic fallback it reaches for. If the update stops or displays another error, use the exact message to troubleshoot the failed WordPress plugin update.
What that prompt doesn’t tell you is why the write failed, and that’s usually where people get stuck, and here are a handful of things that can cause it:
-
A mismatch between accounts. The account running your site isn’t the same one that owns the files it’s trying to change.
-
WordPress Permissions that are too tight on the plugin’s folder, or on a folder further up the chain.
-
You’ve hit a limit, either on disk space or on something called your inode quota (a cap on the total number of files and folders your hosting account is allowed to have, separate from how much storage they take up).
-
A leftover setting from a past migration that’s telling WordPress to behave in a way your current server doesn’t support.
-
Your host has a security rule in place that’s blocking the write entirely.
One thing worth clearing up before you go further is that if you just uploaded an image and it worked fine, that doesn’t rule any of this out. Media uploads often go through a completely different folder and process than plugin updates do, so one working smoothly tells you nothing about whether the other will.
Check what your host actually supports
Once you know WordPress wants an alternative way to reach your files, it’s worth pausing before you fill that box in, because there’s more than one kind of “FTP” and they’re not interchangeable. Plain FTP moves files with no encryption at all. FTPS is the same idea with encryption layered on top, and SFTP is a different animal entirely, running through SSH rather than through FTP at all.
This matters because a lot of hosts these days only offer SFTP, and if that’s you, entering FTP details into that WordPress box will just fail, over and over, no matter how carefully you type your password.
Ask your host directly which protocol your account supports, and whether they’d rather you use a separate file manager or update tool in their own dashboard instead of the WordPress prompt at all.
📝 Note: Don’t save your credentials into wp-config.php just to make this prompt stop appearing. It feels like a convenience now, but if that file is ever exposed through a bug or an old, unsecured backup, those credentials go with it.
Find out exactly where the write is failing
Knowing the right protocol gets you through an urgent update in a pinch, but it doesn’t answer the real question: why is this happening in the first place, and will it happen again next time? To get to the bottom of that, you need to narrow down whether this is a problem with one plugin’s folder, or something affecting your whole site’s ability to write files.
Here’s how to work through it, in order:
-
Locate both folders involved. There’s the plugin’s own folder under wp-content/plugins, and there’s a temporary staging folder WordPress uses during the update itself, under wp-content/upgrade. A folder being readable doesn’t mean it’s writable, and it’s easy to check the wrong one.
-
Compare the account running PHP against the folder’s owner. Ask your host which system account actually executes PHP on your site, then check whether that matches who owns the folder that’s failing.
-
Check your capacity, not just your permissions. Look at both available disk space and your inode quota. Running out of either can cause a WordPress failed to write file to disk error, even though the required fix may be completely different.
-
Look for a rule you didn’t set yourself. Managed hosts, container-based setups, and security plugins can all block a write attempt as a deliberate policy rather than an accident. If you’re running a security plugin, its logs are a good place to check for a blocked action around the same time this started.
Before you change a single thing based on what you find, back up your site entirely. This is the step people skip when they’re in a hurry, and it’s exactly the wrong moment to skip it, since you’re about to start adjusting ownership and permissions on live files.
Fixing ownership and permissions
Once you’ve found the folder that’s actually causing the trouble, the fix is almost always the same shape: give the account running your site exactly the access it needs, and nothing more than that. Directories typically sit at 755 and files at 644 as a starting baseline, though you should think of those as a reasonable default rather than a guarantee that fits every host.
If ownership turns out to be the mismatch, ask your host for the correct account and the exact path that needs fixing, rather than guessing your way through it. And this is where I’d really urge caution: don’t apply a sweeping ownership change across your whole server hoping it catches everything. That’s the kind of fix that solves today’s problem while quietly creating tomorrow’s, on a folder you weren’t even thinking about.
This is the mistake I see most often, so it’s worth saying plainly: never set your files or folders to 777. I understand the appeal. It’s fast, it makes the error disappear, and it feels like the problem is solved. But 777 doesn’t fix the underlying mismatch, it just grants write access to every account and process that can reach that path, including ones that have no business being there.
You’ve traded a confusing prompt for a genuine security hole, and the prompt was the easier problem to have.
Once you’ve corrected the actual issue, retry a single plugin update and check both the front end of your site and whatever feature matters most to your visitors, whether that’s checkout, login, or a contact form, before you consider this closed.
What about that FS_METHOD setting people mention?
If ownership and permissions check out and you’re still stuck, there’s one more thing worth a look: a setting called FS_METHOD, short for File System Method, that lives in your wp-config.php file and tells WordPress how to talk to your server’s filesystem.
It can be set to write directly, or to go through FTP, or to go through SSH, and a value left over from a past migration can sometimes cause a perfectly healthy server to ask for credentials it doesn’t actually need.
Here’s the honest limitation, though: setting FS_METHOD to direct only works if your site’s process already has valid write access to the folder in question. It can’t grant permissions that aren’t already there. If ownership is still wrong underneath it, forcing this setting usually just trades your FTP prompt for a different error message, something like “Could not create directory,” which is really the same problem wearing a different hat.
📝 Note: Only make this change after you’ve backed up, and only once your host has confirmed direct writes are actually supported on your setup. Check that your site still loads correctly afterward. A single misplaced line in wp-config.php is enough to take the whole site down.
If you need this update done right now
Sometimes there isn’t time to chase down a permissions mismatch properly, and that’s fair. If you need the update through today, use whatever update method or file manager your host provides in their own dashboard rather than trying to force the WordPress prompt to cooperate.
A manual update can also work as a stopgap: back up first, download the plugin directly from its original source, find its existing folder under wp-content/plugins, and replace the files while keeping the folder’s original name intact. Avoid uploading a ZIP file from somewhere you don’t fully trust, and avoid nesting one plugin’s folder inside another by accident.
Just know going in that this gets you through today without touching tomorrow and the ownership or quota issue underneath is still sitting there, waiting.
Confirming the update actually worked
A new version number showing up in your dashboard feels like the finish line, but it’s really just the first checkpoint. First, check the status of the WordPress plugin update, then confirm that the plugin is active and its important features still work. The update isn’t done until you’ve confirmed the plugin is active, your site’s public pages load properly, and anything that update could plausibly have touched still works the way it should.
If something does throw an error, hang onto the exact wording rather than paraphrasing it later from memory. “Could not create directory” points you back toward permissions and ownership, while a download failure or a compatibility warning is a completely different trail to follow.
And if your site becomes unreachable at any point during this process, that’s what your backup or staging copy is for: restore first, then reach out to your host before you try anything else.
When the prompt won’t go away
If you’ve worked through all of this and a WordPress plugin update is still asking for FTP every time you try, that’s telling you something specific: the underlying access problem hasn’t actually been resolved; WordPress isn’t just being stubborn. At this point, the most useful thing you can do is hand your host a complete picture rather than a vague description of the symptom.
Give them the plugin name and the exact error message, the specific path WordPress tried and failed to write to, which account runs your site’s PHP process, and who owns that failing folder, plus your available disk space and inode quota, and which protocol, FTP, FTPS, or SFTP, your account actually supports.
Ask them directly whether this is isolated to plugin updates, or whether it reaches into themes, media, and core files too, since that tells you whether you’re looking at one folder’s problem or something baked into how your server is configured.
A backup or staging tool is genuinely useful here, giving you a safe copy to fall back on while your host works through the fix, since it takes the fear out of experimenting with permissions on a live site. It’s worth being clear-eyed about its limits, though: it can hand you a safety net, but it can’t reach into your server and fix a broken ownership setting, a maxed-out quota, or a host’s own policy. That part still has to come from them.
FAQs
Why is my WordPress plugin update asking for FTP details?
It means the process running your site couldn’t write the files an update needs through its normal path, so WordPress is offering an alternative. The usual causes are an ownership mismatch, tight permissions, a full quota, or a rule your host has put in place.
How can I update a plugin without going through FTP at all?
Fix the underlying ownership and write access, remove an FS_METHOD setting that’s forcing the wrong behavior, or use your host’s own update tool or file manager instead. Back up first, always, and check your site afterward.
Why doesn’t setting FS_METHOD to direct just fix this?
Because it’s not granting access, it’s just telling WordPress to assume access is already there. If ownership underneath is still wrong, you’ll likely just trade the FTP prompt for a different error entirely.
Is it ever okay to set permissions to 777 just to move things along?
No, and this is worth being firm about. It hands write access to every account and process that can reach that path, turning a filesystem hiccup into a real security exposure. Ask your host for the narrowest setting that actually gets the job done.
Is SFTP basically the same thing as FTP?
No, they’re genuinely different. SFTP runs through SSH, while FTP and FTPS are their own separate protocols. Confirm which one your host supports before you type anything into that WordPress box.
Conclusion
A WordPress plugin update asking for FTP looks alarming, but underneath it, it’s really just telling you one process couldn’t safely write to one folder. Once you see it that way, it becomes a short list to check: which folder, which account, how much space, and whether your host has a rule in the way.
Work through those in order, and resist any shortcut that promises to skip a step. Back up before you touch anything, get your host to confirm the account and the failing path, and if the prompt returns, treat that as useful information rather than a reason to try something more drastic.
Akshat is the founder and CEO of BlogVault, MalCare, and WP Remote.
