[Samba] clients not connecting to samba shares

Wed Apr 12 19:11:12 UTC 2023

Hi,
I have been looking at this thread a while now. 
First I think what Rowland and myself misunderstood is that you are not using a DC as a Fileserver ( in the beginning I thought you did. That you have a sysvol share on a domain member confused me) so I think so e of the comments from Rowland do not apply here.

Second, if I reread the thread and look at the description of your problem I think it is a permission problem that we have heard a view times over the last view months. Can you confirm that you can not set permissions from windows?
That might indicate that a directory in the path to the share is not accessible for your user.

Regards

Christian

Am 12. April 2023 18:55:52 MESZ schrieb Gary Dale via samba <samba at lists.samba.org>:
>On 2023-04-12 02:48, Rowland Penny via samba wrote:
>> 
>> 
>> 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.
>Yes it should. As you just stated and as the wiki instructs, you have the Unix root and the Windows group
>> 
>>> 
>>>> 
>>>>> 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.
>Again, the instructions say it should be a mix. Whether the owner is 1000 or 0, I am getting the same result on the Windows side.
>> 
>>>> 
>>>>>> 
>>>>> 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
>> 
>Except I am doing what you tell me. It's just not working. What mistakes am I making? If the Domain Administrator is mapped to root, why can't the Domain Administrator see the folders in the shares when the share is owned by root:HOME\Domain Admins and the folders in it are owned by :HOME\Domain Admins or :HOME\Domain Users?
>
>You seem to be obsessing over the fact that my Linux account doesn't authenticate to the AD but the situation I'm describing is entirely between the Samba DC, the Samba file server and a Windows 10 client that is logged in variously as HOME\Administrator or HOME\garydale (which is in the HOME\Domain Admins group).
>
>By flipping the ownership of a share between root and garydale, I can get access to it from my Linux workstation when needed. However it is set to root when I'm trying to get access from Windows and that isn't working. The fact that I find it puzzling that Samba's mapping of HOME\administrator to root seems to not be the same as accessing the share as root is beside the point.
>
>If other people are making the same mistakes, that suggests that the documentation is unclear and needs to be fixed. Rather than getting upset with people who aren't as familiar with the topic as you, perhaps you should look at the problems they are having and find ways to amend the documentation to circumvent these issues.
>
>I've been going out of my way by using just the Samba documents rather than the Debian ones because I've had previous experience with the Samba list dismissing the Debian documents even though the Samba ones share similar failings.
>
>In particular Samba has apparently undergone a major change from a couple of years ago that is not reflected in all of the documents. And the Samba wiki assumes files are in particular places while various distributions place them elsewhere. I've even found a list of error messages in one section without even a hint about how to fix them.
>
>Getting back to the issue of Linux authenticating to a Samba AD, I can't find a Samba wiki that actually addresses that. The ones I've found all give you the setup for a member server. Obviously the two situations are quite different. Yet the closest I've found is one begins by telling you how to set up Samba - something that shouldn't be necessary to authenticate to a DC.
>
>I appreciate that you are a volunteer and you've given me a lot of helpful advice but at this point, despite following it, my access to shares from my Windows 10 VM is less than what it was when I started.
>
>
>-- 
>To unsubscribe from this list go to the following URL and read the
>instructions:  https://lists.samba.org/mailman/options/samba