SMB Connection Fails - "This client is not compatible with the server."

[jejo86]

In the version 3.5.0.89, the SMB connection does not work. Adding a new connection to a Fritz!Box 7490 with latest firmware fails.

The logs show, among others, these errors:

[10-24 17:40:56.811 15440:16132 E/SmbComNegotiateResponse]
Signatures are required but the server does not support them

[10-24 17:40:56.813 15440:16131 W/System.err]
jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.77.1
...
[10-24 17:40:56.814 15440:16131 W/System.err]
Caused by: jcifs.util.transport.TransportException: jcifs.smb.SmbException: This client is not compatible with the server.

See full log: logcat_10-24-2020_17-41-04.txt

I had to downgrade to an older version. Version 3.1.2 RC1 (latest in the F-Droid Repo) works without this problem!

[EmmanuelMess]

Invoking @TranceLove

[TranceLove]

https://en.avm.de/service/fritzbox/fritzbox-7490/knowledge-base/publication/show/3327_SMB-versions-supported-by-the-FRITZ-Box/

It said SMBv1 is disabled by default. 3.1.2 uses old jcifs which supports only v1, while latest version uses jcifs-ng which supports v1 and v2, though v1 is long deprecated and should be only used for legacy devices - hence the switch.

The error message in the log

[10-24 17:40:56.811 15440:16132 E/SmbComNegotiateResponse]
Signatures are required but the server does not support them

The class is jcifs.internal.smb1.com.SmbComNegotiateResponse, implying jcifs-ng has problems communicate to your SMB instance over SMBv1.

The problem can be reproduced when I explicitly specify min protocol and max protocol to NT1 as mentioned in Samba's smb.conf.

(Samba is 4.11.6-Ubuntu on my Mint Ulyana/Ubuntu Focal 20.04)

However, since SMBv1 had been deprecated in favour of the more secure v2 and v3, I think we shall not be fixing this, but encourage users to migrate to SMBv2 instead.

Perhaps disable SMBv1 explicitly in your router and try again?

[jejo86]

Thanks for the information. Actually I made a mistake saying I was using the latest firmware on my Fritz!Box 7490. I was using v07.12 until now. After updating to v07.21 I could connect with the latest version 3.5.0.89 of Amaze, with or without having SMBv1 support activated.

I guess the older firmware only had SMBv1. So my problem is fixed, but in my opinion other people wanting to connect via an old SMB version should be able to do so. I would suggest to add a dropdown, where one can select the SMB version when adding a new SMB connection. Or an autonegotiation function, where Amaze is first trying the latest standard, but automatically falls back to SMBv1 if the newer ones are not implemented in the target.

Also showing an error in case one selected an incompatible version, without having to go through the logs would be nice.

[TranceLove]

AFAIK jcifs-ng can do auto-negotiation on SMB protocol levels.

However search deep into jcifs-ng's repo with the error message got me this: https://github.com/AgNO3/jcifs-ng/issues/40

This is somewhat expected behavior. By default signing is enforced for all IPC$ connections (== RPC). This is a countermeasure for some RPC security issues (related: CVE-2016-2115) and implemented by other clients (e.g. samba) as well.

Depending on your RPC usage and environment these might be non-issues and you can set jcifs.smb.client.ipcSigningEnforced=false to disable that behavior to restore compatibility with servers not having/announcing support for signing.

With SMB2 this issue should not turn up as all servers must support signing.

That setting jcifs.smb.client.ipcSigningEnforced=false would work with my Samba setting min/max protocol to NT1.

Can do a PR for this, but I'll want to make this enabled (disable IPC signature check) for individual connection only since it's security related. This implies non-trivial changes to code... marking 3.6 milestone.

[VishalNehra]

@TranceLove So basically user will be able to choose between signing enforced?

[TranceLove]

@TranceLove So basically user will be able to choose between signing enforced?

Absolutely, as a checkbox.

[VishalNehra]

@TranceLove I don't think it's gonna be that simple, as you said signing must be enabled for v2, what'll happen if user disable signing and still interact on v2 standard

[TranceLove]

@TranceLove I don't think it's gonna be that simple, as you said signing must be enabled for v2, what'll happen if user disable signing and still interact on v2 standard

Should never be affected, since in SMBv2 server signature is required, this flag is ignored.

And as said above, the class throwing the exception was jcifs.internal.smb1.com.SmbComNegotiateResponse which should mean this flag is effective on SMBv1 only.

[VishalNehra]

Shouldn't this be closed? @TranceLove

[TranceLove]

Fix merged, closing.

(Why is it not closed after PR merged?)

[jejo86]

@TranceLove Thank you for your efforts. I finally had the chance to test version 3.5.2.91 in combination with a FritzBox 3490 running FRITZ!OS 07.12, which seems to be the latest firmware for this device, still only supporting SMBv1.

Unfortunately checking the new option "Disable IPC signing check (For legacy SMBv1 servers - UNSAFE!)" does not solve the problem. The "loading wheel" keeps spinning in amaze, and there is no error message at all in the logs nor in the app. Unchecking that option results in the same log messages as described in the initial post.

Please reopen.

[VishalNehra]

🤔 well, can you check if the credentials and permissions are setup correctly?

[jejo86]

The credentials are not the problem. For testing purposes, I tried to use amaze to connect to a different samba server that I can configure. I am running a samba server Version 4.11.6-Ubuntu on Linux Mint 20. If I enter the wrong credentials on purpose the SMB Connection settings pop up in amaze, so the behaviour is different when the credentials are wrong.

I tried to configure my server in a way similar to the FritzBox 3490 one. I thought forcing SMBv1 would do the trick, but amaze does connect normally when Disable IPC signing check (For legacy SMBv1 servers - UNSAFE!) is checked. [EDIT: I just read the previous comments and realized that is exactly what you did in order to solve this problem.] I then played around with the authentication settings, but could not reproduce the error. My /etc/samba/smb.conf contains among others these lines

[global]
...
client min protocol = NT1
#client max protocol = NT1

server min protocol = NT1
server max protocol = NT1

#lanman auth = Yes
#client NTLMv2 auth = No
#client lanman auth = no
#ntlm auth = disabled

I compared the outputs of smbclient when connecting to localhost and to the router fritz.nas

sudo smbclient -L localhost -U <username-localhost> -d 10
sudo smbclient -L fritz.nas -U <username-fritz-nas> -d 10

in the hopes to identify the settings specific to the server running on the router. I compared the output using Meld. Some of the differences that could be interesting are attached: smbclient-logs.zip

Maybe that helps you solve the issue?

If not, I understand that it is difficult to diagnose and solve the problem since you probably do not have the same router to test what is going on there. But as mentioned, the older version of amaze where the other library was used did work just fine. Maybe you can add more logs in order to more easily identify where the applications hangs?!

[TranceLove]

Some sidenotes...

I think what worked in old jcifs but not jcifs-ng was perhaps some quirks in jcifs was "fixed", either a design decision or a security fix.

After checking with the changelog, these changes may become the next target...

2.1.0

• Send SPNEGO wrapped NTLMSSP tokens, old behavor can be restored by setting jcifs.smb.useRawNTLM=true
• Support for SPNEGO and NTLM integrity (mechListMIC, NTLM MIC), checks can be disabled with jcifs.smb.client.disableSpnegoIntegrity or enforced generally jcifs.smb.client.enforceSpnegoIntegrity

1.5.0

• Fix NTLMSSP anonymous auth, by default use Extended Security for everything.
• Fix SPNEGO NTLM fallback, add option to disable (jcifs.smb.allowNTLMFallback)

Still a marathon to go IMO though... perhaps some back and forths to find out what quirk should be enabled.

[jejo86]

I went through all settings in the smb.conf documentation, which could make smbclient behave similar to the jcifs-ng library, i.e. make it fail. These are the settings I worked with, mostly disabling all options:

client min protocol = NT1
client max protocol = NT1
client ipc min protocol = SMB2_10
client ipc max protocol = SMB2_10

#lanman auth = no
client NTLMv2 auth = no
client lanman auth = no
ntlm auth = disabled
raw NTLMv2 auth = no
client use spnego = no 
allow dcerpc auth level connect = no
client schannel = no
client use spnego principal = no
csc policy = disable
disable spoolss = yes

# auto, mandatory, disabled
client ipc signing = mandatory 
client signing = auto

The result is it is smbclient always connecting to fritz.nas without problems, as long as client signing = auto # or disabled and client min protocol = NT1 # or lower plus client max protocol = NT1 # or higher are set.

If I find the time I could maybe create a minimal example application using jcifs-ng to see what the problem is. Are you using the latest version 2.1.5?

[TranceLove]

@jejo86 Yes, help is always welcomed!😉

As of now we are still using jcifs-ng 2.1.3. But as you said the old generation jcifs (stopped at 1.3.12) which was used by previous Amaze worked fine, I think the whole 2.1 series should work the same for the bug.

[TranceLove]

I went through all settings in the smb.conf documentation, which could make smbclient behave similar to the jcifs-ng library, i.e. make it fail. These are the settings I worked with, mostly disabling all options:

client min protocol = NT1
client max protocol = NT1
client ipc min protocol = SMB2_10
client ipc max protocol = SMB2_10

#lanman auth = no
client NTLMv2 auth = no
client lanman auth = no
ntlm auth = disabled
raw NTLMv2 auth = no
client use spnego = no 
allow dcerpc auth level connect = no
client schannel = no
client use spnego principal = no
csc policy = disable
disable spoolss = yes

# auto, mandatory, disabled
client ipc signing = mandatory 
client signing = auto

The result is it is smbclient always connecting to fritz.nas without problems, as long as client signing = auto # or disabled and client min protocol = NT1 # or lower plus client max protocol = NT1 # or higher are set.

If I find the time I could maybe create a minimal example application using jcifs-ng to see what the problem is. Are you using the latest version 2.1.5?

As note, I got error 0xC0000418 when using jcifs-ng to connect to SMB server having the settings here. However, 3.1.2RC1 from F-droid also failed with jcifs.smb.SmbException: This client does not support the negotiated dialect. :sweat_smile: