If you collaborate with other people, you want to share information. In my field, computational physics/chemistry, the amount of data is so large that you cannot use sharing services or cloud mechanisms even if you wanted to. While all users in my group are using one NFS for the home directories, it is hard to ensure that only a particular part of files is available with read/write permissions to the other group members. Now I hear you saying “umask and your problem is solved” – but it’s not as easy as that. I will discuss three options in the order of decreasing maintainability.

If you know a better way, please comment.

In the following, I assume that there are users with accounts “user0” to “userN”. “user0” hosts the space shared across all users as part of the home directory. The unix group name is “examplegroup”. I assume that this is the primary group for all users in this example.

Cron jobs

These are scripts or commands that get executed at a specific time following a regular pattern. For example, if you can set the permissions correctly once by using

chmod -R 770 /homes/user0/members/$(whoami)

then you can automate this by letting each user0 to userN issue this command

(crontab -l ; echo '0 0 * * * chmod -R 770 /homes/user0/members/$(whoami)') | crontab

This extends the current crontab (the list of cron jobs to be executed) by a line executed daily that fixes the problem.
Pro:

• Works regardless of the transfer method.
• Works even if your tools do not support proper Access Control Lists (see below).

Con:

• The admin will hate you for this, as this puts a severe load on the server for scanning the files and checking their permission. Only do this with very few files. If you have like 10000 files in that folder, choose a different solution.

Umask

This is a per-process setting that is inherited to child processes. Umask sets the default permissions for newly created files – please refer to its documentation for how the values are derived. In our case, you would need

umask 007

Put this into each user’s .bashrc file that the problem is solved, right? Well, not quite: this would affect all files that are created in all folders not only the one folder you want to have these default settings in. Not very helpful and potentially dangerous. There is no way to enforce umask on a per-directory setting.
Pro:

• Works like pay-as-you-go: no unnecessary file system operations.

Con:

• Your admin may have disabled this via various ways.
• Not all tools respect the umask value. In particular, older versions of cp are well-known for ignoring this value.
• Only affects processes that open a shell before. In particular, scp does not open a shell, it just copies files. So scp will only work correctly for pulling copies, not for pushing data from remote.

NFS4 Access Control Lists

If you use NFS4, you can make use of the access control lists (ACL) there. If no ACL (or only the default one), the regular permissions apply. Otherwise, the ACL is applied on top of that. The nice thing about the ACL is that you can inherit rules. This way, you can specify that any new folder created in this particular folder will inherit the properties and – only if you specify it this way – will inherit these rules to its children, as well. The problem here: instead of three permissions, you now have 13 or 14 for files and directories respectively. Whether they are supported or enabled depends on your system. What you would have to do is make “user0” issue this command once:

nfs4_setfacl -R -s A:df:OWNER@:RWX,A:dfg:GROUP@:RWX /homes/user0/members/

This is only part of the story, as the regular permissions still are into place. So you need umask again to make this work, because otherwise, the regular permissions would deny access to the folder so the ACL of this folder would not be evaluated at all. The required umask setting here is 007 again. But there is light at the end of the tunnel: you can set umask to 000 (dangerous) and then restrict all other folders using the ACL. This would require adding

umask 000

to your .bashrc and then converting all existing permissions of all users from the regular way they are defined to ACL.
Pro:

• Very flexible.
• Works for nearly every program.

Con:

• One mistake by your admin or slight changes to the way the NFS is mounted and all your data is open to everybody.
• Not all NFS servers will support ACL to the required extend. Some may ignore or drop the inheritance flag which is the key point here.
• scp does not do ACL – again, only pulling works, not pushing.