Default Group Ownership and Permissions

The group specified for any new file is inherited from its containing folder. i.e, the folder in which you are creating these new files must also have group "staff".

You can accomplish what you want to do by using ACLs. First go to System Preferences -> Users & Groups, and make a new group called "accountinggroup". Add the users you want to the group.

You will then need to make a folder in which to store all the files to be shared with this group. Put it in some easily accessible place like in /Users/Shared.

Then log in to an admin account and open Terminal. Paste in all of this and the press return:

sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,\
add_subdirectory,delete_child,file_inherit,directory_inherit" \

Then drag the folder into the Terminal window and press return again.

From then on, any file that is newly created in or copied to any location within that folder hierarchy will have read and write privilges for all users in accountinggroup.

The results you posted are what are expected with standard POSIX permissions.

The group was properly inherited (accountinggroup was assigned because that's what was assigned on its containing folder.)

But permissions cannot be inherited using standard POSIX permissions. The OS X default is Read and Write for the the creator, and Read Only for group and others. The assigned group is inherited from its parent folder, but the permissions aren't.

The only way you can get permission inheritance is to use ACLs. It can't be done with POSIX, neither on OS X nor on any other unix flavour.

ACLs were introduced to OS X in 2005 with 10.4, but they were disabled by default. The OS itself didn't make use of them until 10.5.

I loved the ACL introduction in 10.4, because it finally allowed me to share iMovie projects and an iPhoto library between my wife's and my user accounts. Prior to 10.4, I had needed to store them on an external hard drive with ownership and permissions ignored.

Changing one's umask to provide group read and write permissions can also kinda sorta maybe be used to accomplish what you want. But it's difficult to do, and affects everything you do. Any file you create or save anywhere will then have full read and write permissions, whether or not you save them in the project folder. What's worse, you will have to change the umask setting for all users, not just you. What's even worse, some apps (Finder I believe is one of them) will ignore the umask setting and will set the default OS X permission setting anyway. I would really only recommend going this way if you (and all the users you collaborate with) work exclusively in the command line, which I expect you don't.

What reservations do you have about using ACLs? They are intended to do exactly the kind of thing you are asking about. I have been using the trick I described to share files between my wife's and my user accounts since 2005 and it has worked a dream. It might seem a little scary to set up with Terminal, but it really is not that bad and is trouble free afterwards.

No Access for others can be accomplished by putting the files into a folder that is set for No Access for others. Then, others won't be able to see the files at all; whether or not the No Access bit has been set for them on any of the enclosed files. As long as your project folder is set correctly you shouldn't have to worry about access of any of its contents for others.

Apple puts this in place in users' home folders. Desktop, Documents, Pictures, etc, are all set to No Access for group and others. So nobody can go nosing around inside your Documents folder, even if its enclosed files are set for read access to group and others.

The tweaking of umasks is outside my area of knowledge so I can't provide any more help in that regard. All I know is that when I looked into doing this for similar reasons back in the early OS X days, I found that it wasn't a viable solution for me.

I too was hesitant to embrace ACLs in the beginning; for many of the same reasons you are; they can be difficult to understand, set, and manage. I would not consider myself an expert in utilizing them to their full potential.

But I found that for my purpose, setting up a group folder for me and my wife where we could share files and have them automatically set to read+write for both of us, it was easier than I thought. I just pasted in the command five years ago, and have not had to touch it since. No maintenance required, it just works.

I encourage you to bite the bullet and take the plunge!

Ah, if you are going to be moving files around different volumes (which essentially creates a new copy of the file and gets the standard OS X permissions set), then a custom umask may be the thing for you.

I'd explore that further by starting a new thread dedicated to that topic (put "umask" in the subject line) and it should attract posters who are more knowledgable in that area than I am.

Good luck.

You can accomplish what you want to do by using ACLs. First go to System Preferences -> Users & Groups, and make a new group called "accountinggroup". Add the users you want to the group.

You will then need to make a folder in which to store all the files to be shared with this group. Put it in some easily accessible place like in /Users/Shared.

Then log in to an admin account and open Terminal. Paste in all of this and the press return:

sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,\
add_subdirectory,delete_child,file_inherit,directory_inherit" \

Then drag the folder into the Terminal window and press return again.

From then on, any file that is newly created in or copied to any location within that folder hierarchy will have read and write privileges for all users in accountinggroup.

You sir are a genius.

I have been trying to utilise a users iMac a "central file storage" for a small business client (all new Lion Machines). I was having so many issues with Lion's POSIXs permissions and also Lion's new versions feature.

Every time users saves files to the shared folder they would inherit permission from the computer that created the file. Thus is another user logged on and opened the file it would be 'Locked' and have to be duplicated or the users would have to manually edit permission using 'Get Info'

I have applied the ACL via terminal and now it works like a dream! All files have that are put into the shared folder have a group with 'custom' permissions and any one can use and modify the files, provided they have log in credentials.

The only trap i would warn people of is do not use typical group names like "Staff", "workgroup" etc. I found that using those was problematic. I opted for employees.

Thanks again Király

Hello Kiraly

I try to have your ACL Terminal solution working for me without success.

Your help would be very appreciated.

To make a test I use an iMac running 10.6.8 and an MacBook Pro running 10.7.4.

On the iMac I created a user Sharing Only account.

From there I created a group by the name of accountinggroup (me and that user).

I created a folder on my desktop by the name of test shared folder.

In the terminal I paste and press return once:

sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,\ add_subdirectory,delete_child,file_inherit,directory_inherit" \

No visible result, I am not ask for my password.

Then I drag the test shared folder on the Terminal and press return once and I got “chmod: Invalid permission type '\ add_subdirectory'“

I suspect a syntax error, when I copy/paste the Terminal command from your post I seem to have a carriage return after add_file.

I tried it as is and also by removing the carriage return and putting only a space after the \ and before add_

Last login: Thu Oct 25 08:30:07 on console

Jacques-Paul:~ jacquespaul$ sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,\ add_subdirectory,delete_child,file_inherit,directory_inherit" \

> /Users/jacquespaul/Desktop/test\ shared\ folder

Password:

chmod: Invalid permission type '\ add_subdirectory'

Jacques-Paul:~ jacquespaul$

Copy and paste the whole thing at once. Don't try to copy bits and pieces of it.

sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit"

Hello Kiraly

This time I copyed the Terminal command directly from your post and pasted it into the Terminal.

I had a somewhat different result this time.

Last login: Fri Oct 26 09:04:51 on ttys000

Jacques-Paul:~ jacquespaul$ sudo chmod -R +a "accountinggroup allow delete,chown,list,search,add_file,add_subdirectory,delete_child,file_inherit,di rectory_inherit"

Password:

usage: chmod [-fhv] [-R [-H | -L | -P]] [-a | +a | =a [i][# [ n]]] mode|entry file ...

chmod [-fhv] [-R [-H | -L | -P]] [-E | -C | -N | -i | -I] file ...

Jacques-Paul:~ jacquespaul$ /Users/jacquespaul/Desktop/Sharing\ osfq

-bash: /Users/jacquespaul/Desktop/Sharing osfq: is a directory

Jacques-Paul:~ jacquespaul$

For some reason that did'n work for me.

The shared folder was not inheriting permissions for the group.

Only the owner can edith a document, they other was read only.

I tryed an other solution using the ACL Permissions Tool in TinkerTool System software and this time that worked. Maybe that may be usefull for other members in that forum.

http://www.bresink.com/osx/TinkerTool.html

In ThinkerTool go to ACL Permissions tab/show or set permissions and drag the folder you want to share in the file or folder window.

If you don't see the name of your group in the permissions and ownership window clic the + and add it.

Select the name of your group and under the permission tab clic on the two arrows, select Custom, in the window that appears select everything (especially Inheritance), close and then clic Apply.

In between pasting in the command and dragging the folder into the Terminal window, you pressed return. You should have pressed the space bar instead.

Glad you got it sorted with TInkerTool.

Well I followed your instruction in the second post:

Then drag the folder into the Terminal window and press return again.