chown Command in Linux with Examples

Ownership problems can make a file look correctly permissioned while the wrong account still controls it. The chown command in Linux changes the user and group attached to files and directories, which is the fix when files were created with sudo, unpacked as root, written by a container, moved between service accounts, or assigned to a shared project group.

Use chown for ownership and chmod for permission bits. The two commands often appear together, but they solve different layers: chown decides who owns the path, while chmod decides what the owner, group, and others can do with it.

Check chown Command Availability and Syntax

chown updates file ownership metadata. Each file has an owning user and an owning group, visible in long listings and from stat. Changing the owner usually requires root privileges or the CAP_CHOWN capability, while group changes can also be restricted by the system’s user and group policy.

Most full Linux distributions provide chown through a core utilities package. Current systems may use GNU coreutils, uutils coreutils, BusyBox, or another implementation. For portable administration, prefer common syntax, avoid ambiguous shortcuts, and check local help before using implementation-specific options.

Verify chown Is Available

Confirm the command path before troubleshooting an ownership problem:

command -v chown

A normal Linux system returns a path such as:

/usr/bin/chown

Print implementation details when option behavior matters. GNU and uutils builds usually support --version, while BusyBox-style environments may fall back to help output:

chown --version 2>/dev/null || chown --help

Recent Fedora and Rocky Linux releases identify GNU coreutils. Current Ubuntu 26.04 builds can identify uutils coreutils. The examples use syntax that works on both GNU coreutils and uutils coreutils unless an implementation boundary is called out.

chown Command Syntax

The common forms change an owner, a group, both fields, or copy ownership from another file:

chown [OPTIONS] OWNER FILE...
chown [OPTIONS] OWNER:GROUP FILE...
chown [OPTIONS] :GROUP FILE...
chown [OPTIONS] --reference=REFERENCE FILE...

The GNU chown manual documents GNU-specific options such as --from and --reference, while the POSIX chown utility definition describes the portable recursive and symlink traversal options.

Task	Command Pattern	What It Changes
Change only the owner	chown alice file	Sets the owning user to alice and leaves the group unchanged.
Change owner and group	chown alice:developers file	Sets both ownership fields explicitly.
Change only the group	chown :developers file	Leaves the owner unchanged and changes the owning group.
Use numeric IDs	chown 1000:1000 file	Sets ownership by UID and GID when names are missing or misleading.
Copy ownership from another file	chown --reference=template file	Applies the same owner and group as the reference file.
Change a symbolic link itself	chown -h alice:developers link	Changes link ownership instead of the link target.
Change a directory tree	chown -R alice:developers project	Applies ownership recursively to the directory and its contents.

Write both fields when the group matters. GNU coreutils commonly treats OWNER: as the owner’s login group, but current uutils coreutils builds can set a different group in privileged sessions. The explicit OWNER:GROUP form avoids that surprise.

Old examples sometimes use OWNER.GROUP. GNU coreutils still accepts that form in many cases, but a dot can also be part of a real user or group name. Use the colon form for new commands.

Create a Safe chown Practice Directory

Practice in a disposable directory under your home folder before touching service paths, web roots, backups, SSH keys, or shared project trees:

demo_dir="$HOME/chown-demo"
mkdir -p "$demo_dir/project/subdir" "$demo_dir/ssh-home/.ssh"
cd "$demo_dir"

printf 'draft\n' > report.txt
printf 'owner only\n' > owner-only.txt
printf 'group only\n' > group-only.txt
printf 'reference\n' > reference.txt
printf 'destination\n' > destination.txt
printf 'guarded\n' > guarded.txt
printf 'target\n' > symlink-target.txt
ln -s symlink-target.txt symlink-file
printf 'config\n' > project/app.conf
printf 'data\n' > project/subdir/data.txt
printf 'numeric\n' > numeric-id.txt
printf 'spaces\n' > "file with spaces.txt"
printf 'dash\n' > ./-dash-name.txt
printf 'key\n' > ssh-home/.ssh/id_ed25519

owner=$(id -un)
group=$(id -gn)
uid=$(id -u)
gid=$(id -g)

The owner, group, uid, and gid variables store your current login identity. Keeping those values in variables makes restore commands safer than typing account names repeatedly.

Change File Owners and Groups with chown

Start with single-file changes. They make the syntax clear and give you a small target to verify before recursive ownership changes.

Change Both Owner and Group

Set a file to root:root, then inspect the ownership fields:

sudo chown root:root report.txt
stat -c '%U:%G %n' report.txt

root:root report.txt

Restore the file to your login account before continuing:

sudo chown "$owner:$group" report.txt
stat -c '%U:%G %n' report.txt

The second stat check should show your username and primary group.

Change the Owner but Keep the Group

An owner-only operand changes the user field without changing the group field:

sudo chown root:"$group" owner-only.txt
sudo chown "$owner" owner-only.txt
stat -c '%U:%G %n' owner-only.txt

The owner returns to your account, while the group remains the same group assigned in the first command.

Change Only the Group

Start the ownership at root:root, then use a leading colon to change only the group:

sudo chown root:root group-only.txt
sudo chown :"$group" group-only.txt
stat -c '%U:%G %n' group-only.txt

The owner stays root, and the group changes to your primary group. Restore the file afterward:

sudo chown "$owner:$group" group-only.txt

Copy Ownership from a Reference File

--reference is useful when one file already has the correct owner and group:

sudo chown root:root reference.txt
sudo chown "$owner:$group" destination.txt
sudo chown --reference=reference.txt destination.txt
stat -c '%U:%G %n' reference.txt destination.txt

root:root reference.txt
root:root destination.txt

Both files now have the same owner and group. Restore them before the next example:

sudo chown "$owner:$group" reference.txt destination.txt

Guard Changes by Current Ownership

--from changes a file only when the current owner and group match the value you specify. Use it for ownership repairs where another process could change the file between discovery and repair.

sudo chown root:root guarded.txt
sudo chown --from="$owner:$group" "$owner:$group" guarded.txt
stat -c '%U:%G %n' guarded.txt

root:root guarded.txt

The first guarded change does nothing because the file is not currently owned by your account. Match the real current owner to allow the repair:

sudo chown --from=root:root "$owner:$group" guarded.txt
stat -c '%U:%G %n' guarded.txt

The final check should show your account and primary group.

Show Only Ownership Changes

The -c option reports files whose ownership changed and stays quiet for files already in the requested state. Exact wording can differ between implementations, so treat the output as confirmation text rather than a stable script interface.

sudo chown -c "$owner:$group" report.txt

Handle Difficult Path Names with chown

Quoting and option parsing matter when paths contain spaces, shell metacharacters, or leading dashes. Fix the shell input before blaming chown.

Change Ownership of a File Name with Spaces

Quote the path so the shell passes it as one argument:

sudo chown root:root "file with spaces.txt"
sudo chown "$owner:$group" "file with spaces.txt"
stat -c '%U:%G %n' "file with spaces.txt"

Unquoted spaces turn one file name into several arguments, which can change the wrong files or fail with confusing missing-file errors.

Change Ownership of a File Name Starting with a Dash

A path such as -dash-name.txt can look like an option. Stop option parsing with --, and use ./ when creating or referencing the file from the current directory:

sudo chown root:root -- ./-dash-name.txt
sudo chown "$owner:$group" -- ./-dash-name.txt
stat -c '%U:%G %n' -- ./-dash-name.txt

Use Numeric UID and GID Values with chown

Numeric ownership is useful for container bind mounts, backups from another system, NFS shares, and recovery work where user names are missing or map to the wrong account. Use numeric IDs only after checking which local account they represent.

printf '%s:%s\n' "$uid" "$gid"
sudo chown "$uid:$gid" numeric-id.txt
stat -c '%u:%g %U:%G %n' numeric-id.txt

The numeric fields should match your current UID and GID. If %U or %G shows an unknown name on a restored backup, the numeric owner exists on disk but has no matching local account name.

Handle Symbolic Links with chown

By default, chown changes the target of a symbolic link, not the link object itself. Verify the target before changing ownership so a link does not send the command outside the path you intended to fix.

readlink symlink-file

symlink-target.txt

Change the target through the link path:

sudo chown root:root symlink-file
stat -c '%U:%G %n' symlink-target.txt

root:root symlink-target.txt

Add -h or --no-dereference when you specifically need to change the ownership of the symbolic link itself:

sudo chown -h root:root symlink-file
stat -c '%U:%G %n' symlink-file

root:root symlink-file

Restore the target and link ownership before continuing:

sudo chown "$owner:$group" symlink-target.txt
sudo chown -h "$owner:$group" symlink-file

Repair a Broken Symbolic Link

A broken symbolic link cannot be dereferenced, so normal chown link-name fails because the target does not exist:

ln -s missing.txt broken-link
sudo chown root:root broken-link

chown: cannot dereference 'broken-link': No such file or directory

Either recreate the missing target or change the link object itself with -h:

sudo chown -h root:root broken-link
stat -c '%U:%G %n' broken-link
sudo chown -h "$owner:$group" broken-link
rm broken-link

Use chown Recursively Without Surprises

Recursive ownership changes can repair a whole tree, but they can also break services or expose files if the path is wrong. Preview the target list, keep the path narrow, and avoid recursive ownership changes from /, /etc, /usr, or an entire home directory unless you have a tested recovery plan.

Recursive chown can make large parts of a system unusable when the target path is wrong. Check the path with a read-only command first, then apply the smallest ownership change that fixes the problem.

Preview Recursive Targets

List the paths that would be affected before applying -R:

find project -print | LC_ALL=C sort

project
project/app.conf
project/subdir
project/subdir/data.txt

When only matching files should change, combine a narrower find expression with the find exec command pattern instead of applying ownership to the whole tree.

Change a Directory Tree

Apply ownership recursively only after the preview matches the intended tree:

sudo chown -R root:root project
find project -printf '%u:%g %p\n' | LC_ALL=C sort

root:root project
root:root project/app.conf
root:root project/subdir
root:root project/subdir/data.txt

Restore the practice tree to your account:

sudo chown -R "$owner:$group" project

Repair Only Root-Owned Files in a Tree

A targeted repair is safer than changing every file in a project. Create two root-owned files, preview them, then repair only those matches:

sudo chown root:root project/app.conf project/subdir/data.txt
find project -user root -print | LC_ALL=C sort

project/app.conf
project/subdir/data.txt

Apply the ownership repair to the matching files, then verify the tree:

find project -user root -exec sudo chown "$owner:$group" {} +
find project -printf '%u:%g %p\n' | LC_ALL=C sort

joshua:joshua project
joshua:joshua project/app.conf
joshua:joshua project/subdir
joshua:joshua project/subdir/data.txt

Your username and group will replace joshua:joshua in the verification output.

Choose Symlink Traversal for Recursive Changes

Recursive chown has three traversal modes. Use -P for the safest physical walk that does not follow symbolic links to directories, -H when command-line symlink arguments should be followed, and -L only when every symlink to a directory in the walk should be followed.

-P is the GNU default for recursive traversal and is the best default for backups, deployments, and cleanup work where a symlink could point outside the intended tree.

Guard Recursive Admin Patterns Against the Filesystem Root

--preserve-root tells supported implementations to fail instead of recursively operating on /. It is a guard, not a substitute for checking the path, service account, and group first.

service_user=appuser
service_group=appgroup
app_path=/srv/app

if getent passwd "$service_user" >/dev/null && getent group "$service_group" >/dev/null && [ -d "$app_path" ] && [ "$app_path" != "/" ]; then
  sudo chown -R --preserve-root "$service_user:$service_group" "$app_path"
else
  printf 'check service_user, service_group, and app_path before running chown\n' >&2
fi

Replace the variable values with the real service account, group, and application path before running the command. If the guard prints the check message, inspect the account names and path with getent, pwd, ls -ld, and find before retrying.

Apply chown to Common Ownership Tasks

Restore Files Created with sudo

A common problem appears after redirecting output through sudo, extracting an archive as root, or editing a file with elevated privileges. If a file in your home directory is now root-owned, give it back to your account:

sudo chown "$owner:$group" report.txt
stat -c '%U:%G %n' report.txt

Use this only for files that should belong to your account. Root-owned system files under /etc, /usr, package-managed directories, and service-owned data usually should stay with their existing owner.

Fix Root-Owned SSH Files After Copying Keys

OpenSSH is strict about ownership. If keys under ~/.ssh were copied with sudo and ended up owned by root, restore ownership to the login account that actually uses the keys:

stat -c '%U:%G %A %n' "$HOME/.ssh" "$HOME/.ssh/id_ed25519" 2>/dev/null || true
sudo chown -R "$(id -un):$(id -gn)" "$HOME/.ssh"
stat -c '%U:%G %A %n' "$HOME/.ssh" "$HOME/.ssh/id_ed25519" 2>/dev/null || true

This fixes ownership only. SSH key files still need restrictive permission bits, so check chmod if authentication continues to fail after the owner and group are correct.

Repair Container or Build Artifacts Owned by root

Containers, build scripts, and package tools can leave project files owned by root. Numeric IDs avoid name-mapping surprises when the files came from a container or another system:

find project -user root -print | LC_ALL=C sort
sudo chown -R "$(id -u):$(id -g)" project
find project -printf '%u:%g %p\n' | LC_ALL=C sort

Use the narrow project directory, not your entire home directory. Broad recursive ownership changes can overwrite service, cache, virtual environment, or mounted-volume ownership that should remain different.

Assign a Service Directory to an Application Account

Services often need a dedicated owner instead of your personal login. Set the variables to real values, confirm the account, group, and directory exist, then change the service directory explicitly:

service_user=appuser
service_group=appgroup
app_path=/srv/app

if getent passwd "$service_user" >/dev/null && getent group "$service_group" >/dev/null && [ -d "$app_path" ]; then
  sudo chown -R "$service_user:$service_group" "$app_path"
  stat -c '%U:%G %n' "$app_path"
else
  printf 'check service_user, service_group, and app_path before running chown\n' >&2
fi

Use the account and group created by your package, deployment process, or service unit. Do not invent a service owner without checking how the application runs.

Prepare a Shared Project Group

Group ownership is the first half of a shared-directory workflow. Pair it with group write permissions and the setgid bit when new files should keep the project group:

sudo chown -R "$owner:$group" project
sudo chmod -R g+rwX project
find project -type d -exec sudo chmod g+s {} +

Replace $group with a real project group when the shared directory should belong to a team instead of your primary group. If one user needs access without changing the owning group, use setfacl ACL permissions instead of forcing ownership around a single account.

Troubleshoot Common chown Errors

Most chown failures come from missing privileges, invalid account names, wrong target paths, symlink confusion, immutable files, read-only mounts, or a permission layer that ownership does not control.

Fix Operation Not Permitted

A non-root user normally cannot take ownership of a root-owned file. In the practice directory, a normal shell fails when it tries to reclaim a file that sudo made root-owned:

sudo chown root:root report.txt
LC_ALL=C chown "$owner:$group" report.txt

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

Some implementations append an OS error detail, but the stable failure is Operation not permitted.

Inspect the current owner first:

stat -c '%U:%G %n' report.txt

If you administer the system and the ownership really should change, rerun the narrow command with sudo:

sudo chown "$owner:$group" report.txt
stat -c '%U:%G %n' report.txt

Fix Operation Not Permitted Even with sudo

If sudo chown still fails, the filesystem or inode may be blocking the change. Check for immutable attributes and read-only mounts before trying broader ownership commands:

lsattr report.txt 2>/dev/null || true
findmnt -T report.txt -no TARGET,FSTYPE,OPTIONS

An i flag in lsattr output means the immutable attribute is set. Remove it only when you understand why the file was protected, then retry the ownership change:

sudo chattr -i report.txt
sudo chown "$owner:$group" report.txt
stat -c '%U:%G %n' report.txt

If findmnt shows ro, remount or repair the filesystem through the workflow that owns that mount. On NFS, root-squash and server-side export policy can also block ownership changes even when the local command uses sudo.

Fix Invalid User or Group Names

An account or group that does not exist produces an invalid-name error. Depending on implementation, the same bad owner operand prints one of these C-locale lines:

sudo env LC_ALL=C chown no_such_user_zz: report.txt

chown: invalid user: 'no_such_user_zz:'
chown: invalid spec: 'no_such_user_zz:'

Check the account and group before applying ownership:

getent passwd appuser
getent group appgroup

If either command prints nothing, correct the name or create the account through your distribution’s normal user-management process before rerunning chown.

Fix Cannot Dereference Broken Symlinks

The cannot dereference error means the symbolic link points to a target that does not exist:

readlink broken-link
if [ -L broken-link ] && [ ! -e broken-link ]; then
  printf 'broken symlink: %s\n' broken-link
fi

missing.txt
broken symlink: broken-link

A broken link usually needs the target restored or the link replaced. Use chown -h only when the link object itself needs a different owner.

Fix Ownership That Still Leaves Permission Denied

Ownership is only one access-control layer. If access still fails after the owner and group look correct, inspect mode bits, parent directories, and ACLs before widening permissions.

ls -ld . project project/subdir
stat -c '%A %U:%G %n' project/subdir/data.txt
getfacl project/subdir/data.txt 2>/dev/null || true

A file can be correctly owned but still unreadable if its mode denies access, a parent directory lacks execute permission, an ACL mask limits effective rights, or SELinux/AppArmor policy blocks a service. Fix the layer that actually fails instead of using broad recursive ownership changes.

Fix Symlink Ownership Confusion

If chown symlink-name changed the target instead of the link, confirm what the link points to and use -h only when the link object itself needs different ownership:

ls -l symlink-file
readlink symlink-file
stat -c '%U:%G %n' symlink-target.txt symlink-file

Most ownership repairs should target the real file or directory. Symlink ownership matters mainly in administrative edge cases, backup preservation, or systems that explicitly inspect link ownership.

Clean Up the chown Practice Directory

Remove the disposable directory when you finish practicing. The sudo rm form handles any root-owned files left from the examples:

demo_dir="$HOME/chown-demo"
cd "$HOME"
sudo rm -rf "$demo_dir"

Conclusion

chown ownership repairs are safer when you verify the current owner, write the group explicitly, quote difficult paths, preview recursive targets, and treat symlinks deliberately. Use it for owner and group corrections, keep chmod for permission bits, and switch to ACLs when one-off user access does not justify changing ownership.