WordPress needs the PHP/update process to write selected core, plugin, theme and upgrade directories. A “permission denied” error identifies a filesystem ownership or mode mismatch, not a reason to make the whole site world-writable.
Capture the exact path and process user before changing permissions recursively.
Record the failing operation
Note core/plugin/theme, package version, time and full protected error path. Check PHP and web server logs.
Identify:
file/directory
owner and group
numeric/symbolic mode
PHP handler/user
filesystem method
disk/inode stateRedact hosting account names from shared reports.
Confirm the active PHP user
cPanel/Plesk may run PHP as the account user, a pool user or shared web user. CLI commands may run as another user and create files WordPress cannot later replace.
Use hosting tools or process/log evidence. Do not infer the user solely from neighbouring file ownership.
Align deployments, cron and WP-CLI with the intended account user.
Inspect parent directories
Writing a file requires appropriate permissions on each parent directory. Check the failing path and ancestors, including wp-content/upgrade, plugin/theme directory and temporary path.
A correctly writable final directory can still fail when an ancestor lacks execute/traverse permission.
Do not change unrelated uploads or configuration when the error names one package directory.
Use hosting-supported ownership repair
On shared hosting, cPanel/Plesk or the provider should repair ownership created by restores or migrations. On a VPS, use an administrator who understands the PHP handler and deployment model.
Typical 755 directories and 644 files are common, not universal. Ownership is often more important.
Never apply recursive 777; it permits unauthorised writes and still may not solve SELinux/ACL issues.
Check ACLs and security policy
Access control lists, immutable attributes, SELinux/AppArmor and read-only mounts can deny writes despite normal mode bits.
Use system audit logs and approved tools. Do not disable the entire security policy to permit WordPress updates.
Create the narrow policy/label required by the hosting design and retest one file operation.
Remove stale upgrade files safely
An interrupted update can leave wp-content/upgrade or a destination directory owned by another user. Back up and confirm no update process runs.
Remove only the specific temporary package/directory through the same trusted account. Do not delete the active plugin before retaining its current files and rollback.
Check disk and inodes before retrying extraction.
Review WordPress filesystem credentials
When WordPress cannot write directly, it may request FTP/FTPS credentials. Confirm the host supports that method and the account is restricted to the correct site root.
Do not store FTP passwords in wp-config.php unless the hosting design and secret policy explicitly require it. Prefer SFTP/secure deployment; plain FTP exposes credentials. A repeated credential prompt can mean ownership prevents direct writes, not that the password is wrong.
Decide whether WordPress should write code
Some managed or version-controlled deployments intentionally make production code read-only. In that design, updates belong in staging/build/deployment, not the WordPress dashboard.
Do not weaken immutable infrastructure. Update the source repository/package and deploy through the authorised pipeline.
Keep uploads and cache directories separately writable as required.
Verify directory inheritance
New files can inherit group, ACL or umask settings different from existing files. Create and remove one harmless test file through the same PHP/deployment user, then inspect its owner and mode.
Correct the default group/ACL/umask so the next update remains writable; a one-time recursive chmod will otherwise regress. Coordinate with the host where panel processes reset ownership automatically.
Verify security and updates
Retry one trusted update and confirm old files are replaced cleanly, no mixed version remains and OPcache clears. Test public/admin functions.
Review for overly broad writable files afterward, especially wp-config.php and code directories. Recurring care should check ownership after migrations/restores and document the one approved update path so permission fixes do not become security regressions.