[Samba] MacOSX 10.9.4 with Samba 4.1.11 and permissions weirdness

[Dan Mons]

Hi folks,

I'm running CentOS 6.5 on our storage nodes, with Samba 4.1.11 RPMs from Sernet.

We're having a strange issue with MacOSX clients (testing on 10.9.4)
when writing directories.

Relevant smb.conf share portions:

        create mask = 0660
        force create mode = 0660
        directory mask = 0770
        force directory mode = 0770
        nt acl support = no

With these in place, any Mac client that copies a directory across
writes the permissions for a directory as (reported directly on the
Linux storage):

u=rw
g=rwx
o=
i.e.: 0670

The user loses the execute permission on directories, and can no
longer traverse directories or list their contents.

When I replace the smb.conf portion with the following:

        create mask = 0770
        force create mode = 0770
        directory mask = 0770
        force directory mode = 0770
        nt acl support = no

Directories correctly get 0770 permissions on the Linux file system,
however so do regular files (I'm trying to avoid regular files getting
marked as executable for this particular data store).

We have multiple sites and multiple data stores (two whopping big
Gluster stores, as well as some regular NAS units with standard local
storage), and the problem exists the same way on all of them.

We began testing on Samba 4.1.9 originally, and it showed the same
behaviour.  I'm just wondering if anyone else has seen the same, or if
it's just MacOSX madness (which I'm willing to accept as the answer,
as MacOSX is anything but consistent with SMB).

Previously on Samba 3.6.9 provided with CentOS 6, I would add the
following share options to solve Mac-specific weirdness:

        #security mask = 0660
        #force security mode = 0660
        #directory security mask = 0770
        #force directory security mode = 0770

These no longer work in Samba 4, and both the man pages and Samba wiki
reflect this change.  When I apply my Google-fu to this problem, these
options are what most people are suggesting, but again they're not
available to me.

Cheers for any insight offered.

-Dan

----------------
Dan Mons
Unbreaker of broken things
Cutting Edge
http://cuttingedge.com.au