[Samba] Cannot map to other client shares

[Gaiseric Vandal]

Presumably this is still configured as a classic domain.       I 
recently upgraded my domain controllers from 3.6.25 to 4.4.7.  
(actually, I tried adding badlock patches to 3.6.25 but had issues.)

Samba 4 has a different default max protocol than samba 3.   You 
probably need to add the following to smb.conf

     server max protocol = NT1


Otherwise the default is SMB3.     With a classic domain Windows 10 
definitely will NOT work with SMB3 and somewhere on the samba wiki it 
says to use NT1.    (It didn't break Windows 7 though.) I don't know if 
a max protocol of SMB2 would work.   However  I found in the past that 
SMB2 caused issues with access to samba file servers so I just made NT1 
the max protocol on everything.



You may also need to set the following

         client signing = auto
         client ipc signing = auto
         server signing = auto


(or maybe "server signing = no" )


The BADLOCK patches changed the default signing behavior.  I don't think 
Windows 7 members in a classic domain support signing (thus the registry 
changes to disable signOrSeal.)     O


On 11/30/16 20:03, Dave Beach via samba wrote:
> I have had a very odd problem for a while now, and am hoping this will ring
> a bell for someone who can point me in the right direction.
>
>   
>
> I had a previous Samba DC (v3.5.6) in my home network, running on a
> command-line Slackware box. For a variety of reasons I decided to switch to
> Debian Jessie, which included an upgrade to Samba 4.2.10.
>
>   
>
> I did NOT properly migrate my samba files to the new installation (more out
> of stupidity than any conscious decision), and instead simply copied key old
> files into the right places and, with a bit of tweaking and fixing here and
> there, and copious amounts of duct tape, things generally seem to work well
> enough.
>
>   
>
> Except for the following problems:
>
>   
>
> First, logging into the domain. From my Win7 clients, if I log in VERY
> quickly after getting the Windows login screen, the login appears to be
> successful (netlogon runs, server shares map, etc). If I wait any length of
> time at all between getting the login screen and actually trying to log in,
> I get a "lost trust" message and have to reboot and hover over the keyboard
> to log in quickly. This will repeat itself reliably, unless I get the timing
> exactly right (generally, if I can manage to type the username and password
> before the standard Win7 "tada" greeting sound ends, I seem to be good).
> Very odd.
>
>   
>
> Second, although once I log in I can map and access server shares just fine,
> under no circumstances can I seem to access one Win7 client's local
> workstation shares from another Win7 client. To be perhaps more clear, I
> have on Client1 shared a particular folder. In the "old" domain I used to be
> able to access this share from Client2, and now I cannot. I had originally
> set permissions on the share and folder to "authenticated users", but I
> cannot now access the share even with permissions set to "everyone". The
> specific error message again refers to a lost trust issue.
>
>   
>
> I've obviously managed to screw something up, probably fundamentally with
> the domain by not properly migrating it.
>
>   
>
> I would be sorely tempted to just drop and re-join the domain on the
> workstations, except I'm very worried I'll lose the local user profiles on
> the workstations (I only use local profiles). I was even more tempted to try
> this when I created a new dummy workstation, joined the domain, and found
> out that I can map its local workstation shares from Client1 (for example),
> but I cannot map local shares on Client1 from the new dummy workstation.
> This seems to prove that a workstation that joined the domain after its
> migration is "fine" (and I use that word carefully), but workstations
> already domain clients at the time of migration are not.
>
>   
>
> Any ideas? Can I post anything that might help pin down what this problem
> is, and how to fix it?
>