[jcifs] jcifs and dfs from UNIX host - STATUS_BAD_NETWORK_NAME

[Michael B Allen]

On Fri, May 6, 2011 at 12:00 PM, Andrew Hale <andrew.e.hale at gmail.com> wrote:
> We are experiencing an issue with the jcifs client when trying to extract
> data from a DFS share under the following circumstances:
> We have a subdomain of sub.domain.com that has 40+ domain controllers.  Not
> all domain controllers are hosting the DFS root (does not have local DFS
> shares).  Only a subset of 10 or so do.  Accessing the domain based DFS
> could potentially hit any of these 40 domain controllers from the client.
> When the domain controller referred to the client by DNS does not host the
> DFS root we encounter an error (more on the error below).  When the domain
> controller referred to the client by DNS does host the DFS root everything
> works as expected.  Since DNS can return any of the domain controllers this
> results in inconsistent behavior.
>
> Note I am about 80% sure that this is what is happening. The only way we
> could test this was by modifying the hosts file and hardcoding the subdomain
> to point to the different domain controllers directly.  I realize that this
> is not a 100% replication of the entire live process but it supports my
> theory.
>
> Below is a chunk of a trace file from a failed attempt (referred to a domain
> controller not hosting the DFS root):
>
> 1373 20:15:56 2011/5/3       32.919983           {TCP:41, IPv4:40}
> 130.226.187.2     130.226.185.3     SMB  SMB:C; Tree Connect Andx, Path =
> \\sub.domain.com\IPC$, Service = ?????
> 1374 20:15:56 2011/5/3       32.920355           {TCP:41, IPv4:40}
> 130.226.185.3     130.226.187.2     SMB  SMB:R; Tree Connect Andx, Service =
> IPC
> 1375 20:15:56 2011/5/3       32.921955           {SMB:42, TCP:41,
> IPv4:40}     130.226.187.2     130.226.185.3     DFS   DFS:Get DFS Referral
> Request, FileName: <empty>, MaxReferralLevel: 3
> 1376 20:15:56 2011/5/3       32.922452           {SMB:42, TCP:41,
> IPv4:40}     130.226.185.3     130.226.187.2     SMB  SMB:R;
> InterimResponse; Transact2, Get Dfs Referral - NT Status: System - Warning,
> Code = (5) STATUS_BUFFER_OVERFLOW
> 1377 20:15:56 2011/5/3       32.923334           {TCP:41, IPv4:40}
> 130.226.187.2     130.226.185.3     SMB  SMB:C; Tree Connect Andx, Path =
> \\sub.domain.com\DFS, Service = ?????
> 1378 20:15:56 2011/5/3       32.923697           {TCP:41, IPv4:40}
> 130.226.185.3     130.226.187.2     SMB  SMB:R; Tree Connect Andx - NT
> Status: System - Error, Code = (204) STATUS_BAD_NETWORK_NAME
>
> According to Microsoft Support, packet 1375 looks strange as the filename is
> empty in the DFS referral request.  Then, the client apparently treats the
> DFS path as a normal UNC path and receives a STATUS_BAD_NETWORK_NAME (packet
> 1377-78).
>
> Again according to Microsoft support the filename for the first DFS referral
> request should be populated with the domain name, something like
> "\sub.domain.com" and the next should be the DFS root and so on...
>
> Any ideas on something we may be doing wrong or some piece of configuration
> we are missing?  Should jcifs be able to resolve DFS referrals on domain
> controllers that do not necessarily host the DFS root?

Hi Andrew,

An DFS referral with an empty string for a filename is called a
"Domain Referral" which lists domain-based DFS domains. See "Domain
Referral" in [MS-DFSC].pdf from the WSPP documents.

The problem you are seeing is likely due to the fact that JCIFS does
not retry other servers if it cannot find the desired file. Meaning if
all of the servers advertising a certain DFS volume do not actually
host those files for whatever reason, JCIFS may not find the file.
Over time it has become apparent that Windows is more forgiving in
this scenario and that it will in some cases retry other servers to
find the file. At least I'm pretty sure that's what's happening based
on other user's comments about this.

Unfortunately this is not trivial to fix. It means adding some retry
logic. I would need to study how Windows behaves in this situation. In
particular what happens if the file does not exist in the DFS volume
at all? Should the client really iterate through 40 servers and then
throw an exception that the file was not found? Just replicating this
scenario means setting up two DFS volumes and deliberately breaking or
turning off replication so that one volume is missing files.

Suffice it to say, this is not going to be fixed soon.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/