I have a strange issue where I cannot connect to SMB shares via the servername of my TrueNas server. It shows up on my windows clients just like my other servers, but if I double click to connect it throws a windows networking error saying “Windows cannot access \MyTrueNasServer” error code 0x80070035. So the TrueNas servername is visible in the windows network, however it is not accessible.
Further investigation - using cmd and ping - Ping request cannot find host MyTrueNasServer
I can connect - by using the \{server ip addr}. I have full SMB functionality from there.
I do have other NAS servers on the network which resolve fine via the SERVER_NAME and SMB works fine.
Note: I have a test laptop that produced the same symptoms until as part of my Univention server testing I changed it’s DNS server to the Univention server instead of my pfSense gateway/router. I don’t know how that changed anything since the Univention server does not as yet maintain any information about my TrueNas and neither Truenas or Univention are configured to recognize each other on the network or rely on services from the other.
You need to have a proper DNS entry for the TrueNAS in whatever is handling DNS. A way to get around the DNS issue is to go to each device and add a host entry.
Yes - this would solve the issue, however, somehow the other devices on the network are working without DNS entries, perhaps they are using Bonjour or Netbios somehow. I would love to be able to determine how clients are actually resolving the name. Oddly when I ping the ‘net bios’ name for my Truenas from a Windows 10 computer that is part of the active directory that I am testing, it resolves to TrueNas.local and I get ping replies… there is not record on the DNS server that maps to TrueNas.local, so somehow that name is broadcasted or queried from the TrueNas itself since the DNS name is TrueNas.MyLocalDomain.local not TrueNas.local (which is set on my TrueNas).
Do you know of a tool or method to determine where and by what mechanism client computers are deriving their mappings? (I suspect that several different name resolutions are at work, DNS is actually easy to ‘Dig’ but the other mechanisms I am not sure of).
That’s interesting, so the idea would be to point it at my internal DNS server (which would in turn forward queries to the internet for non local resolution)?
Do you happen to know if pfSense supports being a slave DNS? It would be ideal if the pfSense could still be the DNS server for both the internal and external network, and cache or slave records from the internal DNS for the AD.
I’m having the same problem, and it’s inconsistent. One PC on the network always connects by name and another PC almost never does but occasionally gets to the point of asking for credentials and then fails. It never fails when I provide the IP address. Nothing else on the network is having a problem.
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.
Have you tried setting the domain name under TrueNAS’s Network | Global Configuration setting to match the rest of your network’s domain? I found issues just like you’re describing when the TrueNAS domain doesn’t match, even when it’s not AD. I had just a simple network and as soon as I set the TrueNAS domain to match the router’s domain, everything worked.
I encountered a similar problem when adding a truenas machine to a non-domain network with 5 other working freenas machines. One desktop running Windows 7 could see the server in Neighborhood but not expand to see the shares giving the 80070005 error. It would not ping by name but would ping by ip4. Incidentally, you can add a Discovery Method to the Network tab to show the discovery method as WSD, NetBIOS, SSDP,etc and the IP address which was correct. My router and local DNS is pfsense.
It turns out that my issue was I had forgotten to change the workgroup under Global Configuration. The windows 10 machines didn’t choke but the win 7 machine couldn’t resolve the ping by name. Discovery was by WSD.