Permissions decide what the owner and group may do; chown decides who the owner and group are. Set both at once with user:group, which is a root task:
sudo chown deploy:developers report.txt
The forms
sudo chown deploy file # owner only
sudo chown deploy:developers file # owner AND group
sudo chown :developers file # group only (leading colon)
sudo chown deploy: file # owner, and set group to deploy's primary groupRecursively, for a whole tree
sudo chown -R deploy:developers /srv/app-R walks the directory. This is the standard fix after deploying files as the wrong user, or after a git clone/tar as root left everything owned by root. It pairs with recursive chmod when both owner and mode are wrong.
chown vs chgrp, and who is allowed
- Changing the owner always needs root. A normal user cannot give a file away to someone else (that would let people dodge quotas and plant files).
- Changing only the group can be done by the file's owner with
chgrp, but only to a group they themselves belong to:
chgrp developers report.txt # owner can do this if they're in developersSo chgrp (or chown :group) is sometimes available without sudo; reassigning the owner never is.
The classic case: a root-owned file you cannot edit
You ran something with sudo and now a file in your home is owned by root and you cannot write it. Hand it back:
sudo chown $USER:$USER ~/.config/app/settings.jsonThis is the same root cause behind sudo ssh-keygen making an unusable key: elevation created root-owned files in your space.
FAQ
See also
- Linux file permissions explained: what owner and group can each do.
- How to chmod recursively: fix modes across a tree alongside ownership.
- How to create a group on Linux: the groups you assign here.
- Fix SSH "permissions are too open": the root-owned-key case chown solves.
Sources
Authoritative references this article was fact-checked against.





