Total Commander

Hi,
I have a Netgear router with USB drive attached to it.
I am able to connect to the shares from Windows 7, but when I try to do so from SGS2 or N7 with LAN plugin in TC I receive: unknown user name or bad password.
I am sure of the username and password and I tried using <NAS IP address>\username as username, but the error is still the same.
The LAN plugin works just fine when I connect to my Win7 share though.

The curious thing is that I tried several Android SMB clients and all of them give the same error with the NAS, all of them but one - Mobile SMB (trial), which works just fine and I'm able to browse the shares. This makes me think that it's not my routers fault, but probably something on the jcif configuration side.


Could it be related to jcifs lmCompatibility and jcifs smb client useExtendedSecurity values?

Thanks


P.S. it seems like jcifs<dot>smb<dot>client<dot>useExtendedSecurity is being considered an URL on this forum

I use the ip address of my NAS, attached to my cisco linksys router and it works just fine.

Well, I use the IP address as well, but it still gives me that error.

Yes, this is a known problem: It seems to happen with NAS devices with older server software which use an old authentication scheme no longer supported by jcifs. Unfortunately I have no idea how to fix it...

What about adding a check box "Older NAS compatibility" in the server configuration of the plugin: when checked just do the following:
jcifs.Config.setProperty("jcifs.smb.client.useExtendedSecurity", false);
jcifs.Config.setProperty("jcifs.smb.lmCompatibility", 0);


Please refer to http://jcifs.samba.org/ at "jcifs-1.3.2 released / Samba DFS" post for the explanation.

You are probably refering to this:

jcifs-1.3.2 released / Samba DFS
posted by Mike, Dec 22, 2008
Accessing a DFS link on Samba directly could result in an error. This issue has been fixed. Samba 3.0.x does not support raw NTLMSSP and therefore the new default JCIFS settings that use NTLMSSP break JCIFS and Samba 3.0.x compatibility. To work-around, turn off extended security and use NTLMv1 by setting jcifs.smb.client.useExtendedSecurity=false and jcifs.smb.lmCompatibility=0.

The question is whether I can set these by default, or whether I need an option.

I'm not sure if I understand your last statement.
With that check box checked you set the "compatibility" values (false and 0), otherwise you use the defaults by not setting them (or explicitly setting the values true and 3 respectively).

I don't know if the "compatibility" values will work with all types of share though.

I can provide you the sources of small Android app I used to test my NAS connectivity.

Regards

I don't know if the "compatibility" values will work with all types of share though.

That would be my question - will JCIFS use the compatibility settings (NTLMv1) only if the connection via NTLMv2 fails, or will it always try to connect with the insecure NTLMv1 first?

If it's the former, then I can just set these always, and let jcifs take care of the rest. If the latter, I need a separate checkbox for every connection. Otherwise you couldn't have connections both to your NAS and to your Windows PC.

I can provide you the sources of small Android app I used to test my NAS connectivity.

That's not necessary, but you could try wether you can access a Windows PC with these settings or not.

ghisler(Author) wrote: That's not necessary, but you could try wether you can access a Windows PC with these settings or not.

I checked that already and it connects to a Windows 7 share (stand-alone PC, not part of a domain) without problems with "false" and 0 values.

In my understanding when it's set to NTLMv1 it will always use it, no fallback mechanism.

Anyway my idea was to have that check box for every connection. That'll guarantee max compatibility.

Regards