Bug 7952 - Vista & Windows 7 fail to recognize ACL share permissions
Summary: Vista & Windows 7 fail to recognize ACL share permissions
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: User & Group Accounts (show other bugs)
Version: 3.5.6
Hardware: x86 Solaris
: P3 major
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL: https://eng.purdue.edu/ECN
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-10 14:56 UTC by Mike Moya
Modified: 2011-02-11 14:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Moya 2011-02-10 14:56:29 UTC
After upgrading from Samba v3.2.X to v3.5.6 (source3) none my 
shares that use ACL permissions work (non ACL permission do work) from a Vista or Windows 7 machine. Windows XP and MacOS continue to work perfectly fine. I set up a share to test:

The machine is Solaris 10x86 (not OpenSolaris) at the latest patch level. Here is how I compiled samba:

./configure  \
        --prefix=/opt/${PACKAGE}/${VERSION} \
        --disable-shared-libs \
        --enable-socket-wrapper \
        --localstatedir=/var/samba \
        --with-acl-support \
        --with-configdir=/etc \
        --with-pam \
        --with-privatedir=/etc \
        --with-quotas \
        --with-sendfile-support \
        --without-syslog \
        --without-winbind \
        --without-ads \
        --without-ldap


Here are the global smb.conf settings:

[global]
        workgroup = ECN
        server string = ECN fileserver - beagle
        passdb backend = smbpasswd
        log level = 1 
        max log size = 0
        unix extensions = No
        deadtime = 10
        load printers = No
        printcap name = /dev/null
        local master = No
        wins server = 128.46.154.113
        remote announce = 128.46.154.113
        remote browse sync = 128.46.154.113
        veto oplock files = /*.xls/
        wide links = Yes
        nt acl support = No

Here is the test share:

[data]
        comment = Test Data share
        path = /data
        writeable = Yes
        browseable = No
        valid users = jmmadm,moyman,+cgt411mn,+cgt411t1,+cgt411t2,+cgt411t3,+cgt411t4,+cgt411t5,+cgt411t6
        acl check permissions = No

Running testparm returns:

beagle# testparm 
Load smb config files from /etc/smb.conf
Processing section "[homes]"
Processing section "[pchome]"
Processing section "[profile]"
Processing section "[micro]"
Processing section "[tmp]"
Processing section "[motd$]"
Processing section "[data]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Permissions on the share are set by what group the user is in.

The group permssions are:

beagle# grep cgt411mn /etc/group  
cgt411mn:*:2557:moyman

beagle# grep cgt411t1 /etc/group
cgt411t1:*:2558:jmmadm

Which should give user moyman full read/write/exec access to anything on
the share. Anybody in group cgt411t1 (user jmmadm, my test account) should have
read/exec access to the top level (so it can be mounted) and read/write/exec 
access to the folder T1: 

beagle# ls -dV /data
drwx------+  8 root     root           8 Feb 10 12:43 /data/
    group:cgt411mn:rwxpdDaARWcCos:fd----:allow
    group:cgt411t6:r-xpdDaARWcCos:fd----:allow
    group:cgt411t5:r-xpdDaARWcCos:fd----:allow
    group:cgt411t4:r-xpdDaARWcCos:fd----:allow
    group:cgt411t3:r-xpdDaARWcCos:fd----:allow
    group:cgt411t2:r-xpdDaARWcCos:fd----:allow
    group:cgt411t1:r-xpdDaARWcCos:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:rwxp----------:------:deny
            group@:--------------:------:allow
         everyone@:rwxp---A-W-Co-:------:deny
         everyone@:------a-R-c--s:------:allow
beagle# ls -dV /data/T1
drwx------+  3 root     root           4 Feb 10 12:43 /data/T1/
    group:cgt411mn:rwxpdDaARWcCos:fd----:allow
    group:cgt411t1:rwxpdDaARWcCos:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:rwxp----------:------:deny
            group@:--------------:------:allow
         everyone@:rwxp---A-W-Co-:------:deny
         everyone@:------a-R-c--s:------:allow
beagle# ls -dV /data/T2
drwx------+  2 root     root           2 Feb 10 12:42 /data/T2
    group:cgt411mn:rwxpdDaARWcCos:fd----:allow
    group:cgt411t2:rwxpdDaARWcCos:fd----:allow
            owner@:--------------:------:deny
            owner@:rwxp---A-W-Co-:------:allow
            group@:rwxp----------:------:deny
            group@:--------------:------:allow
         everyone@:rwxp---A-W-Co-:------:deny
         everyone@:------a-R-c--s:------:allow
...etc...



When I try to connect to the share from Windows 7 (I map the drive to X:):

\\beagle\data

I get an error dialog that says:

X:\ is not accessible.

Permission is Denied.

The odd thing is the share still mounts to my machine (with no access)
and there is no error logged in /var/samba/log.smbd. All I can do is
disconnect the drive.

Like I said previously. Windows XP and MacOS mount and work perfectly
as expected. Access is as expected, permissions are inherited as expected, etc... But Windows 7 and Vista fail. 

If I go back to samba v3.2.15, Vista and Windows 7 work as expected 
just like Windows XP and MacOS ... I additionally tried versions 
3.3.14 and 3.4.11 and they too failed like 3.5.6. At first I thought 
maybe I just needed to add/subtract some options in smb.conf but I 
have gone on an exhaustive search, tried many things trial and error 
with smb.conf options to no avail. 

Note that samba is not running as a PDC/BDC/Domain member or anything 
special. Just serving out shares via an smbpasswd file.
--mike
Comment 1 Mike Moya 2011-02-11 14:03:21 UTC
After further investigation (via Google)I found a module called vfs_zfsacl which after compiling and enabling (it is not built on Solaris by default, it should be) fixes this problem. I wish the documentation were more clear that this is needed for anything ACL related on Vista and Windows 7. Actually I wish it were in the documentation. Maybe it is but I could not find it at the samba.org docs web site. You can close this item.
--mike