WordPress file permissions: ownership, writable paths and the 777 trap

Identify the web/PHP and deployment identities

Check which Unix user PHP runs as, who owns the WordPress files, and which account performs deployments or plugin/theme updates. A shared-hosting model can differ from a VPS with a deployment user and service group.

Follow parent-directory permissions too; path traversal needs execute permission.

Separate writable content from code where practical

wp-content/uploads and specific cache/temp directories need writes in many installations. Core, themes, and plugins only need runtime writes if you intentionally allow browser-driven updates.

Disabling browser code editing or writes can reduce risk but requires an alternative update process.

Avoid world-writable fixes

chmod 777 solves permission checks by removing the boundary and can let unrelated processes/users modify files. Fix owner/group, ACL, umask, or service configuration instead.

Review sensitive files such as wp-config.php and backups for unnecessary read access.

Test updates and uploads after changes

Upload media, run the chosen plugin/core update path, clear cache, and inspect created-file ownership. Document the intended permission model so future troubleshooting does not undo it.

• Know the runtime and deploy users.
• Limit writable paths.
• Avoid 777.
• Verify ownership of newly created files.