Linux command: chown

17 July 2026

Every file on a Linux system carries a small label that says who owns it. When a website suddenly cannot write its cache, or a freshly copied folder refuses to behave, the cause is often not the permissions themselves but the owner behind them. The command chown is how you change that owner. It is the quiet partner of chmod: one decides what each class of user may do, the other decides who those users actually are.

1. The Basics

The job of chown is to change the owner and, optionally, the group of a file or directory. Where chmod edits the permission bits (the rwx letters), chown edits the two names those bits refer to.

Every file has exactly one owner and one group:

Attribute	What it is	Set by
owner (user)	The single user who owns the file, usually the one who created it	`chown`
group	One named group of users who share access to the file	`chown` or `chgrp`
mode	What the owner, group, and others may each do (read, write, execute)	`chmod`

The command that decides who a file belongs to. Behind one short word sits the whole idea of ownership in a multi-user system, the reason only root may hand files to other users, and a security rule that quietly disarms dangerous programs.

This article starts with the simplest ownership change and builds up step by step to groups, recursive changes across a whole directory tree, symbolic links, and the surprising rules that protect the system. By the end, the third and fourth columns of ls -l will read like plain language.

The right mental model: permissions and ownership are two halves of one answer. The mode says "the owner may write this"; ownership says "and you are the owner". Neither half means anything without the other.

1.1 Reading Ownership First

Before you change ownership, you have to see it. Run ls -l and look at the third and fourth columns:

$ ls -l report.txt
-rw-r--r--  1 peter staff  1234 May 28 17:02 report.txt
                |     |
              owner  group

Here the owner is peter and the group is staff. The permission string in front (-rw-r--r--) decides what each of them may do, but it is chown that decides the names peter and staff in the first place. If you want to see the numeric IDs behind those names, add -n (short for numeric):

$ ls -ln report.txt
-rw-r--r--  1 1000 1000  1234 May 28 17:02 report.txt

The names are only a friendly face; the kernel stores a numeric user ID (UID) and group ID (GID). That detail matters later, when you copy files between machines that do not share the same list of users.

2. Where the Name Comes From

The name chown is short for change owner.

chown  =  CHange OWNer

It follows the same naming habit as its neighbours: chmod (change mode), cp (copy), mv (move), and rm (remove). Early Unix was typed on slow teletype terminals that printed every character onto paper, so command names were kept as short as they could be while still being readable. The habit stuck, and fifty years later chown is still chown.

The command is a thin wrapper around a single system call, also named chown(), which writes the new owner and group IDs into the file's metadata (its inode). There is a matching command, chgrp (short for change group), that changes only the group. As you will see, chown can do everything chgrp does, so many people never reach for chgrp at all.

3. A Short History

Ownership is one of the oldest ideas in Unix. It shipped in Unix 1st Edition at Bell Labs in 1971, together with the file modes that chmod edits. The pairing of an owner, a group, and a set of permission bits has outlived nearly every operating system it competed with, and it still runs on every Linux server today.

Era	Milestone
1971	Unix 1st Edition ships with file owners and `chown`
1970s	Group ownership joins user ownership, giving the owner/group/others model
1980s	POSIX standardises the "restricted chown" rule that stops users giving files away
Today	The GNU coreutils `chown`, written by David MacKenzie and Jim Meyering, runs on most Linux distributions

As with most core commands, there are two versions in the wild. Linux systems run the GNU coreutils version; macOS and the BSDs ship a BSD version. They agree on the important things, but a few options differ (for example, GNU offers --from and --reference, which BSD lacks, and the two spell the recursive symlink options a little differently). This article uses the GNU version, verified against coreutils 9.4, which is what you will find on almost every Linux server.

4. Simple Use Cases

4.1 Changing the Owner

The simplest form gives a file to a new owner. You name the user, then the file:

$ chown peter report.txt
$ ls -l report.txt
-rw-r--r--  1 peter staff  1234 May 28 17:02 report.txt

The owner is now peter; the group (staff) is left untouched. This is the most common everyday use: a file was created by the wrong user, and you set it right. Note one important rule up front, covered in detail in section 7: on Linux, only root may change a file's owner. In practice you almost always run chown with sudo:

$ sudo chown peter report.txt

4.2 Changing the Owner and Group Together

To set both at once, write the owner, a colon, and the group, with no spaces:

$ sudo chown peter:staff report.txt
$ ls -l report.txt
-rw-r--r--  1 peter staff  1234 May 28 17:02 report.txt

Read peter:staff as "owner peter, group staff". This single form is why most people never learn chgrp: chown already covers the group.

chown  peter : staff  file
       |       |
       |       +--- group: the new group
       +----------- owner: the new user

4.3 Changing Only the Group

If you leave the owner out and start with the colon, only the group changes. This does exactly the same job as chgrp:

$ sudo chown :www-data page.html   # change group only
$ sudo chgrp www-data page.html    # identical result

Both commands set the group to www-data and leave the owner alone. Which you use is a matter of taste; the colon form saves you from remembering a second command.

5. Moderate Use Cases

There is a neat shorthand for "make this user the owner, and set the group to that user's own group". You write the owner, a colon, and then nothing:

$ sudo chown peter: report.txt

The trailing colon means "use peter's login group". If peter's primary group is also called peter (the common default on modern Linux), the file ends up owned by peter:peter. It is a small saving, but a handy one when you reset a user's files to their normal state.

You type	Owner	Group
`chown peter file`	set to `peter`	unchanged
`chown peter:staff file`	set to `peter`	set to `staff`
`chown peter: file`	set to `peter`	set to `peter`'s login group
`chown :staff file`	unchanged	set to `staff`
`chown : file`	unchanged	unchanged

5.2 Using Numeric IDs

You do not have to use names. Anywhere a user or group name is allowed, a numeric ID works too:

$ sudo chown 1000:1000 report.txt

This is essential when a user has no name on the current system, which happens all the time inside Docker containers, on rescue systems, or when restoring a backup from another machine. Because the kernel really stores numbers, not names, numeric IDs always work even when the name lookup does not. If a name and a number could be confused, you can force numeric reading with a leading +, as in chown +1000 file.

Names are a convenience layer. The file remembers a UID and a GID; the mapping to peter and staff lives in /etc/passwd and /etc/group (or in LDAP or Active Directory, through the Name Service Switch). Copy a file to a machine with a different mapping and the same numbers may show a different name, or no name at all. Containers make this vivid: a user namespace can remap IDs, so UID 1000 inside a Docker container may belong to a completely different user on the host.

5.3 Copying Ownership: `--reference`

Instead of naming an owner and group, you can tell chown to copy them from another file with --reference:

$ sudo chown --reference=working.conf broken.conf

Now broken.conf has exactly the same owner and group as working.conf. This is the natural fix when one file in a directory works and another does not, and you want them to match without reading and typing the names by hand.

5.4 Reporting What Changed

By default chown is silent. Two flags make it talk. Use -v (short for verbose) to report every file it touches, or -c (short for changes) to report only the files that actually changed:

$ sudo chown -c peter:staff *.txt
changed ownership of 'notes.txt' from root:root to peter:staff
changed ownership of 'todo.txt' from root:root to peter:staff
# report.txt is not listed: it already belonged to peter:staff

On a large batch, -c is the better choice: it shows only the real work and stays quiet about files that were already correct.

6. Advanced Use Cases

6.1 Changing a Whole Tree: `-R`

The -R flag (short for recursive) applies the change to a directory and everything inside it. This is the single most useful advanced option, and the one you will reach for when handing a website to its web-server user:

$ sudo chown -R www-data:www-data /var/www/site

Unlike the recursive chmod -R trap, recursive chown is usually safe, because owner and group mean the same thing for files and directories. There is still one thing to watch, though, and it involves symbolic links.

6.2 Symbolic Links: `-h` and the Default

By default, when you point chown at a symbolic link, it does not change the link. It follows the link and changes the file the link points to (its target). That is the --dereference behaviour, and it is the default:

$ ls -l link
lrwxrwxrwx  1 peter staff  8 ... link -> secret.txt

$ sudo chown root link          # changes secret.txt, NOT the link
$ ls -l secret.txt
-rw-r--r--  1 root  staff  ... secret.txt

To change the ownership of the link itself instead of its target, add -h (short for no-dereference, from the underlying lchown system call):

$ sudo chown -h root link        # changes the link, leaves the target alone

This matters most during a recursive run. The example from the manual, chown -hR root /u, changes the owner of a whole tree and of any symbolic links found in it, without following those links out of the tree. Combining a plain recursive chown with links an untrusted user can create is a known way to trick a tool into changing files it should never touch, so on shared systems the -h habit is a safety habit.

When you do recurse with -R, three more flags decide whether chown follows symbolic links that point to directories:

Flag	Behaviour during `-R`
`-P`	Do not follow any symbolic link. This is the default, and the safe choice.
`-H`	Follow a symlink only if it is named directly on the command line, not ones found deeper in the tree.
`-L`	Follow every symlink to a directory it meets. Powerful and easy to regret; it can lead `chown` far outside the tree you meant.

If more than one is given, only the last one counts. Unless you have a specific reason, leave the default -P in place.

6.3 Guarding the Change: `--from`

The --from option changes a file only if it currently has the owner (or group) you name. Everything else is skipped:

$ sudo chown --from=olduser newuser file   # only if file is currently olduser's

This is a precision tool. The classic job is a user-ID renumbering: you want to move every file belonging to olduser to newuser, but leave all other files alone. Doing that with find and a separate chown leaves a small window in which the wrong file could slip through; --from closes most of that gap by checking the current owner at the moment of the change:

$ sudo chown -hR --from=olduser newuser /home

6.4 Protecting the Root Directory: `--preserve-root`

A recursive command aimed at / by accident can rewrite the ownership of an entire system. The --preserve-root option makes chown refuse to recurse into /:

$ sudo chown -R --preserve-root peter /   # refuses, instead of wrecking the system

Modern distributions often enable this guard by default in aliases, but it is worth knowing the flag exists, and worth never typing a bare chown -R something / in the first place.

7. Something Most Users Do Not Know

7.1 You Cannot Give Your Own Files Away

Here is the rule that surprises almost everyone. On Linux, an ordinary user cannot change the owner of a file to someone else, even for files they own. Only root may change ownership. Try it as a normal user and you get:

$ chown alice report.txt
chown: changing ownership of 'report.txt': Operation not permitted

This is the POSIX "restricted chown" rule, and it exists for good reasons. If users could give files away, they could dodge disk quotas by dumping files onto someone else's account, or plant a file in another user's name to frame them or slip past a check. So the power to change an owner is reserved for the superuser. Changing the group is more relaxed: you may set a file's group to any group you are a member of, without root.

Ownership flows one way for ordinary users: root can hand you a file, but you cannot hand it to anyone else. To move a file to another user, either become root, or make a copy the other user then owns themselves.

7.2 chown Quietly Disarms setuid Programs

This one is a genuine security feature hiding in plain sight. When you change the owner of a file, the kernel usually clears the setuid and setgid bits at the same time. Recall from chmod that a setuid program runs with its owner's identity. If changing the owner left that bit in place, you could take an ordinary program, make it setuid, then chown it to root and suddenly have a program that runs as root. Clearing the bit on every ownership change slams that door shut:

$ ls -l tool
-rwsr-xr-x  1 peter staff  ... tool     # setuid bit is set (the 's')

$ sudo chown root tool
$ ls -l tool
-rwxr-xr-x  1 root  staff  ... tool     # the 's' is gone; now a plain program

The practical lesson: if you deliberately need a setuid-root program, set the owner first and the setuid bit afterwards. Do it the other way around and your chmod u+s is silently undone by the next chown.

7.3 The Old Dot Separator

You may meet an old script that writes ownership with a dot instead of a colon:

$ sudo chown peter.staff report.txt    # legacy syntax

Very early Unix used a dot as the separator between owner and group. GNU chown still accepts it for backward compatibility, but it now prints a warning, and the support may be removed one day. The dot is also ambiguous: if a real user name contains a dot (say first.last), chown cannot tell where the name ends and the group begins. Always write the modern colon form, peter:staff, in anything new.

7.4 Not Every Filesystem Stores Ownership

Ownership is a feature of the filesystem, not of the file. The native Linux filesystems all record a UID and a GID in each inode:

$ stat -c '%U %G' report.txt
peter staff

But some filesystems have no place to keep that information. FAT32 and exFAT, the formats on most USB sticks and camera cards, store no Unix owner at all. NTFS (the Windows filesystem) does not either, at least not in a form Linux uses by default. When you mount such a disk, the kernel invents an owner for every file from the mount options, and chown simply fails or is ignored:

$ sudo chown peter /mnt/usb/photo.jpg
chown: changing ownership of '/mnt/usb/photo.jpg': Operation not supported

The fix is not chown; it is the mount. You set ownership for the whole disk at mount time with the uid= and gid= options, for example mount -o uid=1000,gid=1000 /dev/sdb1 /mnt/usb. If chown ever answers "Operation not supported", the filesystem, not your permissions, is the reason.

7.5 Ownership Is Not the Only Gate

Part of expertise is knowing when a tool runs out. You can set the owner and group perfectly and still be denied, because ownership is only the first of several access layers:

POSIX ACLs grant extra users or groups their own permissions on top of the owner/group/others model. A trailing + in ls -l (as in -rw-rwxr--+) is your hint; read them with getfacl.
SELinux and AppArmor add a whole separate policy layer. A process can own a file and still be blocked by its security context or profile, no matter what chown and chmod say.

When ownership looks right but access still fails, a small toolbox tells you why. Use them before reaching for another chown:

$ id                       # who am I, and which groups am I in?
$ stat report.txt          # exact owner, group, and mode of one file
$ namei -l /srv/data/file  # ownership and mode of every step in the path
$ find /srv -user root     # every file still owned by root
$ find /srv -group www-data # every file in a given group

The most underused of these is namei -l. Access to a file depends on every directory above it, and namei walks the whole path and prints the owner and mode at each step, so it shows exactly where a chain breaks.

8. Best Practices

Expect to use sudo. Changing an owner needs root. If chown says "Operation not permitted", you are almost certainly missing sudo, not doing anything wrong.
Set ownership before permissions, not after. A chown can clear setuid and setgid bits, so run chown first and chmod second when a file needs both.
Reach for the colon form. chown user:group file sets both at once and saves you a separate chgrp.
Prefer numeric IDs across machines. When moving files between servers, containers, or backups, chown 1000:1000 is reliable where names may not exist on both ends.
Use -h on shared systems when recursing. chown -hR changes links instead of blindly following them out of the tree, which closes a real security hole.
Never type chown -R user /. One stray slash can hand your whole system to the wrong owner. Double-check the path, and keep --preserve-root in mind.
Read the manual when unsure. The mark of a professional is not memorising every option; it is typing man chown the moment a question comes up.

$ man chown                              # the full manual page
$ chown --help                           # a quick summary (GNU)
$ info coreutils 'chown invocation'      # the verbose GNU manual

9. Common Mistakes

9.1 Myth versus Reality

Myth	Reality
"`chown` changes what I am allowed to do with a file."	No. That is `chmod`. `chown` only changes who the owner and group are; the permission bits stay as they were.
"I own this file, so I can give it to another user."	On Linux you cannot. Only root may change a file's owner. You can change the group to one you belong to, but not hand the file away.
"`chown user:group` needs a space around the colon."	It must have no spaces. `peter:staff` is one operand; `peter : staff` is an error.
"`chown` on a symlink changes the link."	By default it follows the link and changes the target. Add `-h` to change the link itself.
"Setting the owner keeps my setuid program working."	Changing the owner usually clears the setuid and setgid bits. Set ownership first, then the special bit.

9.2 Other Traps to Avoid

Fixing permissions with chown when you mean chmod, or the reverse. If the right user still cannot read a file after a mode change, the file may simply belong to the wrong owner. If it belongs to the right user but still fails, check the mode. The two commands solve different halves of the problem.
Forgetting -R on a directory. A plain chown user dir changes only the directory node, not the files inside it. Add -R to reach the whole tree.
Running a recursive chown from the wrong place. chown -R follows the path you give it exactly. Confirm you are in, or pointing at, the directory you think you are.
Using the dot separator in new scripts. peter.staff is legacy, warns, and breaks on names that contain a dot. Write peter:staff.
Breaking a web application with over-broad ownership. Handing every file to www-data can let the web server rewrite its own code. Give the server ownership only of the directories it truly needs to write, such as cache and uploads.

10. Summary

The chown command is small, but it settles a question that every multi-user system must answer: who does this file belong to?

chown means "change owner". It edits the owner and group that ls -l shows, and it has been part of Unix since 1971.
The basic forms are chown user file, chown user:group file, and chown :group file (which equals chgrp).
A trailing colon, as in chown peter: file, sets the group to the user's login group.
Names are a convenience over numeric UIDs and GIDs. Use numbers with chown 1000:1000 when moving files between machines or into containers.
Use -R to change a whole tree, -h to act on a symbolic link instead of its target, and --from to change only files with a given current owner.
Only root may change a file's owner, so you almost always run chown with sudo. You may change the group to one you belong to without root.
Changing ownership usually clears setuid and setgid bits, so set the owner first and the special bit second.
--reference copies another file's owner and group; -c and -v report what changed.
FAT, exFAT, and NTFS store no Unix owner; there you set ownership with the uid= and gid= mount options, not with chown.
Ownership is only the first gate. ACLs, SELinux, and AppArmor can still deny access; id, stat, and namei -l help you find out why.
When in doubt, type man chown.

This is the quick reference worth keeping:

chown peter file            set the owner to peter
chown peter:staff file      set owner peter and group staff
chown peter: file           owner peter, group = peter's login group
chown :staff file           change only the group (like chgrp)
chown 1000:1000 file        use numeric IDs (portable across machines)
chown -R www:www /var/www   change a whole directory tree
chown -h root link          change the symlink itself, not its target
chown -hR --from=old new /  renumber one user's files safely
chown --reference=A B       give B the same owner and group as A
sudo chown ...              ownership changes need root

Ownership is the half of Linux security that people forget until it bites: the permissions look right, yet nothing works, because the file belongs to the wrong user. If a server of yours keeps refusing to write its cache, or a site behaves after a deploy but not before, it often pays to have someone check the whole ownership and permission picture together, calmly, before a blanket chown -R turns a small mismatch into a bigger one.

Peter Martin

Joomla Specialist

Peter is a Joomla specialist and a Linux admin for fast, secure and scalable websites.

11 July 2026