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
>