chgrpChange a file's group
chgrp changes the group that owns a file, which decides who gets the group permission bits. Unlike chown, a file's owner can do it without sudo, as long as they're a member of the target group. Use it to share directories and logs with a team.
chgrp [-R] [-h] [-v | -c] GROUP FILE...devops owns /srv/reports and wants everyone in devteam to read and add reports there.
chgrpChange group: sets the GID stored in each inode (coreutils). Same as chown :GROUP.
chgrp resolves the group name through NSS and calls fchownat() with the owner left as -1, so only the GID in the inode changes. The kernel allows it if the caller is root, or owns the file AND is a member of the new group (checked against the process's current groups, so a group you were just added to only works after a new login). As with chown, changing the group of an executable clears its setuid/setgid bits. chgrp doesn't change permission bits: the group still gets whatever the middle rwx triplet says. For a shared directory you normally pair it with chmod g+ws (setgid) so new files inherit the group, and a 002 umask or default ACL so they're group-writable.
-RRecursive-v / -cReport every file / only changes-hChange a symlink itself, not its target--reference=FILEUse another file's groupGIDA numeric group ID works without a namechmod g+s DIRCompanion: new files in DIR inherit its groupchgrp devteam on a shared directory and stopping thereFiles people create later still get each creator's private group, so others can't edit them.
chgrp devteam DIR && chmod g+ws DIR (plus umask 002 or a default ACL)Running chgrp right after being added to the group and getting 'Operation not permitted'The kernel checks your session's current groups, which don't include the new group until you log in again.
Log in again or newgrp GROUP, then chgrpFixing log permissions with chgrp but not the logrotate configAt the next rotation logrotate creates a new file with the old group and readers lose access.
Set 'create 0640 appsvc adm' in /etc/logrotate.d/appTry these on a Linux machine of your own. Each task has a hint and a solution.
Create ~/data/team and change its group to adm (use sudo if you're not in adm).
Make ~/data/team setgid and group-writable, then create a file inside and check its group.
Recursively change the group of /var/log/app to adm and list each change.
chgrpChange a file's group
chgrp changes the group that owns a file, which decides who gets the group permission bits. Unlike chown, a file's owner can do it without sudo, as long as they're a member of the target group. Use it to share directories and logs with a team.
chgrp [-R] [-h] [-v | -c] GROUP FILE...devops owns /srv/reports and wants everyone in devteam to read and add reports there.
chgrpChange group: sets the GID stored in each inode (coreutils). Same as chown :GROUP.
chgrp resolves the group name through NSS and calls fchownat() with the owner left as -1, so only the GID in the inode changes. The kernel allows it if the caller is root, or owns the file AND is a member of the new group (checked against the process's current groups, so a group you were just added to only works after a new login). As with chown, changing the group of an executable clears its setuid/setgid bits. chgrp doesn't change permission bits: the group still gets whatever the middle rwx triplet says. For a shared directory you normally pair it with chmod g+ws (setgid) so new files inherit the group, and a 002 umask or default ACL so they're group-writable.
-RRecursive-v / -cReport every file / only changes-hChange a symlink itself, not its target--reference=FILEUse another file's groupGIDA numeric group ID works without a namechmod g+s DIRCompanion: new files in DIR inherit its groupchgrp devteam on a shared directory and stopping thereFiles people create later still get each creator's private group, so others can't edit them.
chgrp devteam DIR && chmod g+ws DIR (plus umask 002 or a default ACL)Running chgrp right after being added to the group and getting 'Operation not permitted'The kernel checks your session's current groups, which don't include the new group until you log in again.
Log in again or newgrp GROUP, then chgrpFixing log permissions with chgrp but not the logrotate configAt the next rotation logrotate creates a new file with the old group and readers lose access.
Set 'create 0640 appsvc adm' in /etc/logrotate.d/appTry these on a Linux machine of your own. Each task has a hint and a solution.
Create ~/data/team and change its group to adm (use sudo if you're not in adm).
Make ~/data/team setgid and group-writable, then create a file inside and check its group.
Recursively change the group of /var/log/app to adm and list each change.