PDA

View Full Version : file sharing permissions



jay59cee
23rd April 2010, 10:02 PM
Is there a way to automatically make new files and folders take the same file sharing permissions as the enclosing folder?

I have set up file sharing for selected folders on 2 networked iMacs running OSX. We have a group and the file sharing for the folders (and enclosed folders) set to Read and Write for users in the group. My problem is when we create new folders or files within the shared folders they do not have the same access privileges. If one person makes a new file or folder, the other person has read only access and can't write to it and visa versa.

soulman
24th April 2010, 09:42 AM
I never found an easy way to do this using OS X client. Works fine if you're using the server OS though. The workaround I ended up using was to have everyone who needed to share the files log in to the file server as the same person.

JimWOz
24th April 2010, 11:32 AM
A long running frustration in OSX this one. You wouldn't think something so obviously needed, - collaboration on the same file on a server, would be so hard in the OSX multi user client.

You could investigate the world of ACL's, I try and stay clear of them myself.
A part solution is to change the default umask for each of your users from 022, to 002. This will amend the default behaviour to give group write access. Note this applies to all new files created after the change. On each machine (10.5+) add a line to or create the file /etc/launchd-user.conf with the contents umask 002. (The utility TinkerTool System can do this for you also)

The next part of the problem I found was that applications do not abide by the unix convention of assigning a new file to the same group as the enclosing folder. eg Apple's Textedit insists on new files being assigned to the staff group (10.5+) regardless of where you save them, whereas I found MS Office played ball and files were created with the enclosing folders group assignment - go figure. So your file sharing users need to be a member of the staff group (which they are by default if they have user accounts on the machine serving the files) and it should work.
Note that to prevent other user accounts not members in your special group, but are also members in the staff group, from accessing the files you still need the top enclosing folder to be assigned with write access for the special group, and everyone no access. This filters them out, preventing them from getting in the front door to see the files.

I ended up giving up on all this on my home file server. I now share using Samba instead of AFP. With Samba you can configure a file share such that it:
Forces files to have a selected group assignment - Force Group = mygroup
Force directories to be created with group write permission - Force Directory Mode = 775
Forces files to have group write permission -Force Create Mode = 775.
All of which deliver exactly what you are after, and the owner will be the last person who saved it. Edit the file smb.conf in /etc using a text editor like TextWrangler, after studying up on Samba. Start file sharing with smb in the the Sharing preference pane, and share your folder to the mygroup group.

Edit: - I did some more testing on this, and remember why I gave up in disgust last time, a couple of years ago. You can set either standard POSIX group write permissions, or apply an ACL for the group write that is set to be inherited to all child files and subfolders, - but these only take effect on files or folders copied below. The problem with many applications is they initially create the file in a temporary place, where it is assigned permissions according to your user Umask, (group read only is the default) and your default group (staff by default for 10.5+) and then move the file into the desired directory. - Permissions and any ACL entries are not picked up by the file in this case where moving as opposed to copying takes place. So the only way make either of these situations work is to work on the file in a different place and then copy it in the finder onto the share folder.

So, options that work are:
1) Change users umask to 002, ensure all users who are to have write access to the share folder have user accounts on the host machine (making them members of the default staff group, 10.5+ only). Create the share folder with read and write access for the special group (may or may not include all members of staff). Other users not members of special will not be able to open the folder.
2) Create the share folder, include an ACL that gives the special group read and write access and forces inheritance of these permissions to the files and sub folders contained below. Copy all files to the share folder, do not move or save directly into it. - Note applications that obey the ACL without needing to finder copy (ie create the file directly in the folder) include MS Office apps, Acrobat. Note, one GUI application to create the ACL is TinkerTool System, if terminal isn't your bag.
3) Learn some Samba and edit the /etc/smb.conf file to create an SMB share for your folder, with the properties described above.

I hope this is useful to someone. Personally, I am going to stick with my Samba solution. Note it will work any any mac or linux box.

soulman
24th April 2010, 11:52 AM
Yeah, it's way too complicated. I wrote an AppleScript to change ownership & permissions on all new files, but you still had to drop stuff onto it. At least it's painless on Snow Leopard Server.

jay59cee
26th April 2010, 08:22 AM
Thanks for the ideas. At least I know now that it is not something simple that I was missing.

fletch371
4th May 2010, 09:08 PM
Hey Soulman, interested in your comment "at least it's easy on SLSever". I have been trying to help someone that has had all sorts of permission issues with shared files. What particular settings did you use? Admittedly there are mac clients, windows vista/7 & XP- this may be causing most of the issues.

soulman
4th May 2010, 09:48 PM
I just set up sharepoints on various disks within, and attached to, the server and made them either available to all registered users, particular users, or members of a particular group. I did this via Server Preferences, using the Fie Sharing pane. Works well. I remember I couldn't get it to work properly at first, but once I started doing it all through Server Prefs, it all worked as I expected.

Dambo
4th May 2010, 10:28 PM
Hi everybody

I just had a job today where I had to do this.
I set up a drobo attached to an iMac to replace a crappy WD NAS box.
First off set up any users you want to access the share points in the accounts preferences. I just used sharing accounts so as the user folder wouldn't get too cluttered.
Next setup any groups and assign the the users you want to each group.
You can now set up the sharepoints in sharing preferences by choosing the folders you want to share.
The only way you can set up inherited permissions on share points is by using ACL's. There isn't any GUI to set this up built into the client version of OS X but there are some tools available to download.
I used Tinkertool System 2 in demo mode.
TinkerTool System Release 2: Description (http://www.bresink.com/osx/TinkerToolSys2.html)
Choose ACL Permissions in Tinkertool and drag the folder you wish to assign permissions for into the window.
Next click the plus button and select the group you want to assign to the ACL section.
Click the edit button and tick the inheritance box.
Apply the settings and propagate permissions from the Operations drop down.
This should allow anybody in the assigned group to create and access any files in the sharepoint.

Hope this helps you guys out.

J

JimWOz
5th May 2010, 08:00 AM
...This should allow anybody in the assigned group to create and access any files in the sharepoint.

Now that You've set it up, create a textedit file and save it to the share. - Check the permissions.
Unless the Umask of the user has been changed to default to Group write 002, it will be read only for everyone but the owner, and have the owners default group staff assigned also, regardless of what the folder POSIX permissions and any ACL's say.

The method you describe is supposed to work, but doesn't for a raft of applications that create files in a temporary place and MOVE them into the save location. Files CREATED or COPIED to the save location obey the permissions and ACL inheritance.

So if you are working in an App like Textedit, Nisus Writer or Bean (to name a few I've tried) saving to the share results in the default permissions, Group Staff = read only. But if you are using MS Office or Acrobat, saving to the share results in the ACL being adhered to.