If chown is throwing "Operation not permitted," that's expected behavior, not a bug. On shared hosting, every file you own already belongs to your account's system user. You can't change ownership to a different user because that would require root privileges, and shared hosting deliberately doesn't give you those. What you almost always want instead is chmod, which changes permissions, not ownership.
Why chown needs root
On Linux, every file has an owner (a user) and a group. Changing a file's owner is a privileged operation because it can be used to hand off or steal control of files between accounts. If any user could run chown freely, one customer could reassign another customer's files to themselves. So the kernel restricts chown to the superuser (root) only. Regular users can only change a file's group to another group they belong to, not the owner.
On a shared server, your SSH or FTP session runs as your account's system user, not root. Every file you upload or create is automatically owned by that user and its associated group. There's no scenario on shared hosting where you'd legitimately need to change that. The files are already yours.
What you actually want: chmod
Permission problems almost always show up as one of these:
- A script can't write to a directory (uploads, cache, logs).
- WordPress asks for FTP credentials to update plugins or themes.
- A file downloaded from somewhere else isn't executable.
None of these need a new owner. They need different permission bits on the existing owner. The fix is chmod:
chmod 755 script.sh chmod -R 755 wp-content/plugins chmod 644 wp-config.php
The common conventions: 755 for directories and executable scripts (owner can read/write/execute, everyone else can read/execute), 644 for regular files like PHP scripts and config files (owner can read/write, everyone else read-only). Avoid 777 on a live site. World-writable files and directories are a standard way malware gets a foothold, since any process on the box, not just yours, can write to them.
On most hosting accounts, File Manager also offers a way to change permissions on a file or folder without a terminal, using the same numeric values.
Checking who owns what
Run ls -l in any directory to see the owner and group in the second and third columns. If everything in your home directory shows your own username as both owner and group, ownership isn't the problem, permissions are. If you see a different owner entirely, that's unusual on shared hosting and worth a support ticket rather than a permissions fix.
Where root-level chown does matter
On a server where you have root access, chown works normally. This matters when you're running multiple sites or services under different Linux users on the same box, or restoring files that were extracted with the wrong ownership, which can happen when an archive is unzipped as root:
chown -R webuser:webuser /var/www/site chown www-data:www-data /var/www/site/uploads
Get the owner:group pairing right for whatever user your web server or PHP process actually runs as, or you'll trade one permission error for another.
Related causes worth ruling out
If permissions look correct but something still won't write or execute, check your PHP or web server error log for the exact failure, since "permission denied" errors are logged with the specific path involved. If the issue is specifically WordPress asking for FTP credentials on every update, that's usually the same ownership/permission mismatch.
When to open a ticket
If ls -l shows files owned by a user other than your own account, or you've run a bulk chmod/chown and now can't access your account, open a ticket. Support can check the underlying account mapping directly. Tickets go through the portal, and you'll reach a real person, not a bot.