chown, short for change owner, is the Linux and Unix command that sets the user owner and optionally the group owner of files, directories and other filesystem objects. Ownership determines which of the three permission classes, owner, group or others, applies when a process tries to access a file, so chown works hand in hand with chmod.
In Linux permissions, chown is the tool that assigns responsibility for a file. Because giving away files could be abused to evade disk quotas or plant files under another identity, changing the user owner is restricted: on Linux it requires root privileges or the CAP_CHOWN capability, which administrators usually obtain through sudo.
How chown changes ownership
Every inode stores a numeric user ID (UID) and group ID (GID). chown resolves names to these numbers and updates the inode through the chown, fchown or lchown system calls. The file content is untouched; only metadata and its change time are updated.
The basic syntax is chown [options] OWNER[:GROUP] FILE.... The following table shows how the owner specification is interpreted.
| Specification | Example | Result |
|---|---|---|
| User only | chown alice report.txt | User changes, group unchanged |
| User and group | chown alice:dev report.txt | Both user and group change |
| User and login group | chown alice: report.txt | Group becomes the login group of alice |
| Group only | chown :dev report.txt | Only group changes, like chgrp |
| Numeric IDs | chown 1001:1001 data/ | Sets IDs even without a matching account |
Numeric IDs matter in containers and on shared storage, where the same name may map to different numbers on different systems. The filesystem always stores numbers; names are only a lookup through the user database.
Important options and their effects
The GNU coreutils version of chown, found on most Linux distributions, offers options that control recursion, symbolic links and reporting. Choosing the wrong combination can change ownership far outside the intended directory.
| Option | Effect | Caution |
|---|---|---|
-R | Recursive change through a directory tree | Double-check the path before running |
-h | Changes a symbolic link itself, not its target | Default affects the target |
-H, -L, -P | Control link traversal during recursion | -L can leave the intended tree |
--from=OWNER:GROUP | Changes only files with the given current owner | Safe selective migration |
--reference=FILE | Copies ownership from another file | Reference file must be correct |
-v, -c | Reports every file or only changed files | Useful for audit logs |
--preserve-root | Refuses to operate recursively on / | Default in recent GNU versions |
chown compared with related permission tools
chown answers who owns a file; other tools answer what each party may do or set defaults for new files. Confusing them is a frequent source of permission errors.
| Tool | What it changes | Who may run it |
|---|---|---|
| chown | User owner and group owner | Root for user changes |
| chgrp | Group owner only | Owner, if member of target group |
| chmod | Read, write and execute bits, special bits | Owner or root |
| umask | Default permissions for new files | Each process for itself |
| setfacl | Linux ACL entries for extra users and groups | Owner or root |
A regular user may change the group of a file they own to any group they belong to, either with chgrp or with chown and only a group. Only privileged processes may change the user owner.
Security side effects of changing ownership
chown has deliberate security side effects. When a non-root user changes the owner or group of an executable, the kernel clears the setuid and setgid bits so that an executable cannot keep elevated privileges under a new identity; GNU chown run by root may clear them too, depending on the file type and kernel. After changing ownership of a privileged binary, verify special bits with `ls -l` and restore them only if they are truly required.
Ownership also interacts with the sticky bit on shared directories such as /tmp, where only a file’s owner, the directory owner or root may delete it. Reassigning files there changes who can remove them.
Common mistakes with chown
- Typing a space in a recursive path:
chown -R www-data: / var/wwwtargets the root directory as well as the intended folder. - Following symbolic links with -L: ownership changes can spread into system directories referenced by links.
- Fixing permission errors by making everything owned by the web server user: this lets a compromised application rewrite its own code.
- Assuming names travel between hosts: copying files with numeric IDs to another system can assign them to unrelated accounts.
- Using chown on network or FUSE mounts: many such filesystems ignore or reject ownership changes, and the real control is on the server.
- Running chown in containers without user namespace awareness: host and container UIDs may differ, so files appear owned by unexpected users.
The short version
chown is the command that changes who owns a file on a Linux computer. Every file has an owner and a group, and that ownership decides which permission rules apply when someone tries to open, edit or run it.
It is like transferring the registration of a car. The car stays the same, but the name on the papers changes, and with it who may legally drive and maintain it. Only an administrator can transfer ownership to someone else.
Where it makes a difference
A system administrator migrates a web application to a new Linux server. The files arrive from an archive owned by the administrator’s personal account, and the web server, running as www-data, cannot write to the upload folder. The pages load, but every image upload fails with a permission error.
Instead of handing the entire application to the web server user, the administrator runs sudo chown -R deploy:www-data /srv/app so the deployment account owns the code, then sudo chown -R www-data:www-data /srv/app/uploads for the one directory that must be writable. Uploads work again, while the application code stays read-only to the web server, which limits the damage if the application is ever compromised.