I can substantiate your problem.
First off, for those new to this topic, Mac OS X 10.4 Server (Tiger Server) offers two access control models for file services: Access Control Lists (ACLs) and POSIX permissions (owner, group, and everyone else or world).
For share points that reside on volumes where ACLs are disabled (which is the default), the POSIX access control model has two permissions models for new file creation: standard POSIX behavior (or standard UNIX behavior) and Inherit Permissions from Parent. With standard POSIX behavior, the client's umask is consulted. For Mac OS X, the umask is 0022, which is subtracted from 0777, yielding 0755, which corresponds to the following: owner - read, write, and execute; group and everyone else - read and execute. (The initial bit is for set UID or sticky bits, which are off-topic here. See man chmod for more about these.) Inherit Permissions applies to the AFP server by setting the afp
use_parentpermissions property to value 1 to the share point record in the server's local directory domain. When this is the case (and it was in Mac OS X 10.3.x) the umask is not to be consulted for new file creation; instead, privilege information should be copied from the enclosing folder, whatever that information may be.
New file creation includes duplicating existing files on the share point, copying files to the share point, or saving files to the share point.
One good example implementation of the POSIX access control model with the Inherit Permissions permission model is the creation of a share point to which everyone can read and write. In this case, you want new files created to inherit the 777 permissions from their parent, allowing one user to create a file and another user to delete, rename, or append data to it. With standard POSIX behavior, the umask for the new file would give it 755 permissions where other users (besides the owner) could read the file or copy it elsewhere.
However, I have noticed two bugs in the Mac OS X 10.4 Finder which make diagnosing and applying the Inherit Permissions model very frustrating.
1. First of all, try this: as per the example above, create a share point whose container privileges are 777 with Inherit Permissions enabled, and ACLs turned off. Set the owner and group of the share point to root and admin respectively, although it doesn't matter since we want everyone to read and write to this example share point. Then, mount the share point (ex. this_share) as one user (user A) and copy a test file to it. This should complete successfully. Check the permissions via the Finder's Get Info window, and you'll see that the privileges are correct, although the owner and group listed may be wrong. Check the permissions via "ls -l" in Terminal on the mounted directory (/Volumes/this_share).
Now, duplicate this file via Finder. (Terminal duplication via "cp" or similar will work without error.) Tiger clients will show one of the following errors (wording similar to the following):
a. Sorry, the operation could not be completed because an unexpected error occured (error -50).
b. The operation could not be completed because you do not have sufficient privileges (for item whatever).
c. You may need to enter a name and password before you can copy (this item)...
Dismiss the error and look at the privileges for the original file via the Get Info window. They've changed to show 755, but "ls -l" still shows that the original file has privileges 777! If the Finder duplication operation did create a duplicate file (case a), the duplicate will have privileges 755, which clearly violates the Inherit Permissions model.
