Inherit permissions and 10.2.3+

[david_lheureux]

I was having an inexplicable permissions problem when two users in the same group were writing the same file with server 10.2. After doing some research on Apple’s support site, I found that many people were having the same problem. A variety of solutions, including shell scripts run from cron many times per hour to chmod files, to more in-depth information about the new “inherit permissions” feature in 10.2.3+ (yes?) came out. Here’s the deal (thanks to Joel for assiting me and providing this great site).

I have a file in a directory which has the following perms:

——————————————————–
-rw-rw-r– 1 david www 3329379 Aug 19 09:27 my_file.psd
——————————————————–

When I open this file from Photoshop, edit it, and save it back to the server (from Photoshop), the perms change to:

————————————————————
-rw-r–r– 1 david www 3329108 Aug 19 09:29 my_file.psd
————————————————————

Now, since the group write priv was removed, the file is now uneditable to other members of the group. I tried changing the share point’s “Inherit Permissions” setting in WGM and other techniques of modifying the servers permissions behavior (see below), but the file was continually written with group write privs removed.

After literally dozens of hours of pain tracking this down, it appears that there is some interaction between users designated as “administrators” in Workgroup Manager and the “inherit permissions” feature on share points. Specifically, the server seems to ignore the inherit permissions setting on the share point if the user logged on as a user with admin privs, and instead defaults to umask 644 for admins.

So, if you make the “mistake” of designating your “main” account on the server as an admin account, you will encounter this problem. I finally setup an account named admin for the purposes of operating the server admin tools, and a named account for my day-to-day personal use (without admin privs). Everything seems to work fine–permissions are inherited now on my non-admin account as well as for other non-admin users. It is possible that the UID also has something to do with this also, but I’m not sure, since I ended up having to reset my NetInfo DB.

BTW, I did come across some useful information from a guy named Gerrit DeWitt on Apple’s message board re: permissions handling in 10.2+:

“To apply inheriting permissions on a per-share point basis, use Workgroup Manager to enable this option in the Sharing/AFP section, or use NetInfo Manager. In NetInfo Manager, authenticate locally to the server’s localhost/local domain, navigate to /config/SharePoints/<share point name>; then create or modify the following properties: afp_use_parent_owner (set value to 1) and afp_use_parent_permissions (value of 1). Restart the server.

To apply inheriting permissions globally (for the Apple File Server in general), open NetInfo Manager, and authenticate to the localhost/local domain as an admin user of that domain. Navigate to /config/AppleFileServer/ and change the value of the permissions_model property from classic_permissions to inherit_permissions. Restart the server.

In either case, this behavior only affects NEW file transfers made remotely using AFP, and any existing files’ privileges are NOT altered. This will not magically alter a folder’s contents’ privileges. For that, use the Apply to Enclosed Items button in the Ownership & Permissions section of the Finder Info window for that folder.”

So, it may be helpful for people to know that you can apply the “inherit permissions” model globally by editing the NetInfo DB to change the permissions_model setting.

[Anonymous]

Take a look at the manual “File serveces administration” specifically chapter 2 page 23.

Select “Inherit permission from parent” from the “Protocol” button .

[Author]

Posts