The chown command in Linux
chown (change owner) sets which user and group own a file. Together with chmod it forms the Linux access model: chmod says what owner, group and others may do; chown says who those are. It appears constantly in server work, because services like nginx or postgres must own the files they manage. Changing ownership generally requires sudo.
How chown works
Ownership is two numbers in the inode: a UID and a GID. chown sets them via the chown() syscall; the names you see in ls -l are those numbers translated through /etc/passwd and /etc/group at display time. Copy a disk to a machine with different accounts and files "change owner" without a byte changing — the numbers stayed, the name mapping moved.
Only root may change a file's owner, and the restriction is principled: if users could donate files, disk quotas could be dodged and setuid programs planted in inconvenient places. Unprivileged users may at most re-group files into groups they belong to. One operational footnote: chown historically cleared setuid/setgid bits on the file as a safety measure — worth remembering when a carefully-permissioned binary loses its special bits after an ownership fix.
Syntax
chown [OPTIONS] USER[:GROUP] FILE... Common options
| Option | What it does |
|---|---|
user | Change only the owner. |
user:group | Change owner and group together. |
:group | Change only the group. |
-R | Recursive: apply to a directory tree. |
--from=old | Only change files currently owned by a given user (safety filter). |
How to use chown: examples
$ sudo chown www-data:www-data /var/www/html -R Hand a web root to the web server user — the most typed chown on the internet.
$ sudo chown diego report.txt Change just the owner.
$ sudo chown :developers shared/ Change only the group.
$ ls -l Verify: columns three and four of the long listing are owner and group.
$ sudo chown -R --from=root diego ~/projects Fix files accidentally created as root, touching nothing else.
Real-world use cases for chown
Post-deploy ownership repair
Files uploaded as your user, service running as www-data, app can't write: sudo chown -R www-data:www-data /var/www/app/storage. Scoping to the writable subdirectories (storage, uploads, cache) rather than the whole tree keeps code files safely non-writable by the service.
Onboarding files to a shared group
A team shares /srv/projects: sudo chown -R :developers /srv/projects plus chmod -R g+w, and setgid on the directory (chmod g+s) so new files inherit the group automatically. The trio — chown, chmod, setgid — is the standard shared-folder recipe.
Pro tips and common mistakes
- Only root can change a file's owner — chown without sudo can at most switch the group, to groups you belong to.
- Verify with ls -l (columns 3 and 4) or stat -c "%U:%G" file for scripting.
- Copy ownership from a reference: chown --reference=goodfile brokenfile.
- Limit blast radius on recursive changes with --from=olduser — only files owned by that user are touched.
Frequently asked questions about chown
Why do I get "Operation not permitted"?
Only root can give files away to another user. Prefix the command with sudo. (Changing the group works unprivileged only into groups you belong to.)
What is the difference between chown and chmod?
chown decides who owns the file (user and group); chmod decides what the owner, group and others are allowed to do with it. Fixing a permission problem often needs both.
Why did my web app stop writing files after deployment?
The deploy probably ran as your user, so new files are yours, not the service's. Re-assign them: sudo chown -R serviceuser:servicegroup /path/to/app.
Related commands
List the contents of a directory, with options for hidden files, long format, sorting and more.
findLocate files anywhere in a directory tree by name, type, size, date — and act on them.
chmodChange file permissions with numeric (755, 644) and symbolic (u+x) modes — clearly explained.