Troubleshooting
Fix Shared Users Conflict On Import
Diagnose and resolve shared users conflict on import during WordPress Multisite backup or restore with Multisite Migrate.
Pro
Fix: Fix Shared Users Conflict On Import
When you hit shared users conflict on import, start with the Multisite Migrate job log: last completed chunk, PHP/memory messages, HTTP 502/504, disk/inode errors, or cloud auth failures. Multisite archives are larger and table-heavier than single-site jobs, so shared hosts interrupt long PHP requests — Jobs in Chunks exist specifically for that.
Check tmp/disk free space, upload_max_filesize for imports, S3/Drive/Dropbox/SFTP credentials for Plus uploads, and security plugins that block admin-ajax. After restore issues, verify siteurl/home, rewrite rules, domain mapping (sunrise.php), object-cache drop-ins, and CDN caches. Reproduce once on Staging before changing production limits.
Log-first diagnosis for “Shared Users Conflict On Import”
Separate backup failures from post-restore URL/media/login problems. Capture job percent, last log line, HTTP status, hosting class, and whether a local archive already exists. That evidence decides whether you raise PHP limits, free disk, fix cloud auth, or only re-upload.
For “shared users conflict on import”, avoid restarting from scratch if a chunked job can resume. Lost locks, cleared tmp, or a new job ID are common reasons a progress bar jumps back to 0%.
Fixes that match Multisite reality
Raise PHP time/memory enough for safety, but keep chunked jobs — shared hosts can still kill long workers. Free disk and inodes before large network archives. Allow admin-ajax through WAF or security plugins. On Plus, re-test Drive/Dropbox/S3-compatible/SFTP credentials and quotas.
Free handles core backup/restore; Plus covers BYO cloud; Pro covers remote import, empty-server installer, Staging, and split/extract. Pick the tool that matches the failure — do not upgrade tiers hoping a cloud auth typo will disappear.
After the archive completes
If the local archive is good, you can restore even when cloud upload failed. Fix destination auth/quota, then re-upload, or restore from local. On Staging, confirm HTTPS, mapping, media, and logins before production.
If the front end is stale after a good restore, flush rewrite rules, object cache drop-ins, and CDN — the archive may already be fine.
Retention, encryption, and support hygiene
For fix shared users conflict on import, keep enough archive generations to roll back a bad deploy or failed migration. Optional .venc AES-256 encryption on Multisite Migrate archives protects copies at rest when you store offsite on Plus destinations. Document credentials, schedule windows, and who may run Network Admin jobs.
When opening a support ticket, include the last job log lines, hosting class, PHP limits, free disk, and whether a local archive already exists.
Why this matters
Log-first diagnosis
Identify whether the failure is PHP, disk, DB, cloud, or URL rewrite.
Chunking as the default fix
Resume instead of restarting huge Multisite jobs from zero.
Restore-side checks
Separate backup failures from post-restore URL/media/login issues.
Support-ready evidence
Know which log lines and environment facts to capture for support.
Steps
-
1Capture the failure point
Record job percent, last log line, HTTP status, and hosting type for “shared users conflict on import” before changing settings.
-
2Apply the matching fix
Raise safe limits, free disk, fix credentials, or allow AJAX through WAF — based on the log, not guesswork.
-
3Re-run chunked
Resume the job. Avoid overlapping schedules that collide on locks or wipe tmp mid-run.
-
4Confirm local archive integrity
If the archive finished, note its size/path. Cloud upload can be retried separately from rebuilding Multisite tables.
-
5Validate restore path
Test import/restore on Staging. Check URLs, media, logins, and mapping before production changes.