SMB1 compatible device will not connect to Server 2019 share, connects to Server 2012 r2, continuious 4625 with known good credentials

Hello,

I have a very odd issue that I've searched to great legnth but I have been unable to identify a solution.

Here's the situation, an on-site appliance specifically a FaxFinder Fax Server appears to be a Unix based appliance with SMB1/CIFS support to connect to a Windows file share. Currently this appliance connects to a server running Windows Server 2012 R2 Standard that is acting as a DC/File Share. We are intending to retire the 2012 box in favor of a Windows Server 2019 Standard install.

On the Server 2012 r2 box, we use AD credentials to access the share with no issue, I have checked the SMBServer logs on the 2012 r2 box and it doesn't specifically state, like the 2019 box does, that the appliance is attempting to connect via SMB1. I guesstimate this is because the user logins are all successful on the 2012 r2 machine, or 2019 has added logs since SMB1 is disabled by default.

Here's what I see in the SMB Logs on the 2019 box when I see a failure to connect. (I can provide the etlx upon request)
An Event ID 3000
SMB1 access
Client Address: 192.168.88.21
Guidance:
This event indicates that a client attempted to access the server using SMB1. To stop auditing SMB1 access, use the Windows PowerShell cmdlet Set-SmbServerConfiguration.

After this I get a 551 stating this even though I am positive I have the correct credentials
*SMB Session Authentication Failure
Client Name: \192.168.88.21
Client Address: 192.168.88.21:35154
User Name: scan
Session ID: 0x0
Status: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xC000006D)
SPN: session setup failed before the SPN could be queried
SPN Validation Policy: SPN optional / no validation

Guidance:
You should expect this error when attempting to connect to shares using incorrect credentials.
This error does not always indicate a problem with authorization, but mainly authentication. It is more common with non-Windows clients.
This error can occur when using incorrect usernames and passwords with NTLM, mismatched LmCompatibility settings between client and server, an incorrect service principal name, duplicate Kerberos service principal names, incorrect Kerberos ticket-granting service tickets, or Guest accounts without Guest access enabled*

I also get an Event ID 4625 in the Security Logs stating bad username or password but I know they are correct.

So on to what I have tried:

1. Try a different user account with known good password
2. In Group Policy change "Network Security: Lan Manager Authentication Level" to Send NTLMv2 response only. Refuse LM (and all other NTLMv2 options listed) This is set to the default of "Send NTLMv2 response only" on the working 2012 server
3. Verified that "Microsoft Network Client: Digitally sign communications (always) is disabled
4. Verified that User Rights Assignment in GPEdit matches on the servers
5. Restarted both client and server
6. Changed login syntax from "domainname.local\username" to "username"
7. Changed server target on appliance to FQDN of server "\servername.domainname.local\share" as well as IP address "\192.168.0.10\share" and "\servername\share" and changing the all the back slashes to forward slashes since it's a unix based machine I'm connecting from however the working server is using FQDN syntax with 0 problem.
8. Compared most if not all Group Policy settings between machines and they appear near identical from all the security standpoints that I have reviewed.

Just looking to see if anyone else has an idea of where to proceed. This is a very specific issue and I've run into similar problems in the past but I've not nothing on this one. I hope I've provided enough information on this but please ask questions if you'd like clarification!

Thanks!