Permission Proplem with AFP in MAC Server

[Filiberto]

Hi,
I have a MAC Leopard Server in my office. When I enable file sharing between the systems the system does work properly. I think the problem lies with the AFP permission issue. How can I fix this properly and configure the same in order to avoid any consequences. I have tired to check back the configuration settings but does not found any problems in it. Any suggestions will be appreciated. Thanks in advance.

[Milton.J]

For Mac OS X Server 10.5, it is found that many people had difficulty with the operation permissions. In a classical case a user belonging to a group (call it work) creates a file toto.doc. An administrator has created a share point "jobs" on an AFP server on 10.5. He attributed the following POSIX permissions: Owner: himself, reading / writing; Group: Work, read and write Others: read only. Here User A copy of his file toto.doc on the share point via AFP amd User B, also belonging to the group work, trying to change the file toto.doc. The system there then tells him he did not have sufficient permissions to edit the file. Yet, logically, the file should have permissions read / write for group members work ... except that this is not the case, the group assigned to the file with only read-only. One might think that this is a bug. However, the behavior is exactly that expected. The problem is more insidious, and the fault lies with ... ACLs.

[Spyrus]

Before the arrival of Jaguar Server version 10.2.4 in the behavior of file sharing complies with the POSIX permissions. This means that the permissions of a file copied to a server were the same as the source file, ie the mask is applied between the same source file and the copy on the server. In practice, a file group is read only on the client machine will read only if it is copied to the server. But this posed many problems for users and administrators, as it prevented the transfer of information between users. This is because the default mask applied to all files created on Mac OS X is 022, so a file is always read / write to its owner, but read only for his group. When you copy a file on the server, is this mask is retained. If each file created in Mac OS X was given a mask read / write for the group (002), there would be no problem, the mask is transferred to the server, and authorities would then be correct.

[Snake08]

Apple has changed the customer service and the AFP in 10.2.4 to enable permissions inheritance, as explained in section 107,623 of Knowledge Base. Thus, a recovered file permissions of the group attached to the folder where it is placed. Just check the box to receive parental permission, and presto, it is quiet. This is expected so most of the time, and it was also the behavior of the good old AppleShare IP or sharing of personal files on Mac OS 9. And finally, it worked very well. Except that the big news of Mac OS X Server 10.4 would require a new change, but rather waited very pernicious.

[Zachary]

The ACL (Access Control Lists, lists known as access control or LCA) have made a great versatility in the management of permissions. However, Mac OS X Server 10.4, you must explicitly enable the ACLs for each volume. If ACLs are not active, the permissions of a share can still be assigned as POSIX or through inheritance of permissions. But if they are active, inheritance does not work, besides the ad hoc box is cleared. And guess what? In this case, the allocation of permits as POSIX takes over by default, but you must then possibly add permissions via ACL for that individual users can modify the.