[Samba] clients not connecting to samba shares

Gary Dale gary at extremeground.com
Tue Apr 11 20:19:43 UTC 2023


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/

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
>
>


More information about the samba mailing list