WordPress “Destination folder already exists”: fix installs without a wp-content mess

What the error really means (and what it doesn’t)

WordPress throws “Destination folder already exists” when it tries to install or update a plugin/theme and discovers that the target directory name is already present. That sounds obvious, but the key detail is this: WordPress can’t confidently decide whether the existing directory is a healthy existing install, a partial extraction, a stale leftover from a failed update, or something it shouldn’t touch.

So WordPress plays it safe and bails. That’s usually the correct choice. Your job is to determine whether you’re looking at:

• A legitimate existing plugin/theme (you’re trying to “install” something that’s already there).
• A partial install (directory exists but missing files; WordPress refuses to overwrite).
• A permissions/ownership problem (WordPress can’t remove/replace the directory, so it reports it as “exists” even when it needs to replace it).
• A ZIP structure mismatch (archive extracts into a folder name that collides with an existing one).
• Filesystem abstraction mismatch (direct writes vs FTP/SSH filesystem methods, temp directories, and umask games).

What it usually is not:

• A “WordPress is broken” situation that requires reinstalling the whole site.
• A reason to delete random folders under wp-content until the screen changes.
• A reason to chmod everything to 777 (unless your threat model is “I enjoy living dangerously”).

One quote worth keeping on the wall near your terminal: “Hope is not a strategy.” — Gen. Gordon R. Sullivan. WordPress errors often tempt hope-based operations. Don’t.

Fast diagnosis playbook (check this first)

If you’re on the clock, don’t wander. Run this like an incident triage.

First: confirm what WordPress is trying to install

• Plugin or theme? Name/slug? From repo, or uploaded ZIP?
• Is this an install, update, or “reinstall” attempt?
• Did a previous update fail (white screen, “maintenance mode,” stuck update notice)?

Second: inspect the destination directory

• Does wp-content/plugins/<slug> or wp-content/themes/<slug> exist?
• Is it a full tree or a half-extracted mess?
• Are there weird siblings like <slug>.tmp, <slug>_old, or a leftover upgrade directory?

Third: verify ownership, permissions, and write path

• Can the web server user write to wp-content and wp-content/upgrade?
• Is WordPress using direct filesystem access or asking for FTP credentials?
• Is disk full or inode-starved?

Fourth: check the logs (yes, really)

• Web server error log: permission denied, unzip errors, timeouts.
• PHP-FPM log: open_basedir restrictions, temp dir problems.
• WordPress debug log: filesystem, upgrade, and extraction messages.

Fifth: decide the safest path

• If the directory contains a valid install: do an update, not an install; or use WP-CLI with --force carefully.
• If it’s partial: rename it, then reinstall cleanly.
• If it’s permissions: fix ownership/ACLs, then rerun the update.
• If it’s ZIP structure: repackage or choose a different ZIP.

Interesting facts and historical context (so the weirdness makes sense)

Six-to-ten quick facts that explain why this error exists and why it’s still annoying:

1. WordPress originally assumed shared hosting, where “installing a plugin” meant “upload via FTP,” not atomically swapping directories.
2. The upgrade system relies on a temp workspace (often wp-content/upgrade) and a copy/rename sequence; when that sequence is interrupted, leftovers are common.
3. ZIP archives are not standardized by kindness: many vendors ship a ZIP with a top-level folder that doesn’t match the plugin slug, causing collisions or nested folders.
4. On some hosts, PHP runs as a different user than the web server (or runs under a pool user), producing mixed ownership that only fails during writes.
5. “Filesystem method” logic exists because WordPress can’t assume write access; it tries direct writes, then falls back to FTP/SSH methods when blocked.
6. Atomic directory replacement isn’t always available on all filesystems/permission models; WordPress plays conservative to avoid deleting working code.
7. Plugin and theme directories became de facto package managers long before WordPress had reliable rollback/transaction semantics.
8. Stuck “maintenance mode” comes from a single file (.maintenance) created during upgrades; if cleanup fails, the site can look “down” even when it’s fine.

Failure modes: the real reasons the folder “already exists”

1) The plugin/theme is already installed, but you’re “installing” again

Most common with ZIP uploads and vendor packages. The folder exists, WordPress sees it, refuses to overwrite, and gives you the blunt message. The right move is either update from the Plugins page or remove/rename the existing directory after verifying it’s safe.

2) Partial extraction from a previous failure

A timeout mid-unzip, a full disk, a killed PHP worker, a reverse proxy timeout, or an ops engineer who restarted PHP-FPM “to clear it.” You end up with a directory that exists but is incomplete. WordPress can’t tell whether it should blow it away, so it stops.

3) Permissions/ownership mismatch

The folder exists and should be replaceable, but the web process can’t delete it. WordPress reports “already exists” because its attempt to clean up fails and it can’t proceed safely. Look for Permission denied in logs. You’ll find it.

4) SELinux/AppArmor or hardened policies

On hardened systems, the permissions look correct but mandatory access control blocks writes. This shows up as permission errors even with “correct” mode bits.

5) open_basedir or temp directory issues

Extraction often uses a temp directory; if PHP can’t write to it, you get half-finished installs and confusing errors. WordPress then encounters the half-created destination folder and stops.

6) Weird filesystem behavior (NFS, CIFS, object-backed volumes)

Networked filesystems can have caching, delayed visibility, or rename semantics that don’t behave like local ext4/XFS. Directory replacement can fail in ways that look like “exists” but really mean “rename didn’t propagate.”

7) Deployment tooling fighting WordPress

If you deploy code via Git, rsync, or containers, and WordPress tries to self-modify, you’ve got dueling sources of truth. The error is WordPress being the smaller dog barking at a locked door.

Joke #1: WordPress upgrades are like office chairs—usually fine, until someone leans back with confidence.

Practical tasks: commands, outputs, and what decisions you make

These are real tasks you can run on a Linux host. Each one includes: the command, what a typical output means, and the decision you make.

Task 1: Confirm the target directory exists

cr0x@server:~$ sudo ls -ld /var/www/html/wp-content/plugins/contact-form-7
drwxr-xr-x 5 root root 4096 Dec 27 08:41 /var/www/html/wp-content/plugins/contact-form-7

Meaning: The plugin directory exists and is owned by root:root. That’s suspicious on a typical WordPress box where the web process needs write access.

Decision: Don’t delete it yet. Next check if it’s a valid install and whether ownership is wrong.

Task 2: Check whether it’s a partial install (file count and expected files)

cr0x@server:~$ sudo find /var/www/html/wp-content/plugins/contact-form-7 -maxdepth 2 -type f | wc -l
3

Meaning: Only 3 files is likely incomplete for a real plugin. A healthy plugin usually has dozens of files.

Decision: Treat as partial extraction. Plan to rename and reinstall.

Task 3: Identify the web server user (Apache)

cr0x@server:~$ ps -eo user,comm | egrep 'apache2|httpd' | head
www-data apache2
www-data apache2
www-data apache2

Meaning: Apache worker processes run as www-data.

Decision: Plugin/theme directories should generally be writable by www-data (or managed by deployment tooling, but then WordPress shouldn’t self-update).

Task 4: Identify the PHP-FPM pool user (Nginx + PHP-FPM)

cr0x@server:~$ sudo grep -R "^\s*user\s*=" /etc/php/*/fpm/pool.d/www.conf | head -n 1
user = www-data

Meaning: PHP executes as www-data too (good; fewer mixed-ownership surprises).

Decision: If you still have root-owned plugin folders, they were likely created by manual actions (unzip as root, rsync as root, or CI step gone rogue).

Task 5: Test write access to wp-content (as the web user)

cr0x@server:~$ sudo -u www-data bash -lc 'touch /var/www/html/wp-content/.write-test && echo ok && rm /var/www/html/wp-content/.write-test'
ok

Meaning: The web user can write to wp-content at least at the top level.

Decision: The failure is more likely within a specific subdirectory (plugins/themes/upgrade) or due to ownership/ACL on that plugin folder.

Task 6: Check the upgrade temp directory health

cr0x@server:~$ sudo -u www-data bash -lc 'mkdir -p /var/www/html/wp-content/upgrade && touch /var/www/html/wp-content/upgrade/.upgrade-test && ls -la /var/www/html/wp-content/upgrade | head'
total 8
drwxr-xr-x  2 www-data www-data 4096 Dec 27 09:01 .
drwxr-xr-x 10 www-data www-data 4096 Dec 27 09:01 ..
-rw-r--r--  1 www-data www-data    0 Dec 27 09:01 .upgrade-test

Meaning: WordPress can stage upgrade files.

Decision: If upgrades still fail, focus on destination folder ownership, disk space, or ZIP structure.

Task 7: Check disk space and inode pressure

cr0x@server:~$ df -h /var/www/html
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   39G  600M  99% /

Meaning: You’re basically out of disk. Extraction can fail mid-way, leaving the destination folder behind.

Decision: Free space first. Then clean partial directories and retry. If you ignore this, you’ll keep generating half-installs.

cr0x@server:~$ df -i /var/www/html
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      2621440 2619000   2440  100% /

Meaning: Inodes are exhausted. This can break installs even when “disk space” looks fine elsewhere.

Decision: Find and remove inode-heavy junk (cache directories, old backups). Then retry.

Task 8: Look for stuck maintenance mode

cr0x@server:~$ sudo ls -la /var/www/html/.maintenance
-rw-r--r-- 1 www-data www-data 57 Dec 27 08:40 /var/www/html/.maintenance

Meaning: A previous upgrade didn’t clean up. Users may see “Briefly unavailable for scheduled maintenance.”

Decision: If no upgrade is running, remove it after verifying no active update process. Then focus on why the upgrade failed.

Task 9: Check WordPress debug log for extraction/FS errors

cr0x@server:~$ sudo tail -n 30 /var/www/html/wp-content/debug.log
[27-Dec-2025 08:41:12 UTC] PHP Warning:  copy(/var/www/html/wp-content/plugins/contact-form-7/readme.txt): failed to open stream: Permission denied
[27-Dec-2025 08:41:12 UTC] PHP Warning:  unlink(/var/www/html/wp-content/plugins/contact-form-7/readme.txt): Permission denied

Meaning: Classic ownership/permission issue inside the destination directory.

Decision: Fix ownership/mode/ACL on that path. Don’t keep retrying the install; you’ll just grind logs and patience.

Task 10: Inspect web server / PHP logs for the real error

cr0x@server:~$ sudo tail -n 50 /var/log/nginx/error.log
2025/12/27 08:41:12 [error] 12345#12345: *901 FastCGI sent in stderr: "PHP message: PHP Warning:  mkdir(): Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 56" while reading response header from upstream

Meaning: The filesystem method is direct, but mkdir failed. This is not a WordPress “logic” problem; it’s an OS-level access problem.

Decision: Fix permissions/ownership, then rerun. Avoid hacky plugin zip reuploads until the underlying write path works.

Task 11: Validate ZIP structure before uploading (common vendor problem)

cr0x@server:~$ unzip -l /tmp/vendor-plugin.zip | head
Archive:  /tmp/vendor-plugin.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2025-12-01 10:10   vendor-plugin/
        0  2025-12-01 10:10   vendor-plugin/vendor-plugin/
     2345  2025-12-01 10:10   vendor-plugin/vendor-plugin/plugin.php

Meaning: Nested folder: vendor-plugin/vendor-plugin/. WordPress will extract to vendor-plugin and the actual plugin lives one level deeper, which causes confusion and can collide with existing directories.

Decision: Repackage the ZIP (top-level folder should be the plugin slug and contain plugin files directly) or install via WP-CLI from a corrected path.

Task 12: Use WP-CLI to see what WordPress thinks is installed

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin list --field=name | head
akismet
contact-form-7
hello

Meaning: WordPress already recognizes contact-form-7 as installed. The admin “install” attempt is redundant or the directory is broken but still detected.

Decision: Consider a controlled reinstall using WP-CLI (with overwrite), or rename the directory and reinstall cleanly.

Task 13: Controlled reinstall with WP-CLI (plugin) without blind deletion

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin install contact-form-7 --force
Installing Contact Form 7 (6.0.3)
Downloading installation package from https://downloads.wordpress.org/plugin/contact-form-7.6.0.3.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.

Meaning: --force tells WP-CLI to overwrite. This is safer than manual rm -rf if you trust the source and your filesystem permissions are correct.

Decision: If this works, your issue was likely WordPress admin refusing overwrite while WP-CLI handled it. If it fails, read the exact error and fix the OS-level cause.

Task 14: Rename the destination folder to preserve evidence

cr0x@server:~$ sudo mv /var/www/html/wp-content/plugins/contact-form-7 /var/www/html/wp-content/plugins/contact-form-7.broken-20251227

Meaning: You’ve removed the collision while keeping the old directory for forensics or rollback.

Decision: Now retry installation. If it succeeds, diff the old folder later to understand what failed.

Task 15: Fix ownership cleanly (and only where needed)

cr0x@server:~$ sudo chown -R www-data:www-data /var/www/html/wp-content/plugins/contact-form-7

Meaning: The web user can now manage files inside that plugin directory.

Decision: Retry update/install. If you have a deployment pipeline that expects root ownership, stop and decide who owns code: WordPress or your pipeline. Pick one.

Task 16: Spot and remove stubborn immutable flags (rare, but spicy)

cr0x@server:~$ sudo lsattr -d /var/www/html/wp-content/plugins/contact-form-7
----i---------e------- /var/www/html/wp-content/plugins/contact-form-7

Meaning: The directory has the immutable attribute (i). Deletes and writes will fail even as root.

Decision: If this was set by hardening or a backup tool, remove immutability before trying to update.

cr0x@server:~$ sudo chattr -i /var/www/html/wp-content/plugins/contact-form-7

Task 17: Check SELinux context (if applicable)

cr0x@server:~$ sudo getenforce
Enforcing

cr0x@server:~$ sudo ls -Zd /var/www/html/wp-content
unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/wp-content

Meaning: If wp-content is labeled httpd_sys_content_t, Apache can read but may not write. Writable paths typically need httpd_sys_rw_content_t depending on policy.

Decision: Adjust contexts for writable directories only, not the entire docroot.

Task 18: Find leftover upgrade working directories

cr0x@server:~$ sudo find /var/www/html/wp-content/upgrade -maxdepth 1 -type d -printf '%f\n' | head
upgrade
tmp-1234567890
tmp-1735290072

Meaning: Old temp directories can indicate failed upgrades.

Decision: If no upgrade is running, remove old temp dirs to reduce collisions and clutter, but keep the last one if you need evidence.

Joke #2: Nothing says “enterprise-grade” like a folder named tmp-1735290072 quietly controlling your weekend.

Safe fixes that don’t trash wp-content

Fix strategy A: Rename, don’t delete (default move)

When you’re not 100% sure what’s in that directory, rename it. Renaming is reversible, fast, and keeps evidence. The only time you should delete immediately is when you’re cleaning a known-safe cache directory or a known temp directory.

Good: contact-form-7.broken-20251227
Bad: rm -rf contact-form-7 and then “I think it was fine?”

Fix strategy B: Use WP-CLI for controlled overwrite

The WordPress admin UI is conservative. WP-CLI is direct. If you’re an ops person, you want deterministic behavior and logs you can capture. Use:

• wp plugin install <slug> --force
• wp theme install <slug> --force

But only after confirming the underlying write permissions are correct. If permissions are wrong, forcing writes just produces louder failure.

Fix strategy C: Fix ownership/permissions with restraint

The most dangerous “solution” in WordPress land is blanket permission changes:

• Avoid: chmod -R 777 anywhere.
• Avoid: recursively chowning the entire docroot if you deploy code via Git/CI; you’ll create drift and surprise your next deploy.

Do instead: keep core code owned by your deploy user (or root), and make only the writable directories writable by the runtime user:

• wp-content/uploads
• wp-content/cache (if used)
• wp-content/upgrade
• plugin/theme directories only if you permit in-place updates

Fix strategy D: Stop letting WordPress self-modify in production (if you can)

Opinionated take: on serious production systems, WordPress should not be allowed to update itself by clicking buttons in wp-admin. That’s not purism; it’s reducing uncontrolled change. If you have CI/CD, immutable images, or even basic change control, handle updates as deployments. Then this entire class of errors drops dramatically.

Tradeoff: you must also stop asking WordPress to be a package manager. Pick a model:

• Model 1: WordPress manages plugins/themes. You ensure permissions and accept risk of admin-driven changes.
• Model 2: Your pipeline manages plugins/themes. You disable file modifications in WordPress and deploy artifacts.

Fix strategy E: Repair a broken install without losing customizations

Some plugins store configuration in the database, not in the filesystem. If the plugin directory is corrupted, you can usually reinstall the plugin files without losing settings. But “usually” is not “always.”

Safe approach:

1. Back up the database (or snapshot).
2. Back up the plugin directory by renaming it.
3. Reinstall the plugin/theme cleanly.
4. Verify behavior and logs.
5. Only then remove the old directory.

Three corporate mini-stories (how this goes wrong in real life)

Mini-story 1: The incident caused by a wrong assumption

A mid-size company ran WordPress behind Nginx and PHP-FPM on a VM. Marketing had admin access and installed plugins directly. The ops team assumed that because the site had run for months, file permissions were “fine.” They weren’t—just untested.

One morning, a plugin update failed during extraction. The plugin directory existed, partially updated, and WordPress refused to reinstall: “Destination folder already exists.” The admin panel kept prompting for updates that couldn’t complete. Nobody checked disk space or ownership; they just retried the update five times, creating more partial temp dirs.

The wrong assumption was subtle: “If WordPress can read plugins, it can update them.” On that host, a previous maintenance window had copied plugin directories as root from a backup tarball. WordPress could read them. It couldn’t replace them.

The fix was boring: chown only the affected plugin directory and the upgrade staging directory to the PHP-FPM user, then reinstall with WP-CLI. The postmortem action item was better: lock down production updates and move plugin management into the deployment pipeline.

Mini-story 2: The optimization that backfired

An org moved wp-content to a networked filesystem so multiple web nodes could share uploads and plugins. It looked tidy: one source of truth, no more rsync of media files, easier scaling. The optimization was “shared storage solves everything,” which is the kind of sentence that ages poorly.

During a plugin update, WordPress extracted the ZIP on node A, but node B still saw the old directory state due to caching and delayed metadata propagation. WordPress on node B then tried to update as well (yes, people click buttons twice), collided with a directory in an intermediate state, and threw “Destination folder already exists.” The plugin ended up half-new, half-old across nodes.

They tried to “fix it” by increasing PHP timeouts and adding retries. That made the blast radius larger. Eventually they had to take the admin interface read-only during deployments and ensure only one node performed upgrades—or better, stop doing upgrades via wp-admin entirely.

The lesson wasn’t “never use NFS.” It was: if your application expects local filesystem semantics for atomic directory replacement, you need to design around it. Either centralize updates through a single deployment job or package plugins/themes as artifacts and roll them out predictably.

Mini-story 3: The boring but correct practice that saved the day

A large internal WordPress instance served documentation. It wasn’t glamorous, but it was mission-critical. The team enforced two practices: (1) every change went through a deployment pipeline, and (2) the filesystem was mostly read-only to the runtime user except uploads and a tiny set of writable directories.

One afternoon, a vendor delivered a “hotfix plugin” ZIP and insisted it be installed immediately. The admin tried. WordPress couldn’t write to the plugins directory (by design), and the UI error was—predictably—some variant of a destination folder conflict / inability to overwrite. The panic lasted about five minutes.

Because the practice was boring and consistent, the response was straightforward: the team staged the plugin in a build workspace, validated the ZIP structure, repackaged it correctly, scanned it, then deployed it like any other code change. No manual chmod. No midnight archaeology in wp-content.

The site stayed stable, and the “emergency” became a normal change with auditability. It’s amazing how often “we do deployments the same way every time” is the difference between a small annoyance and a large outage.

Common mistakes: symptom → root cause → fix

1) Symptom: “Destination folder already exists” when uploading a ZIP

Root cause: The plugin/theme directory already exists from a previous install, or the ZIP contains a top-level folder that matches an existing directory.

Fix: Verify the destination path. Rename the existing directory. Validate ZIP layout with unzip -l. Repackage if nested.

2) Symptom: Error repeats after you “deleted the plugin” in wp-admin

Root cause: Deletion in the UI failed due to permissions; the directory remained on disk. WordPress UI is not a promise, it’s a request.

Fix: Check on-disk directory presence and ownership. Delete/rename on disk once you’ve confirmed it’s safe.

3) Symptom: Update fails; plugin directory exists but plugin is broken

Root cause: Partial extraction due to timeout, disk full, inode exhaustion, or killed PHP worker.

Fix: Free disk/inodes, clear stale upgrade temp dirs, rename broken plugin directory, reinstall with WP-CLI.

4) Symptom: WordPress asks for FTP credentials unexpectedly

Root cause: WordPress can’t write directly to the filesystem, so it switches filesystem method.

Fix: Correct write permissions/ownership for the runtime user on needed directories, or commit to an FTP/SSH update workflow (not recommended for production).

5) Symptom: Permissions look fine but updates still fail

Root cause: SELinux/AppArmor blocking writes; or open_basedir/temp directory restrictions.

Fix: Check enforcement mode and contexts; check PHP temp dir; adjust policy for specific writable paths.

6) Symptom: Works on one node, fails on another (multi-node)

Root cause: Shared filesystem consistency issues or different runtime users/UID mappings across nodes.

Fix: Ensure consistent UID/GID, centralize updates, avoid wp-admin updates in clustered environments.

7) Symptom: Only one plugin/theme fails; others update fine

Root cause: That directory has different ownership, ACL, immutable flag, or corrupted contents.

Fix: Inspect that specific path with ls -l, getfacl, lsattr. Repair narrowly.

8) Symptom: “Could not create directory” during install, then “destination folder already exists” next try

Root cause: First attempt created the directory but failed to populate it; second attempt collides with the leftover empty folder.

Fix: Remove/rename the empty folder, fix the original cause (permissions/disk/temp), then reinstall.

Checklists / step-by-step plan (sane, repeatable)

Checklist 1: Single-server WordPress where wp-admin installs are allowed

1. Identify the slug of the plugin/theme you’re installing (folder name under wp-content).
2. Check existence: does the directory exist already?
3. Check health: is it a full install or partial?
4. Check write path: can the runtime user write to wp-content and wp-content/upgrade?
5. Check disk/inodes: don’t troubleshoot installs on a full filesystem.
6. Rename the directory if you suspect partial install or corruption.
7. Reinstall with WP-CLI if possible (it’s clearer and scriptable).
8. Verify: plugin activates, logs are clean, site renders.
9. Clean up: remove old renamed directory after a cooling-off period.

Checklist 2: Production system with CI/CD (recommended)

1. Disable file modifications in production (so wp-admin can’t mutate code).
2. Make the docroot read-only to runtime user except uploads and a controlled set of dirs.
3. Build artifacts (plugins/themes pinned to versions) in CI, not on the server.
4. Deploy atomically (release directories + symlink swap) where possible.
5. Rollback plan must exist and be tested (yes, tested).
6. Observe: error logs, PHP-FPM, and WordPress debug logs are collected centrally.

Step-by-step: clean recovery from “destination folder already exists” (plugin)

1. Take a filesystem snapshot or at least a quick tarball of wp-content/plugins/<slug> and your database dump.
2. Confirm the directory exists and inspect it.
3. Rename <slug> to <slug>.broken-<date>.
4. Ensure runtime user can write to wp-content and wp-content/upgrade.
5. Install/reinstall using WP-CLI with --force (or install via admin once the collision is removed).
6. Activate the plugin and run a quick functional test (front-end, wp-admin, any cron tasks).
7. Watch logs for 10–15 minutes of normal use.
8. Delete the renamed broken directory when you’re confident.

FAQ

1) Does “Destination folder already exists” mean the plugin is already installed?

Sometimes. It only means the directory name exists. It could be a healthy install, or a half-extracted directory from a failed update. Confirm with wp plugin list and by inspecting the directory contents.

2) Should I delete the folder under wp-content/plugins to fix it?

Prefer renaming first. Deletion is irreversible and often destroys evidence you need to understand the failure. Rename, reinstall, validate, then delete later.

3) Why does WordPress refuse to overwrite the folder?

Because overwriting can be destructive if the existing directory contains a working version or local modifications. WordPress chooses safety over convenience, even when it’s inconvenient.

4) Can WP-CLI fix this faster than wp-admin?

Yes. WP-CLI gives you deterministic flags like --force and clearer error output. It also avoids browser/proxy timeouts during large extractions.

5) Will reinstalling a plugin erase its settings?

Usually plugin settings live in the database and survive reinstalling files. But some plugins store config files in their directory. Back up the directory and database before you overwrite anything.

6) I fixed permissions, but the error persists. What now?

Check for SELinux/AppArmor denials, immutable file attributes, and disk/inode exhaustion. Also validate the ZIP structure—nested directories can create repeat collisions.

7) Why does this happen more in clustered setups?

Because shared storage and multiple nodes add consistency and concurrency problems. Two nodes trying to “upgrade” the same directory is how you get half-new code and confusing existence checks.

8) Should I allow WordPress to update plugins/themes in production?

If you run a small site on a single server and accept the risk, it can be fine with good backups. If you run production with change control, use CI/CD and keep runtime writes limited.

9) What about the WordPress FS_METHOD setting?

Forcing FS_METHOD to direct can mask deeper permission problems in some setups and worsen security in others. Fix the underlying ownership/ACLs and let WordPress choose direct only when appropriate.

Next steps you can actually do today

The “Destination folder already exists” error is WordPress telling you: “I see something on disk and I’m not confident enough to stomp on it.” Treat it like a safety interlock, not an insult.

1. Run the fast diagnosis playbook: confirm slug, inspect destination folder, check write permissions, check disk/inodes, then logs.
2. Rename before delete. Preserve evidence, reduce regret.
3. Fix the cause (ownership, staging directory, SELinux, temp dirs), not the symptom.
4. Choose an operating model: either WordPress manages plugins/themes (and you support it), or your pipeline does (and WordPress stops trying).
5. Make it repeatable: turn the steps above into a runbook and stop re-learning the same lesson at 9 AM.

If you do nothing else: stop “fixing” WordPress by randomly deleting wp-content contents. That’s not operations. That’s gambling with better branding.