WordPress Asks for FTP Credentials on Update? Real Fix
You click "Update Now" on a plugin or theme, and instead of the usual progress bar, WordPress stops and asks you to type in an FTP hostname, username, and password. Or it goes ahead and fails outright with "Could not create directory" or "Download failed. Not a valid zip file." On Getwebup's cPanel hosting you almost never need FTP credentials to update anything - so when WordPress starts asking, it's telling you something about file ownership, not about FTP.
Symptom
A few variations of the same underlying problem show up depending on what you're updating:
- A popup titled "Connection Information" appears, asking for FTP/SFTP hostname, username, password, and port before it will let the update continue.
- The update starts, then fails with
Could not create directory. - You see
Download failed. Not a valid zip fileeven though the plugin downloads fine everywhere else. - Auto-updates for core, plugins, or themes silently stop working and the WordPress dashboard shows a permissions warning under Site Health.
Cause
WordPress updates itself by writing new files to wp-content. Before it does that, it checks whether the PHP process (running as your hosting account's user) can write directly to those folders. If it can't, WordPress falls back to asking for FTP credentials so it can write the files that way instead.
On shared and cPanel-managed hosting, this almost always comes down to one of these:
- Wrong file ownership. Files were uploaded via an FTP account, a migration plugin, or a backup restore that left them owned by a different user (or the wrong group) than the one PHP runs as.
- Wrong permissions. Folders set to
755/644is normal - but ifwp-content,wp-content/plugins, orwp-content/themesgot locked down to something tighter (or the ownership is root/another cPanel account), PHP can't write there. - A hardcoded
FS_METHODinwp-config.php. Some security plugins or old migration guides adddefine('FS_METHOD', 'ftpext');to force FTP-based updates. That line alone is enough to trigger the credentials prompt on every server, even ones where direct writes work fine. - Disk quota or inode limit reached. If the account is out of disk space or has hit its inode limit, WordPress can't create the temporary directory it needs mid-update, and you'll get "Could not create directory" instead of the FTP prompt.
"Download failed. Not a valid zip file" is usually a variant of the same disk/inode problem - the zip gets truncated because there's no room left to write it, so WordPress can't unpack it.
Rule out disk space first
In cPanel, open Home » Files » Disk Usage (or check the usage meter in the sidebar). If you're at or near 100% of your quota, that's your answer - clear space before touching permissions. The same page's inode count matters too; shared hosting plans cap the number of files, not just their total size, and a bloated wp-content/uploads or old cache folder can quietly max it out.
Fix
1. Remove any hardcoded FS_METHOD line
Open wp-config.php via cPanel File Manager and search for FS_METHOD. If you find a line like this, delete it (or comment it out) unless you have a specific reason to force FTP:
define('FS_METHOD', 'ftpext');
Once removed, WordPress will re-test direct write access on the next update attempt instead of jumping straight to the FTP prompt.
2. Fix ownership and permissions on wp-content
The safest way to do this on cPanel hosting is via SSH, since it recurses correctly and won't touch files outside your account:
cd ~/public_html
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;
chown -R youruser:youruser wp-content
Replace youruser with your actual cPanel username (run whoami if you're not sure). No SSH access? Do the same thing in File Manager: right-click wp-content » Permissions » set folders to 755 and files to 644, and tick "Recurse into subdirectories." Ownership mismatches from a restored backup usually need a quick note to Getwebup support, since File Manager can't change the Linux owner - only permissions.
3. Force direct filesystem access explicitly
If step 1 didn't have an FS_METHOD line at all and the prompt still appears after fixing ownership, add this instead, just above the /* That's all, stop editing! */ line in wp-config.php:
define('FS_METHOD', 'direct');
This tells WordPress to skip the FTP check entirely and write files directly as the PHP user. It only works cleanly once ownership actually matches what PHP runs as - forcing it before fixing permissions just trades one error for another.
4. Clear the failed update's leftover lock
A failed update sometimes leaves a stale .maintenance file or a partially-written plugin folder behind. Check wp-content for a .maintenance file and delete it, and check wp-content/upgrade for leftover temp folders you can safely remove. Then retry the update.
5. Still stuck? Update manually
If none of the above clears it, you can always sidestep the auto-updater completely:
- Download the plugin or theme's latest
.zipfrom WordPress.org (or your premium plugin's site). - In wp-admin » Plugins » Add New » Upload Plugin, upload the zip directly - this uses a different code path than the auto-updater and often succeeds even when the background updater can't.
- Alternatively, delete the old plugin folder via File Manager (deactivate it first) and upload the new version's extracted folder straight into
wp-content/plugins.
Prevention
- Don't hand-edit ownership via random FTP clients logged in as a different cPanel user - always upload as the account that owns the site.
- After restoring a backup or migrating a site, run the
chown -Rcommand from step 2 once as a matter of routine. - Keep an eye on Disk Usage in cPanel, especially on entry-level plans - inode limits get hit before disk space does more often than people expect.
- Avoid adding
FS_METHODoverrides unless a specific plugin's documentation tells you to. It's rarely needed on Getwebup's cPanel servers.
| Error message | Most likely cause | Fix |
|---|---|---|
| FTP credentials popup | PHP can't write to wp-content directly | Fix ownership/permissions, remove forced FS_METHOD |
| Could not create directory | Disk quota or inode limit reached, or bad permissions on wp-content | Free up space, then fix permissions |
| Download failed. Not a valid zip file | Truncated download from full disk, or a security plugin blocking the request | Check disk usage; upload the zip manually if it keeps failing |
| Auto-updates silently stop | Ownership mismatch after a migration or restore | Run chown -R to match the PHP user |
None of this actually involves FTP in the traditional sense - it's WordPress asking permission to write files, and cPanel hosting almost always wants those files owned by your account's PHP user, not moved through an FTP layer at all.
Frequently asked questions
Should I actually enter FTP credentials when WordPress asks?
You can, and it will usually work, but it's treating the symptom rather than the cause. Every future update will prompt you again until the underlying file ownership or permissions issue is fixed. On Getwebup hosting there's no need to route updates through FTP at all once ownership is correct.
What FTP hostname and port would I even use if I wanted to go that route?
Use your domain (or the server hostname from your welcome email) as the FTP hostname, port 21 for FTP or 22 for SFTP, and your cPanel username and password. But fix the ownership issue instead if you can - it saves you from re-entering this every time.
I set FS_METHOD to 'direct' but updates still fail. What now?
That means ownership or permissions still don't match what PHP runs as - forcing direct mode doesn't bypass the actual write check, it just skips WordPress's own detection of it. Run the chown/chmod commands in the Fix section, or ask support to verify the wp-content owner matches your cPanel account.
Could a security plugin be causing this instead of file permissions?
Yes - some hardening plugins deliberately lock down wp-content or force FTP-based updates as a security measure. Check the plugin's settings for anything labeled 'file editing' or 'update method' before assuming it's a server-level permissions problem.
Does this affect WordPress core updates too, or just plugins and themes?
The same file-write check runs for core updates, plugin updates, theme updates, and automatic background updates - they all go through the same WP_Filesystem check, so the same fix clears all four.