# [jcifs] JCIFS and DFS

Michael B Allen ioplex at gmail.com
Sun Apr 3 20:10:28 MDT 2011

On Fri, Apr 1, 2011 at 2:57 PM, Brent Lowe <brent.lowe at strsoftware.com> wrote:
> 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:
>
>
>
>>>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?

Hi Brent,

First of all, DFS is actually pretty complicated. It's a whole other
sub-protocol of CIFS. I'm not prepared to describe every detail of it
here mostly because I would have to go digging around in the code to
verify those details.

Second, DFS and DNS have no relation at all. So your observation that
server1 and server2 are in DNS has no bearing on DFS.

In general, when a DFS client resolves a name like
\\busicorp.local\path\to\file.txt it sends a DFS referral to a DC of
busicorp.local which returns servers that handle DFS. Then it sends a
DFS referral to one of those servers for "\\busicorp.local\path" which
returns a list of servers that handle that DFS point.. Then it does
another referral to that server with the server and path which should
reutrn the real server and path which ultimately might be something
like "\\fs1.busicorp.local\fdrive\data\to\file.txt". There might be an
additional referral in there somewhere. I would have to study a
capture of the whole thing to recall clearly. But the point is that
everything is done using referrals between the DC, servers that handle
DFS and servers that host DFS volumes. DNS is only used to resolve
hostnames like any network client would.

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

Again, DNS doesn't figure into it. But if a referral returns a server
and path that doesn't actually host the directory being advertised you
are going to experience strange behavior. Windows is more robust than
JCIFS in this situation but that mostly masks configuration /
infrastructure issues (although now that I think about it, technically
JCIFS should retry other servers if a file is not found to account for
the scenario where the file replication service is in the process of
or not yet started copying files).

My guess is that you probably have compound issues. DFS is not
something that you just turn on and then it just works. You actually
have to have a decent understanding namespaces, topology, the FRS, etc
to get it all working optimally. But I don't actually use it myself so
I cannot direct you further about how to setup DFS.

> 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
>
> x.prop simply has domain/user/pass properties.  Using version 1.3.15

That could be a bug. The getDfsPath method should return the real path
for the supplied DFS path. But given that we know your DFS environment
is not optimal it's hard to say.

Mike

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

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