[jcifs] Exception when connecting to DFS share

Michael B Allen miallen at ioplex.com
Fri Sep 7 15:10:48 GMT 2007

Sending to JCIFS mailing list. Let's try to keep this on the list if
there's nothing sensitive about it Eric.

On Fri, 7 Sep 2007 07:44:18 -0500
<Eric.Mitchell at wellsfargo.com> wrote:

> Mike, I hope you get this before looking into the DFS to far.
> I backed out of everything and find that I get the same results even going
> to a regular windows file share.
> 1.2.13 works, but 1.2.17 doesn't. Both are using the same jcifs.properties
> file, which contains the username and encrypted password. But one works and
> the other doesn't.

Again, you need to be more specific. What do you mean by "same
results even going to a regular windows file share"? So listing
smb://server.domain.name.corp/regular_share/ works with .13 but .17
gives you 'Access denied'?

> Our developers are also testing, but from their windows workstations - they
> are not getting the exception, but then again they are not resolving the DFS
> root either. When they go to //domain.name.corp they get what appears to be
> the inaccessible administrative shares of a domain controller. When they go
> to //domain.name.corp/dfs_name it doesn't resolve. 

So these is a separate behaviors aside from "going to a regular windows
file share"?

This may be described a little in the README.txt notes but let me
elaborate on the changes that were made. They are fairly significant.

When JCIFS resolves the authority component of the SMB URL using DNS
and it returns a list of multiple names, it interprets this as a list
of domain controllers. This list of hostnames is used in two scenarios.

[Note: Try the dig command like Linux like:

  $ dig domain.name.corp

to see the full list of names JCIFS is getting.]

If a share is specified, JCIFS will try to connect to the first
hostname, authenticate and mount the target share. If the connection
fails, authentication fails or the mount fails, the exception is caught
and logged (with a sufficiently high log level). The process is then
repeated with the next hostname until the client successfully connects,
authenticates and mounts the target.

The second scenario is when no share is specified. In this case, JCIFS
connects to each host in the list, enumerates the shares, puts them into
a map and then, after all shares of all servers have been enumerated,
the now unique list of shares in the map is used to build a composite
list of all shares on servers.

In a Windows environment, domain controllers register their domain
name. So if you have multiple domain controllers, trying to use the
domain name in an SMB URL will trigger the above logic.

Now, note that DFS is independent of this but because DFS roots may not be
on all servers, the above composite list behavior is necessary to ensure
that the client can find a DFS root.

So, when trying to diagnose a problem related to accessing content under
an SMB URL using a domain name it is important to understand that the
connection logic is quite different. If you are getting something like
'Access denied' you should find the server that is hosting the target
share and try to access it directly using the full hostname like
smb://server5.domain.name.corp/regular_share/ and see if it works.

Also note that this behavior is totally unrelated to listing the NetBIOS
domain name smb://CORP/ which will cause the client to return the "browse"
list of servers in that domain. Completely different logic again.


Michael B Allen
PHP Active Directory Kerberos SSO

More information about the jcifs mailing list