[jcifs] JCIFS and DFS

[Brent Lowe]

Thank you for the response, I really appreciate it.  You are correct in that replication is not setup on my system.  I thought that I was getting around that by setting up a namespace server for each of the servers that company.com resolves to.  I will definitely look into this though.  Some further questions: 



Based on your feedback:
>>A DFS referral for "company.com" will return servers that are
>>responsible for handling referrals for domain-based DFS in the domain.

>>A DFS referral to one of those servers for a DFS root will return
>>servers and paths that makeup the DFS filesystem.


In my case the DFS share is setup on server3.  Server1 and server2 are returned when doing a nslookup/dig on the Linux side.  Based on my interpretation of the above (again, not too experienced here), I would expect that either server1 or server2 should refer the application to server3 to get to the data, is this true?   

If so, this does not appear to be happening.  The only way I can access the files is if I make both server1 and server2 "Namespace Servers", which in a sense acts similar to replication in that they have a view of the directory structure, much like server3.  I would expect that if I replicated the files to server1 and server2 it would have the same affect.

So is it true that whatever servers are returned by nslookup/dig must have direct access to the files?  i.e. in Windows be able to physically go to \\server1\dfs and actually get there?

Also, are there any known issues with the GetDfsPath example?  It seems to return 'null' regardless of what is fed in and the log returns 'The System cannot find the file specified', even with the same path that works with a call to Get.java.  i.e.

java -djcifs.properties=x.prop GetDfsPath smb://company.com/dfs/Devpc/test.txt - returns null and exception in log
also tried with:
java -djcifs.properties=x.prop GetDfsPath smb://company.com/dfs/Devpc
java -djcifs.properties=x.prop Get smb://company.com/dfs/Devpc/test.txt - Will download the file

x.prop simply has domain/user/pass properties.  Using version 1.3.15

Again, thanks for your time.
Brent


-----Original Message-----
From: Michael B Allen [mailto:ioplex at gmail.com] 
Sent: Thursday, March 31, 2011 8:04 PM
To: Brent Lowe
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] JCIFS and DFS

On Wed, Mar 30, 2011 at 4:55 PM, Brent Lowe <brent.lowe at strsoftware.com> wrote:
> A long winded question(s) on DFS and JCIFS.  Essentially, I am looking to
> understand how JCIFS works in a Domain-based DFS system.  I am new to both
> JCIFS and DFS, so please excuse my ignorance if I completely miss the boat.
>
>
>
> Setup:
>
>
>
> Domain:  company.com
>
> DNS servers that resolve to company.com when doing a nslookup on the Linux
> side of the house:
>
>                 server1
>
>                 server2
>
> DFS Namespace server: Server3
>
> DFS Root: \\company.com\dfs
>
> File I would like to retrieve via JCIFS: \\company.com\dfs\test\test.txt
>
>
>
> In Windows:
>
> Going to \\company.com\dfs\test.txt results in the file being accessible.
>
> Going to \\server1\dfs\test.txt results in the file NOT being accessible
>
> Going to \\server2\dfs\test.txt results in the file NOT being accessible
>
> Going to \\server3\dfs\test.txt results in the file being accessible

Hi Brent,

If you use domain based DFS, you're really only supposed to access it
through the domain name. So technicallly I don't think it is an error
that the file is not accessible through the specific file server. But
I also think that it is unusual that it is not accessible. Usually in
this scenario there is a file replication service that makes sure all
servers have the same files. With your setup, it appears that you do
not have replication setup or it's broken.

>
> Utilizing JCIFS to retrieve this file with the example Get.java, is the
> following (loosely) true?   I say loosely because I'm sure there is plenty
> more going behind the scenes, I'm just generalizing.
>
>
>
> JCIFS will resolve strsoftware.com and determine that it's made up of
> server1 and server2.

A DFS referral for "company.com" will return servers that are
responsible for handling referrals for domain-based DFS in the domain.

A DFS referral to one of those servers for a DFS root will return
servers and paths that makeup the DFS filesystem.

> JCIFS will try to retrieve the file from server1 and fail, return Network
> name not found exception because the file is truly not accessible on that
> server because it is not a namespace server.

Not really. JCIFS will retry if it cannot contact the target server or
if an exception occurs trying to access the share. But otherwise, if
the file is actually not there, JCIFS will not retry another server.

> JCIFS will try to retrieve the file from server2 and fail, return Network
> name not found exception because the file is truly not accessible on that
> server because it is not a namespace server.
>
>
>
> Setup 2:
>
> Domain:  company.com
>
> DNS servers that resolve to company.com when doing a nslookup on the Linux
> side of the house:
>
>                 server1
>
>                 server2
>
> DFS Namespace server: Server3 AND Server2
>
> DFS Root: \\company.com\dfs
>
> File I would like to retrieve via JCIFS: \\company.com\dfs\test\test.txt
>
>
>
> In Windows:
>
> Going to \\company.com\dfs\test.txt results in the file being accessible.
>
> Going to \\server1\dfs\test.txt results in the file NOT being accessible
>
> Going to \\server2\dfs\test.txt results in the file being accessible
>
> Going to \\server3\dfs\test.txt results in the file being accessible
>
>
>
> Utilizing JCIFS to retrieve this file with the example Get.java, is the
> following (loosely) true?  I say loosely because I'm sure there is plenty
> more going behind the scenes, I'm just generalizing.
>
>
>
> JCIFS will resolve strsoftware.com and determine that it's made up of
> server1 and server2.
>
> JCIFS will try to retrieve the file from Server1 and fail, return Network
> name not found exception because the file is truly not accessible on that
> server because it is not a namespace server.
>
> JCIFS will try to retrieve the file from Server2 and succeed because the
> file is truly accessible from the server as it is a namespace server.
>
>
>
>
>
> The above examples have been my experience and I just want to make sure that
> I'm not missing something.  In the end, for a file to be accessible in this
> situation, at least one of the hosts that are resolved via nslookup or dig
> must be a namespace server.  Correct?

Not sure. If by "namespace server" you mean a server that is returned
in a referral for some DFS point, then JCIFS should try to locate the
file there. But if it's not actually there, JCIFS will not failover
and try the next one in the list. It will just fail to find the file.
It would be nice if it did. But currently I don't think it does. And
again, technically I think all targets should have the same files. I
don't think it's acceptable practice to use DFS to overlay parts of
filesystems into the same namespace. At the very least that would be
rather inefficient and worse it could easily yield inconsistent
results. Without file replication you could have two files with the
same path that actually contained totally different content. That
could lead to some bazaar failures in applications.

Mike

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