WordPress Asking for FTP Credentials? Here’s the Real Fix

You click Install Now on a plugin, and instead of a progress bar WordPress shows you a form titled “Connection Information” asking for a hostname, an FTP username, and an FTP password. You never set up FTP. You don’t even know if the server has it. When WordPress is asking for FTP credentials, it isn’t asking because it needs FTP. It’s telling you it can’t write to its own files, and the FTP form is just the fallback it reaches for.

The good news: this is a file ownership problem with a clean, permanent fix. The bad news: the most popular “fix” on the internet hides the problem instead of solving it. Here’s how to tell the difference and fix it properly.

Why Is WordPress Asking for FTP Credentials?

WordPress asks for FTP credentials when the PHP process running the site does not own the WordPress files, so WordPress decides it can’t safely write to them directly. Instead of failing, WordPress falls back to connecting over FTP, FTPS, or SSH and shows the “Connection Information” form to get the login details for that connection.

The check happens inside a core function called get_filesystem_method(). According to the WordPress developer reference, the function first looks for an FS_METHOD constant. If none is set, it creates a temporary temp-write-test- file in the folder it wants to write to, then compares the owner of that new file with the owner of WordPress’s own core file. If the owners match, WordPress writes directly. If they don’t, WordPress falls back to SSH2, the FTP extension, or FTP sockets, and that fallback is what triggers the prompt.

That detail matters. The FTP prompt is not about permissions being “too strict” in the way most people assume. WordPress can sometimes write to the folder just fine and still show the prompt, because the ownership check fails. Making folders world-writable with 777 won’t reliably fix it, and it creates a much bigger problem.

Where the FTP credentials prompt usually shows up

• Self-managed VPS servers (DigitalOcean, Linode, Hetzner, AWS Lightsail) where Nginx or Apache runs PHP as www-data or nginx, but the files were uploaded by a different user.
• Freshly migrated sites where the files were extracted or copied as root, so root owns everything.
• Docker and local dev setups with bind-mounted folders, where the files on the host belong to your user but PHP inside the container runs as someone else.
• Servers with SELinux enforcing (CentOS, Rocky Linux, RHEL), where ownership looks correct but the security context blocks writes.

Most cPanel shared hosting runs PHP as the account’s own user, which is why the WordPress FTP credentials prompt is far more common on VPS and custom server setups than on standard shared hosting.

Step 1: Confirm It’s an Ownership Problem in Site Health

The fastest way to confirm the cause is WordPress’s built-in Site Health screen. Go to Tools → Site Health → Info and open the Filesystem Permissions section, which lists whether the WordPress directory, wp-content, uploads, plugins, and themes folders are writable.

If any of those show “Not writable,” the fix is file ownership or permissions on the server, and the steps below apply. If everything shows “Writable” and WordPress still asks for FTP credentials, the ownership check is the culprit: PHP can write to the folders but doesn’t own them.

Before touching anything on the server, take a backup or work on a copy. A WordPress staging site is the safest place to test ownership changes if you’re not comfortable on the command line.

Step 2: Fix File Ownership (The Real Fix)

The permanent fix for WordPress asking for FTP credentials is to make the user that runs PHP the owner of the WordPress files. Once the owners match, WordPress’s ownership check passes, it switches to direct file writes, and the “Connection Information” form disappears without any wp-config.php changes.

First, find out which user PHP actually runs as. On most Linux servers with PHP-FPM, this command shows it:

ps -eo user,comm | grep -E 'php|apache|httpd|nginx' | sort -u

You’re looking for the user next to the php-fpm worker processes (not the master process, which usually runs as root). On Ubuntu and Debian that’s typically www-data. Then compare it with who owns the files:

ls -la /var/www/example.com/wp-content

If the owner column says root or your SSH username while PHP runs as www-data, that mismatch is exactly why WordPress keeps asking for FTP credentials. Change the ownership to the PHP user (replace the path and user with your own):

sudo chown -R www-data:www-data /var/www/example.com

Then reset permissions to the standard WordPress values: 755 for folders and 644 for files, with wp-config.php locked down further.

cd /var/www/example.com
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 640 wp-config.php

Reload the plugin install screen. If the ownership was the issue, the FTP prompt is gone. If your server uses SELinux, you may also need to allow web server writes to wp-content with sudo chcon -R -t httpd_sys_rw_content_t wp-content, since SELinux can block writes even when Linux ownership is correct.

Never “fix” this with chmod -R 777. World-writable files let any process on the server modify your site, which is one of the classic ways a WordPress site gets hacked. Many hosts also block 777 files outright, which can turn the FTP prompt into a 500 internal server error. It also doesn’t reliably remove the FTP prompt, because 777 changes permissions, not ownership.

Step 3: The FS_METHOD Direct Shortcut (Use With Care)

Adding define( 'FS_METHOD', 'direct' ); to wp-config.php tells WordPress to skip the ownership check and write files directly. It removes the FTP credentials prompt instantly, but it only works if PHP already has write access to the folders, and it hides the ownership mismatch instead of fixing it.

This is the fix most guides recommend first, including GoDaddy’s own help article on the WordPress FTP popup. It goes in wp-config.php, above the line that says /* That's all, stop editing! Happy publishing. */:

define( 'FS_METHOD', 'direct' );
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

The two FS_CHMOD lines make sure any files and folders WordPress creates get sane permissions instead of whatever the server defaults to.

Here’s the catch. If PHP can’t actually write to wp-content, FS_METHOD direct doesn’t fix anything. The FTP prompt disappears, and you get a new error instead: “Installation failed: Could not create directory.” That’s the same ownership problem surfacing one step later. FS_METHOD direct is a good shortcut on a server you control where ownership is already correct. It is not a substitute for Step 2.

Is it safe to use FS_METHOD direct?

FS_METHOD direct is safe on a server where each site runs PHP as its own user, which covers most VPS setups and modern managed hosts. It’s riskier on old shared servers where PHP runs as one shared user (like nobody) for every account, because files WordPress writes would then be owned by a user that other sites on the same server also run as. If you’re on that kind of host, ask them to fix ownership rather than forcing direct writes.

Step 4: Save FTP or SFTP Details in wp-config.php (If You Really Need FTP)

Some hardened servers deliberately keep WordPress files owned by a separate user so PHP can’t modify them, and use FTP or SFTP for updates on purpose. In that setup, the right move is to store the connection details in wp-config.php so WordPress stops asking every time.

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_HOST', 'localhost' );
define( 'FTP_USER', 'your-ftp-username' );
define( 'FTP_PASS', 'your-ftp-password' );
define( 'FTP_SSL', true );

For SFTP over SSH, set FS_METHOD to ssh2 and use FTP_PUBKEY and FTP_PRIKEY with paths to a key pair. The ssh2 method requires the PHP SSH2 extension, which many servers don’t have installed, so check with php -m | grep ssh2 first.

The trade-off is obvious: a plain-text FTP password now lives in wp-config.php. Lock that file to 640 or 600 permissions, and use a dedicated FTP account limited to the WordPress folder rather than your main hosting login.

Which Fix Should You Use?

Fixing file ownership is the right answer for almost everyone, because it removes the cause instead of working around it. FS_METHOD direct is a fine shortcut once ownership is correct, and saved FTP or SFTP credentials only make sense on servers that are intentionally locked down.

Fix	Fixes the root cause?	Needs server access?	Best for
Fix file ownership (chown)	Yes	SSH or host support	VPS, migrated sites, Docker
FS_METHOD direct	No, bypasses the check	wp-config.php only	Servers where ownership is already correct
FTP/SFTP constants in wp-config.php	No, uses FTP on purpose	wp-config.php plus an FTP or SSH account	Hardened servers with read-only files
Typing credentials into the prompt	No	Working FTP service	One-off installs only

Typing your credentials into the prompt each time is the worst option. It often fails outright because many modern servers don’t run an FTP service at all, and even when it works, you’ll be asked again on the next update. That’s also a common reason updates stall halfway and leave a site stuck in maintenance mode.

What If the FTP Prompt Comes Back After Fixing It?

If WordPress starts asking for FTP credentials again after you fixed it, something on the server is creating files with the wrong owner. The usual culprits are deployment scripts, cron jobs, or manual uploads run as root or a different SSH user.

• Deploy tools and Git pulls run as your SSH user leave new files owned by that user. Run them as the PHP user, or add a chown step to the end of the deploy.
• WP-CLI run as root creates root-owned plugin folders. Run it as the web user with sudo -u www-data wp plugin update --all.
• SFTP uploads through a separate account create files owned by that account. Add that user to the PHP user’s group and set group-write permissions, or fix ownership after uploading.

One related symptom is worth separating out: if the “Add New Plugin” button and update links are missing entirely, that’s not an ownership problem. It usually means DISALLOW_FILE_MODS is set to true in wp-config.php, which blocks all plugin and theme installs from the dashboard on purpose.

The Bottom Line

When WordPress is asking for FTP credentials, treat it as a message about file ownership, not FTP. Find the user PHP runs as, make it the owner of the WordPress files, reset permissions to 755 and 644, and the prompt goes away for good. Reach for FS_METHOD direct only after that, and never reach for 777.

After 10+ years building WordPress sites and 950+ Fiverr client projects, the server setups that cause the fewest update headaches tend to share one trait: one clear owner for the files, and it’s the same user PHP runs as.

Frequently Asked Questions