[Samba] clients not connecting to samba shares
Gary Dale
gary at extremeground.com
Wed Apr 12 16:55:52 UTC 2023
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.
More information about the samba
mailing list