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: AgNO3/jcifs-ng#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.