Hi,

I am trying to migrate an existing program from original jcifs to jcifs-ng (repo snap shot from june 30th).
However i cannot make jcifs-ng to work with DFS links:

prop.put("jcifs.resolveOrder", "DNS");		
prop.put( "jcifs.netbios.wins", "xxx.xxx.xxx.xxx" );
prop.put( "jcifs.smb.client.enableSMB2", "true" );
prop.put( "jcifs.smb.client.disableSMB1", "false" );
prop.put( "jcifs.traceResources", "true" );
		
CIFSContext baseContext = new BaseContext(new PropertyConfiguration(prop));
		
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(baseContext, "myDomain", "myUser", "myPassord");		

CIFSContext ctx = baseContext.withCredentials(auth);`

SmbFile file = new SmbFile("smb://myServer/myPath/", ctx);
					
SmbFile[] files = file.listFiles();

Program fails on listFiles with following Exception:

main] WARN jcifs.smb.SmbTreeConnection - Referral failed, trying next
jcifs.smb.SmbException: Signature validation failed
at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:646)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:463)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:588)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:542)
at jcifs.smb.SmbTreeConnection.resolveDfs0(SmbTreeConnection.java:715)
at jcifs.smb.SmbTreeConnection.ensureDFSResolved(SmbTreeConnection.java:629)
at jcifs.smb.SmbTreeConnection.ensureDFSResolved(SmbTreeConnection.java:619)
at jcifs.smb.SmbTreeHandleImpl.ensureDFSResolved(SmbTreeHandleImpl.java:69)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:612)
at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:193)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:240)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1245)
at fr.gouban.dev.test.TestCIFS.main(TestCIFS.java:97)
Exception in thread "main" jcifs.smb.SmbException: All referral tree connections failed
at jcifs.smb.SmbException.wrap(SmbException.java:220)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:271)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1245)
at fr.gouban.dev.test.TestCIFS.main(TestCIFS.java:97)
Caused by: jcifs.CIFSException: All referral tree connections failed
at jcifs.smb.SmbTreeConnection.resolveDfs0(SmbTreeConnection.java:726)
at jcifs.smb.SmbTreeConnection.ensureDFSResolved(SmbTreeConnection.java:629)
at jcifs.smb.SmbTreeConnection.ensureDFSResolved(SmbTreeConnection.java:619)
at jcifs.smb.SmbTreeHandleImpl.ensureDFSResolved(SmbTreeHandleImpl.java:69)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:612)
at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:193)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:240)
... 2 more
Caused by: jcifs.smb.SmbException: Signature validation failed
at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:646)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:463)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:588)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:542)
at jcifs.smb.SmbTreeConnection.resolveDfs0(SmbTreeConnection.java:715)
... 8 more

Any help would be appreciated. Program works fine on path that are NOT DFS links.

Thanks

Fab

I have some applications that read and write files from a Hitachi HNAS share with jcifs. Right now, the shares are SMB1 only, but they need to change to SMB2 only, so I'm looking to replace jcifs with jcifs-ng.
I'm using some sample code that just creates an SmbFile and then calls .exists() on it. The url looks (something) like this:
smb://;user:[email protected]/x3vtest03/directory
There's no domain, and jcifs won't authenticate without the semicolon. I've tried with and without the semicolon, but jcifs-ng always throws an exception on the exists() call saying bad user name or password.
If I just create the SmbFile with the one parameter constructor (String url), according to the logs, it was trying to authenticate as GUEST, and that won't work, so I tried setting jcifs.smb.client.domain, username, and password, then:
BaseContext bc = new BaseContext(new PropertyConfiguration(System.getProperties()));
SmbResource sr = bc.get("smb://;:*@10.xx.xx.xx/x3vtest03/test-r/");
if (sr.exists()) // throws
And
NtlmPasswordAuthentication creds = new NtlmPasswordAuthentication(bc, ":+++++");
CIFSContext ct = bc.withCredentials(creds);
SmbFile test1 = new SmbFile("smb://;:[email protected]/x3vtest03/test-r/", ct);b
System.out.println("test1 exists: " + test1.exists()); // throws

But all I get is:
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password.

I'm new to jcifs-ng, and this could all be user error, but I'm running out of ideas.

Thanks

Hi,
I think there is looping with sid.getType() with jcifs.smb.client.enableSMB2=true.
In my test we connect to Windows 2008 R2 server and try to retrieve the type of sid as below

jcifs.internal.dtyp.ACE[] aces = smbFile.getSecurity(false);
String uid = "N/A";
for (ACE ace : aces)
    {
        SID sid = ace.getSID();
	if (sid.getType() == SID.SID_TYPE_USER)
        {
            uid = sid.toString();
            break;
        }
    }

I'm getting forever loop as below:
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getAccountName(SID.java:362)
at TestJCIFS_readfiles.main(TestJCIFS_readfiles.java:124)

The loop:
at jcifs.smb.SID.getType(SID.java:334)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:80)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:108)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SID.resolveWeak(SID.java:487)
at jcifs.smb.SID.getType(SID.java:334)

Could you check in jcifs.smb.SIDCacheImpl.resolveSids,
switch ( s.getType() ) { <---- should this be 'switch ( s.type ) {'

            switch ( s.getType() ) {                        
            case jcifs.SID.SID_TYPE_USER:
            case jcifs.SID.SID_TYPE_DOM_GRP:
            case jcifs.SID.SID_TYPE_DOMAIN:
            case jcifs.SID.SID_TYPE_ALIAS:
            case jcifs.SID.SID_TYPE_WKN_GRP:
                int sid_index = rpc.names.names[ si ].sid_index;
                rpc.unicode_string ustr = rpc.domains.domains[ sid_index ].name;
                s.domainName = ( new UnicodeString(ustr, false) ).toString();
                break;
            }

Thanks in advance.
Thanh

I'm getting an out of memory (the max heap size is 512MB, but also happens if the heap size is 1GB).

I see in the heap dump that 99% of the memory is held by the response_map concurrent hash map in Transport.java. Both SmbTransportImpl.java and Transport.java use the response_map.

In Transport.java, the response_map is populated like this,

this.response_map.put(k, curResp);

and items removed like this,

this.response_map.remove(curResp)

Nothing is getting removed because the remove() call should be using the key and not the curResp for the parameter.

In Transport.java, the logic also seems incorrect on the remove(). The responses are added like this,

this.response_map.put(k, resp)

and removed like this,

this.response_map.remove(req)

the key should instead be used in the remove here as well.

Is this a known issue? I wonder why it hadn't been seen before? Does the hashmap tend to grow bigger when doing big files and hence it's the reason it this not always seen?

Or maybe I'm missing something from reading the code?

Thanks.

This issue probably needs a little bit more visibility, which is why I'm opening this ticket. I have a production environment where I have this construct:

new ZipInputStream(new BufferedInputStream(file.getInputStream(), 1000000))

reading files from a share on a Windows server. These files are zip archives containing PDF files, from which I am extracting the TIFF streams and converting them into web formats (png/jpeg) for viewing using a browser UI. The conversion process can run for an hour depending on the size of the file -- up to 1 GB large have been spotted in the wild. However, when reading some zips, but not others, and seemingly without any good reason, I get the following stack trace after a few minutes since starting the read:

jcifs.smb.SmbException: The handle is invalid.
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:762)
at jcifs.smb.SmbTransport.send(SmbTransport.java:896)
at jcifs.smb.SmbSession.send(SmbSession.java:194)
at jcifs.smb.SmbTree.send(SmbTree.java:156)
at jcifs.smb.SmbFile.send0(SmbFile.java:1012)
at jcifs.smb.SmbFile.send(SmbFile.java:974)
at jcifs.smb.SmbFile.send(SmbFile.java:966)
at jcifs.smb.SmbFileInputStream.readDirect(SmbFileInputStream.java:241)
at jcifs.smb.SmbFileInputStream.read(SmbFileInputStream.java:182)

The rest of the stack trace has been elided, as it is not from under jcifs. This reading process can be restarted, but it will trigger again for the same file in a few minutes after making progress worth a few PDFs within that zip each time.

This issue has been reported with the original jcifs too, so I believe it is an issue with the actual codebase. I've not been able to reproduce this issue except on that one system, and being a production environment where customer actually loses money due to this issue, I had to solve it quickly. Because it is a Windows server using a Windows share, I am now using the native file share mapping using a drive letter, where IO appears to work correctly.

Hello. Thank you for all your help so far!

We are facing another issue when we run against a Windows 2008 server that has both SMB1 and SMB2 enabled.

When we run with jcifs.smb.client.enableSMB2=false to test SMB1 we we get a bunch of "handle not properly released" warnings. These warnings happen in SmbTreeHandleImp.java (finalize) as well as in SmbFileHandle.java (finalize) and SmbTreeConnection.java (finalize).

We DO NOT get these warnings if we run with jcifs.smb.client.enableSMB2=true.

I decided to focus on the SmbTreeHandleImpl.java "not properly released" warnings and I debugged thru the jcifs-ng code. This what I found.

1. It seems to happen when calling SmbFile.setOwner(x).

2. With jcifs.smb.client.enableSMB2=false, an SmbFileHandleImpl gets created and the SmbFileHandleImpl constructor increases the SmbTreeHandleImpl usage_cnt by 1.

this.tree = tree.acquire();

This extra acquire() does not seem to ever call a matching release(). Here is the stack trace (the line numbers correspond to my version of SmbTreeHandleImpl.java since I added some warning messages. I've included my version of this file).

Notice how we call SmbFile.openUnshared() and flow down from there until SmbFileHandleImpl() gets created.

siqsmb1.out:[2017-11-27 15:28:35,847] WARN [1553755675@qtp--541248251-0] jcifs.smb.SmbTreeHandleImpl SmbTreeHandleImpl: Acquire SmbTreeHandleImpl smb://9.30.60.45/thanhvn/export-dat-smb2/Export_0483f65b-b36c-4de7-bcfc-a6a7175259b6/1/f490d0027a4745cb92eb9bfb51a3fa8c/documents/1/People(low confidence).doc [tree_connection_id=1214645987, usage_cnt=2], object id = -140456672. Stack trace: [java.lang.Thread.getStackTraceImpl(Native Method), java.lang.Thread.getStackTrace(Thread.java:1117), jcifs.smb.SmbTreeHandleImpl.acquire(SmbTreeHandleImpl.java:181), jcifs.smb.SmbFileHandleImpl.(SmbFileHandleImpl.java:119), jcifs.smb.SmbFile.openUnshared(SmbFile.java:755), jcifs.smb.SmbFile.openUnshared(SmbFile.java:710), jcifs.smb.SmbFile.setOwner(SmbFile.java:2506), storediq.siqcifs.facade.BaseSmbFacade.setSecurityDescriptor(BaseSmbFacade.java:881), storediq.siqcifs.httpserver.httpcommands.SetSecurityDescriptorCommand.call(SetSecurityDescriptorCommand.java:46)

3. With jcifs.smb.client.enableSMB2=true, the SmbTreeHandleImpl.java call to setOwner() is a little bit different. It never goes into SmbFile.openUnshared(), I assume because it goes into the this.isSMB2() portion of the code below,

public int setOwner(SID owner) throws IOException {
try ( SmbTreeHandleImpl th = ensureTreeConnected() ) {
if ( th.isSMB2() ) {
Smb2SetInfoRequest req = new Smb2SetInfoRequest(this.getContext().getConfig());
req.setInfoType(Smb2Constants.SMB2_0_INFO_SECURITY);
req.setFileInfoClass((byte) 0); // must be set to 0 when setting security info.
req.setAdditionalInformation(SecurityInfo.OWNER_SECURITY_INFO);
Smb2SetInfoResponse resp = withOpen(th, req);
return resp.getErrorCode();
}
}

    int f = openUnshared(O_RDWR | O_EXCL, WRITE_DAC | WRITE_OWNER, 0,  
                SmbConstants.FILE_SHARE_READ | SmbConstants.FILE_SHARE_WRITE, 
                        isDirectory() ? 1 : 0x4000).getFid();

Any help you can provide would be greatly appreciated. If you have any questions please let me know.

Thanks.

SmbTreehandleImpl_modified.zip

Hi,
Before all, thanks for your contribution, It was just what I was looking for!

I clone the master today and I found these errors in the tests compiling the project:

Tests in error:
PACTest.testAES256Checksum:218->verifyAESHMAC:252 » InvalidKey Illegal key siz...
PACTest.testPACAESChecksum:176->verifyAESMAC:229->verifyAESHMAC:252 » InvalidKey

Tests run: 31, Failures: 0, Errors: 2, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.039 s
[INFO] Finished at: 2017-07-14T12:34:30-03:00
[INFO] Final Memory: 32M/467M
[INFO] ------------------------------------------------------------------------

Could I be missing something?

Now skiped them and I trying the lib without any trouble, but I wander if you are planning to release v2 in the short time.

Thanks!

The following fix is missing in your version of jcifs:

http://samba.2283325.n4.nabble.com/Thread-leak-problem-on-connect-timeout-tp2515434p2515435.html

The modification under 3) is missing.

Current dependency on the obsolete log4j 1.x is not optimal since it will not work anymore in java 9.

It would be much better to use a log facade such as slf4j or atleast migrate to log4j2.

I tried to connect to Windows 2008 server with jcifs.smb.client.enableSMB2=true and got jcifs.smb.SmbException: This client is not compatible with the server.
Also tried with the other signing (jcifs.smb.client.signingEnforced, jcifs.smb.client.signingPreferred) properties matching with the settings on the server and got the same error.

From Microsoft, the first release of Windows 2008 supports SMB2 v2.002. I see jcifs-ng states 'SMB2 (2.02 protocol level) support'. Does that mean for Windows 2008, it only works with jcifs.smb.client.enableSMB2=false ? (I tried with SMB1 and it worked).

Thanks,

The relationship between CIFSContext and credentials represented by this idiom seems strange and problematic to me.

ctx.withCredentials(
    new NtlmPasswordAuthentication(
        ctx,
        getTestUserDomain(),
        getTestUser(),
        getTestUserPassword()))

We create credentials that point to a context, but then we create a wrapper for the original context that points back to the credentials. So we can navigate from the wrapper to the credentials, navigate from the credentials to the original context, but from there we can't navigate back to the credentials. It seems like this is bound to cause an issue at some point.

Example from jcifs:

                    jcifs.Config.setProperty( "jcifs.netbios.wins", "192.168.1.220" );
                    NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("domain", "username", "password");
                    SmbFileInputStream in = new SmbFileInputStream("smb://host/c/My Documents/somefile.txt", auth);

None of these have a appropriate constructor and generate 'cannot resolve' errors . Is the jcifs-ng not compatible with the base jcifs-project? If not; where is good documentation with working example? (Connecting to -server, retrieve file, disconnect)

I'm in the process of porting an existing program running find unter jcifs 1.3.14 to jcifs-ng 2.0.5.

The program uses SmbFile.mkdirs() to create a directory before writing into this directory.

When using jcifs-ng with a DFS-Path as the target, I get a NullPointerException:
java.lang.NullPointerException at jcifs.internal.smb1.ServerMessageBlock.writeString(ServerMessageBlock.java:1037) at jcifs.internal.smb1.ServerMessageBlock.writeString(ServerMessageBlock.java:1026) at jcifs.internal.smb1.trans2.Trans2QueryPathInformation.writeParametersWireFormat(Trans2QueryPathInformation.java:72) at jcifs.internal.smb1.trans.SmbComTransaction.nextElement(SmbComTransaction.java:235) at jcifs.smb.SmbTransportImpl.sendComTransaction(SmbTransportImpl.java:1537) at jcifs.smb.SmbTransportImpl.send(SmbTransportImpl.java:1464) at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:397) at jcifs.smb.SmbTreeImpl.send(SmbTreeImpl.java:465) at jcifs.smb.SmbTreeConnection.send0(SmbTreeConnection.java:396) at jcifs.smb.SmbTreeConnection.send(SmbTreeConnection.java:313) at jcifs.smb.SmbTreeConnection.send(SmbTreeConnection.java:294) at jcifs.smb.SmbTreeHandleImpl.send(SmbTreeHandleImpl.java:130) at jcifs.smb.SmbFile.queryPath(SmbFile.java:772) at jcifs.smb.SmbFile.exists(SmbFile.java:825) at jcifs.smb.SmbFile.mkdirs(SmbFile.java:1687) at jcifs.smb.SmbFile.mkdirs(SmbFile.java:1691)

If I specify the file server path (instead of the DFS path), the program runs fine. It also works fine if I downgrade to 1.5.3.

Any ideas what I'm doing wrong?

Regards
Johannes

When registering the URL handler on Android I get that error.

at jcifs.context.SingletonContext.registerSmbURLHandler(SingletonContext.java:125)
at jcifs.Config.registerSmbURLHandler(Config.java:70)

Seems like Android is missing Runtime.class.getPackage().getSpecificationVersion()

Not sure what the right solution is since I don't know what the requirements are for custom url handlers.

We are trying to connect to Windows 2008 R2 server using credentials as 'ed\username' 'passxxxx'
Can you review and provide inputs for these 2 questions:

1. We use credentials as 'ed\username'; however, we see jcifs-ng tied to connect to 'ed' at first?
   [2018-02-22 22:14:30,955] DEBUG [1640446703@qtp--1559202494-2] jcifs.smb.DfsImpl Getting domain controller for ed failed
   java.net.UnknownHostException: ed
   at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:1022) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:53) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:170) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getDcReferrals(DfsImpl.java:189) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getDc(DfsImpl.java:234) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getTrustedDomains(DfsImpl.java:112) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.resolve(DfsImpl.java:348) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.resolve(DfsImpl.java:322) [jcifs-ng-2.0.1-flx.1.jar:?]

2. We got sendrecv timedout.
   We tried to increase the timeout property from 35s to 70s, but still got the timedout at jcifs.util.transport.Transport.waitForResponses after the failure of 'java.net.UnknownHostException: ed'
   Why it waited for the timedout if it already failed with the 'UnknownHostException'. We observed with other case where after the failure of connection to the domain controller 'ed', it tried to connect using the correct credentials 'ed\username' successfully.
   .
   [2018-02-22 22:14:30,955] DEBUG [1640446703@qtp--1559202494-2] jcifs.smb.DfsImpl Getting domain controller for ed failed
   java.net.UnknownHostException: ed
   at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:1022) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:53) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:170) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47) ~[jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getDcReferrals(DfsImpl.java:189) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getDc(DfsImpl.java:234) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.getTrustedDomains(DfsImpl.java:112) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.resolve(DfsImpl.java:348) [jcifs-ng-2.0.1-flx.1.jar:?]
   at jcifs.smb.DfsImpl.resolve(DfsImpl.java:322) [jcifs-ng-2.0.1-flx.1.jar:?]
   ...
   at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) [jetty-util-6.1.26.jar:6.1.26]
   [2018-02-22 22:14:30,956] DEBUG [1640446703@qtp--1559202494-2] jcifs.smb.SmbTreeImpl treeConnect: unc=\192.168.nnn.nn\AUTOSHARED1,service=?????

[2018-02-22 22:15:40,956] DEBUG [1640446703@qtp--1559202494-2] jcifs.util.transport.Transport State is 3
[2018-02-22 22:15:40,957] WARN [1640446703@qtp--1559202494-2] jcifs.util.transport.Transport sendrecv failed
jcifs.util.transport.RequestTimeoutException: Transport1 timedout waiting for response to command=SMB2_TREE_CONNECT,status=0,flags=0x0000,mid=14646,wordCount=0,byteCount=64
at jcifs.util.transport.Transport.waitForResponses(Transport.java:365) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.util.transport.Transport.sendrecv(Transport.java:232) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.sendrecv(SmbTransportImpl.java:973) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.send(SmbTransportImpl.java:1470) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:397) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:605) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:558) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:642) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.getServerTime(SmbFile.java:2488) [jcifs-ng-2.0.1-flx.1.jar:?]
[2018-02-22 22:15:40,958] WARN [1640446703@qtp--1559202494-2] jcifs.smb.SmbTransportImpl Disconnecting transport while still in use Transport1[0.0.0.0<00>/192.168.nnn.nn:445,state=5,signingEnforced=false,usage=6]: [SmbSession[credentials=ed\username,targetHost=192.168.nnn.nn,targetDomain=null,uid=0,connectionState=2,usage=5]]
[2018-02-22 22:15:40,958] DEBUG [1640446703@qtp--1559202494-2] jcifs.smb.SmbTransportImpl Disconnecting transport Transport1[0.0.0.0<00>/192.168.nnn.nn:445,state=5,signingEnforced=false,usage=6]
[2018-02-22 22:15:40,958] DEBUG [1640446703@qtp--1559202494-2] jcifs.smb.SmbSessionImpl Logging off session on Transport1[0.0.0.0<00>/192.168.nnn.nn:445,state=5,signingEnforced=false,usage=7]
[2018-02-22 22:15:40,958] WARN [1640446703@qtp--1559202494-2] jcifs.smb.SmbSessionImpl Logging off session while still in use SmbSession[credentials=ed\username,targetHost=192.168.nnn.nn,targetDomain=null,uid=0,connectionState=3,usage=5]:[SmbTree[share=AUTOSHARE1,service=null,tid=1,inDfs=false,inDomainDfs=false,connectionState=2,usage=0], SmbTree[share=AUTOSHARED1,service=?????,tid=0,inDfs=false,inDomainDfs=false,connectionState=1,usage=1]]

Thanks in advance,

I try to list my folder on path
String path = smb://wawa.local/DFS/Shared/MT4 i Vibank/pdf_files_test/daily/

Properties smbPrt = new Properties();
smbPrt.setProperty( "jcifs.smb.client.domain", WAWA);
smbPrt.setProperty( "jcifs.smb.client.username", him );
smbPrt.setProperty( "jcifs.smb.client.password", 123456 );

after this config i have a code like this:

try ( SmbFile smbFile = new SmbFile( path, new BaseContext( new PropertyConfiguration( smbPrt ) ) ) )
		{
			List<SmbFile> filesList = new ArrayList<SmbFile>( Arrays.asList( smbFile.listFiles( getSmbFileFilter( lDate, isCorrectionFile ) ) ) );
		}
		catch ( Exception e )
		{
			logger.error( e.getMessage(), e );
		}

and then i have an exception:

2018-03-08 12:55:44.938|DEBUG|pool-22-thread-1|DfsImpl.getDcReferrals|Getting domain controller for WAWA failed
java.net.UnknownHostException: WAWA
at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:1025)
at jcifs.netbios.NameServiceClientImpl.getAllByName(NameServiceClientImpl.java:54)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:170)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
at jcifs.smb.DfsImpl.getDcReferrals(DfsImpl.java:189)
at jcifs.smb.DfsImpl.getDc(DfsImpl.java:234)
at jcifs.smb.DfsImpl.getTrustedDomains(DfsImpl.java:112)
at jcifs.smb.DfsImpl.resolve(DfsImpl.java:348)
at jcifs.smb.DfsImpl.resolve(DfsImpl.java:322)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:525)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:219)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1253)
at bos.synchro.executors.TransFiles.getTransFilesMtList(TransFiles.java:860)
at bos.synchro.executors.TransFiles.genTransFilesMtCorrections(TransFiles.java:762)
at bos.synchro.executors.TransFiles.run(TransFiles.java:173)
at bos.synchro.ServerExecutors$RunnableWrapper.run(ServerExecutors.java:201)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:319)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:191)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.lang.Thread.run(Thread.java:795)

I'm accessing a file on Server with no password protection on a path like:

smb://MYSERVER/Public/MyVideo.mkv

When I call SmbFile.getName() on this it returns "PublicMyVideo.mkv", instead of just "MyVideo.mkv"

The problem seems to be in this section of code from SmbResourceLocatorImpl.java, line 150.

                this.unc = "\\";
                if ( this.share != null ) {
                    this.canon = "/" + this.share;
                }
                else {
                    this.canon = "/";
                }

There's no trailing '/' added to 'this.canon' when this.share != null.

This then causes a problem later here where that value is returned from context.getURLPath() and joined with 'name' without any separator being placed in between.

            if ( uncPath.equals("\\") ) {
                // context share != null, so the remainder is path
                this.unc = '\\' + name.replace('/', '\\') + ( trailingSlash ? "\\" : "" );
                this.canon = context.getURLPath() + name + ( trailingSlash ? "/" : "" );
                this.share = shr;
            }
            else {

This results in this.canon = "/PublicMyVideo.mkv"

Then when I call SmbFile.getName(), it scans back for a path separator, which is of course missing and returns the combined Path & name as "PublicMyVideo.mkv"

As mentioned in #20 server enumeration is broken:

• enumeration tries to connect with an empty hostname, previously this seems to have been magically resolved to the master browser
• the relevant code lacks a SMB2 implementation

The domain/workgroup enumeration through smb://NAME is affected by the second issue as well but generally does not work if the name can be resolved through DNS (then there is no indication that it is a workgroup name and will be treated as a server). Not sure whether to fix it (try netbios first for these cases), drop it or just leave it with that gotcha.

Got this error:
java.lang.NoClassDefFoundError: jcifs/CIFSContext
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: jcifs.CIFSContext
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main"

Any ideas what is the cause?

Hi @mbechler / @matthiasblaesing,
I am getting the above error while transferring the file through SMB2.

Below is my current setup:
Jar version:
latest version jcifs-ng-2.0.5

environment properties:
wrapper.java.additional.7=-Djcifs.smb.client.signingPreferred=true
wrapper.java.additional.8=-Djcifs.smb.client.signingEnforced=true
wrapper.java.additional.9=-Djcifs.smb.client.ipcSigningEnforced=true
wrapper.java.additional.10=-Djcifs.smb.client.enableSMB2=true
wrapper.java.additional.11=-Djcifs.smb.client.disableSMB1=true

Log/error details:
ERROR jcifs.internal.smb2.Smb2SigningDigest - The server did not sign a message we expected to be signed
INFO | jvm 1 | 2018/03/07 23:14:38 | 2018-03-07 23:14:38,725 [.Export.0] ERROR com.seccas.task.CreateCollectionFile - Errored CreateCollectionFile task: ClientID=38, SupervisorID=1580021, CollectionID=281229, FileName='testcollex'
INFO | jvm 1 | 2018/03/07 23:14:38 | jcifs.smb.SmbException: Signature validation failed
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:646)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:463)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
INFO | jvm 1 | 2018/03/07 23:14:38 | at jcifs.smb.SmbFile.exists(SmbFile.java:821)
INFO | jvm 1 | 2018/03/07 23:14:38 | at com.seccas.task.CreateCollectionFile.copyCollectionMessages(CreateCollectionFile.java:770)
INFO | jvm 1 | 2018/03/07 23:14:38 | at com.seccas.task.CreateCollectionFile.futureTaskRun(CreateCollectionFile.java:127)
INFO | jvm 1 | 2018/03/07 23:14:38 | at com.seccas.util.SeccasTaskThread.run(SeccasTaskThread.java:46)
INFO | jvm 1 | 2018/03/07 23:14:39 | 2018-03-07 23:14:39,179 [..Export.0] ERROR com.seccas.util.SeccasTaskThread - Error running task
INFO | jvm 1 | 2018/03/07 23:14:39 | jcifs.smb.SmbException: Signature validation failed
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:646)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:463)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
INFO | jvm 1 | 2018/03/07 23:14:39 | at jcifs.smb.SmbFile.exists(SmbFile.java:821)
INFO | jvm 1 | 2018/03/07 23:14:39 | at com.seccas.task.CreateCollectionFile.copyCollectionMessages(CreateCollectionFile.java:770)
INFO | jvm 1 | 2018/03/07 23:14:39 | at com.seccas.task.CreateCollectionFile.futureTaskRun(CreateCollectionFile.java:127)
INFO | jvm 1 | 2018/03/07 23:14:39 | at com.seccas.util.SeccasTaskThread.run(SeccasTaskThread.java:46)
DEBUG | wrapperp | 2018/03/07 23:14:40 | Send a packet PING : ping fffffe35
INFO | jvm 1 | 2018/03/07 23:14:40 | WrapperManager Debug: Received a packet PING : ping fffffe35
INFO | jvm 1 | 2018/03/07 23:14:40 | WrapperManager Debug: Send a packet PING : ping fffffe35
DEBUG | wrapperp | 2018/03/07 23:14:40 | read a packet PING : ping fffffe35

Any idea on this? may I missed any settings?

SMB2 Sessions (at least ones using kerberos authentication) can expire, further requests will then fail with STATUS_NETWORK_SESSION_EXPIRED. That should be correctly handled and the session reestablished if possible so that inflight operations do not fail and descriptors stay valid.

I put out another beta with the latest master branch as of last weekend and got this report over crashlytics. No idea how to reproduce it.

Caused by java.lang.ClassCastException: jcifs.smb.NtlmPasswordAuthenticator cannot be cast to jcifs.smb.NtlmPasswordAuthentication
       at jcifs.smb.NtlmPasswordAuthentication.equals(NtlmPasswordAuthentication.java:169)
       at java.util.Objects.equals(Objects.java:59)
       at jcifs.smb.SmbSessionImpl.matches(SmbSessionImpl.java:335)
       at jcifs.smb.SmbTransportImpl.getSmbSession(SmbTransportImpl.java:363)
       at jcifs.smb.SmbTransportImpl.getSmbSession(SmbTransportImpl.java:333)
       at jcifs.smb.SmbTransportImpl.getSmbSession(SmbTransportImpl.java:104)
       at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:615)
       at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
       at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
       at jcifs.smb.SmbEnumerationUtil.doShareEnum(SmbEnumerationUtil.java:143)
       at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:216)
       at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
       at jcifs.smb.SmbFile.listFiles(SmbFile.java:1182)

Hi, just started using jcifs-ng, great to see this being actively developed as the original did have quite a few issues.

I've hit a problem with isDirectory() throwing "jcifs.smb.SmbException: The network name cannot be found" when I call it on a SmbFile for a server retrieved like this:

        SmbFile smbFolder = new SmbFile("smb://WORKGROUP", cifsContext);
        SmbFile[] smbFiles = smbFolder.listFiles();
        smbFiles[0].isDirectory();

However if I create a copy of the SmbFile like this it works okay.

        SmbFile smbFolder = new SmbFile("smb://WORKGROUP", cifsContext);
        SmbFile[] smbFiles = smbFolder.listFiles();
        SmbFile clone = new SmbFile(smbFiles[0].getPath(), cifsContext);
        clone.isDirectory();

This is running on Android with a snapshot of code grabbed on 4th Feb, the CIFSContext has "jcifs.smb.client.enableSMB2" set to "false" as the listFiles() call failed otherwise.

We are running jcifs-ng from Windows 7 to Windows 2008 server R2. We got the below exception with error 'Enumeration failed'. We tried to narrow it down to the case when listing files of a folder has more than 197 files.

The problem happens with both case jcifs.smb.client.enableSMB2=true and jcifs.smb.client.enableSMB2=false

The stack trace from calling SmbEnumerationUtil.listFiles() is:

2017-11-25 23:33:55 DEBUG SmbTransportImpl:? - Error code: 0xC0000008 for Trans2FindNext2
2017-11-25 23:33:55 DEBUG SmbTreeConnection:? - Not retrying
jcifs.smb.SmbException: The handle is invalid.
at jcifs.smb.SmbTransportImpl.checkStatus(Unknown Source)
at jcifs.smb.SmbTransportImpl.sendComTransaction(Unknown Source)
at jcifs.smb.SmbTransportImpl.send(Unknown Source)
at jcifs.smb.SmbSessionImpl.send(Unknown Source)
at jcifs.smb.SmbTreeImpl.send(Unknown Source)
at jcifs.smb.SmbTreeConnection.send0(Unknown Source)
at jcifs.smb.SmbTreeConnection.send(Unknown Source)
at jcifs.smb.SmbTreeConnection.send(Unknown Source)
at jcifs.smb.SmbTreeHandleImpl.send(Unknown Source)
at jcifs.smb.DirFileEntryEnumIterator1.fetchMore(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.advance(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.next(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.next(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.advance(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.SmbEnumerationUtil.listFiles(Unknown Source)
at jcifs.smb.SmbFile.listFiles(Unknown Source)
at TestJCIFS_readdir.main(TestJCIFS_readdir.java:29)
2017-11-25 23:33:55 WARN DirFileEntryEnumIteratorBase:? - Enumeration failed
jcifs.smb.SmbException: The handle is invalid.
at jcifs.smb.SmbTransportImpl.checkStatus(Unknown Source)
at jcifs.smb.SmbTransportImpl.sendComTransaction(Unknown Source)
at jcifs.smb.SmbTransportImpl.send(Unknown Source)
at jcifs.smb.SmbSessionImpl.send(Unknown Source)
at jcifs.smb.SmbTreeImpl.send(Unknown Source)
at jcifs.smb.SmbTreeConnection.send0(Unknown Source)
at jcifs.smb.SmbTreeConnection.send(Unknown Source)
at jcifs.smb.SmbTreeConnection.send(Unknown Source)
at jcifs.smb.SmbTreeHandleImpl.send(Unknown Source)
at jcifs.smb.DirFileEntryEnumIterator1.fetchMore(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.advance(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.next(Unknown Source)
at jcifs.smb.DirFileEntryEnumIteratorBase.next(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.advance(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.SmbEnumerationUtil.listFiles(Unknown Source)
at jcifs.smb.SmbFile.listFiles(Unknown Source)
at TestJCIFS_readdir.main(TestJCIFS_readdir.java:29)
folder gstorey_000.pst/ count:198
2017-11-25 23:33:55 DEBUG SmbTransportPoolImpl:? - Closing pool
2017-11-25 23:33:55 DEBUG SmbTransportPoolImpl:? - Closing pool

We collected two tracedumps:
jcifs-ng_197files.cab where there is NO problem
jcifs-ng_198files.cab where the problem happens.

Any ideas or suggestions would be greatly appreciated.

Thanks,

It seems that jcifs-ng does not work on Android. I see exceptions like this:
java.lang.ClassNotFoundException: org.ietf.jgss.Oid
That is because Oid class does not seem to be a part of Android jre.
Legacy jcifs is working fine on Android, btw.
Is there a way to make jcifs-ng more portable, or include Oid-related classes into Android lib?

Good morning! It's me again.

I have a question about SMB2 performance for the SMbRandomAccessFile.write() API. We have noticed that the performance is about twice compared to using the "old" SMB1 jcifs-1.3.18-flx.1.jar library. The performance seems to "improve somewhat" when writing larger number of bytes.

For example, when writing a few bytes (eg. 1, 2 or < 13 bytes), the SMB2 write() takes on average 4-5 ms, whereas the jcifs-1.3.18 library takes ~2ms. I'm thinking that there is some "overhead" that is being paid in the SMB2 write() (or transport) code which 'shows more' when writing a small number of bytes.

I haven't added debug timing statements to the write() call stack yet to determine where that overhead may be coming from. I wanted to ask you if you had an idea or orient me on that part of the code to look.

When writing larger number of bytes at a time, the performance tends to improve, but I assume it's because 'this overhead' becomes a smaller piece of the overall write() time.

Any ideas or suggestions that would help me know which part of the code I should investigate, will be greatly appreciated.

Thanks in advance,

Justo

PS. We've also noticed that other APIs such as file open/create/mkdir also run 1-3 ms slower compared to their jcifs-1.3.18 counterparts.

Hi,

I'm using jcifs-ng version 2.0.5, but I can't seem to make the JAASAuthenticator work.
I always end up with an "invalid null Subject provided"...
resource/client.jaas file has been setup to point to the keytab file and includes a principal.

Jaas config:
jcifs {
com.sun.security.auth.module.Krb5LoginModule required
client=true
useKeyTab=true
storeKey=false
keyTab="C:\Users\-----\git\-----.keytab"
principal="[email protected]"
debug=true;
};

--- code ---
Logger l = Logger.getLogger("jcifs.smb.JAASAuthenticator");
l.setLevel(java.util.logging.Level.FINEST);
//System.setProperty("java.security.krb5.kdc", "------------");
//System.setProperty("java.security.krb5.realm", "----------");
System.setProperty("sun.security.krb5.debug", "true");

    // Set JAAS
    System.setProperty("java.security.auth.login.config", Thread.currentThread().getContextClassLoader().getResource("resource/client.jaas").toString());
    System.setProperty("java.security.krb5.conf","c:\\users\\-------\\git\\krb5.cnf"); 
    Properties sp = System.getProperties();
    PropertyConfiguration p = new PropertyConfiguration(sp);
    CIFSContext userCtx = null;
    BaseContext bc = new BaseContext(p);
    JAASAuthenticator ja = new JAASAuthenticator(bc);
    ja.setUser("-------");
    ja.setRealm("-------");
    userCtx = bc.withCredentials(ja);
    
    try {
        SmbResource f = new SmbFile("smb://----.-----.-----/Share/Filter.csv", userCtx);
        System.out.printf("%s%n",f.exists());
    }
    catch ( Exception e ) {
        e.printStackTrace();
    }

--- debug ---
2643 [Transport4] DEBUG jcifs.internal.smb1.com.SmbComNegotiateResponse - Have initial token 60820076068200062B0601050502A0820--------
42643 [Transport4] DEBUG jcifs.smb.SmbTransportImpl - Negotiation response on Transport4 :SmbComNegotiateResponse[command=SMB_COM_NEGOTIATE,received=true,errorCode=0,flags=0x0098,flags2=0xC801,signSeq=0,tid=0,pid=11842,uid=0,mid=0,wordCount=17,byteCount=138,wordCount=17,dialectIndex=0,securityMode=0x3,security=user,encryptedPasswords=true,maxMpxCount=255,maxNumberVcs=50,maxBufferSize=65535,maxRawSize=0,sessionKey=0x9AD7FB3A,capabilities=0x8000D2FC,serverTime=Tue Feb 27 22:36:42 CET 2018,serverTimeZone=-60,encryptionKeyLength=122,byteCount=138,oemDomainName=]
42643 [Transport4] DEBUG jcifs.internal.smb1.com.SmbComNegotiateResponse - Signing not-enabled not-required
42643 [Transport4] DEBUG jcifs.internal.smb1.com.SmbComNegotiateResponse - Unicode is enabled
42643 [Transport4] DEBUG jcifs.smb.SmbTransportImpl - Signature negotiation enforced false (server false) enabled false (server false)
42643 [main] DEBUG jcifs.smb.JAASAuthenticator - Logging on
42674 [main] ERROR jcifs.smb.JAASAuthenticator - Failed to create login context
javax.security.auth.login.LoginException: invalid null Subject provided
at javax.security.auth.login.LoginContext.(LoginContext.java:384)
at javax.security.auth.login.LoginContext.(LoginContext.java:458)
at jcifs.smb.JAASAuthenticator.getSubject(JAASAuthenticator.java:214)
at jcifs.smb.Kerb5Authenticator.toString(Kerb5Authenticator.java:321)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at jcifs.smb.SmbSessionImpl.toString(SmbSessionImpl.java:1024)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at jcifs.smb.SmbTransportImpl.getSmbSession(SmbTransportImpl.java:381)
at jcifs.smb.SmbTransportImpl.getSmbSession(SmbTransportImpl.java:97)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:561)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
42674 [main] DEBUG jcifs.smb.SmbTransportImpl - Establishing new session SmbSession[credentials=Kerb5Authenticatior[subject=null,user=----@----,realm=----],targetHost=----------,targetDomain=null,uid=0,connectionState=0,usage=1] on Transport4
42674 [main] DEBUG jcifs.smb.SmbTreeImpl - treeConnect: unc=\--------------,service=?????
42674 [main] DEBUG jcifs.smb.JAASAuthenticator - Logging on
42674 [main] ERROR jcifs.smb.JAASAuthenticator - Failed to create login context
javax.security.auth.login.LoginException: invalid null Subject provided
at javax.security.auth.login.LoginContext.(LoginContext.java:384)
at javax.security.auth.login.LoginContext.(LoginContext.java:458)
at jcifs.smb.JAASAuthenticator.getSubject(JAASAuthenticator.java:214)
at jcifs.smb.Kerb5Authenticator.toString(Kerb5Authenticator.java:321)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:451)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
42674 [main] DEBUG jcifs.smb.SmbSessionImpl - sessionSetup: Kerb5Authenticatior[subject=null,user=----@----,realm=----]
42674 [main] DEBUG jcifs.smb.SmbSessionImpl - Extended security negotiated
42674 [main] DEBUG jcifs.smb.SmbSessionImpl - Remote host is ------.----.------
42885 [main] DEBUG jcifs.smb.Kerb5Authenticator - Have initial token NegTokenInit[flags=0,mechs=[1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.10],mic=null]
42885 [main] DEBUG jcifs.smb.Kerb5Context - Found ExtendedGSSContext implementation: com.sun.security.jgss.ExtendedGSSContext
Java config name: c:\users------\git\krb5.cnf
Loaded from Java config
42932 [main] DEBUG jcifs.smb.Kerb5Context - Service name is [email protected]
42932 [main] DEBUG jcifs.smb.SmbSessionImpl - Session setup failed
jcifs.smb.SmbException: Context setup failed
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:152)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:795)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:790)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:790)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427)
at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
at jcifs.smb.Kerb5Context.(Kerb5Context.java:92)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:334)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:149)
... 17 more
42932 [main] DEBUG jcifs.smb.SmbTreeImpl - Disconnect tree on treeConnectFailure
jcifs.smb.SmbException: Context setup failed
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:152)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:795)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:790)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:790)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427)
at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
at jcifs.smb.Kerb5Context.(Kerb5Context.java:92)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:334)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:149)
... 17 more
42948 [main] DEBUG jcifs.smb.SmbTreeImpl - Usage dropped to zero, release session
42948 [main] DEBUG jcifs.smb.SmbSessionImpl - Usage dropped to zero, release connection Transport4[------.----.------/--.--.--.--:445,state=3,signingEnforced=false,usage=2]
42948 [main] WARN jcifs.smb.SmbTreeConnection - Referral failed, trying next
jcifs.smb.SmbException: Context setup failed
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:152)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:795)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:790)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:790)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427)
at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
at jcifs.smb.Kerb5Context.(Kerb5Context.java:92)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:334)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:149)
... 17 more
jcifs.smb.SmbException: Context setup failed
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:152)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:795)
at jcifs.smb.SmbSessionImpl$3.run(SmbSessionImpl.java:790)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:790)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)
at jcifs.smb.SmbFile.exists(SmbFile.java:821)
at com.---.ods.tools.CopyNasToIngestion.main(CopyNasToIngestion.java:135)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:193)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:427)
at sun.security.jgss.GSSCredentialImpl.(GSSCredentialImpl.java:62)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
at jcifs.smb.Kerb5Context.(Kerb5Context.java:92)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:334)
at jcifs.smb.Kerb5Authenticator.createContext(Kerb5Authenticator.java:149)
... 17 more
42951 [Thread-1] DEBUG jcifs.smb.SmbTransportPoolImpl - Closing pool
42951 [Thread-1] DEBUG jcifs.smb.SmbTransportImpl - Disconnecting transport Transport4[------.----.------/--.--.--.--:445,state=5,signingEnforced=false,usage=0]
42951 [Transport4] DEBUG jcifs.util.transport.Transport - recv failed
java.net.SocketException: Socket Closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at jcifs.util.transport.Transport.readn(Transport.java:70)
at jcifs.smb.SmbTransportImpl.peekKey(SmbTransportImpl.java:783)
at jcifs.util.transport.Transport.loop(Transport.java:420)
at jcifs.util.transport.Transport.run(Transport.java:762)
at java.lang.Thread.run(Thread.java:745)
42951 [Thread-1] DEBUG jcifs.smb.SmbTransportPoolImpl - Removing transport connection Transport4[------.----.------/--.--.--.--,state=5,signingEnforced=false,usage=0] (1772370013)
42951 [Transport4] DEBUG jcifs.util.transport.Transport - Disconnected
42951 [Thread-1] DEBUG jcifs.smb.SmbTransportImpl - Disconnecting transport Transport3[------.----.------/--.--.--.--:445,state=5,signingEnforced=true,usage=0]
42951 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Logging off session on Transport3[------.----.------/--.--.--.--:445,state=5,signingEnforced=true,usage=1]
42951 [Transport4] DEBUG jcifs.util.transport.Transport - Notified clients
42951 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Disconnect tree on logoff
42951 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Reacquire transport
42951 [Thread-1] DEBUG jcifs.util.transport.Transport - Trying to connect a disconnected transport
42992 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Usage dropped to zero, release connection Transport3[------.----.------/--.--.--.--:445,state=5,signingEnforced=true,usage=2]
42992 [Thread-1] DEBUG jcifs.util.transport.Transport - Trying to connect a disconnected transport
43024 [Transport3] DEBUG jcifs.util.transport.Transport - recv failed
java.net.SocketException: Socket Closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at jcifs.util.transport.Transport.readn(Transport.java:70)
at jcifs.smb.SmbTransportImpl.peekKey(SmbTransportImpl.java:783)
at jcifs.util.transport.Transport.loop(Transport.java:420)
at jcifs.util.transport.Transport.run(Transport.java:762)
at java.lang.Thread.run(Thread.java:745)
43024 [Thread-1] DEBUG jcifs.smb.SmbTransportPoolImpl - Removing transport connection Transport3[------.----.------/--.--.--.--:445,state=5,signingEnforced=true,usage=0] (643748130)
43024 [Transport3] DEBUG jcifs.util.transport.Transport - Disconnected
43024 [Transport3] DEBUG jcifs.util.transport.Transport - Notified clients
43024 [Thread-1] DEBUG jcifs.smb.SmbTransportImpl - Disconnecting transport Transport2[------.----.------/--.--.--.--:445,state=5,signingEnforced=false,usage=0]
43024 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Logging off session on Transport2[------.----.------/--.--.--.--:445,state=5,signingEnforced=false,usage=1]
43024 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Disconnect tree on logoff
43024 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Reacquire transport
43024 [Thread-1] DEBUG jcifs.util.transport.Transport - Trying to connect a disconnected transport
43071 [Thread-1] DEBUG jcifs.smb.SmbSessionImpl - Usage dropped to zero, release connection Transport2[------.----.------/--.--.--.--:445,state=5,signingEnforced=false,usage=2]
43071 [Thread-1] DEBUG jcifs.util.transport.Transport - Trying to connect a disconnected transport
43102 [Transport2] DEBUG jcifs.util.transport.Transport - recv failed
java.net.SocketException: Socket Closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at jcifs.util.transport.Transport.readn(Transport.java:70)
at jcifs.smb.SmbTransportImpl.peekKey(SmbTransportImpl.java:783)
at jcifs.util.transport.Transport.loop(Transport.java:420)
at jcifs.util.transport.Transport.run(Transport.java:762)
at java.lang.Thread.run(Thread.java:745)
43102 [Thread-1] DEBUG jcifs.smb.SmbTransportPoolImpl - Removing transport connection Transport2[------.----.------/--.--.--.--:445,state=5,signingEnforced=false,usage=0] (1861247844)
43106 [Transport2] DEBUG jcifs.util.transport.Transport - Disconnected
43106 [Transport2] DEBUG jcifs.util.transport.Transport - Notified clients

Would be great if the jcifs-ng artifacts could get published to maven central.

I think this would improve adoption.

Failed to connect to NetApp server (with SMB1/SMB2) although I successes with pure JCIFS and from smbclient throwing:

jcifs.smb.SmbException: 0xC0000001
at jcifs.smb.SmbTransportImpl.checkStatus2(SmbTransportImpl.java:1424)
at jcifs.smb.SmbTransportImpl.checkStatus(SmbTransportImpl.java:1535)
at jcifs.smb.SmbTransportImpl.sendrecv(SmbTransportImpl.java:1007)
at jcifs.smb.SmbTransportImpl.send(SmbTransportImpl.java:1506)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:548)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:477)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:363)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:341)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:607)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:550)
at jcifs.smb.SmbFile.connect(SmbFile.java:509)

We are running against a server running Windows 2008 R2. We get the following exception in SmbTransportImpl.java when calling SmbFile.listFiles() on a directory containing 654 files. The SmbFile.listFiles() call works most of the time, but somehow it fails in this specific directory.

java.io.IOException: Message size 0 exceeds maxiumum buffer size 65535
at jcifs.smb.SmbTransportImpl.doRecvSMB2(Unknown Source) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.doRecv(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.util.transport.Transport.loop(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.util.transport.Transport.run(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]

These is the stack trace from calling Smb.listFiles(),

[2017-11-18 05:38:50,251] WARN [-2047669190@qtp-771331191-0] jcifs.util.transport.Transport sendrecv failed
jcifs.util.transport.TransportException: Transport1 error reading response to command=SMB2_QUERY_DIRECTORY,status=0,flags=0x0004,mid=6,wordCount=0,byteCount=34
at jcifs.util.transport.Transport.waitForResponses(Unknown Source) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.util.transport.Transport.sendrecv(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.sendrecv(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbSessionImpl.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeImpl.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send0(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeHandleImpl.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeHandleImpl.send(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.DirFileEntryEnumIterator2.open(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.DirFileEntryEnumIteratorBase.(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.DirFileEntryEnumIterator2.(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbEnumerationUtil.doEnum(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbEnumerationUtil.listFiles(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.listFiles(Unknown Source) [jcifs-ng-2.0.1-flx.1.jar:?]

The only JCIFS properties we have set are:

jcifs.smb.client.enableSMB2=true
jcifs.traceResources=true
jcifs.util.loglevel=4

The funny thing is that when we add another folder or file(s) to the directory, then the SmbFile.listFiles() call works fine. So we suspect that there is something odd happening when receiving/parsing the responses in SmbTransportImpl.doRecvSMB2().

I added 'log.warn()' debug messages to doRecvSMB2() to see what is happening in this method and noticed that it throws here,

if ( ( nextCommand != 0 && nextCommand > maximumBufferSize ) || ( nextCommand == 0 && size > maximumBufferSize ) ) {
throw new IOException(String.format("Message size %d exceeds maxiumum buffer size %d", nextCommand, maximumBufferSize));
}

where nextCommand = 0 and size is 65536 which is one more than the maximumBufferSize of 65535. I notice that maximumBufferSize is initialized in BaseConfiguration.java to 0xFFFF and this value cannot be changed thru a JCIFS property.

Below is the doRecvSMB2() method with the debug log.warn() messages I added. Next to each log.warn() message I annotated the value I get (see comments). I also tried to double the size of the maximumBufferSize to 0x1FFFE but that didn't help.

Any ideas or suggestions would be greatly appreciated. Not sure what is going on.

private void doRecvSMB2 ( CommonServerMessageBlock response ) throws IOException, SMBProtocolDecodingException {
	log.warn("doRecvSMB2: Start HERE");
    int size = ( Encdec.dec_uint16be(this.sbuf, 2) & 0xFFFF ) | ( this.sbuf[ 1 ] & 0xFF ) << 16;
    log.warn("doRecvSMB2: first size="+size); // size=65688 
    if ( size < ( Smb2Constants.SMB2_HEADER_LENGTH + 1 ) ) {
        throw new IOException("Invalid payload size: " + size);
    }

    if ( this.sbuf[ 0 ] != (byte) 0x00 || this.sbuf[ 4 ] != (byte) 0xFE || this.sbuf[ 5 ] != (byte) 'S' || this.sbuf[ 6 ] != (byte) 'M'
            || this.sbuf[ 7 ] != (byte) 'B' ) {
        throw new IOException("Houston we have a synchronization problem");
    }

    int nextCommand = Encdec.dec_uint32le(this.sbuf, 4 + 20);
    log.warn("doRecvSMB2: first nextCommand="+nextCommand); // nextCommand = 152
    int maximumBufferSize = getContext().getConfig().getMaximumBufferSize();
    int msgSize = nextCommand != 0 ? nextCommand : size;
    log.warn("doRecvSMB2: fist msgSize="+msgSize+", maximumBufferSize="+maximumBufferSize); 
             //  msgSize=152, maximumBufferSize=65535
    if ( msgSize > maximumBufferSize ) {
        throw new IOException(String.format("Message size %d exceeds maxiumum buffer size %d", msgSize, maximumBufferSize));
    }

    ServerMessageBlock2Response cur = (ServerMessageBlock2Response) response;
    byte[] buffer = getContext().getBufferCache().getBuffer();
    try {
        int rl = nextCommand != 0 ? nextCommand : size;
        log.warn("doRecvSMB2: first rl="+rl); // first rl=152

        // read and decode first
        System.arraycopy(this.sbuf, 4, buffer, 0, Smb2Constants.SMB2_HEADER_LENGTH);
        readn(this.in, buffer, Smb2Constants.SMB2_HEADER_LENGTH, rl - Smb2Constants.SMB2_HEADER_LENGTH);

        int len = cur.decode(buffer, 0);

        if ( len > rl ) {
            throw new IOException(String.format("WHAT? ( read %d decoded %d ): %s", rl, len, cur));
        }
        else if ( nextCommand != 0 && len > nextCommand ) {
            throw new IOException("Overlapping commands");
        }
        size -= rl; // size = 65688 - 152 = 65536
        log.warn("doRecvSMB2: second size="+size); // second size=65536
        
        while ( size > 0 && nextCommand != 0 ) {
            cur = (ServerMessageBlock2Response) cur.getNextResponse();
            if ( cur == null ) {
                log.warn("Response not properly set up");
                this.in.skip(size);
                break;
            }

            // read next header
            readn(this.in, buffer, 0, Smb2Constants.SMB2_HEADER_LENGTH);
            nextCommand = Encdec.dec_uint32le(buffer, 20);
            log.warn("doRecvSMB2: nextCommand="+nextCommand); // nextCommand = 0
            
            if ( ( nextCommand != 0 && nextCommand > maximumBufferSize ) || ( nextCommand == 0 && size > maximumBufferSize ) ) {
            	log.warn("doRecvSMB2: Throwing-2 msgSize > maximumBufferSize"); 
                           // size=65536 > maximumBufferSize=65535
            	throw new IOException(String.format("Message size %d exceeds maxiumum buffer size %d", nextCommand, maximumBufferSize));
            }

Not really an issue, but I wanted to bring your attention to the Apache Commons VFS provider I've created for jcifs-ng. http://github.com/IdentityAutomation/vfs-jcifs-ng

I switched to jcifs-ng after learning that this one is supporting large reads out of the box. I used to do this myself by banging into SmbInputStream implementation and overriding the relevant transaction size fields. I need this because without large read support, performance with jcifs is truly atrocious on long-latency links.

However, I ran into trouble with passing authentication data via the smb:// URL. After some experimentation, I discovered that pretty much only this specific form works as a drop-in replacement:

SmbFile directory = new SmbFile(new URL(null, directoryString, new jcifs.smb.Hanlder());

This used to work with jcifs:

SmbFile directory = new SmbFile(directoryString);

There were a number of related issues.

Firstly, invoking the jcifs.Config.registerSmbURLHandler() did not seem to work for me, though I did not spend enough time to figure out why. I had to provide the Handler explicitly. I checked that the relevant system property listed the jcifs package, so I really do not understand why new URL() with some smb://-prefixed did fail.

Secondly, the only reason why I was trying the URL-based constructor was that only this specific constructor accepting a single URL parameter appeared to recognize the authentication parameters from the URL and set them up correctly in the config. E.g. the string variant, which I used to have:

SmbFile directory = new SmbFile(directoryString);

would fail to authenticate. The chain of constructors appear to ignore any URL-passed authentication stuff. I think this is a bug, and that particular String constructor should be changed just invoke this(new URL(null, arg, new jcifs.smb.Handler()), so that at least that one would work like it used to work with jcifs.

Is this the correct maven package? https://mvnrepository.com/artifact/eu.agno3.jcifs/jcifs-ng
It appears to be out of date.

Thanks.

Hi, this is an old bug from the original jcifs, this functions never worked properly. The this.fp += count; line shouldn't be there in the readFully function as this.fp has already been advanced in the call to this.read(b, off + n, len - n).

    @Override
    public final void readFully ( byte b[], int off, int len ) throws SmbException {
        int n = 0, count;

        do {
            count = this.read(b, off + n, len - n);
            if ( count < 0 )
                throw new SmbEndOfFileException();
            n += count;
            this.fp += count;
        }
        while ( n < len );
    }

Hi,

I want leverage SMB2/3 files sharing capabilities and integrate it in my project.
I have built the jcifs-ng in my local environment. But I couldn't find any examples or sample code which could be used as reference. Could you please rpovide sample/ example codefor reference

thanks
Manas

There seems to be a chance that the properties change while going through the iterator, probably an Android thing. I've only had a few crash reports on Crashlytics.

Fatal Exception: java.util.ConcurrentModificationException
       at java.util.Hashtable$HashIterator.nextEntry(Hashtable.java:727)
       at java.util.Hashtable$EntryIterator.next(Hashtable.java:778)
       at java.util.Hashtable$EntryIterator.next(Hashtable.java:776)
       at java.util.Hashtable.putAll(Hashtable.java:424)
       at jcifs.context.SingletonContext.init(SingletonContext.java:72)
       at jcifs.context.SingletonContext.getInstance(SingletonContext.java:92)
       at jcifs.context.SingletonContext.registerSmbURLHandler(SingletonContext.java:129)
       at jcifs.Config.registerSmbURLHandler(Config.java:70)

I have released an alpha version of my Android app with this library and I got this report on Crashlytics. No idea how to reproduce.

java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.String.length()' on a null object reference
       at jcifs.smb.SmbResourceLocatorImpl.getType(SmbResourceLocatorImpl.java:414)
       at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:207)
       at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
       at jcifs.smb.SmbFile.listFiles(SmbFile.java:1177)

My test-setup:

I have a Windows 2016 Server Evaluation, installed as Domain Controller. That VM is equipped with three virtual nics (NAT for Internet Connection, Host-Only Networking for Debugging and and internal network). I have a second Windows 2016 server, that is joined to the domain. This setup was intended for experiments with Kerberos.

I wrote a minimal GSS<->SSPI Adapter, that exposes the windows SSPI functions wrapped into GSS Context/Credentials. Background is, that microsoft has shutdown the access to the TGT, that Oracle/OpenJDK java need to implement Kerberos Authentification.

While I tested jcifs-ng I noticed an odd behavior on the domain controller. On the secondary server I can repeatedly open connections and do listings, on the domain controller only the first connection attempt works. The second fails:

Jun 20, 2017 10:35:55 PM jcifs.smb.SmbSessionImpl sessionSetupSMB1
WARNUNG: Exception during SSP authentication
jcifs.smb.SmbException: Server chose an unsupported mechanism null
        at jcifs.smb.SpnegoContext.negotitate(SpnegoContext.java:193)
        at jcifs.smb.SpnegoContext.initSecContext(SpnegoContext.java:174)
        at jcifs.smb.SmbSessionImpl$4.run(SmbSessionImpl.java:822)
        at jcifs.smb.SmbSessionImpl$4.run(SmbSessionImpl.java:818)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:818)
        at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
        at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)

I looked into it further and modified the jcifs.smb.SpnegoContext.negotitate method in line 192 not to check of supported mechanism. (lines 192-194 were commented) And this basicly fixes the issue.

Here you find a trace for both cases (pcap file in ZIP):

successful_and_unsuccessfull_cap_2.pcap.zip

The first handshake is the expected sequence:

• The GSS Context is established on the client and the initial token is generated, SSPI indicates SEC_I_CONTINUE_NEEDED
• The token is send to the server (Packet number 49) and the server replies with the reply token (Packet number 51)
• The reply token is fed into SSPI and that indicates 'SEC_E_OK' (the handshake is done)

The second is the one, that blows with the current implementation (the trace shows the working state!):

• The GSS Context is established on the client and the initial token is generated, SSPI indicates SEC_I_CONTINUE_NEEDED
• The token is send to the server (Packet number 113) and the server replies with the reply token (Packet number 115). The reply token indicates KRB5KRB_AP_ERR_MODIFIED
• The reply token is fed into SSPI and that indicates 'SEC_I_CONTINUE_NEEDED'
• A new token is generated and send to the server (Packet number 119) and now an accept reply token (Packet number 121) is generated
• The reply token is fed into SSPI and that indicates 'SEC_E_OK' (the handshake is done)

Looking at the network trace, I conclude, that the exception is generated, because the second round (Packet 121) does not indicate a supportedMech, the supportedMech was present in Packet number 119.

Long story short - my fix currently looks like this:

--- a/src/main/java/jcifs/smb/SpnegoContext.java
+++ b/src/main/java/jcifs/smb/SpnegoContext.java
@@ -189,7 +189,7 @@
 
             if ( spToken instanceof NegTokenTarg ) {
                 NegTokenTarg targ = (NegTokenTarg) spToken;
-                if ( !this.mechContext.isSupported(targ.getMechanism()) ) {
+                if ( targ.getMechanism() != null && !this.mechContext.isSupported(targ.getMechanism()) ) {
                     throw new SmbException("Server chose an unsupported mechanism " + targ.getMechanism());
                 }
             }

I did not yet dive into the negotiate protocol, so this is most probably to easy.

Android studio - device: Android 7.0
on NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(...) this happens:

FATAL EXCEPTION: main
Process: com.cornmo.moprac.moprac, PID: 26084
java.lang.NoClassDefFoundError: Failed resolution of: Lorg/ietf/jgss/Oid;
at jcifs.smb.NtlmContext.(NtlmContext.java:50)
at jcifs.smb.NtlmPasswordAuthentication.createContext(NtlmPasswordAuthentication.java:234)
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:785)
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:606)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:560)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:543)
at jcifs.smb.SmbFileInputStream.(SmbFileInputStream.java:96)
at jcifs.smb.SmbFileInputStream.(SmbFileInputStream.java:71)
at com.cornmo.moprac.moprac.Headof$1.onClick(Headof.java:58)
at android.view.View.performClick(View.java:5612)
at android.view.View$PerformClick.run(View.java:22288)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6123)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)
Caused by: java.lang.ClassNotFoundException: Didn't find class "org.ietf.jgss.Oid" on path: DexPathList[[zip file "/data/app/com.cornmo.moprac.moprac-2/base.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_dependencies_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_0_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_1_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_2_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_3_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_4_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_5_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_6_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_7_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_8_apk.apk", zip file "/data/app/com.cornmo.moprac.moprac-2/split_lib_slice_9_apk.apk"],nativeLibraryDirectories=[/data/app/com.cornmo.moprac.moprac-2/lib/arm, /system/lib, /vendor/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:380)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at jcifs.smb.NtlmContext.(NtlmContext.java:50) 
at jcifs.smb.NtlmPasswordAuthentication.createContext(NtlmPasswordAuthentication.java:234) 
at jcifs.smb.SmbSessionImpl.sessionSetupSMB1(SmbSessionImpl.java:785) 
at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:466) 
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358) 
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336) 
at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600) 
at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:606) 
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:560) 
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481) 
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457) 
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418) 
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:543) 
at jcifs.smb.SmbFileInputStream.(SmbFileInputStream.java:96) 
at jcifs.smb.SmbFileInputStream.(SmbFileInputStream.java:71) 
at com.cornmo.moprac.moprac.Headof$1.onClick(Headof.java:58) 
at android.view.View.performClick(View.java:5612) 
at android.view.View$PerformClick.run(View.java:22288) 
at android.os.Handler.handleCallback(Handler.java:751) 
at android.os.Handler.dispatchMessage(Handler.java:95) 
at android.os.Looper.loop(Looper.java:154) 
at android.app.ActivityThread.main(ActivityThread.java:6123) 
at java.lang.reflect.Method.invoke(Native Method) 
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757) 

Typo in symbolic name header, missing export of jcifs package.

I'm getting the following NPE when I call SMBFile.listFiles() against a Windows 2008 Server R2. I'm running against SMB1, so I disabled SMB2 with the property jcifs.smb.client.enableSMB2=false. I also made sure that jcifs.smb.client.disableSMB1=false.

Exception in thread "main" java.lang.NullPointerException
at jcifs.smb.DirFileEntryEnumIteratorBase.advance(DirFileEntryEnumIteratorBase.java:144)
at jcifs.smb.DirFileEntryEnumIterator1.open(DirFileEntryEnumIterator1.java:94)
at jcifs.smb.DirFileEntryEnumIteratorBase.(DirFileEntryEnumIteratorBase.java:67)
at jcifs.smb.DirFileEntryEnumIterator1.(DirFileEntryEnumIterator1.java:46)
at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:198)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:253)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1271)
at TestJCIFS_readdir.main(TestJCIFS_readdir.java:63)

My test is simple. Given a top directory, traverse the two subdirectories and listFiles().

I added some debug code and noticed that the data is being asynchronously loaded by this Transport thread:

jcifs.internal.smb1.trans2.Trans2FindFirst2Response.readDataWireFormat(Trans2FindFirst2Response.java:143), jcifs.internal.smb1.trans.SmbComTransactionResponse.readBytesWireFormat(SmbComTransactionResponse.java:315),
jcifs.internal.smb1.ServerMessageBlock.decode(ServerMessageBlock.java:1195),
jcifs.internal.smb1.trans.SmbComTransactionResponse.decode(SmbComTransactionResponse.java:240),
jcifs.smb.SmbTransportImpl.doRecvSMB1(SmbTransportImpl.java:1228),
jcifs.smb.SmbTransportImpl.doRecv(SmbTransportImpl.java:1097),
jcifs.util.transport.Transport.loop(Transport.java:459), jcifs.util.transport.Transport.run(Transport.java:762), java.lang.Thread.run(Thread.java:785)]

And the DirFileEntryEnumIteratorBase.advance() call is getting the results here ->

protected final FileEntry advance ( boolean last ) throws CIFSException {
FileEntry[] results = getResults(); <- HERE. Null is being returned
while ( this.ridx < results.length ) {
FileEntry itm = results[ this.ridx ];
this.ridx++;
if ( filter(itm) ) {
return itm;
}
}

But the results haven't been loaded yet by the asynchronous call to Trans2FindFirst2Response.readDataWireFormat() here ->

   setResults(results); <- HERE

    /*
     * last nextEntryOffset for NT 4(but not 98) is 0 so we must
     * use dataCount or our accounting will report an error for NT :~(
     */
    System.out.println("readDataWireFormat:data count="+getDataCount());
    return getDataCount();

So there seems to be a synchronization problem between the data (results) not being loaded and set, and the iterator trying to get the results (when it has not been set yet by the readDataWireFormat() call).

Is there a synchronization bug between these two pieces of code?

Thanks in advance.

we are going to use content-fetch and delete action on remote files from a smb3 devices. Still there is an open questions around JCIFS support for SMB3. Can you guys please confirm. Thanks in advance.

Investigate RPC bind failures (STATUS_INVALID_PARAMETER) with SMB2. Affected are W2K12/16, not W2K8, not samba. Possible additional requirements on DCERPC payloads when used over SMB2 (negotiation, security, unicode maybe?).

Hi, I'm trying to implement SMB2 SET_INFO request for setting security info, particularly OWNER_SECURITY_INFORMATION, and I'm getting the above error code meaning one of my parameters is incorrect. I'm implementing a class called FileSecurityDescriptorInfo that implements BasicFileInformation which has the encode/decode methods implemented according to the spec. Is there tracing of some kind that I can enable to pin point which parameter is incorrect? Or some other way perhaps?

Thanks for the help!

Hi,
Our test is to WS 2008 R2 Standard Service Pack 1 with SMB 1.0 and SMB 2.1. Its SMB signing setting is:
Microsoft network server: Digitally sign communications (always) = Disabled
Microsoft network server: Digitally sign communications (if clent agrees) = Disabled

We are using SMB1 to talk to the Windows Server with:
jcifs.smb.client.signingPreferred=false
jcifs.smb.client.signingEnforced=false

NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(SingletonContext.getInstance(), "", argv[1], argv[2]);
file = new SmbFile("smb://" + argv[0] + "/" + argv[3] + "/" + argv[4] + "/", SingletonContext.getInstance().withCredentials(auth));
System.out.println("Getting owner of " + file.getName());
String uid = file.getOwnerUser().toString();
System.out.println("Owner id is " + uid);

The test is able to create a context. The context gets the signing values correct as:
DEBUG SmbTransportImpl:684 - testing this signingEnforced - false
DEBUG SmbComNegotiateResponse:244 - Signing not-enabled not-required
DEBUG SmbComNegotiateResponse:280 - Unicode is enabled
DEBUG SmbTransportImpl:692 - Signature negotiation enforced false (server false) enabled false (server false)

However when it tries to get the owner uid, the connection transport picks up the signing value wrong:

SmbTransportImpl:684 - testing this signingEnforced - true
SmbComNegotiateResponse:229 - Signatures are required but the server does not support them

Then later we got the jcifs.CIFSException: Failed to resolve SIDs

2018-02-08 21:16:11 WARN SmbTreeConnection:572 - Referral failed, trying next
jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.0.10
at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:649)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:213)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:555)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:642)
at jcifs.smb.SmbPipeHandleImpl.ensureTreeConnected(SmbPipeHandleImpl.java:111)
at jcifs.smb.SmbPipeHandleImpl.ensureOpen(SmbPipeHandleImpl.java:166)
at jcifs.smb.SmbPipeHandleImpl.sendrecv(SmbPipeHandleImpl.java:250)
at jcifs.dcerpc.DcerpcPipeHandle.doSendReceiveFragment(DcerpcPipeHandle.java:113)
at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:243)
at jcifs.dcerpc.DcerpcHandle.bind(DcerpcHandle.java:216)
at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:234)
at jcifs.dcerpc.msrpc.LsaPolicyHandle.(LsaPolicyHandle.java:43)
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:106)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:188)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2431)
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2417)
at TestJCIFS_getOwnerID.main(TestJCIFS_getOwnerID.java:48)

Exception in thread "main" jcifs.CIFSException: Failed to resolve SIDs
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:111)
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:188)
at jcifs.smb.SID.resolve(SID.java:480)
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2431)
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2417)
at TestJCIFS_getOwnerID.main(TestJCIFS_getOwnerID.java:48)
Caused by: jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.0.10
at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:649)

    at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:213)
    at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
    at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:555)
    at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
    at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457)
    at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418)
    at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:642)
    at jcifs.smb.SmbPipeHandleImpl.ensureTreeConnected(SmbPipeHandleImpl.java:111)
    at jcifs.smb.SmbPipeHandleImpl.ensureOpen(SmbPipeHandleImpl.java:166)
    at jcifs.smb.SmbPipeHandleImpl.sendrecv(SmbPipeHandleImpl.java:250)
    at jcifs.dcerpc.DcerpcPipeHandle.doSendReceiveFragment(DcerpcPipeHandle.java:113)
    at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:243)
    at jcifs.dcerpc.DcerpcHandle.bind(DcerpcHandle.java:216)
    at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:234)
    at jcifs.dcerpc.msrpc.LsaPolicyHandle.<init>(LsaPolicyHandle.java:43)
    at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:106)
    ... 5 more

Caused by: jcifs.util.transport.TransportException: jcifs.smb.SmbException: This client is not compatible with the server.
at jcifs.util.transport.Transport.run(Transport.java:752)
at java.lang.Thread.run(Thread.java:745)
Caused by: jcifs.smb.SmbException: This client is not compatible with the server.
at jcifs.smb.SmbTransportImpl.doConnect(SmbTransportImpl.java:686)
at jcifs.util.transport.Transport.run(Transport.java:725)

When I turn on SMB2, I don't see the issue.

Thanks,

I've started using this library and I have most of what I need working but it works with against SMB on my Windows machine but it does not work against my Synology NAS. I see other Android apps can work with the Synology NAS just fine, so I'm wondering if there is something wrong with the way I implemented my code. So my question is, is there a sample project I can test my Synology NAS with?

The error I get is:

01-19 14:22:01.641 24408-25061/mypackage W/SmbTreeConnection: Referral failed, trying next
                                                                               jcifs.smb.SmbException: Failed to connect: nas/192.168.86.89
                                                                                   at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:673)
                                                                                   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:213)
                                                                                   at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
                                                                                   at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:557)
                                                                                   at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
                                                                                   at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457)
                                                                                   at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418)
                                                                                   at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:543)
                                                                                   at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:219)
                                                                                   at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
                                                                                   at jcifs.smb.SmbFile.listFiles(SmbFile.java:1177)
                                                                                   at mypackage.servers.smb.SMBServer$2.subscribe(SMBServer.java:78)
                                                                                   at io.reactivex.internal.operators.observable.ObservableCreate.subscribeActual(ObservableCreate.java:40)
                                                                                   at io.reactivex.Observable.subscribe(Observable.java:10842)
                                                                                   at io.reactivex.internal.operators.observable.ObservableSubscribeOn$SubscribeTask.run(ObservableSubscribeOn.java:96)
                                                                                   at io.reactivex.Scheduler$DisposeTask.run(Scheduler.java:452)
                                                                                   at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:61)
                                                                                   at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:52)
                                                                                   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                                                                                   at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
                                                                                   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
                                                                                   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
                                                                                   at java.lang.Thread.run(Thread.java:764)
                                                                                Caused by: jcifs.util.transport.TransportException: java.lang.NullPointerException: Attempt to invoke interface method 'boolean jcifs.internal.SmbNegotiationResponse.isValid(jcifs.CIFSContext, jcifs.internal.SmbNegotiationRequest)' on a null object reference
                                                                                   at jcifs.util.transport.Transport.run(Transport.java:752)
                                                                                   at java.lang.Thread.run(Thread.java:764) 
                                                                                Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'boolean jcifs.internal.SmbNegotiationResponse.isValid(jcifs.CIFSContext, jcifs.internal.SmbNegotiationRequest)' on a null object reference
                                                                                   at jcifs.smb.SmbTransportImpl.doConnect(SmbTransportImpl.java:708)
                                                                                   at jcifs.util.transport.Transport.run(Transport.java:725)
                                                                                   at java.lang.Thread.run(Thread.java:764) 
01-19 14:22:01.647 24408-25061/mypackage W/SMBServer: jcifs.smb.SmbException: Failed to connect: solonas/192.168.86.89
                                                                           at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:673)
                                                                           at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:213)
                                                                           at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
                                                                           at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:557)
                                                                           at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
                                                                           at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:457)
                                                                           at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:418)
                                                                           at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:543)
                                                                           at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:219)
                                                                           at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
                                                                           at jcifs.smb.SmbFile.listFiles(SmbFile.java:1177)
                                                                           at mypackage.servers.smb.SMBServer$2.subscribe(SMBServer.java:78)
                                                                           at io.reactivex.internal.operators.observable.ObservableCreate.subscribeActual(ObservableCreate.java:40)
                                                                           at io.reactivex.Observable.subscribe(Observable.java:10842)
                                                                           at io.reactivex.internal.operators.observable.ObservableSubscribeOn$SubscribeTask.run(ObservableSubscribeOn.java:96)
                                                                           at io.reactivex.Scheduler$DisposeTask.run(Scheduler.java:452)
                                                                           at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:61)
                                                                           at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:52)
                                                                           at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                                                                           at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
                                                                           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
                                                                           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
                                                                           at java.lang.Thread.run(Thread.java:764)
                                                                        Caused by: jcifs.util.transport.TransportException: java.lang.NullPointerException: Attempt to invoke interface method 'boolean jcifs.internal.SmbNegotiationResponse.isValid(jcifs.CIFSContext, jcifs.internal.SmbNegotiationRequest)' on a null object reference
                                                                           at jcifs.util.transport.Transport.run(Transport.java:752)
                                                                           at java.lang.Thread.run(Thread.java:764) 
                                                                        Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'boolean jcifs.internal.SmbNegotiationResponse.isValid(jcifs.CIFSContext, jcifs.internal.SmbNegotiationRequest)' on a null object reference
                                                                           at jcifs.smb.SmbTransportImpl.doConnect(SmbTransportImpl.java:708)
                                                                           at jcifs.util.transport.Transport.run(Transport.java:725)
                                                                           at java.lang.Thread.run(Thread.java:764) 

Thanks.

Hi,
Out test is trying to retrieve the owner uid of an object as
String uid = smbFile.getOwnerUser().toString();

We run the test against 2 servers:
1st: Windows 2008 R2 server. The test passed.
2nd: netApp version 9. The test failed with the stack trace below and the error is 0xC000003A which is PATH NOT FOUND

DEBUG [-195684588@qtp--1409420992-0] jcifs.smb.SmbTreeConnection Not retrying
jcifs.smb.SmbException: The system cannot find the path specified.
at jcifs.smb.SmbTransportImpl.checkStatus2(SmbTransportImpl.java:1387) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.checkStatus(SmbTransportImpl.java:1498) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.sendrecv(SmbTransportImpl.java:974) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTransportImpl.send(SmbTransportImpl.java:1469) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:397) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeImpl.send(SmbTreeImpl.java:465) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send0(SmbTreeConnection.java:396) ~[jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send(SmbTreeConnection.java:313) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeConnection.send(SmbTreeConnection.java:294) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeHandleImpl.send(SmbTreeHandleImpl.java:130) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbTreeHandleImpl.send(SmbTreeHandleImpl.java:117) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.openUnshared(SmbFile.java:741) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbPipeHandleImpl.ensureOpen(SmbPipeHandleImpl.java:169) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbPipeHandleImpl.sendrecv(SmbPipeHandleImpl.java:250) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.dcerpc.DcerpcPipeHandle.doSendReceiveFragment(DcerpcPipeHandle.java:113) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:243) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.dcerpc.DcerpcHandle.bind(DcerpcHandle.java:216) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:234) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.dcerpc.msrpc.LsaPolicyHandle.(LsaPolicyHandle.java:43) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SIDCacheImpl.resolveSids0(SIDCacheImpl.java:107) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SIDCacheImpl.resolveSids(SIDCacheImpl.java:189) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SID.resolve(SID.java:480) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2415) [jcifs-ng-2.0.1-flx.1.jar:?]
at jcifs.smb.SmbFile.getOwnerUser(SmbFile.java:2401) [jcifs-ng-2.0.1-flx.1.jar:?]
at storediq.siqcifs.facade.BaseSmbFacade.getExtendedAttributes(BaseSmbFacade.java:592) [siqsmb-1.0.2.jar:?]
at storediq.siqcifs.httpserver.httpcommands.GetExtendedAttributesCommand.call(GetExtendedAttributesCommand.java:40) [siqsmb-1.0.2.jar:?]
at storediq.siqcifs.httpserver.ServerServlet.invokeCommandHandler(ServerServlet.java:198) [siqsmb-1.0.2.jar:?]
at storediq.siqcifs.httpserver.ServerServlet.doRequest(ServerServlet.java:77) [siqsmb-1.0.2.jar:?]
at storediq.siqcifs.httpserver.ServerServlet.doPost(ServerServlet.java:218) [siqsmb-1.0.2.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [servlet-api-2.5-20081211.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-20081211.jar:?]
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.Server.handle(Server.java:326) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) [jetty-6.1.26.jar:6.1.26]
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) [jetty-util-6.1.26.jar:6.1.26]:

We did not see much differences when comparing two debug stacks. We only saw one thing different:
1st: good case: Smb2CreateResponse Opened just the name 'lsarpc'. But for the failed case, it open with the name '192.168.0.10\IPC$\lsarpc'
Do you see if the error has to do anything with that? Any other advise for us to look into?
--------------------- 1st good case --------------------------------
[-1554196232@qtp--885766133-1] jcifs.smb.SmbTreeImpl treeConnect: unc=\192.168.225.248\IPC$,service=?????
[-1554196232@qtp--885766133-1] jcifs.smb.SmbTreeConnection Switching tree
[-1554196232@qtp--885766133-1] jcifs.smb.SmbTreeConnection Acquired tree on switch SmbTree[share=IPC$,service=null,tid=5,inDfs=false,inDomainDfs=false,connectionState=2,usage=2]
[-1554196232@qtp--885766133-1] jcifs.smb.SmbFile openUnshared: \lsarpc flags: 19f0023 access: 2019f attrs: 80 options: 0
[-1554196232@qtp--885766133-1] jcifs.internal.smb2.create.Smb2CreateRequest Opening lsarpc
[Transport0] jcifs.internal.smb2.create.Smb2CreateResponse Opened lsarpc: 811B0000300000001500000030000000
---------------------- 2nd failed case -----------------------
[-195684588@qtp--1409420992-0] jcifs.smb.SmbResourceLocatorImpl Share is IPC IPC$
[-195684588@qtp--1409420992-0] jcifs.smb.SmbResourceLocatorImpl Share is IPC IPC$
[-195684588@qtp--1409420992-0] jcifs.smb.SmbTreeImpl treeConnect: unc=\192.168.0.10\IPC$,service=?????
[-195684588@qtp--1409420992-0] jcifs.smb.SmbTreeConnection Switching tree
[-195684588@qtp--1409420992-0] jcifs.smb.SmbTreeConnection Acquired tree on switch SmbTree[share=IPC$,service=null,tid=2,inDfs=true,inDomainDfs=false,connectionState=2,usage=2]
[-195684588@qtp--1409420992-0] jcifs.smb.SmbFile openUnshared: \lsarpc flags: 19f0023 access: 2019f attrs: 80 options: 0
[-195684588@qtp--1409420992-0] jcifs.internal.smb2.create.Smb2CreateRequest Opening 192.168.0.10\IPC$\lsarpc
[-195684588@qtp--1409420992-0] jcifs.smb.SmbTransportImpl Error code: 0xC000003A for Smb2CreateRequest

Thanks in advance,

Hi,
I'm trying to get all shares from my SMB server but sometimes (it is not consistent) ArrayIndexOutOfBoundsException is thrown.
I debug it little bit and I saw that the response len value is huge (about 931M)
Do somebody familiar with this issue?

`       Properties prop = new Properties();
        prop.put( "jcifs.smb.client.enableSMB2", "true");
        prop.put( "jcifs.smb.client.disableSMB1", "false");
        prop.put( "jcifs.traceResources", "true" );
        Configuration config = new PropertyConfiguration(prop);
        CIFSContext context = new BaseContext(config);
        CIFSContext contextWithCred  = context.withCredentials(new NtlmPasswordAuthentication(null, "domain", "admin", "pass"));
        String url = "smb://192.1.10.102/";
        try (SmbFile share = new SmbFile(url, contextWithCred)) {
            for (SmbFile f : share.listFiles(filter)){
                System.out.println(f.getName());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }`

Stacktrace:
jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.1.10.102
at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:673)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:213)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:47)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:557)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:481)
at jcifs.smb.SmbEnumerationUtil.doShareEnum(SmbEnumerationUtil.java:143)
at jcifs.smb.SmbEnumerationUtil.doEnum(SmbEnumerationUtil.java:216)
at jcifs.smb.SmbEnumerationUtil.listFiles(SmbEnumerationUtil.java:277)
at jcifs.smb.SmbFile.listFiles(SmbFile.java:1251)
at Main.test(Main.java:41)
at Main.main(Main.java:17)
Caused by: jcifs.util.transport.TransportException: java.lang.ArrayIndexOutOfBoundsException
at jcifs.util.transport.Transport.run(Transport.java:752)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at jcifs.smb.SmbTransportImpl.negotiate2(SmbTransportImpl.java:639)
at jcifs.smb.SmbTransportImpl.negotiate(SmbTransportImpl.java:522)
at jcifs.smb.SmbTransportImpl.doConnect(SmbTransportImpl.java:690)
at jcifs.util.transport.Transport.run(Transport.java:725)
... 1 more

when i try to delete file a have an exception that the file is used by another process:
code below

try ( SmbFile smbFile = new SmbFile( mtPath, new BaseContext( new PropertyConfiguration( prt ) ) ) )
{
	List<SmbFile> filesList = Arrays.asList( smbFile.listFiles() );
	for ( SmbFile srcFile : filesList )
	{
		try
		{
			srcFile.close();
			srcFile.delete();
		}
		catch ( Exception e )
		{
			logger.error( e );
		}
	}
}
catch ( Exception e )
{
	logger.error( e );
}

We are experience another listFiles() issue with SMB1 on Linux to Windows Server 2008 R2. From our testing, this issue does not happen on Windows (where jcifs-ng is). It sometimes (about 50%) happens on our Linux environment. When enabling SMB2, we do not see the issue at all.

2017-11-28 03:42:13 ERROR FileEntryAdapterIterator:? - Failed to create child URL
java.net.MalformedURLException: Name must not be empty
at jcifs.smb.SmbFile.checkName(Unknown Source)
at jcifs.smb.SmbFile.(Unknown Source)
at jcifs.smb.DirFileEntryAdapterIterator.adapt(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.advance(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.FileEntryAdapterIterator.next(Unknown Source)
at jcifs.smb.SmbEnumerationUtil.listFiles(Unknown Source)
at jcifs.smb.SmbFile.listFiles(Unknown Source)
at TestJCIFS_readdir.main(TestJCIFS_readdir.java:39)

I collected network traces below and hope that you can see what may happen with SMB1 case:

smb1_NameMustNotBeEmpty.cap <-- Problem with SMB1 on Linux
smb1_NameMustNotBeEmpty-2ndRun-NoError.cap <-- No Error with SMB1 on Linux
smb2_NameMustNotBeEmpty.cap <-- No Error with SMB2 on Linux

Thank you very much for your help!