I have no idea what’s going on. Some people seem to mention this behavior, but never there is any solution around. It’s only few people, so it looks like a configuration issue, and either it’s really rare or so common that I’m the last who didn’t get it yet. It’s as follows.
I have an experimental setup with a Samba 4 AD instance as Domain controller. The VM that demonstrates the bug is a samba 3.6.10 member server. Both are based on SerNet‘s builds (enterprisesamba and packages from the SerNet Samba 4 Appliance). Everything’s hosted on a Xen machine and made with debian squeeze as the base OS.
Rainbow Shield Bugs on Jatropha,
Ton Rulkens, Mozambique
Inside one share, I have a directory with some ACLs set, with the mask and default mask set to rwx. If I’m now creating a file using the shell, the file’s ACL mask becomes rw which is just correct. If I’m doing the same with samba, the mask will be rwx which is just plain wrong as the file would be executable like this.
I’ve tried many more or less random things like s-flags, samba parameters (inherit acls has no effect, it seems) and googled as described above, but this thing’s going consistently wrong.
Anybody around who knows more or is stunned like I am? Well, I didn’t expect to run into this issue, really not.
I’m giving back!
Whoever helps me to find an answer or even a fix can get some of my knowledge in the form of code: I offer a complete setup for Samba 4 and 3.6 experiments with Debian Squeeze. It incudes a debian packages source with all you need for such a (virtual) environment of this kind, such as an updated bind9 build and integratable S4 packages and a time saving xen-tools role script, which installs a DomU with these package sources, adding SerNet’s 3.6 (remote) sources as well, many often needed standard packages readily installed, /etc/hosts file adapted to the LAN environment, ethtools, NFS4 mounted from DomU (for easy data exchange between VMs, filesystem ACLs readily setup, and an A record added to a DNS zone file on the host system. So that’s all those repeated tasks after xen-create-image that usually take about 30 to 60 minutes every time to turn the installation into a comfortable, accessible and well integrated VM ready to dig into Samba’s Active Directory implementation details, and even taking steps towards a future production environment on a clean debian foundation (we’re not that far though, in my opinion).
Using this role and some more files in /etc/xen-tools/skel, it takes me 15 minutes for a S4-AD DC and a member server provisioned and up running, ready to join a Windows client and access with native AD management tools.