[jcifs] Restoring connection after samba server restart

[Dmytro Polivenok]

27.07.2011, 22:32, "Michael B Allen" <ioplex at gmail.com>:
> On Wed, Jul 27, 2011 at 11:29 AM, Dmytro Polivenok <polivenok at yandex.ua> wrote:
>
>>  Hi,
>>
>>  We are experiencing issues with restoring connection after samba server restart. It is important for us and may be important to other people since we are using jCIFS from application on JBoss server and to recover connection we need to refresh connection somehow.
>>  We found that it is related to TID regeneration. TIDs are generated after server startup and on server restart all TIDs are regenerated. jCIFS caches TIDs and after server restart or shared folder recreation it is unable to access resource because uses old TIDs and doesn’t refreshes them.
>>
>>  In SmbTree class in method void send(ServerMessageBlock request, ServerMessageBlock response)  at the end of the method there is following code:
>>
>>     try {
>>
>>         session.send(request, response);
>>
>>     } catch(SmbException se) {
>>
>>         if(se.getNtStatus() == se.NT_STATUS_NETWORK_NAME_DELETED) {
>>
>>             treeDisconnect(true);
>>
>>         }
>>
>>                 throw se;
>>
>>     }
>>
>>  Method treeDisconnect contains code related to removing old TIDs.
>>
>>  When TID is invalid, NtStatus is equal to NT_STATUS_INVALID_PARAMETER.
>>
>>  So I changed this code in the following way to refresh TID when it is invalid:
>>
>>     try {
>>
>>         session.send(request, response);
>>
>>     } catch(SmbException se) {
>>
>>         if(se.getNtStatus() == se.NT_STATUS_NETWORK_NAME_DELETED || se.getNtStatus() == se.NT_STATUS_INVALID_PARAMETER) {
>>
>>                         treeDisconnect(true);
>>
>>         }
>>
>>         throw se;
>>
>>     }
>>
>>  What do you think about this?
>
> Hi Dmytro,
>
> JCIFS does not "cache" TIDs. A TID is a key that references a "tree"
> (a mount of a share) so it just looks like something is being cached.
> But if the server closes the socket to the client, JCIFS will rebuild
> everything and it should recover just fine. I just tested this in the
> last release actually (but with a Windows server). So I would argue
> that if a "server restart" leaves the TCP connection open but
> invalidates the TID on the server, that would be a bug in the server
> and you should report the issue to whomever maintains that particular
> server codebase.
>
> However, the rules of behavior that JCIFS follows is that JCIFS should
> do whatever the oldest supported version of Windows does (which as of
> 2011 would be Windows XP SP2). Meaning, if you can show that Windows
> recovers gracefully from said error, we will fix it (or at least I
> will add it to the TODO list to be fixed) in JCIFS.
>
> So if you test Windows and find that handles this condition without a
> problem, then please send me two packet captures:
>
>   1) a capture of JCIFS failing as described above and
>   2) a capture of Windows successfully recovering from the above
> described condition.
>
> Note that you should not post packet captures to the mailing list.
> Please send them to me directly.
>
> Also, please use a client that is NOT joined to the domain so that it
> uses NTLM to authenticate and not Kerberos. Technically in this case
> it should probably not make a difference but for the best possible
> comparison you should make the client use NTLM. The ideal test would
> be to use a Windows XP SP2 machine NOT joined to the domain, reboot
> it, login using a local account, do Start > Run > cmd and then C:\>dir
> \\path.fqdn.local\share and then enter the same credentials that you
> used with JCIFS. This will result in a packet capture that should look
> almost identical to running the examples/ListFiles.java example from
> JCIFS and therefore will make a good comparison.
>
> For getting a capture, look into netcap.exe from the Windows "Support
> Tools" package or WireShark.
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/

Sorry for confusion, problem was actual on stoping and starting folder share not in stoping and restarting server. Below you can find more details:

1. Share folder on Windows machine(tried both on Win XP and Win 7);
2. Acces it using jCIFS;
3. Stop sharing this folder (samba server continues working, there are also other shared folders);
	You will receive following stack-trace:
	Caused by: jcifs.smb.SmbException: The parameter is incorrect.

		at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:561)

		at jcifs.smb.SmbTransport.send(SmbTransport.java:638)

		at jcifs.smb.SmbSession.send(SmbSession.java:238)

		at jcifs.smb.SmbTree.send(SmbTree.java:109)

		at jcifs.smb.SmbFile.send(SmbFile.java:775)

		at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1986)

		at jcifs.smb.SmbFile.doEnum(SmbFile.java:1738)

		at jcifs.smb.SmbFile.list(SmbFile.java:1709)

		at jcifs.smb.SmbFile.list(SmbFile.java:1606)

4. We started sharing folder again and stack-trace above appears again and again. We found out that JCIFS tries to use old TID, and after folder re-sharing TID was regenerated and old TID is no longer valid.

Thanks,
Dmytro