[Samba] Samba 4 AD share: Access denied
Ryan Ashley
ryana at reachtechfp.com
Wed Aug 13 07:51:36 MDT 2014
I already tried removing it from the global section. I had the same idea
you do. Unfortunately, the only thing testparm shows as being recognized
is the path, comment, and read only flag. Still does not work. I did
open a bug report since I have now been through this LONG email chain
twice and tried everything as well as my variations on everything
several times now. It just seems to want to deny access. I wish it was
just denying it to 7, so I could blame 7, but it denies access to all
OSes including my Android phone and my Debian Wheezy laptop.
Thanks for your help, but I am not up yet. Maybe we'll get it sooner
rather than later. Also, I have set all shared directories to 777 and
all files in said directories to 666 until we get it working. Then I can
worry about locking it down.
On 08/13/2014 12:30 AM, Davor Vusir wrote:
> 2014-08-12 23:06 GMT+02:00 Ryan Ashley <ryana at reachtechfp.com>:
>> Just so you know, those attributes only work in the global section. I added
>> them to my shares, but it does not use them. I was still unable to access
>> said shares after rebooting the member server to insure the changes were
>> accepted.
>>
> Sorry to hear that. I guess I'm out of ideas. For now...
>
>> root at fs01:~# testparm /etc/samba/smb.conf
>> Load smb config files from /etc/samba/smb.conf
>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
>> Processing section "[install$]"
>> Processing section "[staff$]"
>> Processing section "[fbc$]"
>> Loaded services file OK.
>> Server role: ROLE_DOMAIN_MEMBER
>> Press enter to see a dump of your service definitions
>>
>> [global]
>> workgroup = TRUEVINE
>> realm = TRUEVINE.LAN
>> security = ADS
>> ntlm auth = No
>>
>> dedicated keytab file = /etc/krb5.keytab
>> kerberos method = secrets and keytab
>> local master = No
>> domain master = No
>> winbind enum users = Yes
>> winbind enum groups = Yes
>> winbind use default domain = Yes
>> winbind nss info = rfc2307
>> idmap config TRUEVINE:range = 10001-40000
>> idmap config TRUEVINE:schema_mode = rfc2307
>> idmap config TRUEVINE:backend = ad
>> idmap config *:range = 70001-80000
>> idmap config * : backend = tdb
>> map acl inherit = Yes
>> store dos attributes = Yes
>> vfs objects = acl_xattr
>>
>> [install$]
>> comment = "Software installation files"
>> path = /home/shared/install
>> read only = No
>>
>> [staff$]
>> comment = "Staff file share"
>> path = /home/shared/staff
>> read only = No
>>
>> [fbc$]
>> comment = "Family Bible College file share"
>> path = /home/shared/fbc
>> read only = No
>>
>> As you can see, testparm ignores them in the share sections. I will remove
>> them since they do not work.
>>
> What happens if you remove them from the global section and only have
> them in the share sections?
>
> Regards
> Davor
>
>> On 8/12/2014 4:57 PM, Ryan Ashley wrote:
>>> I do not have those attributes on my actual AD DC, only on my member
>>> servers. I followed the guide to the letter and put them in global, but I
>>> will happily try putting them in the share section as suggested. If it works
>>> I will let you know. Thanks for the help. If this fixes it I will also
>>> update my ticket and advise the guide be updated.
>>>
>>> On 8/12/2014 4:29 PM, Rowland Penny wrote:
>>>> On 12/08/14 20:41, Davor Vusir wrote:
>>>>> In my first setup, a combined (compiled) AD DC and file server I never
>>>>> got it to work with "vfs objects = acl_xattr" in the global section. I
>>>>> had two more shares and could not get the permissions to work until I
>>>>> put "vfs objects = acl_xattr" in the share sections. The shares were
>>>>> on LVM volumes mapped to directories later shared with Samba. My
>>>>> conclusion is that "vfs objects = acl_xattr" in the global section on
>>>>> a AD DC does not extend (or how to put it) beyond the netlogon and
>>>>> sysvol shares. I have not tested this configuration on one (1) mounted
>>>>> LVM volume where /usr/local and Sambashares reside.
>>>>
>>>> If you add "vfs objects = acl_xattr" to smb.conf on a Samba 4 AD DC, you
>>>> are turning off the 'dfs_samba4' vfs module. If you run 'testpam
>>>> --suppress-prompt --verbose', you will find 'vfs objects = dfs_samba4,
>>>> acl_xattr'.
>>>>
>>>>> I have now changed the setup to a dedicated virtual AD DC and a
>>>>> physical file server because of poor network performance. After the
>>>>> switch I experienced the same; proper permissions denies access... The
>>>>> setup is still the same; mounted LVM volumes later shared with samba.
>>>>> By removing "vfs objects = acl_xattr, map acl inherit = Yes and store
>>>>> dos attributes = Yes" from the global section, as mentioned in
>>>>>
>>>>> https://wiki.samba.org/index.php/Setup_and_configure_file_shares_with_Windows_ACLs,
>>>>
>>>> You only add these line to a member server, they are not required on the
>>>> AD DC.
>>>>
>>>> Rowland
>>>>
>>>>> and instead putting "vfs objects = acl_xattr" in the share section
>>>>> solves it. If you are using more vfs objects you may have to reorder
>>>>> them. And I also noticed that removing Everyone from the Share tab
>>>>> will neither let you edit nor remove ACE:s in the Security tab. So
>>>>> first let Everyone be there, add Domain Admins, press Apply. Add
>>>>> Domain Admins to the ACL, press Apply. Take ownership. After this
>>>>> procedure you are able to edit ACE:s. This will not guarantee that
>>>>> inheritence is correct. Again, "vfs objects = acl_xattr" in the global
>>>>> section does not seem to extend beyond global section. And I'm not
>>>>> sure why "map acl inherit = Yes and store dos attributes = Yes" are in
>>>>> the global section (I'm using neither). Both belongs to a share
>>>>> section according to
>>>>> http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html.
>>>>>
>>>>> Hope it helps.
>>>>>
>>>>> Regards
>>>>> Davor
>>>>>
>>>>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba
mailing list