in a recent Tumleweed update samba was updated to version 4.11.0
In this update support for smb1 has been removed.

I currently use a couple of Buffalo NAS drives - one of which is about ten years old and only supports smb1. Since the samba update I can no longer access this drive.
Is there a way to get smb1 support switched back on in samba 4.11?
Currently I can only access the drive via ftp

From the release notes…

SMB1 is disabled by default

The defaults of ‘client min protocol’ and ‘server min protocol’
have been changed to SMB2_02.

This means clients without support for SMB2 or SMB3 are no longer
able to connect to smbd (by default).

It also means client tools like smbclient and other,
as well as applications making use of libsmbclient are no longer
able to connect to servers without SMB2 or SMB3 support (by default).

It’s still possible to allow SMB1 dialects, e.g. NT1, LANMAN2
and LANMAN1 for client and server, as well as CORE and COREPLUS on
the client.

Note that most commandline tools e.g. smbclient, smbcacls and others
also support the ‘–option’ argument to overwrite smb.conf options,
e.g. --option=‘client min protocol=NT1’ might be useful.

As Microsoft no longer installs SMB1 support in recent releases
or uninstalls it after 30 days without usage, the Samba Team
tries to get remove the SMB1 usage as much as possible.

SMB1 is officially deprecated and might be removed step by step
in the following years. If you have a strong requirement for SMB1
(except for supporting old Linux Kernels), please file a bug
at and let us know about the details.

I guess it might be time to retire that old nas (although ti still works well) and switch completely to my other (that supports smb2)

Well, I think it is a good idea to retire any old devices only supporting SMBv1, but the release notes do explain how to implement it if necessary eg by adding ‘client min protocol=NT1’ in smb.conf

It has been fairly well publicised. One of many such articles…

SMBv1 is a major security hole today.
One of many ways it’s used is many if not most or nearly all Ransomeware attacks.

Likely the most appropriate question is what you think you can’t do over an fTP connection that you were able to do with SMBv1?

Read, write, mapping to a drive or “place” are all possible over FTP in place of SMB (any version).

So, be specific what you want but think you’re missing and maybe you’ll have a “better” solution without sacrificing the possible loss of your files.


Completely agree with this!

There are a lot of files on this drive with Japanese names which ftp (via dolphin) chokes on.
I guess there is probably some setting in dolphin that would stop it choking on these files in ftp? (smb works flawlessly with the Japanese characters)

This might be a server-related issue. You should be able to interrogate the server’s support for UTF8 with an ftp client using the FEAT command…

FEAT FTP command
The FEAT command providesFTP clients with a mechanism of quickly determining what extended features the FTP server supports. If this command is supported, the server will reply with a multi-line response where each line of the response contains an extended feature command supported by the server.

In any case, you could test behaviour using the ftp CLI.

unfortunately the (older) NAS does not support utf8.

I think the best course of action is to enable SMB1 for the purpose of transferring the files from the legacy NAS to a newer secure storage environment ASAP.

Option “vers=1.0” enables access to OS/2’s LANMAN shares, which NAICT is the same situation.

Yes, if mounting a samba share (as opposed to samba browsing/access via Dolphin or smbclient)

More info

man mount.cifs