Troubleshooting guide · migration-hosting · Published 2026-08-16 · 3 min read

Website file permissions and ownership sync

File permissions and ownership sync explained: the 403/500 symptoms, ownership mismatch after a move, and safe chown/chmod.

Flat editorial illustration showing two data boxes crossing a bridge with a dotted orbit trail between them, one box accepting the transfer.
Illustration: this article at a glance.

What permissions and ownership control

On a Unix-like server, a file and every directory have two properties that decide who can read, write and run them: a permission mode (the read/write/execute bits) and an ownership (the user and group the file belongs to). The webserver process, the FTP user and the shell user all access files as specific operating-system users, and if their identity does not match the file's owner or group, access fails.

Editorial close-up illustration showing two data boxes crossing a bridge with a dotted orbit trail between them, one box accepting the transfer.
Illustration: a closer look at the technique described above.

Two common failures trace back to this:

Ownership mismatch after a move

This is the classic post-migration bug. You download the site as your local user or the old FTP user, upload it to the new host, and every file is owned by that upload identity rather than by the webserver user (often apache, www-data, nginx or nobody). The files exist, but the webserver cannot read or write them, producing 403s or white screens.

The fix is to re-sync ownership to the account and group the webserver runs as. On a cPanel-style host, files belong to the account user, and directories typically get group write for that user.

# Own everything by the expected application user and group
chown -R user:user /home/user/public_html

# Files read-only for web execution; directories writable by the group
find /home/user/public_html -type d -exec chmod 755 {} \;
find /home/user/public_html -type f -exec chmod 644 {} \;
ItemSafe defaultWhy
Files644Read for all, write for owner
Directories755Traverse and read, owner writes
Upload/cache dir755 + owner-writable, or 775 group-writableApp must write
Executables / scripts755Owner can run

A safer sync, and what not to do

Blindly running a single chmod -R 777 hands every file to every local user and is the fix that creates a security hole. Prefer a targeted pass: re-own the tree, apply 644/755 broadly, then set group-write only on the directories the application actually needs to write (uploads, cache, logs), using the account user as owner. Add an optional setgid bit on shared directories so new files inherit the group.

chmod g+ws /home/user/public_html/uploads

On a managed host some directories are intentionally owned by a different user (for example nobody for certain caches), so know the panel's layout before you change everything. The 403 Forbidden guide distinguishes an ownership problem from a server rule problem, and the move to new hosting and host migration checklist guides make the ownership resync a named step in the migration instead of a fix found later.

Need a website built, fixed, optimised, migrated or replaced?

This technical resource is written by CSMBAC, a small design and development studio. If you would rather hand the problem to a professional, the website service page explains how we build enquiry-ready websites.

Explore website services