Permissions – Fix ‘sudo chmod -rwx’ Not Removing Group Write Permissions

• A user may be a member of multiple groups.
• A file is be owned by exactly one group and one user.
• If the user is a member of the file's owner group (i.e., group foo owns the file and one of the user's groups is foo), then the respective group permissions apply to that user (unless overridden by the owner permissions).

The owner group is part of the file's ownership. Consider:

$ stat /usr/bin/crontab 
  File: ‘/usr/bin/crontab’
  Size: 35984       Blocks: 72         IO Block: 4096   regular file
Device: 803h/2051d  Inode: 131439      Links: 1
Access: (2755/-rwxr-sr-x)  Uid: (    0/    root)   Gid: (  103/ crontab)
Access: 2015-02-05 20:20:43.438507538 +0530
Modify: 2013-02-09 12:32:23.000000000 +0530
Change: 2014-09-30 19:22:09.508515013 +0530
 Birth: -

This states that the file's ownership is with user root and group crontab.

Say I'm member of group A, group B, and group C. Now I create a file somewhere. ... [To] which group get's the owner_group permissions applied ?

That depends on what your primary group is at the time you created that file. The primary group is the first one listed when you run the groups command. Usually, this is determined by your GID. However, you can temporarily set one of your other groups as primary using the newgrp command. For example:

$ groups 
muru adm cdrom sudo dip plugdev lpadmin sambashare
$ rm foo; touch foo
$ stat -c %G foo  # this prints the owner group of the file
muru
$ newgrp sudo   
$ rm foo; touch foo
$ stat -c %G foo
sudo

I have the distinct feeling I don't really understand something here, or that I misunderstand the meaning of the term "owner group".

That the owner group is an attribute of the file, not the user.

I understand the string (after the first char) is partitioned into groups of 3 (rwx) for

owner
owner_group
all/world/anyone

Slightly off: the third field is others, not all. Others covers everyone except the owner of the file and members of the owner group of the file. The distinction comes into play when using symbolic modes with chmod:

• chmod a-x takes away everyone's execute permissions
• chmod o-x takes away everyone else's execute permission, while leaving the owner and owner group's execute permission untouched.

Lastly, a note on user private groups. UPGs are fairly common on desktop systems, but do not take them for granted elsewhere. If UPGs are enabled, it is likely that the user's primary group and username have the same numeric id and name, and there is a unique group for each user. That is all.

I changed my etc/fstab so that it would mount the network share as follows:

//WDMyCloud/Story_1_5Tb_2 /home/plex/story cifs _netdev,guest,uid=plex,gid=mediaserver,rw,iocharset=utf8,file_mode=0770,dir_mode=0770 0 0

In particular, I added the following options to the string:

,iocharset=utf8,file_mode=0770,dir_mode=0770,

This gave full read, write and execute permissions on the network share to the members of "uid=mediaserver" group. "Uid=plex" already had all such permission even prior to the modifications; I chose to grant no permission to "o"ther users at all.

Now if I ls -l the folder where I mounted my STORY I get:

drwxrwx--- 2 plex mediaserver 0 Mar 3 09:53 story

Consequently, Transmission (member of the "uid=mediaserver" group) saves its downloads alright: happy ending!

Now, whereas I see what those options do (the "absolute" values are identical to chmod, which makes the whole thing pretty much self-explanatory), I do not understand why what I did earlier (setting uid and gid) was not enough/correct, nor do I understand why executing chmod with sudo privileges would do nothing to solve the issue. Actually the similarity of this option to chmode makes it look like some sort of chmod executed upon mount, so why would a chmod executed later not solve?