[jcifs] Re: Exception when connecting to DFS share

[Eric Mitchell]

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

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


Hi Mike, I have some interesting results...

The DFS Root connection works to 
smb://fileservername.our.domain.corp/dfs_rootname/
And it is also retrieving the referrals correctly with this method.. for 
example: smb://fileservername.our.domain.corp/dfs_rootname/testdir1/ 
successfully retrieves a file list where /testdir1 resides on 
smb://filserver2.our.domain.corp/testdir1/. However the dfs_root namespace is 
a domain based DFS namespace - and by using fileserver1.our.domain.corp - I 
would be loosing redundancy if fileserver1 is lost.

>From my understanding, a domain based dfs has its namespace metadata stored in 
the active directory, and all of the domain controllers retrieve this metadata 
(via an AD lookup) and cache it to pass to client requests (when requesting 
smb://our.domain.corp/dfs_rootname/ for example)

I could be wrong, but I don't think (and I hope there isn't) any ldap query 
expected between the client and the domain controllers. 

When the jcifs client calls on smb:/our.domain.corp/dfs_root/ it is expecting 
to receive a list of all domain controllers, then queries (via RPC$ perhaps?) 
the domain controllers for the /dfs_root referrals.  Any ldap dependencies 
should only be between the DC's and the dfs_namespace stored in active 
directory - no?

So right now I know that going to a fully qualified servername/dfs_root I do 
get the referals to other servers that are sharing within the same dfs 
namespace. But when going to the fully qualified domain name/dfs_root - I am 
getting connections to a large list of domain controllers, but not 
successfully proceeding beyond that point. Is this due to a difference in the 
referal information the client recieves between these two methods 
(server1.our.domain.corp vs our.domain.corp)? 

Eric