A WordPress permission error after a host migration often means the restored files belong to a different account from the PHP process that must write them. Check ownership and the hosting model before changing permission numbers. A directory can look writable to your SSH account while remaining unwritable to WordPress.
This guide applies when media uploads, plugin updates, or generated CSS stopped working after a move. If the error says no space left on device, use the disk and inode guide first. These failures need different repairs.
Identify the exact write that failed
Copy the error, affected path, and timestamp into a private incident note. Distinguish creating an upload directory, writing the original image, generating a thumbnail, unpacking an update, and moving extracted files into place. Success at one step does not establish permission for another.
With authorized shell access, inspect the relevant directories from the WordPress installation. These commands read metadata and do not modify access:
pwd
id
ls -ld . wp-content wp-content/uploads
Ask the host to compare these owners and groups with the PHP-FPM pool or other web-process identity. The user shown by the shell's id command is not necessarily the account running browser requests. Include parent-directory traversal permissions in that comparison.
Separate three possible restrictions
| Evidence |
Investigation |
| Restored directory owned by the former account |
Migration ownership mapping |
| Correct owner, unexpected access denial |
ACL, read-only mount, or host security policy |
| Original upload works, generated files fail |
Destination path and image-processing temporary directory |
The WordPress file-permissions handbook explains why the process identity matters. Its examples span different hosting models. Do not treat one numerical permission setting as a universal prescription.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Have the host repair the narrow mismatch
Provide the failing path, current owner, expected application account, and operation. Request the smallest ownership or access correction consistent with the host's deployment model. A managed service may deliberately keep application code read-only while allowing uploads elsewhere.
Avoid recursive ownership changes across the account. They can break deployment access, isolated applications, backups, and shared services. Do not set directories to 777 or disable a security policy just to see whether the error disappears. Those changes can create a different incident while hiding the original cause.
If a plugin asks for FTP credentials only after the move, investigate the filesystem method and ownership with the host. Do not paste production passwords into a support ticket or force a filesystem method without understanding the host's requirements.
Verify both writing and delivery
Upload a small harmless image through WordPress. Open the original and generated sizes as a logged-out visitor. If Elementor was affected, regenerate one test page's styles and verify the stylesheet actually loads. A successful write and a public 403 are separate problems.
Repeat the normal deployment or backup process that might reset ownership. Record whether the correction survives it. Otherwise the next automated release may restore the failure.
For an unresolved migration, request help with the failing filesystem operation. Bring sanitized paths and ownership evidence, not a full server directory listing or private credentials.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.