[Samba] Cannot map to other client shares

Tue Dec 6 14:27:05 UTC 2016

That is really weird.

I think what is happening is that if you log in immediately you are 
using cached credentials.  If you wait a little bit then your network 
connections are up and you are truly doing network authentication.  If 
you were do unplug from the network, reboot, login with cached 
credentials, and then reconnect network cable I would suspect your 
access to shares would be OK.

I had been running Samba 3.6.25 on my domain controllers (Solaris.)   
oracle provided a badlock patch for this.   All was OK for a while but 
after a power outage windows 7 PC's were unable to log in (expect be 
disconnecting and using cached credentials.) Rolling out the samba 
3.6.25 badlock patch fixed the issue. Currently I am running Samba 4.4.7 
on domain controllers and 3.6.25 on file servers and it all seems OK.   
I suspect I could have kept 3.6.25 (+ badlock patch) with the right 
combination of smb.conf settings

I don't think samba 4.2.10 is a supported version.  Can you upgrade to 
4.2.13 ?   Make sure you back up the /etc/samba and /var/samba/locks 
directories first.

On 12/05/16 14:49, Dave Beach via samba wrote:
> Suggested changes applied to smb.conf (and yes, server role is classic PDC):
>
>         server max protocol = NT1
>         client signing = auto
>         client ipc signing = auto
>         server signing = auto
>
> With no apparent change to the behaviour or resolution to the problem(s).
>
> I'm particularly mystified by the logging-in behaviour (that is, if I manage to do it quickly I can log in, but if I wait I cannot); not sure how the above suggestions would relate to this timing issue.
>
>> -----Original Message-----
>> From: samba [mailto:samba-bounces at lists.samba.org] On Behalf Of Gaiseric Vandal via samba
>> Sent: Thursday, December 01, 2016 10:00 AM
>> To: samba at lists.samba.org
>> Subject: Re: [Samba] Cannot map to other client shares
>>
>> 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?
>> -- 
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>