Hacker News new | past | comments | ask | show | jobs | submit login

> I tried to manually connect to `smb://nasbox.local` in Finder and it works with `nasbox.local` appearing in the sidebar.

Right; that part still works, seemingly because probing for SMB shares doesn’t involve passing an SMB URI through whatever layer of the SMB stack can no longer resolve mDNS origins. It’s only connecting to the shares themselves that generates that arcane error message.

> I can also click `nasbox` (without `.local` and this is advertised by the avahi-daemon on the nasbox I believe) and it opens the network shares fine.

Yup; the Apple SMB stack is seemingly happy to resolve a WINS origin. Which means SMB servers will interoperate fine with macOS clients as long as the SMB server doesn’t run AFP (which nobody has a reason to be running these days anyway) and doesn’t offer Time Machine backup (which... is often the whole point of having a NAS.) If your NAS is configured to offer Time Machine backup, the WINS announcement gets subsumed by/attached to the mDNS host metadata record for the NAS (which is required to make Time Machine work), such that trying to connect to the SMB share via the Networks item (or the sidebar) will try to use the "canonical" mDNS origin for the host, rather than the WINS SMB-service origin—even if mDNS pointed at it.

> However, if the Mac goes to sleep for a while and then later wakes up, I can no longer access the shares

A thing about mDNS is that it gets announced on intervals, and clients are expected to cache it; but like regular DNS, the cached record announcements have TTLs, and you’re not allowed to use a record after its TTL runs out... but unlike regular DNS, you can’t just go re-fetch the mDNS record from the source once it expires; you have to wait for it to be re-announced.

This is why every bonjour/avahi/zeroconf tutorial has a line that says “now wait 15 minutes to see if your changes took effect.”

And this also means that these services inevitably do this thing where their URIs won’t resolve for the first few minutes after your computer wakes up from sleep, until they receive a refreshed announcement of the mDNS peer’s A and SRV records.

This has always been an inherent flaw in mDNS, papered over by various pre-resolution or standards-violating caching strategies by things higher-up the stack than the mDNS resolver itself. I’m not surprised that this sort of hacks papering-over is something prone to regressions, in macOS or any OS.

(This is also why Apple gave up on "Back To My Mac." It was dependent on "Wide-Area Bonjour", which was even more fraught and flaky than regular mDNS, with service records frequently disappearing from their domain, leaving you unable to resolve the address of your remote peer, despite it sitting there happily waiting with ports open. It especially didn't play well with laptops sleeping in a Wake-on-LAN state, despite several generations of Power Nap trying to make it work.)

Jeez, this is so messed up…

So basically I cannot have both Time Machine and SMB from the same NAS box servicing a Catalina Mac? I just tried disabling Time Machine share in Samba and Catalina Mac still complains "The operation can't be completed because the original item for "Share" can't be found." if I click the sidebar to connect to a share.

The sidebar entry is still coming from mDNS. Play with the NAS’s config until it shows up the same way Windows peers with shares do: as an all-uppercase-named machine only visible under the WINS workgroup name in Networks. (Finder will give it a sidebar entry from then on after the first time you connect to it, IIRC.)

Also, wait 15 minutes. Because mDNS.

Thanks for the suggestion. I figured it's actually less painful to just cmd+K in Finder to manually connect to NAS via its local host name before Apple got time to fix the bug…

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact