WordPress cannot move a plugin to upgrade-temp-backup

Identify the move that failed

A manual plugin update stops with “Could not move the old version to the upgrade-temp-backup directory”. In the WordPress forum case, a first update left a temporary folder. On the next attempt, the plugin disappeared from the list although its directory remained visible at the host. The thread reports several different file owners. It does not confirm which caused the rejection. The message nevertheless identifies a precise operation and lets you check the two affected locations.

For manual plugin and theme updates, WordPress can move the old version to a temporary location before putting the new one in place. For a folder-based plugin, the usual destination follows wp-content/upgrade-temp-backup/plugins/nom-du-dossier. The source is in the installation's plugins folder. Both paths may differ from usual values on a site customizing its folders or delegating updates to hosting. If package installation fails after setting the old version aside, core may try to restore old files. This temporary copy serves that operation; its presence does not guarantee full restoration.

Distinguish similar-looking messages. “Could not create the upgrade-temp-backup directory” concerns folder creation. “Could not move the old version” concerns movement from source to destination. A restoration-failure message concerns returning from the temporary copy. Each may involve different permissions or quotas. Database state needs a separate check. Restoring files alone does not replay a data migration a new version may already have started.

1. Record the time, exact plugin name, visible versions and complete message. Check whether an update is still active in the dashboard or at the host.
2. After the operation ends, record the plugin's state under Plugins > Installed Plugins. In multisite, also check Network Admin's Plugins screen if it is managed there.
3. Request copies of both folders if present before retrying. Core may try to delete that plugin's temporary directory before a new move. Another attempt can therefore erase evidence or the only complete copy remaining.

Check what still works before retrying

If the site is accessible, open a controllable plugin function through an appropriate session. For a form plugin, for example, load the staging page containing it and check that a dummy form opens. For a plugin managing an administration screen, open that screen with the intended account. Record version and status on the Plugins screen. An inactive plugin and an absent plugin require different checks. A folder visible at the host does not confirm that it contains the main file with its header or that expected files are readable.

If the site responds but an important feature disappeared, prioritize restoring a known version on an isolated copy. Request a backup recovering the plugin's exact directory and database state at update time. This check aims to determine whether both locations contain a complete version and which was actually used. A partial directory may mix files from different versions. Comparing only the version number in a main file cannot rule that out.

Avoid deleting the plugin through the interface to obtain a clean folder. Uninstallation may execute processing that removes data. Separate the safety copy, file restoration and reactivation. If the plugin was network-active, also measure results on a control subsite. On hosting that manages plugins through deployment, check which tool is intended to write these files. A deliberate write rule calls for the designated deployment flow.

1. Record the pre-intervention state: displayed version, local or network activation and one function you can retest.
2. Retain a file backup and a reference to the database backup. Do not reuse a temporary folder whose origin and version are uncertain.
3. If the site is unstable, avoid a second update during diagnosis. Prepare targeted restoration or ask the host to preserve both folders and associated logs.

Use the dashboard and Site Health

This route suits an administrator who can open the dashboard and has staging, even without a terminal. Open Tools > Site Health > Status and find checks for available update space and write access to the temporary-backup folder. Record results before correction. The general check may detect an inaccessible parent or an overfull disk. A favorable result does not prove that this plugin's subdirectory can be moved or cleaned by the update mechanism.

Under Plugins > Installed Plugins, identify the single component to test. On the copy, ensure the starting version and update mechanism match the observed case. A copy hosted elsewhere may have different permissions. If you cannot reproduce permissions, use the copy to verify file state and rollback, then request a move check on the original environment. For a plugin updated through a private package, retain the distribution channel intended by its publisher.

After the hosting owner corrects space or access, retry one manual update in staging. Record the first step that changes. If WordPress asks for FTP credentials, report it. It may use a different filesystem access mode from the one assumed. If the copy returns to the old version after failure, check its number and control function. If the failure message changes, retain the new text. Resolving a move rejection may reveal a different problem later in the update.

1. Record Site Health checks and plugin status. Give the hosting owner the time, plugin path and exact message.
2. Once correction is confirmed, run one staging update. Retain its result and open the control function.
3. If moving still fails, compare paths. If staging works but the original environment does not, request comparison of both filesystem access mechanisms.

Compare locations through SFTP or SSH

Using SFTP or a file manager, open the affected WordPress root, then its plugins folder. Record the exact plugin location and check that a recognizable main file sits at the correct level. Then compare the same-named folder under upgrade-temp-backup/plugins if present. Record displayed dates, owners and permissions for both directories and parents. Also check for a symbolic link or mounted volume. A persistent temporary directory may originate from something other than the latest operation. Back it up separately before moving it or requesting removal.

With a Linux terminal, the block below lists targeted paths and content-volume space. Replace the staging path and folder name. If the plugins folder has moved, also replace the plugins value. df -h reports volume space and df -i available filesystem entries. An account-specific quota may be lower than the volume shows. Ask the host to confirm. If both folders reside on separate mounts, also query the source volume. The command tests no move.

Then compare the terminal user's identity with the update mechanism's. Sufficient SSH or SFTP permissions do not imply that PHP or WordPress's FTP account can modify both parents. Ask the owner to check this for the domain, process and filesystem method involved. The operation may fail moving the original or handling an already-present destination. A system log may identify the step and error. Avoid applying ownership or recursive modes to the entire site. Have only the directory or rule preventing the authorized move corrected, and retain previous values.

content='/srv/recette/wordpress/wp-content'
plugins="$content/plugins"
dossier='extension-temoin'

for chemin in "$plugins" "$plugins/$dossier" \
  "$content/upgrade-temp-backup" "$content/upgrade-temp-backup/plugins" \
  "$content/upgrade-temp-backup/plugins/$dossier"; do
  if [ -e "$chemin" ] || [ -L "$chemin" ]; then
    ls -ld -- "$chemin"
  else
    printf 'Absent ou inaccessible %s\n' "$chemin"
  fi
done
df -h -- "$content"
df -i -- "$content"

Restore a complete version if the plugin no longer appears

If WordPress no longer recognizes the plugin after the incident, retrieve the exact working version from a verified backup or intended distribution channel. In a private folder, check that the package contains the plugin directory and main file at the expected level. If an archive adds an outer wrapper folder, remove that level in the preparation copy. Keep current state and temporary backup separate. Do not copy archive files over a mixture with unknown contents. In staging, prepare the selected version's complete folder and have it restored to the expected location through the site's management method.

A plugin becoming visible again may remain inactive. First check compatibility with staging PHP and WordPress, and that its settings remain present. Reactivate it only with its previous scope, local or network. Check a concrete function after activation. For a form, check opening and a captured dummy submission. For a component exposing a page, check the public response and associated administration screen. Consult the log afterward, because loading the main file may succeed while a dependency is missing.

Before restoring a backup folder, compare it with a reference package of the same version. Check directory name, main-file presence and expected file list. Through SSH, a sha256sum hash of the main file may show that two copies differ. An identical hash on that file alone does not validate dependencies. If the publisher's package contains customized files installed by your team, identify them and check how they are maintained before copying. For a third-party or paid package, use the source designated by your contract or team. An archive found in an old download folder does not verify its origin.

If files are restored but data no longer matches, compare with the database backup on a separate copy. A newer version may have changed table structure or options. In that case, restoring an old folder may be insufficient. Follow the maintainer's procedure before any database restore. A complete restore can erase writes made since the backup. Document scope and verify recovery on the copy before deciding the method for the affected site.

1. Check the package and set existing folders aside. Restore one complete folder to the intended location on the copy.
2. Confirm the version in the list and check the control function. If logs report a data issue, suspend reactivation and check compatibility between files and database.
3. If the attempt does not restore service on the copy, restore files retained before this test or return to the consistent staging snapshot. Keep both states for comparison.

Check a complete pass and the next update

A successful correction yields a new version visible in the list, preserves expected activation and lets the control function work. After the operation ends, check that this plugin's temporary folder was not left in an ambiguous state. Its parent may remain present or contain remnants of another operation. Check the precise target and log. If the version remains old after a later failure, compare its contents and behavior with the initial state to verify file restoration.

When a folder persists after an update reported successful, record its size, timestamp and exact name. Compare these clues with the operation log before concluding that WordPress failed to clean its copy. The old folder may come from an interrupted attempt or have been placed by a hosting tool. Have a copy retained outside the working directory tree and confirm with the owner that processing ended before handling the remnant.

The forum reports failure on a second pass. If two successive test versions are available in staging, check another update after the first. Otherwise, restore the test copy from its snapshot and repeat the same update, then record this comparison's limitation. Expected behavior is consistent moving and cleanup without an unexpected owner change. Keep the time and both paths so the host can match the test to system events. If a permission change fixed moving but harmed another function, restore the previous rule and resume comparison with narrower scope.

Interpret ownership before requesting a correction

Fictional example: the plugins folder belongs to deploy:deploy with drwxr-xr-x permissions, while PHP runs as www-data, which does not belong to the deploy group. PHP can read and traverse the folder, but these permissions alone do not allow it to move an entry there. The plugin working onscreen therefore does not prove the update mechanism can move it.

Ask the maintainer to compare the effective PHP account, ownership and permissions of the source and destination parent folders. ACLs, a read-only mount or server security rules may alter an analysis based only on displayed numbers. The solution must match this hosting's deployment method; copying a recursive chmod found elsewhere can break that arrangement.

Include the exact error, plugin slug, affected paths and space/inode readings in the ticket, without login credentials. Site Health is the free starting check; a cleanup plugin does not repair these permissions. After intervention, update one staging plugin, verify loading, then disappearance of the temporary-backup error. Retain previous permissions so a mistargeted change can be undone.