Server doesn't exist error mounting DFS share.

[s_castle]

HI Guys,   We've been having trouble with our Macs connecting to our home areas, which are on an Active Directory DFS share.   When we try and connect, we get the message the server may not exist or it is unavailable at this time.  Windows machines connecting to the same DFS share have no trouble, and running the command "smbutil dfs " with the relevant share details returns what appears to be a correct list of servers and share names.

Doing a google, I found https://community.jamf.com/t5/jamf-pro/issue-connecting-to-dfs-share-with-high-sierra/m-p/188998, but it didn't make any difference, presumably because the servers are already running at least SMB 2 (i think it might be 3).

I quickly pinged all the servers listed in the DFS listing, and they all respond.

Any ideas of what I can do to at least diagnose the problem, and hopefully solve it?  

This problem is happening on fully up to date installs of Catalina, Big Sur and Monterey.

[jhalvorson · Accepted solution]

@s_castle  After you run the smbutil dfs command, it should provide the referral network address that is a FQDN (fully qualified domain name).

For example:

smbutil dfs //company.orangeroot.org/dept/infotech

------------- Domain Entry 1  -------------
Domain requested : /company.orangeroot.org
                  ExpandedName: /ADDC101.company.orangeroot.org
                  ExpandedName: /ADDC102.company.orangeroot.org

------------- Entry 1  -------------
Referral requested : /ADDC101/dept/infotech
     list item 1 : Path: /ADDC101/dept/infotech
     list item 1 : Network Address: /fileserver123.company.edu/infotech
     list item 1 : New Referral: /fileserver123.company.edu/infotech

If the Entry 1 referral network address offered is a valid Fully Qualified Domain Name, then that is what the Mac will try to connect to.  In the example, the Mac would effectively connect to smb://fileserver123.company.edu/infotech

If the referral network address offered is something like /AD101/depart, then I believe you'll need to point this out to the admin of your domain controller.

[s_castle]

Turns out not all the servers listed in the DFS share had FQDNs.   I can't change that, but I've been able to change the DNS suffix settings on the affected machines so they are now accessible.   

Basically, the problem was that the DNS settings for each device (picked up from DHCP)  included two sub domains, but not the root.   The servers are in the root domain, but not either sub.    The Macs were just searching the two sub domains, not the root.   Adding the root domain to the Mac's DNS Suffix search list solved the problem.

Weirdly, Windows just copes with this, so it's clearly searching the root as well.   The machines are on the same subnet, so are picking up DNS details from the same source. Unless our Windows admins encountered the same problem and rather than fixing the problem at the source, just edited the Windows DNS Search suffixes via Group Policy or some such.