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