If WordPress refuses to install or update its core files, themes or plugins over FTP, and you see a string of "Could not copy file" or "Could not create file" errors, the cause is almost always the FTP server on the host, not your site. This guide explains the classic Pure-FTPd version of the problem, the workaround, and why it matters far less on a modern managed WordPress setup.
The symptom
Some server configurations running Pure-FTPd have trouble letting WordPress write files back over FTP during an upgrade. When you try to update WordPress core, or update or install a theme or plugin, the process fails partway through with messages that look like this:
- Could not copy file.: /wp-admin/css/theme-editor.dev.css
- Could not copy file.: /public_html/wp-admin/css/theme-editor.dev.css
- Could not copy file.: /.../.../wp-admin/css/theme-editor.dev.css
- Could not create file.: /public_html/
These cases all stem from the same underlying issue: WordPress can connect over FTP and read, but the way certain Pure-FTPd configurations report paths and permissions trips up the file copy step, so the new files never land where they should.
Why it happens
WordPress has more than one way to write files during an upgrade. On many hosts it writes directly through the web server user. Where that is not possible, it falls back to FTP and asks you for FTP credentials. It is that FTP fallback path, combined with how some Pure-FTPd builds present the filesystem, that produces the errors above. Nothing is wrong with your content or your database; the update simply cannot complete the copy.
The fix
A patch addressing this went into WordPress 3.2, and it made the workaround plugin obsolete for anyone running that version or later. The change was tracked in the WordPress core ticketing system as ticket 10913 (core.trac.wordpress.org/ticket/10913).
- If you are still on a pre-3.2 install that shows these errors, install and activate the compatibility plugin. Updates should then work as expected.
- As soon as you can, update WordPress core itself to a current release. Once you are past 3.2 the patch is built in and the plugin is no longer needed, so you can deactivate and remove it.
Because this fix dates back to the WordPress 3.2 era, the more useful long term action today is to run a supported, current version of WordPress. Modern releases do not carry this Pure-FTPd copy bug, and keeping core, themes and plugins patched is itself the single most important thing you can do for WordPress security, as the official WordPress hardening guide sets out.
Avoiding the FTP path altogether
The cleanest way to sidestep FTP upgrade problems is to let WordPress write files directly, so it never needs FTP credentials in the first place. That comes down to correct file ownership and permissions on the account. On our WordPress SEO hosting the accounts are configured so that one click updates run without dropping into the FTP fallback, which is where errors like the ones above appear.
If you run several WordPress sites across a network and want each one isolated on its own dedicated Class C IP, the same direct update behaviour applies per account, so you are not fighting FTP quirks on every property at once. For more WordPress specific answers, see the WordPress FAQ hub.
Quick checklist
- Confirm the errors mention "Could not copy file" or "Could not create file" during an update; that points at the FTP write path.
- On a pre-3.2 install, apply the compatibility plugin as a stopgap.
- Update WordPress core to a current version so the built in patch takes over and the plugin can be removed.
- Ideally, host on an account where WordPress updates itself directly and never has to ask for FTP details.
