samba - Nov 2010 - ACL Problems with Samba and ADS Integration

I am running a Samba Box as a Domain Member in a Windows ADS Domain (Windows
Server 2003). The Box has joined the ADS domain and the kerberos authentication
works, I can see "smbd" processes running with AD user accounts.
But I can not set ACLs on the directories or the files located on the share. If
I change them using Windows Explorer, they either will be ignored by samba, or I
get the Message:
Unable to save Permission Changes on [Directory]
The parameter is incorrect
This message comes if I want to grant "Full Control" permissions on
files or directories.
I am not the in depth pro configuring samba, so maybe I did some configuration
mistakes. I read about an ACL patch for samba. I did not build samba from the
sources, I installed the packages and updates supplied by the OpenSUSE 11.3
distro.

My smb.conf file looks like this:
------------------------------------------------
[global]
??????? workgroup = [MyDomain]
??????? security = ADS
??????? realm = [My.Kerberos.Realm]
??????? password server = pdc.emulator.at.my.domain
??????? server string = %L server (OpenSUSE, Samba)
??????? dns proxy = No
??????? disable spoolss = Yes
??????? show add printer wizard = No
??????? map to guest = Bad User
??????? domain logons = No
??????? domain master = No
??????? local master = No
??????? netbios name = [ThisServersName]
??????? wins support = No
??????? client use spnego = Yes
??????? idmap uid = 15000 - 25000
??????? idmap gid = 15000 - 25000
??????? template homedir = /home/%D/%U
??????? template shell = /bin/bash
??????? usershare allow guests = No
??????? winbind use default domain = Yes
??????? winbind refresh tickets = Yes
??????? winbind enum users = Yes
??????? winbind enum groups = Yes
??????? winbind nested groups = Yes
??????? acl group control = Yes
??????? acl map full control = True
??????? ntlm auth = No
??????? lanman auth = No
??????? interfaces = bond0
??????? log level = 3 acls:5 winbind:5

[groups]
??????? comment = All groups
??????? path = /raid
??????? read only = No
??????? inherit acls = Yes
??????? force directory security mode = 0770
??????? admin users = [MyDomain]\[DelegatedAdminUser]
??????? hide dot files = Yes
??????? hide unreadable = Yes
------------------------------------------------

Can anyone figure out where the problem is. Do I need to compile from source and
include some patches, or is the configuration the problem.
I did no group or user bindings with the "net" command.

Best Regards, Mike

Hi,

We are using samba 3.5.3 and ctdb-1.0.114 on SuSe Linux. When we copy a big
files from Windows XP into samba share, the network is down. copying failed.

After repaired the network, mount the share again. we cannot remove the failed
copying file in the samba share. It prompted 'there is another program are
using this file...'

Form SuSe side(samba server), It's a 'DENY_ALL' lock on the file
even the session of Windows XP is terminated.

sfs2_02:/var/lib/samba # smbstatus |grep DENY
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
Processing section "[share1]"
Processing section "[share2]"
Processing section "[share11]"
1:7766       1004       DENY_NONE  0x100081    RDONLY     NONE            
/share/fs2   .   Fri Nov 26 04:32:28 2010
1:7766       1004       DENY_NONE  0x100081    RDONLY     NONE            
/share/fs2   .   Fri Nov 26 04:32:28 2010
1:7766       1004       DENY_ALL   0x30196     WRONLY     EXCLUSIVE+BATCH 
/share/fs2   meego-netbook-chromium-ia32-1.0-20100524.1.img.lock   Fri Nov 26
04:32:44 2010


googled with 'DENY_ALL'. and tried server parameter(veto oplock
files/reset on zero vc/locking) of smb.conf, but still cannot work. Am we
missing something? Or, how we solve this copying issue?

Very appreciate your help!


Paste smb.conf
--------------
[global]
        clustering = yes
        realm = smtc
        netbios name = smtc
        netbios aliases = A1 A2
        workgroup = sm
        security = user
        preferred master = no
        domain master = no
        local master = no
        encrypt passwords = yes
        password server = sm-kbqgd6
        idmap uid = 10000-1000000
        idmap gid = 10000-1000000
        idmap backend = rid:sm=10000-1000000
        allow trusted domains = no
        load printers = no
        printcap name = /dev/null
        disable spoolss = yes
        winbind enum users = no
        winbind enum groups = no
        winbind use default domain = yes
        log level = 2 passdb:3 auth:3 winbind:3
        log file = /var/log/samba/log.%m
        browseable = yes
        lanman auth = no
        ntlm auth = yes
        obey pam restrictions = no
        kernel change notify = no
        ea support = no
        store dos attributes = no
        host msdfs = yes
        ldap admin dn         ldap suffix         map to guest = Bad User
        machine password timeout = 2147483647
        vfs objects         aio read size = 0
        aio write size = 0
        locking = no
interfaces wins support = no

[share1]
    path=/share/fs1
    writeable=yes

[share2]
    path=/share/fs2
    writeable=yes

Thanks,

On Tue, Nov 30, 2010 at 11:01:13AM +0100, Volker Lendecke
wrote:
> Sure, that would be a possible reason. But something looks
> not right in your setup. After a failover, locking.tdb
> should be empty. When smbd is started on node2 after the
> failover is done, it will open the locking.tdb file with
> CLEAR_IF_FIRST. This means, all entries which are by
> definition empty are wiped out. Alternatively, if you are
> running ctdb, then smbd should have either been able to send
> the kill message to the other node, or the code should have
> discovered that process 12924 is not around anymore and it
> should have removed the conflicting entry from the
> locking.tdb entry.
Can you give a few more details about your setup? Do you
have ctdb running? Do you have "clustering=yes" set in your
smb.conf?

Thanks,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen