LFCA 26 🐧 Changing Ownership — chown, chgrp
Permissions decide what can be done to a file. Ownership decides who the permissions apply to. Every file has an owner and a group, set when the file is created to the creating user and their primary group. When a file needs to belong to someone else — a web server that runs as www-data, a shared directory that should be owned by a team group, a home directory that was copied with the wrong owner — the tools are chown and chgrp. These commands change the owner and the group, and because ownership is the gate to every permission decision, changing it is a serious operation. A wrong chown can lock a user out of their own files, give a service access it should not have, or break an application that depends on a specific ownership. This chapter covers the syntax of both commands, the recursive flag and its dangers, the reference flag, the symbolic and numeric forms, the patterns for common tasks, and the habits that make ownership changes safe and reversible.
Key point: chown changes the owner of a file, and optionally the group in the same command. chgrp changes only the group. Both accept -R for recursion, --reference to copy ownership from another file, -v for verbose output, and --preserve-root to refuse operating on /. Only root can change the owner of a file; a file’s owner can change the group to any group they belong to. The owner and group are stored as UIDs and GIDs, and the names are looked up from /etc/passwd and /etc/group at display time.
Why ownership matters
Ownership is the first thing the kernel checks when a file is accessed. The owner’s permissions are checked first, then the group’s, then others’. Changing the owner changes which set of permission bits applies, which is a more fundamental change than changing the bits themselves.
Why the owner is usually the creator. When a user creates a file, the owner is set to that user’s UID and the group is set to the user’s primary GID. This is the default, and it is almost always right. The cases where it is not right are the cases that need chown: a file created by one user but meant to be owned by a service, a file copied from another system with the wrong owner, a directory that should belong to a team group rather than an individual.
Why the group is often more useful than the owner. The owner is a single user, and there can be only one. The group can contain many users, so granting access to a team means setting the group and adding members to it. This is why the group is the primary mechanism for shared access, and why chgrp and the group part of chown are used so often.
Why ownership is stored as numbers. The file records the owner as a UID and the group as a GID. The names are a display convenience, looked up from /etc/passwd and /etc/group. This means a file can be owned by a UID that no longer exists, which is why ls -l sometimes shows a number instead of a name. The number is still what the kernel uses.
Why changing ownership is more dangerous than changing permissions. Permissions are set by the owner, and the owner can always change them back. Ownership is set by root, and a user cannot change the owner of their own file. This asymmetry means a wrong chown can only be undone by root, which raises the stakes. The command is simple; the consequences are not.
Why
chownrequires root. Allowing a user to give their files to another user would break the accountability model — a file’s owner is meant to indicate who created it and who is responsible for it. Allowing a user to take ownership of another user’s files would be worse. Root is the only identity trusted to reassign ownership, and this is whychownis almost always run withsudo.
The chown command
chown changes the owner of a file. Its basic form takes a user name and a path.
$ chown alice file.txtAfter this command, file.txt is owned by alice. The group is unchanged unless it is specified.
Specifying both owner and group. The owner and group can be set in one command with a colon separator.
$ chown alice:developers file.txtThe owner becomes alice and the group becomes developers. This is the most common form, because setting ownership usually means setting both.
Setting only the group. If the owner should stay the same and only the group should change, the owner part can be omitted with a leading colon.
$ chown :developers file.txtThis changes only the group. It is equivalent to chgrp developers file.txt, and both forms are used. The colon form is convenient when the owner is already correct.
Copying ownership from a reference. The --reference flag copies the ownership from another file.
$ chown --reference=template.conf new.confThe owner and group of new.conf become those of template.conf. This is useful when a new file should match an existing one, and it avoids needing to know the values.
Why the colon is the separator. The colon distinguishes the owner from the group in a single argument. A dot was historically allowed as an alternative (alice.developers), but it is ambiguous when user names contain dots, and the colon is the modern standard. Older scripts may use the dot form.
Why the numeric form works. The owner and group can be given as UIDs and GIDs instead of names.
$ chown 1000:1001 file.txtThis is useful in scripts where the names might not be available, or when the exact numbers matter more than the names. The kernel works with numbers, so the numeric form is the one that always works.
Why chown on a symlink is different. By default, chown follows symbolic links and changes the target, not the link. The -h flag changes the link itself. This matters when a symlink is used to redirect ownership, and the default behavior can produce surprises.
The chgrp command
chgrp changes only the group of a file. It is the specialized tool for the group case, and it is equivalent to chown :group file.
$ chgrp developers file.txtThe group becomes developers. The owner is unchanged. The command is used when a file’s group needs to change but the owner is already correct, which is the common case for shared directories and team files.
Why chgrp exists separately. Before chown accepted the colon form, chgrp was the only way to change the group, and the two commands had separate syntax. Today chgrp is a convenience, and it remains in use because it is clear about its purpose. A script that changes only the group is more readable with chgrp than with chown :group.
When chgrp is preferred over chown. When the intent is purely to change the group, chgrp expresses it directly. When the owner and group are both changing, chown user:group is the single command that does both. The choice is about clarity, not capability.
Why a non-root user can run chgrp. A file’s owner can change the group to any group they belong to. This is the one ownership change a non-root user can make. It is useful for moving a file into a shared group directory without involving root. The restriction is that the new group must be one of the user’s groups.
Why the group change is limited to the user’s groups. Allowing a user to set an arbitrary group would let them grant access to a group they are not part of, which could be a privilege escalation. The kernel restricts the change to groups the user belongs to, and root can set any group.
Recursive ownership changes
The -R flag applies the change to every file and directory in a tree. It is the standard way to change ownership after copying a directory or deploying an application.
$ sudo chown -R www-data:www-data /var/www/htmlThe web server’s document root becomes owned by www-data in both owner and group, recursively. This is the canonical deployment command for a web application, and it is the example that most administrators learn first.
Why recursion is necessary. A directory tree has many files, and changing ownership one at a time is impractical. -R walks the tree and applies the change to each entry. It is the standard way to fix ownership after a cp, an rsync, or an extraction from an archive that did not preserve ownership.
Why -R is dangerous. A recursive chown on the wrong path changes the ownership of everything under it. A command like chown -R user:group / would change ownership of the entire filesystem, breaking every service and every user. The --preserve-root flag, which is the default on modern systems, refuses to operate on /, but it does not protect against a typo like /var instead of /var/www.
Why the --from option is useful. The --from option limits the change to files that currently have a specific owner and group. This is a safety measure that prevents changing files that have already been changed or that were never meant to be changed.
$ sudo chown -R --from=alice:alice bob:bob /srv/projectOnly files currently owned by alice:alice are changed. Files owned by other users are left alone. This is valuable when a directory contains files from multiple sources and only some should be reassigned.
Why the order matters for directories. chown -R processes the tree top-down. If a subdirectory is a mount point, -R does not cross into it by default, which is usually the right behavior. The -H, -L, and -P flags control how symlinks are followed, matching the behavior of chmod -R.
Why chown -R on a home directory requires care. Changing the owner of a home directory changes the owner of every file in it, including configuration files, SSH keys, and caches. The service that runs as that user will then be unable to read its own files, and the user may be unable to log in. The --from option is the safe way to do this, and a backup before the change is prudent.
Why
chown -Ris often paired withchmod -R. After copying a directory, both the ownership and the permissions may be wrong. The two commands are often run together, withchownsetting the owner and group andchmodsetting the mode. The order matters:chownfirst, thenchmod, because the mode is interpreted relative to the owner.
Common patterns
Several ownership patterns appear in nearly every Linux administration task. Knowing them makes the right command immediate.
Web server document root. The files served by a web server should be owned by the user the server runs as, so the server can read them and, where needed, write to them.
$ sudo chown -R www-data:www-data /var/www/html
$ sudo find /var/www/html -type d -exec chmod 755 {} \;
$ sudo find /var/www/html -type f -exec chmod 644 {} \;The chown sets the owner and group. The find commands set directories to 755 and files to 644, which is the standard split. The -exec runs the command once per file, which is slower than xargs but simpler to read.
Shared team directory. A directory where a team collaborates should be owned by a group and set with the setgid bit so new files inherit the group.
$ sudo chown -R :developers /srv/project
$ sudo chmod -R 2775 /srv/projectThe group becomes developers, and the setgid bit makes new files inherit the group. The mode 2775 grants the owner and group full access and others read and traverse.
Home directory ownership. A user’s home directory should be owned by the user and their primary group.
$ sudo chown -R alice:alice /home/aliceThis is the standard fix when a home directory has the wrong owner, which can happen after a restore from backup or a manual copy.
SSH directory permissions. The .ssh directory and its contents have strict ownership requirements, and sshd refuses to use keys that are not owned by the user.
$ chown -R alice:alice ~/.ssh
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pubThe private key must be 600 and owned by the user. The .ssh directory must be 700. The public key can be 644. These are the values sshd requires, and any deviation causes the key to be rejected.
Docker and container volumes. A volume mounted into a container is owned by the UID the container runs as, which may not match any user on the host. The chown is often run inside the container or with the numeric UID.
$ sudo chown -R 1000:1000 /srv/app/dataThe numeric form is used because the UID may not have a name on the host.
Complete Example Session
# ============================================
# PART 1: BASIC CHOWN
# ============================================
touch file.txt
ls -l file.txt
# -rw-r--r-- 1 alice alice 0 Mar 15 10:00 file.txt
sudo chown bob file.txt
ls -l file.txt
# -rw-r--r-- 1 bob alice 0 Mar 15 10:00 file.txt
# ============================================
# PART 2: OWNER AND GROUP
# ============================================
sudo chown bob:developers file.txt
ls -l file.txt
# -rw-r--r-- 1 bob developers 0 Mar 15 10:00 file.txt
# ============================================
# PART 3: GROUP ONLY
# ============================================
sudo chown :sudo file.txt
ls -l file.txt
# -rw-r--r-- 1 bob sudo 0 Mar 15 10:00 file.txt
sudo chgrp developers file.txt
ls -l file.txt
# -rw-r--r-- 1 bob developers 0 Mar 15 10:00 file.txt
# ============================================
# PART 4: NUMERIC FORM
# ============================================
sudo chown 1000:1001 file.txt
ls -ln file.txt
# -rw-r--r-- 1 1000 1001 0 Mar 15 10:00 file.txt
# ============================================
# PART 5: RECURSIVE
# ============================================
mkdir -p /tmp/tree/a/b
touch /tmp/tree/a/file1 /tmp/tree/a/b/file2
sudo chown -R www-data:www-data /tmp/tree
ls -lR /tmp/tree
# /tmp/tree:
# drwxr-xr-x 3 www-data www-data ... .
# ...
# -rw-r--r-- 1 www-data www-data ... file1
# -rw-r--r-- 1 www-data www-data ... file2
# ============================================
# PART 6: REFERENCE
# ============================================
touch template.conf new.conf
sudo chown alice:developers template.conf
sudo chown --reference=template.conf new.conf
ls -l template.conf new.conf
# -rw-r--r-- 1 alice developers ... template.conf
# -rw-r--r-- 1 alice developers ... new.conf
# ============================================
# PART 7: FROM OPTION
# ============================================
mkdir -p /tmp/mixed
touch /tmp/mixed/one /tmp/mixed/two
sudo chown alice:alice /tmp/mixed/one
sudo chown bob:bob /tmp/mixed/two
sudo chown -R --from=alice:alice carol:carol /tmp/mixed
ls -l /tmp/mixed
# -rw-r--r-- 1 carol carol ... one (changed)
# -rw-r--r-- 1 bob bob ... two (unchanged)
# ============================================
# PART 8: WEB ROOT
# ============================================
# Standard web deployment
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
# ============================================
# PART 9: SSH KEYS
# ============================================
chown -R alice:alice ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
# ============================================
# PART 10: PERMISSION DENIED
# ============================================
# As a non-root user:
chown bob file.txt
# chown: changing ownership of 'file.txt': Operation not permitted
# A non-root user can change the group to one they belong to:
chgrp developers file.txt # if alice is in developers
# succeeds
# ============================================
# PART 11: WHAT NOT TO DO
# ============================================
# sudo chown -R alice:alice /
# Changes ownership of the entire filesystem — catastrophic.
# sudo chown -R www-data:www-data /var
# Changes ownership of system directories — breaks services.
# sudo chown alice /etc/passwd
# Changing ownership of identity files breaks the system.The eleven parts cover the basic forms, the recursive and reference options, the --from safety, the common patterns, and the failures and dangers.
Quick Reference
Commands
| Command | Effect |
|---|---|
chown user file | Change owner |
chown user:group file | Change owner and group |
chown :group file | Change group only |
chown user: file | Change owner, group to user’s primary |
chgrp group file | Change group only |
Flags
| Flag | Effect |
|---|---|
-R | Recursive |
-v | Verbose |
-c | Report changes only |
-h | Affect symlinks, not targets |
--reference=ref | Copy ownership from ref |
--from=user:group | Change only if current matches |
--preserve-root | Refuse / (default) |
Numeric Form
| Form | Meaning |
|---|---|
1000 | UID 1000 |
1000:1001 | UID 1000, GID 1001 |
:1001 | GID 1001 only |
Who Can Change What
| Action | Who |
|---|---|
| Change owner | root only |
| Change group to own group | File owner |
| Change group to any group | root |
| Change owner and group | root |
Common Patterns
| Task | Command |
|---|---|
| Web root | chown -R www-data:www-data /var/www/html |
| Shared team | chown -R :developers /srv/project |
| Home directory | chown -R alice:alice /home/alice |
| SSH keys | chown -R alice:alice ~/.ssh |
| Container volume | chown -R 1000:1000 /srv/data |
| Safe reassign | chown -R --from=old:old new:new path |
Comparison with chmod
| Aspect | chown | chmod |
|---|---|---|
| Changes | Owner/group | Permission bits |
| Who | root (owner for group) | Owner |
| Symbolic | No | Yes |
| Numeric | UID:GID | Mode |
| Recursive | -R | -R |
| Reference | --reference | --reference |
Best Practices
✅ Do This:
# Set owner and group together
sudo chown -R www-data:www-data /var/www/html # ✅
# Use --from for safe reassignment
sudo chown -R --from=alice:alice bob:bob /srv/project # ✅
# Use --reference to match an existing file
sudo chown --reference=template.conf new.conf # ✅
# Use numeric form when names are not available
sudo chown -R 1000:1000 /srv/app/data # ✅
# Back up before a recursive ownership change
sudo tar -czf backup.tar.gz /srv/project
sudo chown -R newuser:newgroup /srv/project # ✅
# Fix SSH ownership explicitly
chown -R alice:alice ~/.ssh && chmod 700 ~/.ssh # ✅
# Verify with ls -l after the change
ls -l /var/www/html # ✅❌ Don’t Do This:
# Don't chown the whole filesystem
sudo chown -R alice:alice / # catastrophic # ⚠️
# Don't chown system directories
sudo chown -R www-data:www-data /var # breaks services # ⚠️
# Don't chown identity files
sudo chown alice /etc/passwd # breaks the system # ⚠️
# Don't chown without a backup on important trees
# The change can only be undone by root # ⚠️
# Don't forget -h for symlinks
chown alice link # changes the target, not the link # ⚠️
# Don't assume a non-root user can chown
chown bob file # Operation not permitted as non-root # ⚠️
# Don't use the dot separator in modern scripts
chown alice.developers file # ambiguous, use colon # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
chown without sudo | Operation not permitted | Use sudo |
Forgot -R | Only top-level changed | Add -R |
| Wrong recursive path | Unintended files changed | Use --from, verify |
| Symlink target changed | Link untouched, target changed | Use -h |
| UID shown as number | User not in /etc/passwd | Expected for stale UIDs |
| Dot separator | Ambiguous | Use colon |
| Group change denied | Not a member of the group | Use a group you belong to |
| Home directory locked | Owner changed incorrectly | Fix with sudo chown |
Real-World Examples
1. Web root
sudo chown -R www-data:www-data /var/www/html2. Shared team directory
sudo chown -R :developers /srv/project3. Home directory fix
sudo chown -R alice:alice /home/alice4. SSH keys
chown -R alice:alice ~/.ssh5. Reference copy
sudo chown --reference=/etc/skel/.bashrc ~/.bashrc6. Numeric for containers
sudo chown -R 1000:1000 /srv/app/data7. Safe reassignment
sudo chown -R --from=alice:alice bob:bob /srv/project8. Restore from backup with ownership
sudo tar -xzf backup.tar.gz -C / --same-owner9. Change group only
sudo chgrp developers file.txt10. Verify after change
ls -ln /var/www/htmlVisual: Owner and Group
┌──────────────────────────────────────────────────────────┐
│ ls -l output: │
│ │
│ -rw-r--r-- 1 alice developers 1024 Mar 15 file.txt │
│ │ │ │
│ │ └── group (GID) │
│ └── owner (UID) │
│ │
│ File on disk stores: │
│ UID = 1000 │
│ GID = 1001 │
│ │
│ Names are looked up from: │
│ /etc/passwd → 1000 = alice │
│ /etc/group → 1001 = developers │
│ │
└──────────────────────────────────────────────────────────┘Visual: chown vs chgrp
┌──────────────────────────────────────────────────────────┐
│ chown alice:developers file.txt │
│ Owner: alice │
│ Group: developers │
│ │
│ chown alice file.txt │
│ Owner: alice │
│ Group: unchanged │
│ │
│ chown :developers file.txt │
│ Owner: unchanged │
│ Group: developers │
│ │
│ chgrp developers file.txt │
│ Owner: unchanged │
│ Group: developers │
│ │
│ chown :developers and chgrp developers are equivalent. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Recursive with –from
┌──────────────────────────────────────────────────────────┐
│ BEFORE: │
│ /srv/project │
│ file1 alice:alice │
│ file2 alice:alice │
│ file3 bob:bob │
│ │
│ COMMAND: │
│ chown -R --from=alice:alice carol:carol /srv/project │
│ │
│ AFTER: │
│ /srv/project │
│ file1 carol:carol (changed) │
│ file2 carol:carol (changed) │
│ file3 bob:bob (unchanged — different owner) │
│ │
│ Only files matching the --from condition are changed. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Web Deployment Pattern
┌──────────────────────────────────────────────────────────┐
│ 1. Extract the application │
│ tar -xzf app.tar.gz -C /var/www/html │
│ │
│ 2. Fix ownership │
│ chown -R www-data:www-data /var/www/html │
│ │
│ 3. Fix permissions │
│ find /var/www/html -type d -exec chmod 755 {} \; │
│ find /var/www/html -type f -exec chmod 644 {} \; │
│ │
│ 4. Verify │
│ ls -ln /var/www/html │
│ │
│ The web server can now read the files. │
│ │
└──────────────────────────────────────────────────────────┘Visual: What a Wrong chown Breaks
┌──────────────────────────────────────────────────────────┐
│ chown -R alice:alice /var/www/html │
│ │
│ Before: www-data owns the files │
│ web server can read them │
│ │
│ After: alice owns the files │
│ web server may not be able to read them │
│ → 403 errors for every request │
│ │
├──────────────────────────────────────────────────────────┤
│ chown -R alice:alice /home/bob │
│ │
│ Before: bob owns his home directory │
│ bob can log in, read his files, use his SSH keys │
│ │
│ After: alice owns bob's files │
│ bob cannot write to his own home │
│ SSH key auth may fail │
│ → login and session errors │
│ │
├──────────────────────────────────────────────────────────┤
│ chown -R alice:alice /etc │
│ │
│ System configuration files now owned by alice. │
│ Services that run as root or their own users cannot │
│ read or write what they need. │
│ → the system is broken. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Permission Check Order
┌──────────────────────────────────────────────────────────┐
│ Process tries to access a file │
│ │ │
│ ▼ │
│ Is process UID == file owner UID? │
│ │ │
│ ├── Yes ──► Use OWNER bits │
│ │ │
│ └── No │
│ │ │
│ ▼ │
│ Is file's GID in process's group list? │
│ │ │
│ ├── Yes ──► Use GROUP bits │
│ │ │
│ └── No ──► Use OTHERS bits │
│ │
│ Changing the owner changes which set of bits applies. │
│ This is why chown is more consequential than chmod. │
│ │
└──────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Change owner | chown user file |
| Change owner and group | chown user:group file |
| Change group only | chgrp group file or chown :group file |
| Recursive | -R |
| Reference | --reference=ref |
| Conditional | --from=user:group |
| Numeric | UID:GID |
| Symlinks | -h for the link itself |
| Who can chown | root only |
| Who can chgrp | File owner, to their own groups |
Key takeaways:
- Ownership determines which permission bits apply — the owner is checked first, then the group, then others, so changing the owner changes the effective permissions
chownsets the owner and optionally the group — the colon formuser:groupsets both in one commandchgrpsets only the group — equivalent tochown :group, and clearer when the owner is unchanged- Only root can change the owner — a file’s owner can change the group to a group they belong to, but nothing more
-Rapplies the change recursively — the standard way to fix ownership after a copy or deployment, and the flag that makes the command dangerous--fromis the safety mechanism — it limits the change to files that currently match a specific owner and group, preventing unintended reassignment--referencecopies ownership from another file, which avoids needing to know the values- The numeric form is used when names are unavailable — container volumes and stale UIDs are the common cases
- Symlinks are followed by default —
-hchanges the link itself, which is the safer behavior when the link is the target - A wrong recursive
chowncan break a service or a user account — the web root, the home directory, and/etcare the paths where mistakes are most costly, and a backup before the change is prudent
Remember: Ownership is the gate to every permission check. chown and chgrp are simple commands with serious consequences, because the change can only be undone by root and the effect is invisible until something tries to access the file. Use --from when reassigning, back up before recursive changes, verify with ls -l after, and remember that the owner is checked before the group — changing the owner changes everything downstream.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!