[jcifs] Re: Exception when connecting to DFS share

[Eric Mitchell]

Michael B Allen <miallen <at> ioplex.com> writes:

> 
> 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.
> 
> Mike
> 
Mike, thanks for the elaboration, tis good to understand.
I'm a little further now than before, but still having what appears to be an 
issue connecting to the dfsroot.

Here is what I am seeing when performing a listfiles:

smb://our.domain.name.corp/  retrieves what appears to be an listing of all 
hidden shares and sysvol shares. (driveletter$, ADMIN$, IPC$, etc) No 
dfs_roots are listed in the output.

smb://our.domain.name.corp/dfs_root/  Gets the following error 
"Exception in thread "Main Thread" jcifs.smb.SmbException: The network name 
cannot be found.
        at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:514)
        at jcifs.smb.SmbTransport.send(SmbTransport.java:614)
        at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:277)
        at jcifs.smb.SmbSession.send(SmbSession.java:233)
        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:154)
        at jcifs.smb.SmbFile.doConnect(SmbFile.java:816)
        at jcifs.smb.SmbFile.connect(SmbFile.java:854)
        at jcifs.smb.SmbFile.connect0(SmbFile.java:793)
        at jcifs.smb.SmbFile.getType(SmbFile.java:1195)
        at jcifs.smb.SmbFile.doEnum(SmbFile.java:1649)
        at jcifs.smb.SmbFile.listFiles(SmbFile.java:1631)
        at jcifs.smb.SmbFile.listFiles(SmbFile.java:1564)
        at ListFiles.main(ListFiles.java:18)"

(Note: From a windows client - simply hitting "start" "run" and typing 
\\our.domain.name.corp\dfs_rootname\ pulls up the file browser in the dfsroot 
successfully.)

Doing a dig on or nslookup from the linux servers against our.domain.name.corp 
pulls in a listing of all the domain controller IP's and each IP having the 
registered name of our.domain.name.corp (as expected). 

Search order is DNS,WINS,BCAST. But I've also tried changing the order around 
to no avail. 

the jcifs.properties:
jcifs.smb.client.signingPreferred=true
jcifs.smb.client.disablePlainTextPasswords=true
jcifs.smb.client.domain=our.domain.name.corp
jcifs.netbios.wins=(a wins server IP here)
jcifs.resolveOrder=DNS,WINS,BCAST
jcifs.smb.client.username=(an AD userID here)
jcifs.smb.client.password=(an encrypted password here)

Is there anything else I can collect that may indicate where the issue lies?
Based on this configuration, I think everything should work.. but I just can't 
see what I'm missing.