WordPress Asks for FTP Credentials on Update? Real Fix

· 6 min read · 2 views · Getwebup

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 file even 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/644 is normal - but if wp-content, wp-content/plugins, or wp-content/themes got locked down to something tighter (or the ownership is root/another cPanel account), PHP can't write there.
  • A hardcoded FS_METHOD in wp-config.php. Some security plugins or old migration guides add define('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:

  1. Download the plugin or theme's latest .zip from WordPress.org (or your premium plugin's site).
  2. 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.
  3. 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 -R command 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_METHOD overrides unless a specific plugin's documentation tells you to. It's rarely needed on Getwebup's cPanel servers.
Error messageMost likely causeFix
FTP credentials popupPHP can't write to wp-content directlyFix ownership/permissions, remove forced FS_METHOD
Could not create directoryDisk quota or inode limit reached, or bad permissions on wp-contentFree up space, then fix permissions
Download failed. Not a valid zip fileTruncated download from full disk, or a security plugin blocking the requestCheck disk usage; upload the zip manually if it keeps failing
Auto-updates silently stopOwnership mismatch after a migration or restoreRun 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.

Questions people actually ask