The solution is to set one of the Local Computer Policies to "Guest Only". See the image below. This solution found through trial and error. Note the line highlighted in blue.
Note the text below (emphasis added):
"This security setting determines how network logons that use local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. The Classic model allows fine control over access to resources. By using the Classic model, you can grant different types of access to different users for the same resource.I do not have a local account credential (in short, no password). Once I switched "Network access: Sharing and security model for local account" to "Guest only", I was able to login to my computer running Windows 10.
If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. By using the Guest model, you can have all users treated equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read-only or Modify.
Default on domain computers: Classic.
Default on stand-alone computers: Guest only"
Related to this is the fact that Microsoft depreciated SMBv1. This was not an issue related to my current post, but was an issue a while back, so I am posting the solution for how to restore SMBv1. The following post by Microsoft was a useless dead-end, but it does provide some gobbledygook context. SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709 and later versions.
The following post provides a solution on how to reactivate SMBv1 so that your Linux computer can access Samba shares on a Windows 10 computer. How to access files on network devices using SMBv1 on Windows 10.