A few other thoughts:
- Given the use of AD, this could be a naming issue. If the Windows boxes are receiving a domain name from the DC, they may also be automatically appending it when doing name-based connections, so even though you are telling it to go to \MyTrueNasServer, they may be attempting to connect to MyTrueNasServer.domain and never getting a proper IP. Attempting to ping by name should give you an idea whether or not that is happening, and adding a DNS record in the forward lookup section of the AD DNS may resolve.
- Split DHCP / DNS in an AD environment can be a challenge. With AD (I’m sure you know) you HAVE to have the DC as the DNS resolver. In all of my client locations we have the DC pointed to the pfSense box instead of external DNS for forwards, but I have not been able to get the DC to trust the pfSense box for local domain lookups. Because of that if you are using pfSense for DHCP, even with DHCP reservations, I don’t think you can get those network names propagated up to the DC automatically.
- This might (maybe, possibly) also be related to issues with SMB versions in Windows. A good article talking about some of those here:
In another article I read one of those SMB version issues was resolved after the user discovered that, although windows was claiming it was up to date, there was a failed update he found in update history blocking further updates from being seen.
4. I have personally seen this with the “open share” piece mentioned in the article above. I can’t connect from a currently patched version of Windows to my Open Canary devices by name because my file shares don’t require authentication. It’s been a while since I tested, but the error I was getting wasn’t about the nature of the share, it was simply saying it could not connect to the device name (don’t remember the error code given), but I could open the connection by IP.
HTH.