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_ACLsI'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/ The ownership is explicitly set to a mix of id types.> >> 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.> >>> >> 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. Here's the smb.conf on the file server (leaving off most of the shares):> # cat /etc/samba/smb.conf > # Global parameters > [global] > ???????netbios name = THELIBRARIAN > ???????realm = HOME.RAHIM-DALE.ORG > ???????server role = member server > ???????workgroup = HOME > ???????idmap config * : range = 10000-9999999 > ???????idmap config * : backend = autorid > > [sysvol] > ???????path = /var/lib/samba/sysvol > ???????read only = No > > [netlogon] > ???????path = /var/lib/samba/sysvol/home.rahim-dale.org/scripts > ???????read only = No > > [Profiles] > ???????browseable = No > ???????create mask = 0777 > ???????directory mask = 0777 > ???????guest ok = Yes > ???????path = /home/samba/profiles > ???????read only = No > > [homes] > ???????browseable = No > ???????comment = Home Directories > ???????create mask = 0700 > ???????directory mask = 0700 > ???????valid users = %S > > [printers] > ???????browseable = No > ???????comment = All Printers > ???????create mask = 0700 > ???????path = /var/tmp > ???????printable = Yes > > [print$] > ???????comment = Printer Drivers > ???????path = /var/lib/samba/printers > > [shares] > ???????path = /home/shares > ???????read only = No > > [archives] > ???????path = /home/shares/archives > ???????read only = No > >
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