Monterey struggles with file sharing

TidBITS Talk
21

I’ve made headway on my Monterey challenge with file sharing, and I think it’s now fixed.

The problem was a DNS issue, combined with seems to be a bug in Monterey’s file sharing code.

My gateway router is an ASUS RT-AC86, running the well-known “Merlin” variant of the stock ASUS firmware. It uses dnsmasq for its DHCP server, as well as for local DNS. (I’ve used dnsmasq for at least a decade, as part of Tomato firmware builds). I configure the dnsmasq DHCP server with a number of reserved IP addresses for servers, printers, and most other known devices on my LAN. In addition, I’ve generally configured dnsmasq with “local” specified as the local domain. That simplifies making connections to various LAN devices, and saves me having to remember and type IP addresses when I want to connect to local printers, file servers, routers, IP cameras, etc.

The domain .local is also used by mDNS for discovery and address resolution of devices that support mDNS. Most Apple devices do, and we have a lot of Apple devices, all advertising themselves with mDNS (Bonjour). The .local addresses used by dnsmasq and the .local addresses used by mDNS have happily coexisted in the past. But there’s something in the Monterey implementation that seems unhappy with the use of .local by dnsmasq.

I changed the configuration of the ASUS router to use “home” as the local domain instead of “local”, and file sharing happiness on my M1-MacBookAir was restored. I certainly don’t understand why. The file server with which the MBA has been struggling to access is a Mac mini running Big Sur. It uses mDNS to advertise itself as an SMB server at miniserver.local. Using mDNS, the MBAir can obtain the mini’s LAN address (both IPv4 and IPv6 addresses). Since it speaks mDNS, there’s no reason for it to issue a unicast DNS query to my router. If it did, dnsmasq would return the same IP that an mDNS query obtains direct from the mini. For that matter, the MBA could obtain the IPv6 address advertised by the mini, and use IPv6 to make the connection.

I mentioned above that I suspect Monterey being partly culpable. A MacBook Air (with Mojave) on the same LAN has not encountered the file sharing issues that I see with Monterey. For clarity, the issues occur when initiating file sharing by clicking on a device icon in a finder sidebar, not when using cmd-K.

In any event, having changed the local domain specified in dnsmasq from “local” to “home”, file sharing across my network seems to be working fine. I have to remember to enter “router.home” or “printer.home” etc to connect to LAN devices, but I can probably deal with that.

For completeness, while researching this problem, I learned that the official TLD now sanctioned by the IETF for home networks is “home.arpa”, not “home”. Details are found in the relevant RFC (RFC8375).

I’m indebted to @trilo for suggesting that DNS might be implicated.
And to @Shamino for the primer on mDNS.
And of course to Adam for providing this community forum…

5 Likes
22

Glad to hear it. I’m actually surprised it ever worked, since most systems running mDNS (everything in my home these days - macOS, WIndows 10 and Linux) are configured to reserve the .local domain for mDNS. So a real DNS server with that name may not get much traffic at all.

The only systems in my home where a .local request goes out over normal DNS (in my case, to a Raspberry Pi, where my home DNS server resides) are those too old to support mDNS. Everybody else sends the request over mDNS.

Now, if your device’s mDNS host name matches your DNS host name, then it will respond to it’s name .local regardless of how the request went out. But if there’s a mismatch (e.g. the host has one IP address and the DNS server is serving a different address), then you could have problems, because one of those servers will be serving the wrong address. DHCP-assigned dynamic addresses and other kinds of self-assigning address systems can often be the culprit here.

But if everything matches, then it may simply be yet another instance of network voodoo. Weird things happen when there are misconfigurations like this (e.g. two different protocols configured to respond to the same namespace), even if it seems on the surface that it should work.

Thanks for the reference. That’s good to know.

In my case, I used to have a static IP address from my ISP and I’ve got a domain registered against that address (under the old locality-based part of the .us top-level domain). Even though that address no longer exists and there is no server running under that domain, I continue to use hostnames under that domain for my home network.

I should probably change it over to .home.arpa (and request deletion of that no-longer-valid domain) at some point, but it hasn’t been an issue so far.

It’s more likely that one of these days I’ll pay for hosting for a personal web site (since ISPs no longer offer free hosting and the other free hosting services are terrible) and I’ll create a sub-domain under whatever name I choose to use for my home LAN. But it’s been over 10 years already, so I can wait a few more. :slight_smile:

23

Good to hear it’s sorted. DNS can be a quirky thing and whenever I see a machine stalling when connecting to a server I like to try it with the IP address just to see if it works. If it instantly connects via IP it tends to suggest a DNS issue and offers a place to start looking.

24

Pretty much the only entity on my network that would ever send a .local request to the on-net DNS server (dnsmasq) is me! I’m lazy (and forgetful), so being able to just type “router” or “vpn” or “laser” or “nas” into a browser has become my habit when I want to connect to one of the hosts on my LAN.

I double- and triple-checked that dnsmasq had the same data for the Mac mini: same name (“miniserver”), same IP, etc. The Bonjour browser app showed what mDNS was advertising. Everything matched. But there’s more than network voodoo going on. My Monterey Macs would handle file sharing just fine if I used cmd-K to make the connection. But not when clicking on the miniserver’s icon in a Finder window sidebar. That really makes no sense to me. Monterey seems to be using a different methodology to resolve the address and establish an SMB session depending on how the user initiates the transaction. Another Apple mystery.

With file sharing now working fine, I can now focus on my next Monterey mystery - why Time Machine is so unhappy.