The Uploaded File Could Not Be Moved to wp-content/uploads

Why it happens

• The month folder (for example uploads/2026/10) belongs to another user than the one PHP runs as. This usually happens when something run as root made the folder first: a WP-CLI command, a cron job, a restore or an SFTP upload as another account.
• The folder has the right owner, but its mode takes away the owner's right to write, for example 555.
• The Store uploads in this folder setting under Settings → Media points to a folder that exists on this server but that PHP cannot write in. The message then names that folder, for example oldmedia/2026/10.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

WordPress found this month's folder in wp-content/uploads, but PHP is not allowed to put a file in it. The folder exists, so WordPress did not try to make it, and the move at the end failed. The fix is to make the folder belong to the user PHP runs as, with mode 755.

What you see#

The message appears under the file name on Media → Add Media File, in the media library uploader, and in WP-CLI. The folder in the message is the month of the upload:

WP-CLI prints the same text:

Warning: Unable to import file '/tmp/sourdough-loaf.png'. Reason: The uploaded file could not be moved to wp-content/uploads/2026/10.Error: No items imported.

How it works#

WordPress does two things in order, and each has its own message.

First, wp_upload_dir() calls wp_mkdir_p() for the month folder. That function returns true as soon as the path exists as a folder. It never asks whether PHP can write there. Only when the folder is missing does it try to make one, and a refusal gives "Unable to create directory". That message has its own page: could not create directory.

Second, WordPress moves the file. A browser upload (wp_handle_upload()) uses PHP's move_uploaded_file(). A sideload (wp_handle_sideload(), used by WP-CLI and the REST API) uses copy() and then unlink(). When the move returns false, WordPress shows this message, the same text for both. The calls are written with @, so PHP's own warning is hidden. I switched on WP_DEBUG_LOG and repeated the failed import, and debug.log was never created. The message is all you get.

So the two messages point at different folders:

Why it often starts on the first of a month#

With month folders on, WordPress makes a new folder for each month, owned by whoever creates it. If a WP-CLI command, a cron job or a restore runs as root and makes uploads/2026/11, that folder belongs to root. Uploads work all October and fail on the first of November, when the first browser upload meets that folder. I reproduced this without waiting for November. I ran wp --allow-root as root to make uploads/2026/11, then called WordPress's sideload function as www-data for that month:

{"error":"The uploaded file could not be moved to wp-content\/uploads\/2026\/11."}

After chown www-data:www-data wp-content/uploads/2026/11, the same call returned the new file's path and URL.

Site Health does not catch it#

Tools → Site Health → Info → Filesystem Permissions checks only the top-level uploads folder, not the year and month folders inside it. With the month folder owned by root, Site Health still said Writable:

Owner, mode and the write test#

Folders I tried on the same site, all with the same file:

Ownership comes first. With mode 755 only the owner can write, so 755 helps only when the owner is PHP's user. The same site, checked from the shell:

drwxr-xr-x 2 root root 4096 Oct 30 07:26 ./2026/10

cd wp-content/uploadschown -R www-data:www-data .find . -type d -exec chmod 755 {} +find . -type f -exec chmod 644 {} +

drwxr-xr-x 2 www-data www-data 4096 Oct 30 07:26 2026/10

Edge cases I tested#

• Month folders off. With Organize my uploads into month- and year-based folders unticked and uploads owned by root, the message ended in wp-content/uploads. with no year or month. Giving uploads back to www-data fixed it.
• Upload Path in use. With upload_path set to /srv/oldmedia, which existed on the server and belonged to root, the message read "...could not be moved to oldmedia/2026/10." WordPress shows only the last part of a path that is outside its own folder. With upload_path set to a path that did not exist, the message was "Unable to create directory uploads/2026/10", the other error.
• Leftover files. A wp media import that I ran as root left three files owned by root in the month folder. Folder and files then needed fixing together, which chown -R does. The find . ! -user www-data command above found them.

If it keeps coming back#

Something keeps creating folders as the wrong user. Run WP-CLI as the site's user (sudo -u www-data wp ...) and check what your backup or restore tool runs as. Do not run wp as root. For the 755 and 644 values on a whole site, see the 500 error page. Image-resizing failures after a successful move are a different error: the server cannot process the image. If PHP cannot even hold the file while it arrives, the message is missing a temporary folder. If WordPress says the file is too big before it gets this far, see file exceeds the maximum upload size. After moving a site, check the settings that came across.