Skip to content
shellmap

Change the group ownership of a file or directory

Reassign a file's group — for granting team-wide read/write via group permissions, for matching a service account's primary group, or for fixing post-clone permissions where the working tree is owned by the wrong group.

How to change the group ownership of a file or directory in each shell

Bashunix
sudo chgrp staff file.txt

`chgrp GROUP FILE` sets only the group (leaves owner unchanged). Equivalent alt-forms: `chown :staff file.txt` (note the leading colon — sets group only) or `chown alice:staff file.txt` (sets both). `-R` recursive. Requires the calling user to be IN the target group (or be root).

Zshunix
sudo chgrp staff file.txt
Fishunix
sudo chgrp staff file.txt
PowerShellwindows
$acl = Get-Acl file.txt; $acl.SetGroup((New-Object Security.Principal.NTAccount "Developers")); Set-Acl file.txt $acl

Windows group ownership is largely vestigial — POSIX-style group permissions don't map onto Windows ACLs the same way. On Linux/macOS pwsh 7, fall back to `chgrp`. Most "Windows group" needs are better served by adding the group to the ACL with `icacls /grant "Developers:(M)"` instead of changing the primary group field.

cmd.exewindows
icacls file.txt /setowner ":Developers"

cmd has no direct `chgrp` analogue. The closest is granting the group access via `icacls /grant "Developers:(RX)"` (read+execute) or `(M)` (modify) or `(F)` (full control). The Linux concept of "primary group" doesn't translate; Windows files have a "primary group" field for POSIX compatibility but it's rarely consulted.

Equivalents listed for Bash, Zsh, Fish, PowerShell, cmd.exe.

Gotchas & notes

  • **`chown :group` vs `chgrp group` — same effect, different ergonomics**: both forms set ONLY the group. `chgrp` is shorter; `chown :group` is convenient when you're already typing `chown` for owner changes. The colon-only form is GNU + BSD portable. The legacy `chown user.group` (dot separator) was deprecated in GNU coreutils 8.x and removed eventually — always use the colon. To set BOTH: `chown alice:staff file.txt`.
  • **Group membership is required**: a non-root user can only `chgrp FILE GROUP` if they (a) own the file AND (b) are a member of the target group. `id alice` lists alice's groups; `groups` lists the current user's groups. To add a user to a group: `sudo usermod -aG developers alice` (the `-a` is CRITICAL — without it, `-G` REPLACES all secondary groups). User must log out and back in for the new membership to take effect (or use `newgrp developers` for a sub-shell with the new group active).
  • **Setgid bit (`chmod g+s dir/`) makes new files inherit the directory's group** — vital for shared team directories. Without setgid, files created in `/srv/shared/` get the CREATOR's primary group; with setgid (`drwxrwsr-x`), they inherit `/srv/shared/`'s group. Combine with `chmod 2775` (setgid + rwxrwxr-x) for a typical team folder. New subdirectories ALSO inherit the setgid bit recursively — so the inheritance propagates. ACLs (`setfacl -d`) are a more granular alternative when "always group X regardless of who creates" is needed.
  • **Numeric GID for portability**: same trap as UID. `chgrp 50 file.txt` (numeric GID) is what tar archives, Docker, and NFS see at the wire; the NAME mapping happens via `/etc/group` LATER. Crossing host boundaries: `chgrp -R 1000 /data` is reproducible; `chgrp -R developers /data` extracts as different IDs on every host. Inside Docker: the container's `/etc/group` is usually minimal (no `developers` group), so name-based chgrp fails — pass numeric.
  • **After `chgrp`, the SETGID bit is preserved** on Linux (unlike `chown`, which clears SETUID/SETGID for security). So `chmod g+s dir/` then `chgrp team dir/` keeps the setgid bit. To verify: `ls -ld dir/` should show `drwxrws---` (the `s` in group position). If the directory shows `drwxrwS---` (capital S), the setgid bit is set but the EXECUTE bit is missing — fix with `chmod g+x dir/` so directory traversal works.

Related commands

Related tasks