Fix WordPress File Ownership So Plugin Updates Work Without FTP Prompts

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

If WordPress repeatedly asks for FTP credentials or reports that a plugin update failed, the usual cause is a mismatch between the account that owns your files and the account running PHP. WordPress first tests whether its process can create, replace, and delete files. When that test fails, its Filesystem API falls back to FTP, FTPS, SFTP, or SSH credentials.

The reliable fix is not to make everything world-writable or to force direct updates. Back up the site, identify the real PHP/web-server account, inspect ownership, select an ownership model appropriate to your host, change only the affected paths, and then retry the update.

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

Why WordPress asks for FTP credentials

A plugin update is a filesystem operation, not just a download. WordPress must write the package, unpack it, replace the existing plugin directory, remove obsolete files, and create a temporary .maintenance marker while the update runs. Before doing that, WordPress checks whether the PHP process can write to the relevant directories.

When the files are owned by the account running the web server, and newly created files will inherit suitable ownership, WordPress can use direct filesystem I/O. No credentials are needed because the operating-system permission check succeeds. If the process cannot write safely, WordPress uses its Filesystem API to request another method, such as FTP, FTPS, SFTP, or SSH.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Ownership is host-dependent. On one server the PHP worker may run as www-data; on another it may run as apache, nginx, nobody, a per-site user, or a pool-specific account. Shared hosting may intentionally keep files owned by your hosting or FTP account rather than by a common web-server user. That is why copying a command that changes everything to www-data can break a site or weaken its isolation.

Direct updates versus credential-based updates

The deciding factors are the file owner and group, the account running PHP, whether the site is shared or single-user, the encryption of any remote transport, and whether the arrangement follows least privilege.

Prepare before changing ownership

1. Back up the database and files. Make a current, restorable backup of the WordPress directory, uploads, configuration, and database. A permissions change can make the site or other applications inaccessible if the path or account is wrong.
2. Confirm the document root. Locate the directory that contains wp-admin, wp-includes, wp-content, and wp-config.php. A control-panel account may contain several sites, so do not assume the first public directory is the one you need.
3. Choose a maintenance window. Updating a plugin changes live code. If you will be changing ownership recursively, schedule a time when you can test the front end, dashboard, scheduled jobs, and any connected services.
4. Record the current state. Save the output of ownership and permission checks before editing. This gives you a rollback reference and helps your host support team diagnose the change.

Identify the account that runs PHP

Do not assume the answer is www-data. First determine how the site executes PHP: Apache with a module, PHP-FPM behind Apache or Nginx, a per-user hosting pool, or a managed platform. The control panel or hosting documentation may state the account directly.

On a server where you have shell access, an administrator can inspect running processes with a command such as ps -eo user,group,comm,args | egrep 'php-fpm|apache2|httpd|nginx'. PHP-FPM pool configuration commonly contains a user and group setting; the value for the pool serving this site is the relevant one. Process listings can show a master process rather than the worker, so confirm the pool or worker account instead of relying on a single line of output.

On shared hosting, you may not be able to inspect processes. Ask support which account executes PHP for your domain and whether the provider expects files to remain owned by your FTP account. If support cannot provide that information, use the provider’s documented permission tool rather than guessing.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

Inspect the WordPress paths and their owners

Check the document root, wp-content, and wp-content/plugins separately. Ownership on a parent directory can differ from ownership on plugin directories, and an update can fail because one nested directory is not writable even when the top-level listing looks correct.

With shell access, use read-only commands first:

ls -ld /path/to/wordpress /path/to/wordpress/wp-content /path/to/wordpress/wp-content/plugins
find /path/to/wordpress/wp-content/plugins -maxdepth 2 -type d -printf '%M %u:%g %pn' | head -n 40
stat -c '%A %U:%G %n' /path/to/wordpress/wp-content /path/to/wordpress/wp-content/plugins

Replace the example path with the confirmed document root. The first fields show mode bits; the owner and group identify which accounts can modify the directories. A directory also needs execute permission to be traversed. A file that is writable but sits inside a non-writable directory can still prevent an update.

Use the file manager or SFTP client’s properties view if you do not have shell access. Look for the owner, group, and permissions on the same three paths. Avoid editing permissions on the entire home directory, server root, or unrelated sites while investigating one WordPress installation.

Choose the ownership model that matches your host

Single-user or dedicated server

On a dedicated server, the PHP worker and the site administrator may be the same account, or the worker may be a dedicated account that is also the owner of the WordPress files. The goal is that the PHP process can create temporary files and replace plugin directories without granting access to unrelated applications.

If administration is performed by a separate shell user, a common least-privilege design is a shared group: the site files are owned by the administrator, the PHP account belongs to the site group, and group write permission is granted only where WordPress must update files. The exact group and mode depend on the server’s umask, deployment process, and isolation settings.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

Shared hosting

Many shared hosts deliberately keep files owned by your hosting or FTP account while PHP runs in a restricted per-site environment. In that model, changing ownership to a global web-server account can make the files inaccessible to your account or violate the provider’s isolation rules. Keeping the provider’s ownership and entering SFTP, FTPS, or the host’s supported credentials when WordPress asks may be the safer and intended workflow.

When you are unsure

Do not change ownership until the host confirms the execution model. A managed WordPress provider can apply the provider-specific fix, and a server administrator can verify the PHP-FPM pool, group membership, and access-control layers. The right owner is the account that the host designed to manage this site, not a universal username.

Repair only the affected paths

Use the hosting provider’s documented chown, chgrp, and permission procedures. The following patterns illustrate the scope of a repair; substitute the confirmed account, group, and path, and have an administrator review them before execution:

chown -R SITEUSER:SITEGROUP /path/to/wordpress/wp-content
find /path/to/wordpress/wp-content -type d -exec chmod 755 {} ;
find /path/to/wordpress/wp-content -type f -exec chmod 644 {} ;

These are examples, not universal prescriptions. Some hosts require a different owner, a different group, ACL entries, or tighter modes. Some deployment systems intentionally use group-writable directories. Applying a recursive command to the wrong path can change another site, a system directory, or files that must remain protected. Confirm the path with pwd, use an absolute path, and review the command before pressing Enter.

Change only what the update requires. If the problem is limited to wp-content/plugins, do not recursively rewrite ownership of the whole server. If a single plugin directory has an incorrect owner, repair that directory after checking whether a deployment tool or security policy will immediately revert it. Preserve special files such as wp-config.php according to the host’s hardening guidance rather than applying one mode to every file.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

Retry the update and remove a stale maintenance marker

1. Log in to WordPress and open Dashboard > Updates.
2. Run the plugin update again, or open Plugins and select the individual plugin’s update link.
3. Watch for a completion message and verify that the plugin version changed. Then load the public site and a representative dashboard screen.
4. If WordPress still requests credentials, use the host-approved SFTP, FTPS, FTP, or SSH method. Direct updates are not mandatory when the remote method is secure and correctly configured.

A failed update can leave a .maintenance file in the WordPress directory. When that marker remains after the underlying problem is fixed, WordPress may continue displaying a maintenance or failed-update notice. Connect with the approved FTP or SFTP method, show hidden files, and remove only .maintenance from the WordPress root. Do not delete similarly named files elsewhere, and do not remove the marker while an update is genuinely still running.

Security boundaries: fixes that create bigger problems

Never use 777 as a blanket fix

Mode 777 gives owner, group, and every other local process read, write, and execute access. WordPress warns that world-writable files let server processes or other users modify the installation, creating a security exposure. It also hides the real ownership problem and can allow an unrelated compromised account to alter executable PHP code.

Do not force direct mode just to suppress a prompt

Adding define('FS_METHOD', 'direct'); to wp-config.php can force WordPress to attempt direct file I/O, but WordPress documents that direct access can be unsafe on poorly configured hosts. It does not repair ownership, group membership, or directory permissions. Remove an override that was added only to silence the prompt unless the host explicitly requires and supports it.

Prefer encrypted remote access

If credentials are necessary, prefer SFTP or FTPS when the host supports them. Plain FTP does not provide the same transport protection. Use a dedicated account limited to the site, strong authentication, and the smallest directory scope the provider allows.

Troubleshooting by symptom

Verify the repair without weakening the site

• Confirm the PHP execution account and the owner/group of the document root, wp-content, and wp-content/plugins.
• Update a small, non-critical plugin and confirm that WordPress can create, replace, and remove files.
• Check the front end, administrator login, media uploads, scheduled tasks, and any cache or security plugin that depends on writable directories.
• Review the resulting modes and ownership; ensure no unrelated directory became writable by everyone.
• Keep the backup and the before-change ownership record until the site has operated normally through at least one update cycle.

If you cannot identify the PHP account, the correct document root, or the host’s intended ownership model, stop before running recursive commands. Request server-permissions help or use WordPress hosting with filesystem support that documents its PHP user and update method. A short support intervention is safer than a broad permission change that exposes multiple sites.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.