chown: change file ownership on Linux, with -R and user:group

Short answer: chown changes who owns a file — the user, the group, or both. sudo chown USER FILE sets the owner, sudo chown USER:GROUP FILE sets both, and sudo chown :GROUP FILE changes only the group (the same job as chgrp). Add -R to apply it to every file inside a directory.

sudo chown www-data:www-data /var/www/html       # one owner, one group
sudo chown -R deploy:deploy /srv/app              # a whole directory, recursively

Every flag below was checked against GNU coreutils’ chown(1) man page on Debian 12.

How chown reads OWNER:GROUP

The pattern is chown [OPTIONS] [OWNER][:[GROUP]] FILE..., and what you put before the colon — and whether there is a colon at all — changes what gets touched:

A bare colon with nothing on either side, or the empty string, changes nothing at all — chown treats that as a no-op rather than an error.

chown -R: recursive, and what it does to symlinks

sudo chown -R USER:GROUP /path/to/dir

-R walks into every subdirectory and changes every file it finds, directories included. By default it does not follow a symlink it meets along the way — it changes the ownership of the link itself, not whatever the link points at (-P, the default under -R). -L follows every symbolic link to a directory it encounters, and -H follows one only if it was named directly on the command line. Mixing those into a recursive chown over a tree with symlinks pointing outside it is the one way this command reaches further than you meant — leave the default alone unless you have a specific reason not to.

A single symlink: --dereference vs -h

Without -R, chown on a symlink’s own path still changes the target it points to by default (--dereference). -h (--no-dereference) changes the symlink’s own ownership instead, which matters only on systems where a symlink can have an owner distinct from its target — Linux is one of them.

Who is allowed to chown what

On Linux, only root can give a file to a different user. An ordinary user owning a file cannot hand it to someone else, even to give it away — that would let you dodge disk quotas by gifting files to other accounts. Without root, chown fails outright:

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

Changing the group is less restrictive: the file’s owner can change its group to any group they are themselves a member of, no root needed — run groups to see which ones that is. Changing the owner, or the group to one you do not belong to, needs sudo.

Common chown tasks

--reference=RFILE copies RFILE’s owner and group onto the targets instead of spelling them out — useful when you know which existing file already has the ownership you want and do not want to look up its UID. -c (--changes) prints a line only for files it actually modified, which on a big -R run is far more readable than -v’s one line per file.

chown on the Docker socket

docker: Got permission denied while trying to connect to the Docker daemon socket is a group problem, not an ownership one — the fix is adding your user to the docker group (sudo usermod -aG docker $USER, then log out and back in), not chowning /var/run/docker.sock to yourself. The socket is recreated owned by root:docker on every daemon restart, so a one-off chown on it only holds until the next reboot. The full fix, including why group membership needs a fresh login session to take effect, is in Docker daemon socket permission denied.

chown and a 403 from nginx or Apache

A web server answering 403 Forbidden for files that are readable in a shell is usually the directory permissions on the way down to the file, not the file’s owner — nginx’s worker process needs execute (traversal) permission on every directory in the path, not just read on the file itself. Check who the file actually belongs to first:

ls -la /var/www/html/index.html
stat -c '%U:%G %a %n' /var/www/html/index.html

If the owner is your own user rather than www-data (nginx) or apache (Apache), that is one legitimate cause and chown -R www-data:www-data /var/www/html fixes it — but check the directory mode bits too before you assume ownership was the whole problem; the full walkthrough is in nginx 403 Forbidden.

chown changes who; chmod changes what they can do

The two are easy to reach for interchangeably when a permission error shows up, but they fix different problems. chown decides which user and group a file belongs to. chmod decides what the owner, the group and everyone else are allowed to do with it — read, write, execute — once ownership is settled, and chmod -R 777 is almost never the fix it looks like — the chmod guide explains the permission bits.

Finding out who a UID actually is

chown 1000:1000 works even when no name matches that number, and ls -l then prints the bare number instead of a name — a common sight after restoring files from a different server where the UIDs do not line up. See listing users on Linux to match a UID back to a name, or create the missing account with the same UID if the files should stay tied to it.

Frequently asked