10.4.6, Guest access, ACLs, SMB connections andpermissions problems.

Question

I applied the 10.4.6 Combo update to our Tiger Server sometime last week. Since then Windows
users connecting to the server have been complaining that they are unable to drag files created by Macs into various folders because of permissions errors.
None of the clients are bound to the server, everyone connects as Guest.
Clients are a mix of 10.2.8, 10.3.9 and 10.4.6 on the Mac side, and Win XP Home SP2 and Pro SP2 with all current security patches. Some of the Macs are using MS Office running in Classic mode. ACLs are used on the shares.
Obviously the first place to look is the ACLs, which may be setup by me in a dumb fashion.
I have the "unprivileged" user from the NetInfo directory setup with Full Control over the share, and Deny just set to inherit. Until now this has worked as expected.
Have I got the ACLs completely wrong for this type of share scenairo, or has something got broken with the latest set of patches?
If so, what users or group should I be setting up when the majority of the incoming connections are guests.
XServe G5   Mac OS X (10.4.6)  

Answer 1

re you saying I also have to have the root of the data drive set for the Everyone group to have Read/Write access?
No, just the share point needs the privileges you want set. By looking at your ls printout, you have both the file_inherit and directory_inherit controls set for the container folder (Public), so new files created within that container will inherit that ACL entry.
I should have been clearer about the meaning of "container": If fileA has path /Volumes/somedisk/folder/fileA, then folder is the container of fileA; similarly, if folderB has path /Volumes/somedisk/folder/folderB, then folder is the container of folderB. Some documentation refers to container as "enclosing folder." Being a container does not imply being a share point (nor vice-versa); the two are independent. If folder is also a share point, then somedisk is its container.
But back to the question: Your privileges seem correct for the ACL entry pertaining to everyone; however, I've noticed that Mac OS X systems will treat a folder as read-only if all read and write controls are set except for delete and delete_child (or one of them is disallowed via a deny rule). This is because a lot of applications perform Save/Save As in the following way: they create a new temporary file, delete the existing one, then rename the temporary file to the old one's name. Even the Finder reports such folders as read-only, although commands like mkdir and touch work. Even though applications can't complete their Save function, inspection of the affected directory will reveal that the temporary file was created. I think this is just a matter of applications expecting delete to come with the package of read and write; it's a valid assumption if the system is POSIX-only, but ACLs allow more flexibility. Perhaps in future releases of Mac OS X applications will be able to work with ACLs more effectively, rather than in a semi-POSIX manner.
One more thing: You can verify the structures of your volumes by using Disk Utility or diskutil verifyVolume /Volumes/volname. This is essentially the same test as fsck, since fsck calls diskutil when working with HFS+ volumes; however, diskutil offers live verification with Mac OS X 10.4.3 and later, and it sometimes provides more detailed output.
--Gerrit