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?
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?
>
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
Maybe Matching Threads
- Cannot map to other client shares
- Cannot map to other client shares
- Cannot map to other client shares
- 转发: 答复: ??????: Is the "\\x.x.x.x" type tree connect request a client related feature?
- File uploaded to webDAV server on GlusterFS AFR - ends up without xattr!