[Samba] still ACL bug in 3.0.14a

[Tom Schaefer]

Sparc Solaris / UFS file system.  I have some ACL's set up for a handful
of users and its all worked flawlessly with every incarnation of Samba
I've used over the past couple years, which would be most.

Last Friday evening I upgraded from 3.0.11 to 3.0.13 and some of the users
I have some ACL's set up for promptly found Monday that they couldn't save
new Excel files, they'd be informed the file already exists be prompted to
overwrite and then be informed the folder is marked read only.  They end
up with two 0 byte files, one with the name they where trying to save the
Excel file as and another of the form fsaxx.tmp.

So Tuesday afternoon I reverted the less crucial Samba servers back to
3.0.11 and came in at 6:30AM Wednesday to revert the other servers back to
3.0.11.  Everything is gravy with 3.0.11 as it always been.

I noticed 3.0.14 and 3.0.15pre had been up and back down.  But the change
logs where there and mentioned items dealing with ACLs so I thought I'd
hold off posting to this forum and see if a new Samba would fix it.

I downloaded 3.0.14a today, compiled, and tested.  Sadly, No!  The same
problem is there.  Just before I began posting this very message I came
across the thread "ACL and delete files" and it turns out what the
numerous messages in that thread are describing is exactly what I'm seeing
to.  I had thought it was more of an Excel thing but as I've tested it
today in conjunction with 3.0.14a it turns it is a general thing, exactly
as that thread describes - a file can be created or modified, but not
deleted or renamed.

Actually, I have determined one additional interesting item not in that
other thread -- Windows XP SP1 works fine with a directory using ACLs with
3.0.13 and 3.0.14a IF AND ONLY IF you do not have Microsoft patch KB885835
installed.  XP with SP2 is always screwed.  I've only tested with one Win
2K system and it exhibits the same problem with the new Sambas as well.

The problem is totally reproducible across different boxes here and even
using the most very basic of a smb.conf.  User schaefer should be able to
connect to his home share, go into his tmp/crap/ folder and create,
modify, and delete files as he pleases.  In any Samba 3.0.11 or prior he
can.  Haven't tried 3.0.12.  3.0.13 and 3.0.14a he can't...

root at huckfinn:/accounts/staff/schaefer/tmp bash# ls -ld crap
d---------+  2 root     root         512 Apr 15 11:15 crap/

root at huckfinn:/accounts/staff/schaefer/tmp bash# getfacl crap

# file: crap
# owner: root
# group: root
user::---
group::---              #effective:---
group:203:rwx           #effective:rwx
group:cfusion:rwx               #effective:rwx
mask:rwx
other:---

root at huckfinn:/accounts/staff/schaefer/tmp bash# id schaefer
uid=241(schaefer) gid=60003(cfusion)

root at huckfinn:/accounts/staff/schaefer/tmp bash# cat /usr/local/samba/lib/smb.conf
# Samba config file created using SWAT
# from TOMCAT.umsl.edu (134.124.15.21)
# Date: 2001/08/31 11:24:37

# Global parameters
[global]
        hosts allow = 134.124. 128.206.
        workgroup = UMSL
        netbios name = HUCKFINN
        interfaces = 134.124.15.26 127.0.0.1
        bind interfaces only = Yes
        security = SHARE
        encrypt passwords = Yes
        nt acl support = No
        name resolve order = lmhosts wins bcast host
        os level = 19
        preferred master = no
        wins server = 134.124.45.45
        username map = /usr/local/samba/lib/usernamemap
        unix extensions = no
#       unix charset = ISO8859-1
        smb ports = 139

[Homes]
        comment = Home Directories
        username = %S
        valid users = %S
        writeable = Yes
        map archive = No
        browseable = No
        create mask = 664
        directory mask = 775
        force create mode = 664
        force directory mode = 775