Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3629
  • Last Modified:

File Sharing Permissions in OS X

I am logged in to my G5 Mac Pro (running Leopard 10.5.1) as user 'ecAdmin'. This user is an Administrator.

I want to:

- Create a folder called 'ecShare' and enable file sharing

- UserA, UserB and UserC (three different users) should be able to connect to this computer (from their Macs) and mount the shared folder 'ecShare' on their desktops. I want them to log in with their own user name (in other words, I do NOT want them to log in as user 'ecAdmin')

- EACH user should have FULL CONTROL (read and write) to ALL files and folders in the 'ecShare' folder, regardless of who created the file or folder.

So, from my Mac, I create a folder called 'ecShare' and set permissions to:
  ecAdmin (Me) - Read & Write
  staff - Read & Write
  everyone - Read & Write

Next, I open System Preferences | Sharing and turn on 'File Sharing'

Next, I click the '+' icon to add a shared folder. I browse to my 'ecShare' folder and set the same permissions:
  ecAdmin (Me) - Read & Write
  staff - Read & Write
  everyone - Read & Write

So far so good, right? Wrong!

The second I create a file or folder inside of 'ecShare', I become the owner, but everyone else gets READ ONLY permission.

What gives? Why don't new files or folders inherit the permissions set by the 'ecShare' folder?
0
ecarbone
Asked:
ecarbone
1 Solution
 
Eoin OSullivanConsultantCommented:
ecarbone - This is the DEFAULT behaviour of OSX.  All new folders are set as Read-only for Groups and others.
The article below discusses all the ways the get around this problem ... from easy to more complex.  
Personally I like the SharePoint Option discussed in Option 4 for Client Computers.

http://www.codebase.ca/art/index.cgi/OS%20X/OSX_Workflow_Perms.html

0
 
jennixchangeCommented:
Actually, none of the suggestions on the link above is valid for the user's question. In the time since the question was posted Leopard has been released (under which SharePoints does not function), and the option has also been removed from recent OSX server versions in favor of ACL's, which are unavailable under non-server versions of OSX.

Saying "this is the default behavior for OSX" neither solves his problem, nor does it make the issue a "feature" and not a bug as the article says.
Default behavior is one thing, but not giving ANY support for such a basic necessity in file sharing is just inexcusable.

The correct solution has been (finally) documented by Apple, and can be found here.

http://support.apple.com/kb/HT2202

I'll save you a click by reposting the meaty part:


Umask for user applications
In Mac OS X 10.5.3 and later, you can create the file /etc/launchd-user.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
 
This will set the users umask for all applications they launch, such as Finder, TextEdit, or Final Cut Pro, and control the permissions set on new files created by any of these applications.
 
Umask for system processes
In Mac OS X 10.4 and later, create the file /etc/launchd.conf with the contents "umask nnn". Do not include the quotation marks and replace nnn with the desired umask value, such as 027 or 002.
 
This will set the umask for all processes. Changing this value is strongly discouraged because it changes the permissions on files used by the system software. If the permissions are too restrictive, dependent software may not work. If the permissions are too open, they may introduce security issues.
 
 
Umask for a specific LaunchAgent or LaunchDaemon
In Mac OS X 10.4 and later, advanced administrators can set a separate umask for a specific LaunchAgent or LaunchDaemon by adding a Umask value to the launchd plist file. This setting will override, for that process only, the umask setting in /etc/launchd.conf or /etc/launchd-user.conf. For more information on this option, see man launchd.plist.

Open in new window

0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now