If the group of /some/dir is foo, and I run

chmod g+s /some/dir

...then any child of /some/dir will also have group foo.

Crucially, however, a new subdirectory /some/dir/subdir will not have g+s (although, as just stated, it its group will be foo).

How can I ensure that all descendant subdirectories of /some/dir not only inherit the group foo, but also inherit the g+s permission?

FWIW, my umask is 002, the filesystem is nfs, and the options according to mount are (rw,relatime,vers=3,rsize=20961,wsize=413177,namlen=255,hard‌​,proto=tcp,timeo=450‌​,retrans=2,sec=sys,m‌​ountaddr=xxx.xxx.xxx‌​.xxx,mountvers=3,mou‌​ntport=333,mountprot‌​o=udp,local_lock=non‌​e,addr=xxx.xxx.xxx.x‌​xx).

UPDATE: I now understand the source of my confusion: sometimes changing a directory's group (with chgrp) has the effect of disabling a previously enabled setgid bit. E.g.

% rm -rf /some/dir
% mkdir -p /some/dir
% chmod g+s /some/dir
% ls -ld /some/dir
drwxrwsr-x 2 jones jones 0 Nov  7 07:13 /some/dir
% chgrp foo /some/dir
% ls -ld /some/dir
drwxrwxr-x 2 jones jones 0 Nov  7 07:13 /some/dir

(Note that the setgid bit ends up unset.)

As I said, this happens only sometimes. For example, if I repeat the same sequence above, but I run the chgrp command under sudo, then the setgid bit remains set at the end.

This effect of chgrp on the permissions is what threw me off.

1 Answer 1


Once /some/dir has the setgid bit, new subdirectories do inherit it, so all newly-created descendents have the appropriate group and setgid bit.

Using chgrp can drop the setgid bit. POSIX says

Unless chgrp is invoked by a process with appropriate privileges, the set-user-ID and set-group-ID bits of a regular file shall be cleared upon successful completion; the set-user-ID and set-group-ID bits of other file types may be cleared.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .