Configure Samba for Windows 3.1
Only do this on a Samba server that is only accessible locally and not accessible from the internet.
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 = LANMAN2
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.
server min protocol can be CORE, COREPLUS, LANMAN1, or LANMAN2, but not NT1 or later.
