Inconsistent connection to same smbfile

[GeraintDuck]

Hi,

I'm seeing some odd behaviour on our fileshares - sometimes .exists() would return true and other times false. In one case I could connect to the parent but connecting directly to any of the subfolders directly would return false (however connecting to the parent and iterating to the children would work correctly).

I've eventually narrowed it down to this small example showing the inconsistency I'm seeing - it seems the initial connection will sometimes work, whereas the connections thereafter all work as expected. I'm unsure what information to give you to help dig into this - let me know and I'll see what I can do to help diagnose it.

import java.util.Properties;

import jcifs.CIFSContext;
import jcifs.config.PropertyConfiguration;
import jcifs.context.BaseContext;
import jcifs.smb.NtlmPasswordAuthenticator;
import jcifs.smb.SmbFile;

public class SmbTest {
    
    private static String domain = "<omitted>";
    private static String username = "<omitted>";
    private static String password = "<omitted>";

    public static void main(String[] args) {
        SmbFile dir1 = null;
        SmbFile dir2 = null;
        try {
            
            String path = "smb://SERVER/GROUP/PS/test/";            
            System.err.println(path);
            
            Properties p = new Properties();
            p.putAll(System.getProperties());
            NtlmPasswordAuthenticator auth = new NtlmPasswordAuthenticator(domain, username, password);      
            CIFSContext cifsContext = new BaseContext(new PropertyConfiguration(p)).withCredentials(auth);          
            
            dir1 = new SmbFile(path, cifsContext);         
            System.err.println(dir1.exists());
            
            dir2 = new SmbFile(path, cifsContext);          
            System.err.println(dir2.exists());
            

        } catch (Exception e) {
            e.printStackTrace();
            System.exit(1);
        }

    }

}

Giving this console output:

smb://SERVER/GROUP/PS/test/
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
false
true

Notice that the first .exists() returns false whereas the second returns true, for the same path.

Changing String path = "smb://SERVER/GROUP/PS/test/"; to String path = "smb://SERVER/GROUP/PS/"; however, returns true for both .exists() calls.

Kind regards,
Geraint

[GeraintDuck]

Oddly the key seems to be the dir1.exists() call - if that line's commented out you get false for the other print statement. Equally changing the first to System.err.println("anything else"); also still gets you false for the other .exists() call.

[mbechler]

My best guess would be that the bug is DFS related, this should be the only case where client state can result in different requests being made. Unfortunately these are quite a pain to figure out.

A jcifs.smb.DfsImpl DEBUG or TRACE level log would be great (if you redact them, try to replace server names etc. with something of the same length, as that might matter), if you provide a DEBUG level log for all jcifs - even better. If you are able to figure out how the DFS links are set up in that domain, that would be quite helpful, too. If possible, a packet capture of the resulting SMB traffic might also be helpful.

[GeraintDuck]

Thanks for the reply, hopefully these will help to get started. I've ran the same program with a DEBUG/TRACE level enabled, with my code slightly edited to:

	        dir1 = new SmbFile(path, cifsContext);  
	        log.debug("Initalized 1st SmbFile, now running dir1.exists()...");
	        log.warn("dir1.exists() returned: " + dir1.exists());
	        
	        dir2 = new SmbFile(path, cifsContext);     
	        log.debug("Initalized 2nd SmbFile, now running dir2.exists()...");
	        log.warn("dir2.exists() returned: " + dir2.exists());

debug.log
trace.log

[mbechler]

The issue looks to be that the first open request is directed to xxxxfc01vfil01 while the correct target server from the DFS referral would be NTNX-xxxxFC01VFIL01-3.EAME.xxxxxxxx.ORG. This only happens in the first request, once the data is cached, the correct server is used the request.

I believe the culprit is
https://github.com/AgNO3/jcifs-ng/blob/4d45352b1fca9430b9799fbd59f2c667cec2d945/src/main/java/jcifs/smb/SmbTreeConnection.java#LL751C17-L751C17 as in your case the share name is the same, but the servers are different - which is not detected and therefore the connection is not adjusted.

Will need to include a more complex DFS setup in my test environment to properly reproduce and address that.

[GeraintDuck]

Thanks for looking into it. Let me know if there's something I can do to help on my end e.g. testing.

[mbechler]

If you have an opportunity to inquire about the detailed setup of the relevant DFS links, that might be helpful, as unfortunately my first attempts to provoke that situation in my test environment were unsucessful.

[GeraintDuck]

I've got a little more information around our set-up.

Apparently xxxxFC01VFIL01.EAME.xxxxxxxx.ORG is a dfs path but with 3 different dedicated ips for redundancy, routed via a load balancer (and I think hence the -3 on the address you mentioned previously).

They were all migrated to Nutanix paths earlier this year (I assume hence the NTNX- address prefix), and that feels related since I didn't see this issue last year.

If you have other specific questions I can try and follow up but I'm afraid this is somewhat stretching my knowledge of DFS/networking architecture!