Windows rename on SMB share ignores ACLs

Question

We're getting ready to put ACLs on our file server into production use, and I was checking to make sure that the file sharing experience for Windows users via SMB mounts would match what OS X users see via AFP mounts to the same shared folders and files.
I've discovered that when Windows users rename files and folders via SMB mounts, the permissions are controlled by the POSIX privileges of the enclosing folder, and ACLs privileges appear to be completely ignored. I have a simple test case where I prepare a shared test folder that grants a particular user full access via an ACL, but no access via POSIX (this is deliberate). Via AFP on an OS X system, the user can do whatever they want on the share, as you'd expect. They have no problems renaming or deleting items; their ACL privileges are properly observed. However, when the same user logs onto a Windows system and access the share via SMB, if they create a folder or file, they won't be able to rename it. The only way to get around that appears to be to grant them POSIX read/write privileges on the enclosing folder (not on the item itself). For this one operation, it would appear that POSIX privileges are observed, but ACLs are being ignored. [This has been submitted to Apple as a Bug Report (Problem ID 6143881).]
We're running OS X Server 10.5.2, but plan to upgrade to OS X Server 10.5.4 once our ACLs are running in a production setting. I wonder if other folks see the same problem with renaming files or folders in Windows with SMB shares in OS X Server 10.5.4.
On my server, on an AFP+SMB share, I create a test folder with the following privileges:
ls -led path/to/testfolder # Show POSIX settings & ACLs for test folder
drwx------+ 2 root wheel 68 Aug 12 11:25 testfolder
0: user:myuser allow list,addfile,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr, writeextattr,readsecurity,writesecurity,chown,file_inherit,directoryinherit
These privileges can be set via the following commands. Within an AFP+SMB share, create a test folder as follows:
sudo mkdir -p /path/to/testfolder
cd /path/to/testfolder
sudo chmod -R -N . # Remove any inherited ACLs from testfolder
sudo chmod u=rw+X,go= . # Set POSIX privileges to octal 700
sudo chown root:wheel . # Set POSIX owner & group
sudo chmod +a "user:myuser allow list,addfile,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr, writeextattr,readsecurity,writesecurity,chown,file_inherit,directoryinherit"
From Windows, navigate to the testfolder on the SMB share. You can do this as a Network Place, Mapped Network Drive, or by explicitly navigating to
\\myserver\myshare\path\to\testfolder
Create a new folder in Windows Explorer. It will come up by default named "New Folder". Try to rename it and you'll get a Windows error: "Error Renaming File or Folder. Cannot rename New Folder: Access is denied. Make sure the disk is not full or write-protected and that the file is not currently in use."
Run the Note Pad accessory. Create a file in the testfolder named "Foo.txt". Try to rename it in Windows Explorer. Same problem.
If you perform equivalent operations on an OS X System via AFP mount to the same test folder, you won't have any problems; the ACL privileges will be correctly granted.
The only workaround I've been able to come up with to grant Windows users "rename" privileges on our SMB mounts is to do so by enabling read/write POSIX privileges on the enclosing folder ("testfolder"). You can either:
1) Make the user the POSIX owner of the enclosing folder, and grant the owner read/write access, or
2) Set the POSIX group to a group the user is a member in, grant that group read/write access, or
3) Enable POSIX world read/write access (careful!).
Without POSIX read/write privileges to the enclosing folder, it would appear that Windows users on SMB shares can't rename files or folders. Interestingly, they can upload folder hierarchies with arbitrarily named files and folders and won't run into problems; it's specifically when items are renamed when they already exist that you may run into problems.

Answer 1

Just an FYI: I received a response to my bug report. Apple reports that this problem has probably already been addressed in OS X Server 10.5.3, so it's likely this issue will disappear when I update my server from 10.5.2 to 10.5.4.
If you look at http://support.apple.com/kb/HT1142, there's this item:
File Services
The smb.conf file is updated to include the line "acl check permissions = no" in order to provide expected permissions behavior for Windows clients connecting to the SMB service.