The Scenario
Everything seemed perfect after migrating a client’s site to a fresh DigitalOcean droplet. However, the moment I tried to update a plugin, the process hit a wall. Instead of the usual progress bar, a grey popup demanded FTP credentials.
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed.
It’s a headache because modern cloud hosting rarely uses traditional FTP anymore. We use SSH/SFTP or direct file management. Seeing this prompt doesn't mean your server is broken. It simply means WordPress realized it doesn't have the "keys" to write files directly to your disk.
Why This Happens
WordPress runs a quick background check before every update. It tries to create a tiny temporary file in your wp-content directory. If the owner of that new file doesn't match the owner of the directory, WordPress gets suspicious. It assumes it lacks direct write access and falls back to the legacy FTP method as a safety measure.
This mismatch usually stems from three specific issues:
- User Mismatch: Your web server (like
www-data) isn't the owner of the WordPress files. - Root Uploads: You uploaded the site files via SSH using the
rootuser. - Restricted Permissions: Your folder permissions are set too tightly, such as 555 instead of the standard 755.
The Quick Fix: Forcing FS_METHOD
If you're in the middle of a launch and need a 30-second solution, you can bypass the ownership check entirely. This tells WordPress to stop asking questions and just write the files. This is a common band-aid for 90% of users.
- Access your server via SFTP or your hosting file manager.
- Open
wp-config.phpin your site's root folder. - Paste this line right above the "That's all, stop editing" message:
define('FS_METHOD', 'direct');
Warning: If your underlying permissions are still set to "Read Only," this will just trade the FTP prompt for a "Could not create directory" error. If that happens, you need the permanent fix below.
The Permanent Fix: Correcting Ownership
The cleanest way to solve this is to make sure your web server actually owns your files. On Ubuntu or Debian, the user is almost always www-data. On CentOS or RHEL, you'll likely see apache or nginx.
Step 1: Identify your web server user
Not sure who is running your PHP? Run this command to find out:
ps aux | grep php
Look at the leftmost column. If you see www-data or httpd, that is the user you need to use in the next step.
Step 2: Reclaim Ownership
Head to your web root (usually /var/www/html). Run this command to hand ownership back to the web server:
# Replace /var/www/html with your actual path
sudo chown -R www-data:www-data /var/www/html
Step 3: Reset Permissions to Industry Standards
Security is a balancing act. You want 755 for directories and 644 for files. If these numbers feel like gibberish, use a Unix Permissions Calculator to visualize what you're changing. It helps ensure you aren't accidentally giving the public write access to your sensitive files.
Apply these standard permissions from your WordPress root:
# Fix all directories to 755
find . -type d -exec chmod 755 {} \;
# Fix all files to 644
find . -type f -exec chmod 644 {} \;
Verification
Go back to your WordPress Dashboard and try that update again. The FTP prompt should vanish instantly. If you added the FS_METHOD line earlier, you can safely delete it now. Your server is now configured correctly enough that WordPress doesn't need the "direct" hint anymore.
A Final Word on Security
While chown -R www-data works perfectly for private VPS setups, be cautious on shared servers where multiple users might have access. While you're cleaning up your wp-config.php, it’s a good time to rotate your security keys. Use a secure password generator to create unique strings for your database and salts. This ensures your site stays locked down after you've fixed the access hurdles.
If the prompt persists, check if your server uses mod_ruid2. This Apache module changes how users are handled and might require ownership to match your specific FTP username instead of the web server user.