Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

Is it a remote time-machine backup, i.e. to a Time Capsule (or a NAS pretending to be one)? Time Machine used to use AFP, but since AFP was deprecated, it now exclusively uses SMB for remote backups. (Specifically, it creates a sparsebundle image on the SMB share, and then locally mounts it.)

Now, Apple has their own implementation of SMB; and it seems to have been seeing frequent updates in Catalina (see https://support.apple.com/en-ca/HT210803).

Since the Apple SMB stack has some decent amount of kernel integration—and Time Machine doesn’t really have any—I’d guess that recent changes to Apple SMB are also the culprit for any freezes where it’s in the critical path.

And Apple SMB seems likely to blame, because there are already other well-known regressions from the recent changes to Apple SMB. Seemingly, there’s a lot of cowboy coding going on in this part of the system right now. For example, macOS can no longer connect to SMB shares via their mDNS names (e.g. smb://example.local). This means that any SMB server that shows up in the Finder sidebar (through an mDNS announcement configured to achieve AFP or Time Machine serving) now just chokes and kills the Finder process when you try to connect to one of its exposed SMB shares through that sidebar connection (see e.g. https://community.synology.com/enu/forum/3/post/129160). You now have to explicitly connect to the share using its IP (e.g. smb://10.0.0.1) from the Finder ⌘K modal.

Weirdly enough, Time Machine itself isn’t broken for the SMB shares it auto-discovers through its configuration modal, so presumably they realized their error in that specific case and made Time Machine pre-resolve the mDNS name in the smb:// URI to an IP address, before attempting the connection. But they forgot to add this same code to the Finder. :/

I'm hitting the stupid SMB bug everyday but the symptom seems to be different. I tried to manually connect to `smb://nasbox.local` in Finder and it works with `nasbox.local` appearing in the sidebar. 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.

However, if the Mac goes to sleep for a while and then later wakes up, I can no longer access the shares with the same message "The operation can’t be completed because the original item for “folder_name” can’t be found".

This is so damn frustrating.

> This is so damn frustrating.

Agreed. And then there's that extremely childish "Windows 95 blue screen" icon representing SMB shares... Really professional.

I think that icon was meant to be bait for Microsoft.

The host metadata, as it shows up in the macOS Finder/open dialogs/etc, is configurable by having your host publish an mDNS _device-info._tcp service record. You can publish a display name (as arbitrary unicode), an icon (as a machine model name), etc.

I'm guessing Apple figured that if they made the default icon insulting, that might incense Microsoft into building mDNS support into their SMB stack, just in order to use it to broadcast that _device-info service, to make Microsoft SMB present more professionally on macOS clients.

Sadly, Microsoft never bothered. But at least I get to use it to make my Linux homeserver look like an Xserve! (See https://www.tumfatig.net/20170607/let-mac-os-auto-discover-y...)

(Though, sadly, this exact combination of mDNS-announcing-SMB is what is broken in the newest macOS, so I can't recommend you follow the above guide right now. Maybe we'll get support for this back in a few releases...)

To be honest, Xserve is the only sane option for displaying a NAS (with its many drive bays! :)

Not all SMB shares. If you use a Mac to host an SMB share, it'll appear on other Macs with a nice Mac icon. ;)

I don't know, I find it funny/charming and I'd be sad if Apple got rid of it. It's something of an easter egg—you can't tell that it's a BSOD unless you open the QuickLook or Get Info window (or set your Sidebar Icon Size to "Large").

> 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…

I've given up on Mac-to-Mac networking in Catalina. All my other (older) Macs in the house can talk to each other just fine, but the new Catalina Mac just pretends to connect to them and fails. I have to use thumb dives to move files to/from it.

Apple networking had mostly "just worked" since the 80s. It took a big hit when they abandoned Appletalk, and now with Catalina it doesn't work at all. Apple has fallen a long way since its glory days.

The annoyance of trying to connect to a remote system and the entire desktop and all Finder windows locking up whilst there is a network request is the most annoying issue. I can't understand why it wouldn't make the request in a thread with a callback on success/failure - instead it seems to be in the primary thread and therefore hang the machine until it decides it can or cannot interact with the remote network share. Pretty shoddy.

Reply on news.ycombinator.com