Configure Samba for Windows 3.1: Difference between revisions
(Create page) |
(Remove redundant information from preamble) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Only do this on a Samba server that is only accessible locally and not accessible from the internet. |
|||
== Compatibility == |
|||
SMB1 and <code>lanman auth</code> support was deprecated in Samba 4.11.0 (2019-09-17)<ref>https://www.samba.org/samba/history/samba-4.11.0.html</ref> as part of the effort to rewrite the VFS layer so that file operations are performed using <code>openat</code>-style system calls instead of paths. This effort was completed in Samba 4.15.0 (2021-09-20).<ref>https://www.samba.org/samba/history/samba-4.15.0.html</ref> |
|||
Samba 4.16.0 (2022-03-21)<ref>https://www.samba.org/samba/history/samba-4.16.0.html</ref> 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 <code>/etc/samba/smb.conf</code> and make sure the following lines exist: |
Edit <code>/etc/samba/smb.conf</code> and make sure the following lines exist: |
||
| Line 5: | Line 15: | ||
<syntaxhighlight lang="ini"> |
<syntaxhighlight lang="ini"> |
||
[global] |
[global] |
||
server min protocol = LANMAN2 |
|||
ntlm auth = ntlmv1-permitted |
|||
server min protocol = CORE |
|||
lanman auth = yes |
|||
</syntaxhighlight> |
</syntaxhighlight> |
||
Then |
Then: <code>systemctl restart smbd.service</code>, <code>smbpasswd -a $USER</code>, and restart the service again. |
||
== Troubleshooting == |
|||
Set <code>log level</code> to at least <code>2</code>, then check the logs at <code>/var/log/samba</code> (or wherever <code>log file</code> points to). The reason for a login being denied should be there. Additionally, make sure <code>ntlm auth = ntlmv1-permitted</code> is set even if no NTLMv1 clients will ever connect to the server; it is a prerequisite for <code>lanman auth = yes</code> being allowed.<ref>https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html</ref> You do not need to set <code>plaintext auth = yes</code> 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. |
|||
<code>server min protocol</code> can be <code>CORE</code>, <code>COREPLUS</code>, <code>LANMAN1</code>, or <code>LANMAN2</code>, but not <code>NT1</code> or later. |
|||
== References == |
|||
<references /> |
|||
[[Category:Guides]] |
[[Category:Guides]] |
||
Latest revision as of 22:49, 21 October 2023
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.
