An update asks for FTP credentials, uploads fail, or WordPress says it cannot create a directory. Numeric permissions alone do not explain the failure; ownership, process user, parent directory, ACLs, and hosting policy also matter.
Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to identify the exact account and path involved in an update or upload failure without weakening the entire WordPress tree.
Likely failure paths
- Files were copied or deployed under a different owner than the PHP process expects.
- A parent directory is not writable even though the final path looks correct.
- A security control, immutable attribute, quota, or read-only deployment blocks writes.
The branches are ordered to protect the strongest evidence around this possibility: files were copied or deployed under a different owner than the PHP process expects. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Access recovery is also a security event; the goal is not merely to get one administrator back in; it is to restore the intended trust path without leaving a reusable bypass or erasing evidence of unauthorized changes; in this guide, the practical goal is to identify the exact account and path involved in an update or upload failure without weakening the entire WordPress tree.
A controlled investigation
- Identify the PHP/web process user and the owner/group of the failing path.
- Inspect each parent directory, available disk space, inode quota, and any ACL.
- Compare the host’s documented permission scheme before changing modes.
- Test creation of one harmless file in the exact target through the same deployment path.
The sequence moves from observation toward intervention. Preserve the result of the final check—test creation of one harmless file in the exact target through the same deployment path—because it provides a useful comparison after the repair.
Inspect ownership before changing a mode bit
Run read-only inspection against the exact path named in the update error. The process user must fit the host’s ownership model.
id
stat -f '%Su:%Sg %Sp %N' wp-content wp-content/plugins
find wp-content/plugins/problem-plugin -maxdepth 2 -type f -exec stat -f '%Su:%Sg %Sp %N' {} \;Interpretation and safety: The stat format shown is for macOS/BSD; GNU stat uses different flags. Do not respond with recursive chmod 777—correct the owner/group and only the paths that are wrong.
Worked diagnostic: evidence before action
The opening hypothesis is files were copied or deployed under a different owner than the PHP process expects. Test it with the least invasive observation available: identify the PHP/web process user and the owner/group of the failing path. Do not change configuration until the observation has been saved with a timestamp.
When that evidence is consistent with the hypothesis, stage this repair: correct ownership or group membership according to the hosting model. Otherwise, preserve the current state and advance to the next branch. This keeps rollback simple and prevents a second change from masking the first.
Make the smallest durable change
- Correct ownership or group membership according to the hosting model.
- Apply the narrowest needed directory/file modes to the named path.
- If production is intentionally immutable, perform updates through the deployment system instead of granting runtime writes.
Before applying “Correct ownership or group membership according to the hosting model,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can repeat the specific update or upload; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Close the incident with evidence
- Repeat the specific update or upload.
- Confirm public PHP cannot write into executable locations it does not need.
- Review the change recursively only within the intended WordPress directory.
One successful refresh is not closure. Keep the incident open until you can also confirm public PHP cannot write into executable locations it does not need, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Keep an incident note with the verified account, operator, time, recovery channel, changed credentials or roles, and every temporary file or exception created; rotate exposed secrets and remove emergency access as part of the same change; include the result of this first observation: identify the PHP/web process user and the owner/group of the failing path.
State what was tested, including the result of “Identify the PHP/web process user and the owner/group of the failing path,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Do not trade visibility for a green screen
- WordPress explicitly warns against 777 because it grants excessive write access.
- Do not run recursive chmod/chown from an unverified current directory.
Incident handoff
Primary references
- WordPress file permissions — official reference consulted for this guide.
- WordPress hardening — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Correct ownership or group membership according to the hosting model”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.