[Samba] clients not connecting to samba shares

[Rowland Penny]

On 11/04/2023 21:19, Gary Dale via samba wrote:
> On 2023-04-11 15:09, Rowland Penny via samba wrote:
>>
>>
>> On 11/04/2023 19:05, Gary Dale via samba wrote:
>>
>>>> I will say it again, you are using a Samba AD DC as a fileserver, 
>>>> this means that you must set the permissions from a Windows machine 
>>>> and those permissions are stored in an EA, what you see from 'ls' is 
>>>> irrelevant
>>>> I will say this again, you will be better off running a separate 
>>>> fileserver (Unix domain member).
>>> That's what I am doing. However the permissions set from Linux are 
>>> what the wiki on setting up file shares says to use.
>>
>> Are you following this :
>>
>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>>
>> or this:
>>
>> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_POSIX_ACLs
> 
> I've been following the first one. Note the line for those of us using 
> the default backend that says:
> chown root:"Domain Admins" /srv/samba/Demo/

'root' is a special case, the Windows user 'Administrator' is mapped to 
'root' and is the only Windows/Unix mapping required.

> 
> The ownership is explicitly set to a mix of id types.

It shouldn't be.

> 
>>
>>> What is this telling me?
>>
>> It is telling me that you are mixing local Linux users and Domain groups.
>>
> Which is as it should be.

No, Everything should be in AD, you could sync things between AD and 
another LDAP, but I have never seen the point, usually just more work 
for little (if any) gain.

>>
>>>>
>>> I'm maintaining Linux access by owning the folders with my Linux account 
>>
>> First mistake.
> 
> Not really. So long as the Windows group can access the share and files, 
> it shouldn't matter who owns them. They set the the share ownership to 
> root in the wiki. A lesser account shouldn't cause a problem but it 
> allows me to continue to work while trying to get this figured out.
> 
> Setting up the file shares was my original issue. It's still the issue 
> that concerns me most. Getting to login to my workstation using AD is 
> something else that I don't have working yet. I see the two issues as 
> unconnected. I'm using a domain account with the Windows 10  VM and it's 
> not working - even when I follow the letter of the wiki and set the 
> share ownership to root.
> 
> 
>>
>>> but using the Windows group to allow Windows users to access them. 
>>> I've tried propagating the ownership of the folder I'm most 
>>> interested in to both :HOME\Domain Admins and also :HOME\Domain Users 
>>> but neither is allowing me to see the folders in Windows. Nor can I 
>>> grab access rights through the Windows Properties Security tab on the 
>>> share.
>>>
>>> I get the same results when I follow the letter of the file server 
>>> wiki and set the share ownership to root.
>>
>> You do not have to believe me or follow what I advise, but if you 
>> don't, I am finished with this thread.
>>
>> You do not use local Unix users with AD, you create the required users 
>> in AD and use those, to prove it, look at this:
>>
>> rowland at devstation:~$ grep 'rowland' /etc/passwd
>> rowland at devstation:~$
>>
>> As you can see, my username isn't in /etc/passwd
>>
>> So, how does this work ?
>>
>> rowland at devstation:~$ getent passwd rowland
>> rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash
>>
>> Yes, my username etc comes from AD.
>>
>> I am fairly sure that I have said this, forget most of what you know 
>> about NT4-style domains, you need to put EVERYTHING into AD.
>> You only need a few local Unix users (perhaps only one) just in case 
>> something locally goes wrong and you need to log in and fix it.
>>
>> You can have multiple DC's for failover, if one DC goes faulty, you 
>> can easily replace it, without losing the domain.
>>
>> Rowland
>>
> As I have said in the past, it's been a long time since I used an 
> NT-style domain. I've forgotten almost everything about it. And I don't 
> see a current need for multiple DCs because the one I have running is 
> working according to tests I've run since you found the DNS problem. 
> Multiple DCs could help if there were network issues but the DC, file 
> server and workstation are all on the same machine.
> 
> I can also see it helping if there is a corruption on one - so long as 
> the corruption doesn't propagate. However, it's not like I'm doing a lot 
> with the DC. I should be able to revert to a previous snapshot or a 
> backup if I find any unfixable corruption. Worst case would be a reinstall.
> 
> I've currently got a stand-alone AD DC in a VM, a file server providing 
> Samba shares and a Windows 10 VM workstation that logs into the domain 
> and sort-of connect to the shares but can't access the files. I'm trying 
> to get the workstation to talk to the file server. I can sort out the 
> Linux login later after I get this working.
> 

Sorry, but I feel that I am wasting my time here, you do not appear to 
be listening to what I am trying to tell you and you are making the same 
mistakes that other users have.
I am going to leave this thread because it appears to be going around in 
circles. Good luck with your endeavours.

Rowland