[jcifs] Re: Exception when connecting to DFS share

[Michael B Allen]

On Wed, 12 Sep 2007 18:48:25 +0000 (UTC)
Eric Mitchell <eric.mitchell at wellsfargo.com> wrote:

> > 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). 

Hi Eric,

Find out which server hosts the DFS root and try to list it's shares
directly (e.g. ListFiles on smb://server100.our.domain.name.corp/).

> 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.

I agree. It should work. Maybe there's still another DFS MO that I
haven't seen yet (e.g. clients are getting info using LDAP).

Mike

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/