I have a directory called "members" and under it there are folders/files. How can I recursively set all the current folders/files and any future ones created there to by default have 775 permissions and belong to owner/group nobody/admin respectively? I enabled ACL, mounted, but can't seem to get the setfacl command to do this properly. Any idea how to accomplish this?
I actually found something that so far does what I asked for, sharing here so anyone who runs into this issue can try out this solution:
sudo setfacl -Rdm g:groupnamehere:rwx /base/path/members/ sudo setfacl -Rm g:groupnamehere:rwx /base/path/members/
R is recursive, which means everything under that directory will have the rule applied to it.
d is default, which means for all future items created under that directory, have these rules apply by default. m is needed to add/modify rules.
The first command, is for new items (hence the d), the second command, is for old/existing items under the folder. Hope this helps someone out as this stuff is a bit complicated and not very intuitive.
It is easy to recursively set simple UNIX permissions at upon demand of an appropriately authorized user, the permissions of directories and files. It is not possible to automatically impose this.
You could tell users to use the set the umask of 0002, and that helps to make new files at 0775 (depending on the application). But it is not enforcable.
My understanding is that ACLs are not inherited on UNIX/Linux systems. They are set upon demand.
As for file/directory ownership, you are pretty much out of luck here.
As for file/directory group ownership, by setting the directory set-gid bit (i.e. g+s on DIRECTORIES), this does cause the group ownership to be inherited.
What I have done in such situations is to execute a periodic root cron script which resets non-conforming permissions/ownerships to the standard in such directories.
Another (NOT RECOMMENDED) process is to have the same user-id be used when working on these files. This could be accomplished by the user logging into the system under his own UID, and then using sudo or su to run as the id. This still is not 100% especially concerning ACLs and permission bits.