[jcifs] Workgroup confusion?

Michael B Allen ioplex at gmail.com
Fri Jul 22 12:26:34 MDT 2011

On Fri, Jul 22, 2011 at 1:46 PM, Gert van Spijker <gert at ab-graph.com> wrote:
> I have developed a jcifs based configuration utility for our software
> stack that scans the network for available shares and then checks if
> certain folders and files exist.
> I am testing this on my home network which consists of 3 linux/samba
> servers and 4 wxp/w7 workstations divided in 2 workgroups. My scanner
> finds both workgroups and all servers on the network but when I try to
> query the servers for their shares I get a jcifs.smb.SmbException thrown
> on *some* of them.
> To make debugging simpler I tried to query the shares in the
> examples/ListFiles program, and the same happens:
> I debug ListFiles.java from SERVER1 with a command line argument of:
> //smb/SERVER2/
> I get the following stack trace:
> jcifs.smb.SmbException: Failed to connect: SERVER2<20>/
> jcifs.util.transport.TransportException
> java.io.IOException: host unreachable
>        at jcifs.smb.SmbTransport.setupSocket(SmbTransport.java:307)
>        at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:266)
>        at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:338)
>        at jcifs.util.transport.Transport.run(Transport.java:235)
>        at java.lang.Thread.run(Thread.java:619)
>        at jcifs.util.transport.Transport.run(Transport.java:251)
>        at java.lang.Thread.run(Thread.java:619)
>        at jcifs.smb.SmbTransport.connect(SmbTransport.java:327)
>        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
>        at jcifs.smb.SmbFile.doConnect(SmbFile.java:906)
>        at jcifs.smb.SmbFile.doShareEnum(SmbFile.java:1778)
>        at jcifs.smb.SmbFile.doEnum(SmbFile.java:1727)
>        at jcifs.smb.SmbFile.listFiles(SmbFile.java:1706)
>        at jcifs.smb.SmbFile.listFiles(SmbFile.java:1639)
>        at ListFiles.main(ListFiles.java:17)
> When I log the related network packets I see that the DNS packet going
> out queries a name server2.WORKGROUP2. It gets a "No such name" DNS
> response from my router, which is correct because SERVER2 is a member of
> When stepping into:
>     java.net.InetAddress.isReachable(SO_TIMEOUT)
> I see that Java is calling native code here, so this native code (I am
> developing and testing on Ubuntu 11.04 Linux) is apparently responsible
> for querying the name with the wrong workgroup suffix. As I mentioned
> before, other addresses are handled correctly.
> And when I remove (out comment) the call to isReachable() then
> everything works as expected! This call seems almost redundant to me
> anyway. Why not just try to send the request and let it time out if the
> server is not reachable?
> The source of this problem is obviously not a bug in jcifs but I wonder
> if I am the only one who has seen this happen.
> I also invite suggestions as how to avoid this issue other than
> modifying the jcifs source code (which is my current solution).
> Anyone?

Hi Gert,

This is most likely a name service issue. You are trying to use a
NetBIOS name without a NetBIOS name server (aka WINS). The NetBIOS
implementation in JCIFS can broadcast a name lookup on the local
network but I believe this is disabled by default (see the
jcifs.resolveOrder property and the BCAST value) and note that these
broadcast requests cannot reach beyond the local subnet. So if you are
not using BCAST and you do not have WINS configured, you will have
inconsistent results. JCIFS is falling back to trying DNS but of
course DNS does not resolve NetBIOS names (although if the NetBIOS
name matches the first label of the FQDN hostname and the DNS server
uses a DNS search suffix it will work and more often than not it does

In general, querying the NetBIOS browse service for servers and then
using those NetBIOS hostnames to connect to servers is not going to
work reliably because NetBIOS is deprecated (WINS has been disabled by
default in Windows Server for a long time - ever since AD was
introduced I think).


Michael B Allen
Java Active Directory Integration

More information about the jCIFS mailing list