samba - Sep 2013 - Samba4: Can't create shares outside sysvol and netlogon

Hi,

I am trying to create shares for my users in our new Samba4 domain, but 
with no luck so far.
My current /etc/samba/smb.conf looks like this:

[global]
workgroup = ADLS
realm = ADLS.EXAMPLE.COM
netbios name = CASTOR
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, 
winbind, ntp_signd, kcc, dnsupdate
idmap_ldb:use rfc2307 = yes

[netlogon]
path = /var/lib/samba/sysvol/adls.example.com/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[homes]
path = /var/lib/samba/exchange_folder
read only = No
map acl inherit = Yes

I am connected to the server with a Win7 client, no problem to bring it 
into the new domain. I can view and browse sysvol and netlogon. I can 
create subfolders under sysvol and netlogon but clicking on my 
homes-share gives me error code 0x80070035.
I also see no security tab when right-clicking on it.

I assume bind and samba are working fine together, otherwise I shouldn't 
be able to join the domain at all, right?
Any productive hint with this is appreciated, as I read several howtos 
and tried so many configuration, all with no success.
BR
Thoralf

On 9/17/2013 6:45 AM, "Th. S?ldenwagner"
wrote:
> Hi,
>
> I am trying to create shares for my users in our new Samba4 domain, but
> with no luck so far.
Which flavor of Linux are you trying this on?

If CentOS/RHEL, one thing I always forget to check is SELinux issues. 
Maybe you have as well?

# getenforce
- Will tell you whether SELinux is disabled, permissive or enforcing.

# setenforce permissive
- Setting it /temporarily/ to "permissive" is a useful check to see 
whether you have a SELinux issue somewhere that need addressed.

Assuming that you have "auditd" running, try looking at:
# cat /var/log/audit/audit.log | audit2allow
Which may show you an overall view of how many exceptions you have.

In general, SELinux issues boil down to a few root causes and fixes:

#1 - There's a boolean that you need to maybe turn on.  If you dig 
through the "sealert -a UUID" messages in the system log, it does a
good
job of explaining when this might apply.

#2 - There's a file system labeling problem.  i.e. you are trying to let 
a process access things in a non-standard place and/or with a 
non-standard label.  These are fixed with "restorecon" and
"semanage
fcontext" changes.

#3 - There's no way to fix labels or booleans to allow what you need, so 
you need to create a local exception policy.  This can be done using 
"audit2allow" and "semodule -i".  You should be careful
about which
exceptions you feed to audit2allow and try to keep the resulting 
exception policy as minimal as possible.