[jcifs] JCIFS and DFS

[Brent Lowe]

To follow-up on this thread for future readers, I figured out what my problem was, it boiled down to the domain I was using for JCIFS.  In AD you can setup an alias for a domain to use for pre Windows 2000 clients.  I had used this as my domain for JCIFS and would get the Network Name Not Found error.  Simply changing it over to the proper/official domain name, seems to have taken care of the problem and both the Get and GetDfsPath examples work as expected.  Why I used the pre-Windows 2000 client alias?  Just what we always have used around here and it bit me.

Thanks for the assistance.  If this sounds odd or just off in general, I'd love to hear your thoughts.
Brent

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

On Mon, Apr 4, 2011 at 5:00 PM, Brent Lowe <brent.lowe at strsoftware.com> wrote:
> Thanks again for the reply and your patience.
>
> Understood regarding the DNS servers, I agree with you that they shouldn't come into play with DFS.  The thing I'm running into however is that they seem to matter in my case.  Without them being setup as Namespace Servers there are no referrals in the logs to the actual file.  It essentially just stops with a 'Network name cannot be found'.  With them being setup as Namespace servers I can see in the log created by JCIFS the referrals happening to go find the actual file.  That's what has me stumped, based on your explanation I do not see why they matter.
>
> Any thoughts on how one would go about troubleshooting this?  I know my DFS instance is not setup optimally, but it does work on the Windows side.
>
> Regarding the GetDfsPath issue, here is some more information.  In the case of the DNS servers being setup up as Namespace servers (i.e. Get.java works), GetDfsPath returns 'null' to STDOUT.  In the case where the DNS servers are not setup as Namespace servers (i.e. Get.java does not work) I get a 'The Network name cannot be found' exception.

I don't know what the problem is Brent. I would have to study packet
captures of your issue but to be brutally honest I just don't feel
like doing that unless it's clearly a bug in JCIFS. OSS is great if
you're willing to do a lot of exploration and testing yourself but
unfortunately you've wandered into one of the more complicated areas
of the CIFS protocol. I somewhat doubt that you're going to be able to
do provide information via email that will allow me to make a
definitive diagnosis.

Mike

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


> -----Original Message-----
> From: Michael B Allen [mailto:ioplex at gmail.com]
> Sent: Sunday, April 03, 2011 10:11 PM
> To: Brent Lowe
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] JCIFS and DFS
>
> 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:
>>
>>
>>
>> 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?
>
> 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
>> 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
>
> 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/
>>
>