Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Fixing custom permissions for OS X Server shares OS X Server
I have a client who I set up with an OS X Server. In addition to Users' home directories, there is a shared folder where my users save files that need to be read and written to by all users. OS X Server has default permissions set so that the owner of a file has read/write access and everyone in the group has only read-only access (standard UNIX behavior). I needed (as do many others, I have found out) to let the group have read and write access, as well.

Although Apple's KnowledgeBase article number 107623 claims that OS X 10.2.6 server can be set to inherit permissions or set with custom permissions, this ability seems to be less of a feature and more of a phantom. After searching the Apple Discussions, I have found many other users with similar problems, and the only solution seems to be to give up with Workgroup Manager and embrace cron. Until tonight I had never used cron, but I now understand its use. I wanted to pass on my solution to this problem to anyone else with this or a similar problem (I also posted on the Apple Discussions).

You will need a basic understanding of how to execute commands via the Terminal (specifically pico) and have a basic understanding of permissions (owner, group, others, chmod, etc...).

I ended up using the Unix command cron to run a command that fixes the permissions for my /Shared folder on a regular schedule. It sounds a little scary if you have never used cron, but trust me -- it's not difficult! My roommate showed this to me in no time. Below are annotated instructions - I hope they help. I wish Workgroup Manager was able to take care of these permissions, but it doesn't, and this is the easiest solution I could find. And believe me: it's easy! Here's what to do:

As root (use sudo) edit the file /etc/crontab (for example, sudo pico /etc/crontab and enter your root password when requested. When you open the file, you will see a page of text that looks a little intimidating. At the very top of the page are some environmental variables. If you don't know what that means, ignore them (or look them up). The first line to note is the one that reads:
#minute hour    mday    month   wday    who     command
Note: Any line beginning with a # is a comment and as such will be ignored by cron. When you add a line, you will define when that command runs based on those column headings. When you open the file for the first time, you will see several examples of commands that are set to run for system maintenance. For example, the first command under the "# Run daily/weekly/monthly jobs." line is:
15      3       *       *       *       root    periodic daily
The command called periodic is a system function used to clean up your computer. This cron line tells it to run as user root every day (that's the * under the wday for week day and mday for day of the month), of every month (that's the * under month) at 3am (it's in 24hr time) and 15 minutes: that's 3:15am every day. Get it? (A star means "every.")

[robg inserts: For a longer intro to cron, see this older hint.]

The command I am running is supposed to set permission for all files in /Shared so that the Owner and Group have read and write access. That command must be run as root. Here's the line I added:
*/1     7-19       *       *       *       root    /bin/chmod -R gu+rw /Shared
The -R is to set permissions recursively in the folder /Shared. For more options for chmod, type man chmod.

Under the minute column, I wrote */1 to have the task run every minute). I only have my command running from 7am through 7pm, so I wrote 7-19 under the hour column (remember, 7pm in 24hr time is 19).

Note: Don't forget to save the file when you are done. If you used pico, hit CTRL-X to exit, Y to commit to changes, and hit Return to confirm that you are saving to the file /etc/crontab.)

I was hesitant to solve this problem using a UNIX command, but Workgroup Manager just isn't living up to my needs. It's too bad, but I feel that OS X Server just isn't yet ready for the corporate world. Maybe 10.3 will be better. For now, though, I expect cron will make my client happy. Heck, they don't know the difference! Good luck, and I hope this helps.
    •    
  • Currently 1.56 / 5
  You rated: 2 / 5 (9 votes cast)
 
[33,443 views]  

Fixing custom permissions for OS X Server shares | 9 comments | Create New Account
Click here to return to the 'Fixing custom permissions for OS X Server shares' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
umask script
Authored by: hayne on Oct 17, '03 11:57:31AM
The default permissions (that give read-only access for group) is a consequence of the default 'umask' setting. A widely adopted alternative solution to the problem is therefore to change the default 'umask'. There is a script available that does that. You can download it from this page by Alec Bartsch

But note that (contrary to the problems experienced by the author of this hint) many people have found that this global umask stuff is no longer necessary if you are using AFP sharing on OS X Server. The page linked to above says:

In version 10.2.3 of OS X Server, Apple introduced a preference setting in the Sharing section of Workgroup Manager which provides control over default permissions on Apple File Protocol share points. (See screen grab at right.) Provided that the server and all client machines are running 10.2.3 or later, this feature gives the administrator the choice of using traditional Unix-style permissions or traditional Macintosh AFP-style permissions.


[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: anwnn on Oct 17, '03 01:30:28PM

Just one thing of note...

I implemented a very similar cron job to fix the same issue well before the 10.2.6 "feature" was put out. This command will most likely have output, especially if the files are locked. Right now, all of that output is getting dumped to an email to root. If you're running that every minute, that means every time it runs, root gets an email.

Be wary, if you ever enable sendmail and have root's mail forwarded somewhere (to yourself, for admin purposes), you'll get bombarded with thousands of messages. The best way to avoid this, is to redirect output to /dev/null, once you're sure your cron job is functioning correctly.



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: TvE on Oct 17, '03 06:27:48PM

My experience is that it WORKS as advertised (I tested on 10.2.8 build 6R73).

What I have found to be odd is that the permissions is DISPLAYED incorrectly at the clients.

So I would suggest you to try once again and and see if you can get the permissions to work as expected.
I set up a new group "cumulus", created several users "u1", & "u2", turned on the "inherit permission flag".
Then I created files on the sharepoint as "u1" logged out and back in as "u2" and was able to edit the file :-)

Looking t the info on the client it showed the group to be "admin" in stead of "cumulus" - looking at the server via ssh showed the correct group "cumulus".

I have been told that this is fixed in Panther...



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: JohnnyMnemonic on Oct 18, '03 02:17:44PM

I explain the issue that you describe in this hint. I confess that I was sytmied for awhile, too, until I realized the issue--and then it was obvious.

I haven't tested this with Panther, so can't confirm if this is resolved, but I hope so. Also, I have written the author of "X-Ray" to learn if he might be able to redirect the GUI permissions viewer to correctly identify the perms on a server share; you might be inclined to write Rainer Brockerhoff yourself if this feature would be of interest. Finally, I have seen that AFP permissions can be set to either Unix style, or Inherit custom perms, in the Sharing panel in WGM; was the author unaware of this, or did he find that the perms didn't stick even after using this tool?

[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: sjmills on Oct 17, '03 09:31:29PM

What is the technique for redirecting cron output to some other place besides sendmail?



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: bxi106 on Nov 10, '03 02:54:27PM

was this issue fixed in server 10.3?



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: gateone on Dec 28, '03 10:02:37AM

No, 10.3 still has the same problem...



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: RagMan on Jan 14, '04 11:43:36AM

This is not a problem in 10.3, you just open WorkGroup Manager and select "Sharing".
Here once you select a folder you are share you press the "Protocolss" button and select "Inherit permissions from parent", then "Save" changes.
You may have to then Press the "General" Button and press "Copy" to copy these privilages to enclosed items if you wish.



[ Reply to This | # ]
Fixing custom permissions for OS X Server shares
Authored by: g3ski on Nov 22, '04 11:48:26PM

That IS the problem. It doesn't work correctly, accurately, and consistently. It's still an issue in 10.3.

---
"I want my two dollars!"



[ Reply to This | # ]