Hosting Move Messed Up File Permissions? Here's the Fix

That 403 Error After Moving Hosts? Yeah, It's Permissions

You moved your site to a new host, everything looks fine in the file manager, but now you get 403 Forbidden or 500 Internal Server Error on pages. Maybe images are just broken. Don't panic — I've seen this at least a dozen times. The cause is almost always your file and folder permissions got scrambled during the transfer.

Quick Fix: Reset Permissions (The Right Way)

Here's the no-nonsense fix. You'll need SSH access to your new server. If you only have FTP, skip to the FTP section below.

Step 1: SSH In and Go to Your Site Root

ssh user@yourserver.com
cd /path/to/your/site

Step 2: Fix All Directories to 755

find . -type d -exec chmod 755 {} \;

Step 3: Fix All Files to 644

find . -type f -exec chmod 644 {} \;

Step 4: (If You Use WordPress) Fix wp-config.php

That file should be 600 or 640, not 644. Run:

chmod 600 wp-config.php

That's it. Reload your site. If it works, you're done. If not, read on — there's a twist.

Why This Works

Most shared hosting runs on Linux (usually Apache or Nginx). The server expects directories to have 755 permissions (read, write, execute for owner; read and execute for everyone else). Files need 644 (read and write for owner; read-only for others). When you migrate, the transfer process often sets everything to 755 or sometimes 777 (which is bad and insecure). Or it sets them to 600 (too restrictive). The above commands fix that.

I had a client last month whose entire WordPress site showed a white screen after migration. Ran these commands, boom — site worked. The old host had a different user:group setup, and the files got transferred with wrong ownership and permissions.

When the Quick Fix Doesn't Work

Sometimes the fix above isn't enough. Here are the less common variations I've run into:

Variation 1: File Ownership Is Wrong

Your files might be owned by root:root when they need to be www-data:www-data or youruser:youruser. Check with:

ls -la

If you see root where you expect www-data, fix it (only if you know what you're doing):

chown -R www-data:www-data .

On some shared hosts, the user is your cPanel username and group is nobody or psacln. Ask your new host what the correct user:group is. I once spent two hours debugging a site that had nobody:nobody — the fix was changing it to myuser:psacln.

Variation 2: umask Is Set Wrong

Even after fixing existing files, new ones you upload via FTP might still have bad permissions. That's your FTP client or server's umask setting. For most cases, you want a umask of 022. That means new files get 644 and new directories get 755. Check your FTP client settings. In FileZilla, it's under Edit -> Settings -> Transfers -> File Types -> set 'Unix permissions' to 0644 for files and 0755 for directories. If you use cPanel's File Manager, the permissions are usually fine but double-check after upload.

Variation 3: SELinux or AppArmor Is Blocking

If your new host uses SELinux (common on RHEL/CentOS) or AppArmor (Ubuntu), permissions can be overridden by security contexts. You'll see errors in /var/log/audit/audit.log or /var/log/syslog. Fix it by setting the right context. Quick and dirty (if you have root):

chcon -R -t httpd_sys_content_t /path/to/your/site

Or use restorecon -R /path/to/your/site to restore from defaults. I've seen this happen on a VPS where WordPress uploads were denied even with 755 permissions — SELinux was the culprit.

Variation 4: .htaccess File Is Gone or Wrong

Sometimes the migration drops your .htaccess file. If you get a 500 error after fixing permissions, check if .htaccess exists. If not, generate a fresh one. For WordPress, it's usually:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

How to Prevent This Mess Next Time

Three things:

1. Use a plugin for WordPress — Tools like UpdraftPlus or Duplicator handle permissions automatically. They'll set the right ones on restore. I've used Duplicator for years — never had a permission issue after a migration with it.
2. Check permissions right after migration — Before you point your domain, run the find commands above. Saves you a panic later.
3. Set umask in your FTP client — As I said, 022 for umask. Or use SFTP/SCP instead of plain FTP, which often preserves permissions better. Most modern hosts support SFTP — use it.

And one pro tip: if you're moving from a host that uses mod_suphp to one that uses php-fpm, the ownership model changes. On mod_suphp, files need to be owned by your user. On php-fpm, they often need to be www-data or nobody. Don't assume the new host works like the old one. Ask their support before you migrate — they'll tell you the correct ownership. I learned that the hard way.

That's it. Go fix your site. If you're still stuck, drop a comment with your hosting setup and I'll help.