Configure Samba for Windows 3.1
Before you begin, you should know that SMB1 is very insecure. Only do this on a Samba server that is only accessible locally and not accessible from the internet. Also, an SMB account should already be set up in Samba using smbpasswd.
Compatibility
SMB1 and lanman auth support was deprecated in Samba 4.11.0 (2019-09-17)[1] as part of the effort to rewrite the VFS layer so that file operations are performed using openat-style system calls instead of paths. This effort was completed in Samba 4.15.0 (2021-09-20).[2]
Samba 4.16.0 (2022-03-21)[3] is the first post-deprecation version to remove SMB1 features; wildcards in the copy, rename, and delete commands sent by DOS-based Windows clients (such as 3.1) are not supported, as well as server-side copying. I started seeing issues with Windows for Workgroups 3.11's SMB1 functionality with this release.
If further removals happen, I might fork 4.10.0, 4.11.0, or 4.15.0, and rip out anything unrelated to SMB1 support, try to apply any applicable patches from future versions, and maybe call it something like smb1d.
Instructions
Edit /etc/samba/smb.conf and make sure the following lines exist:
[global]
server min protocol = CORE
ntlm auth = ntlmv1-permitted
lanman auth = yes
Then: systemctl restart smbd.service, smbpasswd -a $USER, and restart the service again.
Troubleshooting
Set log level to at least 2, then check the logs at /var/log/samba (or wherever log file points to). The reason for a login being denied should be there. Additionally, make sure ntlm auth = ntlmv1-permitted is set even if no NTLMv1 clients will ever connect to the server; it is a prerequisite for lanman auth = yes being allowed.[4] You do not need to set plaintext auth = yes for Windows for Workgroups 3.11 support. If the auth settings are correct and the old computer still cannot access the server, double-check that the service was restarted and that user passwords were reset post-setting update.
