Both show up in the same "fix this permission error" troubleshooting session, which is exactly why they get blurred together — but they answer two completely different questions. chmod answers what can each scope (owner, group, others) do to a file that already has an owner and group. chown answers who the owner and group actually are in the first place. Reaching for the wrong one is the single most common reason chmod 777 shows up as a "fix" for what was really an ownership problem all along.
What chmod actually controls
Every file already has an owner and a group attached to it — chmod never touches either one. It only sets what each of the three existing scopes (owner, group, everyone else) is allowed to do: read, write, execute, plus the setuid/setgid/sticky special bits. See Linux Permissions Calculator for converting between octal, symbolic notation, and the special bits interactively — this post stays on how chmod and chown relate, not the permission bits themselves.
One detail worth knowing: the file's owner can always chmod their own file, regardless of what its current permissions say — even a file already set to 000 (no access for anyone) can still be chmod'd back open by its owner, because chmod is gated on ownership metadata, not on the permission bits it's about to change.
What chown actually controls
chown changes who the owner and group are:
chown alice file # change the owner to alice, leave the group as-is
chown alice:staff file # change the owner to alice AND the group to staff
chown :staff file # change only the group, leave the owner as-is (same as chgrp staff file)That third form has its own dedicated command, chgrp, for exactly this one job — functionally identical to chown :group, just more explicit about intent when a script only ever touches group ownership.
The asymmetry that actually matters
A regular user can always chmod a file they own, however they like. The same is not true for chown: on Linux, changing a file's owner to someone else requires root (specifically the CAP_CHOWN capability) — an ordinary user cannot give a file away, even a file they own themselves. Changing the group is more permissive: the owner can change it to any group they're already a member of, without needing root at all. This asymmetry is deliberate: freely reassigning ownership would break disk quota accounting and let one user dump files onto another user's storage allowance.
Why real workflows need both, not either
The common case that puts both commands in the same breath: a file lands with the wrong owner — created by root during setup, or checked out of git before the service account existed — and also needs different permission bits than whatever it already has. Fixing only one half leaves the other problem in place:
chown -R appuser:appgroup /srv/app
chmod -R 750 /srv/appOrder between the two doesn't matter — they're independent operations on the same file, not a sequence where one depends on the other having already run.
The recursive flag's sharp edge
-R works on both commands, but a single chmod -R 644 across a directory tree is a classic mistake: it strips the execute bit from every directory too, and a directory without execute permission can't be entered or have its contents accessed by path — even if you can still technically list names in it. The fix is chmod -R u+rwX,g+rX,o+rX — capital X, not lowercase — which sets execute only on directories, or on files that already had execute set for at least one scope, leaving ordinary non-executable files alone. The alternative is two separate passes with find, one for directories and one for files.
Common mistakes
- chmod 777 to fix an ownership problem. If the real issue is that a process runs as a user who doesn't own the file, chown to the right user (or group) is the actual fix — opening permissions to everyone is a workaround that also opens the file to everyone else on the system.
- Expecting to chown a file to another user without root. This fails by design; use
sudo, or have the target user create the file themselves in the first place. - Recursive chmod with a single numeric mode across mixed files and directories. Covered above — use capital
Xor separatefindpasses.
FAQ
Can I chmod a file I don't own?
No, unless you're root — ownership, not group membership or existing permission bits, is what grants the right to chmod a file.
Can I give my own file to someone else with chown?
Not without root. Have that user create the file themselves, or use sudo chown if you have the access to do so.
What's the actual difference between chown :group and chgrp group?
None functionally — chgrp exists as a clearer, more explicit name for the same operation chown already supports via its :group form.
Try it yourself
Linux Permissions Calculator converts between octal, symbolic notation, and the setuid/setgid/sticky special bits chmod controls — runs entirely in your browser.