Backing up and restoring WordPress websites should be easy, right? That’s the promise of the popular All-in-One WP Migration plugin. However, sometimes the road to simplicity has a few bumps. One such bump appeared when users noticed that restoring a backup dropped critical file permissions, which could cause access issues—or worse, pose a security risk. Fortunately, a smart tweak to file ownership settings helped smooth it all out.
TL;DR
The All-in-One WP Migration plugin sometimes resets or “drops” file and directory permissions during a site restore. This could lead to broken sites or security problems. A clever solution was to adjust file ownership after restoration. This trick not only fixed things—it also made the site more secure.
What’s All-in-One WP Migration?
If you have a WordPress site, chances are you’ve at least heard of this plugin. All-in-One WP Migration lets you:
- Export your entire website—including database, media files, plugins, and themes
- Import that data to a new WordPress site
- Skip scary technical stuff like SQL or FTP
You hit “Export” on one site, then “Import” on another—easy-peasy. Or so it should be.
The Sneaky Problem: Dropped Permissions
Let’s say you’ve just restored a site to a new server. Everything looks good… until it doesn’t. Maybe your images don’t load. Maybe your theme’s stylesheet is missing. Where did everything go?
It turns out that during the restore process, the plugin changes file and folder permissions.
- Files that should be readable might now be locked
- Folders that need to allow scripts could now be restricted
This happens because of how Linux systems manage ownership and permissions. After a restore, files don’t always belong to the right user anymore.
The result? The web server can’t access them properly. That’s when things break.
Why Permissions Matter
File permissions control who can read, write, or execute a file or directory. They’re represented by numbers like 755 or 644. What do these mean?
- 644: Read and write for the owner. Read-only for everyone else.
- 755: Full rights for the owner. Read and execute for others.
Your WordPress site depends on these settings being just right. If they’re too loose, hackers might exploit them. If they’re too tight, your own website may fail to load.
Why Does the Plugin Do This?
It’s not entirely the plugin’s fault. When files are copied or moved across systems, ownership and permissions can get lost depending on how the server is configured.
During restore, All-in-One WP Migration extracts files into your WordPress directory. But it uses the PHP process’s user to do that. If your server runs PHP as a different user than your web server (like Apache or Nginx), uh-oh—permission clash.
The Fix: Adjusting File Ownership
The key to solving this is setting the right ownership of files after restore. Here’s a simple recipe that system admins use:
chown -R www-data:www-data /var/www/html
This command tells Linux, “Hey, make sure all files in this directory are owned by the ‘www-data’ user”—the typical user your web server runs as. Once everything is properly owned, permissions like 644 and 755 start working again as expected.
But Wait—Is That Safe?
Yes, and it’s even better for security. Giving ownership to the right user prevents unauthorized scripts or users from sneaking into your files.
Also, you’re not just randomly setting permissions. You’re matching them to the correct ownership structure. That makes the system smarter and more secure.
Quick Guide to Safe Restore Using All-in-One WP Migration
- Restore your site using the plugin as usual
- SSH into your server (or use your host’s file manager)
- Run the
chowncommand to fix ownership - Optionally, reset loose permissions with:
find /var/www/html -type f -exec chmod 644 {} \; find /var/www/html -type d -exec chmod 755 {} \; - Clear your server cache and reload the site
Now everything should work—and stay secure!
Fancy Web Hosting? Less of a Worry
If you’re on a managed WordPress hosting platform like Kinsta, WP Engine, or SiteGround, chances are the hosts already have things set up to avoid this issue. In those cases, the plugin behaves a lot better right out of the box.
Still, it’s a good idea to check file ownership after every restore. Automation doesn’t always mean perfection.
A Real-World Example
We worked with a client who moved their site from a shared host to a VPS. They used All-in-One WP Migration to restore the site. Immediately after, all images and theme stylesheets failed to load.
The cause? The restore process had set incorrect file ownership (owned by root instead of www-data). The server couldn’t serve the files—even though the permissions were technically correct.
We ran the ownership and permission commands above. Within minutes, the site bounced back to life. And with correct ownership, it was also more secure than ever before.
Tips to Prevent Future Headaches
- Always back up file permissions and ownership before making big changes
- Create a post-restore script to fix ownership automatically
- Test your restored site in a staging environment before going live
- Consider using a plugin that logs restore actions
The Bottom Line
All-in-One WP Migration is a fantastic tool, especially for non-techies. But like any tool, it has quirks. One of those quirks is how it handles file permissions and ownership during site restore.
The good news? A little command-line magic can fix things—and even tighten site security in the process. Whether you’re a developer, a site owner, or just the “techy friend” helping someone out, knowing how to adjust file ownership could save the day.
So next time your WordPress site goes weird after a restore, don’t panic. Just grab your terminal, fix the ownership, and get back to shipping awesome websites.