Note: This document assumes that you know how to read Terminal output for user, group, owner, directory, and privileges information. If you cannot, you should seek assistance. How to read this information is explained in part in technical document 106712, "
Mac OS X: Troubleshooting Permissions Issues".
When privilege mapping is used
Privilege mapping is used if:
- The client and server do not share a common directory service, or
- The account used to log in at a the client is not the same one used to log in to the server.
For example, you use the account "locadmin" to log in to a Mac OS X computer, then connect to a Mac OS X Server with an account named "01user," mounting a share point named "Groups". Viewed at the server, the privileges for Groups look like this:
ls -ld /Groups
drwxrwxr-x 7 root admin 264 Jan 8 03:15 Groups
ls -l /Groups
drwxr-x--- 6 15user group1 264 Jan 7 13:00 group1
drwxr-xr-x 5 15user group2 264 Nov 26 03:15 group2
drwxr-xr-x 5 01user managed 264 Nov 21 03:15 managed
drwxr-x--- 5 04user mmanaged 264 Nov 21 03:15 mmanaged
drwxr-xr-x 5 11user tgroup1 264 Jan 8 03:15 tgroup1
When viewed at the client, privileges for Groups looks like this:
ls -ld /Volumes/Groups
dr-xr-xr-x 7 locadmin unknown 264 Jan 8 03:15 Groups
ls -l /Volumes/Groups/
d--------- 6 locadmin unknown 264 Jan 7 13:00 group1
dr-xr-xr-x 5 locadmin unknown 264 Nov 26 03:15 group2
drwxr-xr-x 5 locadmin unknown 264 Nov 21 03:15 managed
dr-x------ 5 locadmin unknown 264 Nov 21 03:15 mmanaged
dr-xr-xr-x 5 locadmin unknown 264 Jan 8 03:15 tgroup1
The effective privileges seen here are the union of owner, group, and everyone, as applies to 01user. You can see that these "mapping" actions have taken place to present 01user's privileges as those of localadmin:
- The effective owner privilege is taken from the actual server privilege of the authenticated account.
- Thus, 01user's actual server privilege has been transposed into the owner's slot of the effective privilege output; and all folders are presented as if localadmin is the owner, even though he is not in reality. This presentation of the owner privilege is known as User Access Rights (UARights), as described in "Inside AppleTalk", pages 13-32. The user access rights (UARights) contain a summary of what the rights are, regardless of the category (owner, group, world) from which they were obtained.
- Server groups are represented locally as "unknown", and the group permissions are just a copy of world (everyone) permissions.
- Effective group privileges echo the server's actual everyone privileges.
Examples:
- Actual privileges of the folder mmanaged are 750, and 01user is a member of the group mmanaged. From the mapped perspective, this becomes a privilege of 500 for localadmin.
- Actual privileges of the folder group1 are 750, and 01user is not a member of group1. Thus, the folder group1 is locally locked with effective mapped privileges of 000 for localadmin.
- Actual privileges of the folder "managed" are 755. Because 01user owns this folder, the effective mapped privileges are also 755.
When privilege mapping is not used
Privilege mapping is not used when:
- The client and server share a common directory service such as Open Directory, LDAP or NetInfo, and
- The same account is used to log in to both the client and the server.
Using the same Groups directory as above and 01user this scenario, these are the privileges seen at the client:
ls -ld /Volumes/Groups
drwxrwxr-x 7 root admin 264 Jan 8 03:15 Groups
ls -l /Volumes/Groups
drwxr-x--- 6 15user group1 264 Jan 7 13:00 group1
drwxr-xr-x 5 15user group2 264 Nov 26 03:15 group2
drwxr-xr-x 5 01user managed 264 Nov 21 03:15 managed
drwxr-x--- 5 04user mmanaged 264 Nov 21 03:15 mmanaged
drwxr-xr-x 5 11user tgroup1 264 Jan 8 03:15 tgroup1
Privilege mapping is not being used, since the client and server are sharing a common directory service, allowing the client to readily resolve the user and group names and ID numbers used on the server.
Notes
1. Unmapped permissions provide better compatibility for applications that rely upon specific behavior with respect to permissions. For example, the chmod command might be expected to work since 01user appears to be the owner, but will be rejected by the server when the actual owner is not 01user. Additionally, sticky bits cannot be set or used. These differences may cause issues in subtle ways.
2. Unmapped permissions are necessary when using the "Inherit permissions from parent" setting on AFP share points.
3. Unmapped permissions should be used with AFP home directories.
Situations to avoid
Unpredictable results can occur when an account exists on both client and server with the same short name and/or UID, and the client and server do not share a directory service.
Note: GIDs and UIDS do not conflict with each other. The server being used in all of these examples has both a user (01user) and a group (mmanaged) with the ID 1026. Privilege mapping is off in this example, but the client cannot resolve the UIDs and GIDs used by the server. At a client computer that has a local "01user" account with a UID of 1026, and the same server as before, the privileges look like this:
ls -ld /Volumes/Groups
drwxrwxr-x 7 root admin 264 Jan 8 03:15 Groups
ls -l /Volumes/Groups
drwxr-x--- 6 1040 1027 264 Jan 7 13:00 group1
drwxr-xr-x 5 1040 1028 264 Nov 26 03:15 group2
drwxr-xr-x 6 01user 1025 264 Feb 3 16:21 managed
drwxr-x--- 5 1029 1026 264 Nov 21 03:15 mmanaged
drwxr-xr-x 5 1036 1029 264 Jan 8 03:15 tgroup1
Note that ID numbers appear instead of user and group names. This is because the client has no way of determining which users and groups these IDs correspond to. Also note that "01user" will be denied access to the "mmanaged" folder, even though the user is a member of the mmanaged group on the server. The client cannot map GID 1026 to any group, so the user cannot be a member of that group.
Important: This same situation can occur with a common directory service if groups are created in the local domain on the server. Workgroup Manager warns that you are working in a domain that it not network visible.