After some digging, I believe it to be an issue where samba-tool demote does not
remove the DFS records. This causes clients to attempt to map \\<domain>\
with a DC that is unavailable, giving the error. A manual solution is to remove
the bad entries from
CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=<domain>.
I've filed a bug report. https://bugzilla.samba.org/show_bug.cgi?id=10060
----- Original Message -----
From: "Mike Ray" <mray at xes-inc.com>
To: samba at lists.samba.org
Sent: Tuesday, July 30, 2013 2:14:30 PM
Subject: [Samba] Intermittent access to Sysvol/Netlogon shares
Hello all-
Cutting to the chase, I'm noticing varying/intermittent access to the
netlogon and sysvol shares. All clients are windows 7 and samba is 4.0.6. Some
clients are able to run 'gpupdate /force' and will successfully apply
updates. Other clients fail out on this and state that it can't read the
default domain policy GPT.INI file from \\<domain>\.... When I try to
manually navigate there, I can connect to \\<domain>\ but am denied access
to both netlogon and sysvol with an 'access denied, internal error'
message. Connecting to either DC via \\<dc>\ works and from there, for the
clients that failed \\<domain>\ it seems to be arbitrary if they can
browse the entire directory (no relation to nltest /dsgetdc). Additionally, they
might not be able to access say netlogon, but if i browse through sysvol, I can
get into what is the netlogon folder no problem. Clients that have no issue
connecting to \\<domain>\ are equally able to browse all parts of
\\<dc>\.
samba-tool ntacl sysvolcheck, samba-tool drs showrepl, samba_dnsupdate --verbose
and samba-tool dbcheck all report zero errors. There is presently nothing in the
logs either.
Of the two DCs, for the last week or so, one of them was panicking internally
and crashing to an weird state every few minutes; a patch provided by Andrew
Bartlett has since stopped that behavior. If that DC is the only one running or
if the other one is running concurrently, seemingly random clients will
experience the above issues and some will be fine. If the DC who didn't have
that glitch is the only one running, it appears that this issue does not ever
occur.
Anyone have any clue what might be so messed up with that first DC?
-Mike Ray
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba