Changing Ownership: `chown` and `chgrp`

Transferring Control

Sometimes you need to change who owns a file or what group it belongs to. This is common when deploying applications, setting up shared directories, or fixing permission issues after copying files.

Changing ownership: chown sets a file's owner and, optionally, its group in a single call by separating them with a colon (user:group); a leading colon with no username changes only the group, which is also what the dedicated chgrp command does. Adding the recursive flag applies the change to a directory and everything inside it — necessary because ownership isn't automatically inherited by existing contents when a directory's owner changes.

Important security rules:

1. Only root can give away ownership. A regular user cannot transfer a file they own to another user. This prevents a malicious user from creating a file, filling it with malicious content, and then transferring ownership to root to trick an admin.

2. Users can change group ownership to any group they belong to. If you're a member of both developers and ops, you can change a file you own to either group without elevated privileges.

3. Changing ownership doesn't change permissions. If a file is rw-r--r-- owned by alice, and ownership transfers to bob, it's still rw-r--r-- — but now bob is the owner with read/write access.

Common production scenario:

A common deployment pattern is building or copying files as one user (e.g., a deploy user) while the service that ultimately serves them runs as another (e.g., www-data). After deployment, ownership of the whole tree is recursively handed to the service user and group, and permissions are normalized separately — files get read access, directories get the traverse bit — so the service can actually read what was just deployed.

Key Point: In containerized environments (Docker, Kubernetes), ownership issues are common when mounting volumes. A container might run as UID 1000, but the host directory is owned by UID 1001. The kernel uses numeric UIDs for permission checks, not usernames—so even if both systems have a user named appuser, if their UIDs differ, permissions won't match. Always use ls -ln (numeric UIDs) when troubleshooting cross-system permission issues, and consider using USER directives in Dockerfiles to ensure consistent UIDs.