Monterey struggles with file sharing

TidBITS Talk
1

Help wanted :smiley:

At the start of the year, I retired a much-loved 2015-vintage MacBook Pro running Mojave and replaced it with an M1 MacBook Air. The latter shipped with Monterey, and has been nothing but headaches, not the least of which is an on-going problem with something as basic as file sharing. Hours troubleshooting and searching on Google, without success. More hours on the phone with Apple support have been fruitless. I’m hoping the TidBITS brain trust might have some insights on what’s going on.

I have an M1 Mac mini (Big Sur) running on our network as a household file server, among other things. Attempts to connect to ‘miniserver’ from a Finder window on the MBA are problematic. The miniserver appears in the list of locations in the sidebar of a Monterey finder window (as it should). Clicking on miniserver displays Connecting… at the top of the Finder window. This usually fails after 30s (with Connection Failed), but I’ve seen it take as long as 4:30 to timeout and report failure.

Another way of connecting is with the Connect as button at upper-right of the Finder window. This solicits the Name and Password pop-up window to establish the connection, which then usually fails with an error box: “There was a problem connecting to miniserver. The server may not exist…”. But it doesn’t always fail. Occasionally, after 10-20 seconds, the list of available volumes available on miniserver will appear. If I then select one with a double-click, it generally take 30 seconds before the list of files & folders on the volume appears.

While investigating this headache, I found that I can successfully connect using Finder/Go/Connect to Server… (Cmd-K shortcut), and then entering smb://192.168.1.6 (the IP of the Mac mini). Or smb://miniserver.local (the miniserver’s mDNS name).

I contacted Apple support, and eventually made my way through the AppleCare gauntlet to a Senior Advisor who took an interest. He had me install their Capture Data utility on both machines, and use it to capture detailed logs from the MBA and the Mac mini simultaneously while attempting a connection. He apparently sent the massive log files off to Engineering, but no insight was obtained. He eventually suggested that I boot the MBAir into the Recovery partition and re-install Monterey from scratch. Not much else to try, so I did so. That odyssey took over 24 hours to download the 14.3 installer (over my 500 Mbps fibre connection)! Parenthetically, I’ve determined why the download from Apple’s update server was so sluggish. Perhaps a topic for another day.

In any event, the re-install of Monterey made no difference. Nor did the recent update to 14.3.1 (an 8-hour download ordeal).

I’m pretty sure that this is a Monterey issue. My wife’s MBAir (still on 14.3) exhibits the same problem. However, an Early-2015 MBAir running Mojave handles file sharing connections to the Mac mini just fine.

For completeness:

  • My LAN is mostly GigE.
  • WiFi coverage is a pair of Unifi 802.11ac access points, one upstairs, one downstairs.
  • I ruled out any mystery WiFi issues by buying a USB-C adaptor and connecting the MacBook Air with an ethernet cable directly to the same GigE switch connecting the Mac mini.
  • The Mac mini has its internal SSD, plus an external 2TB drive dedicated to TM backups (another major headache), and a 4TB RAID drive which is the family repository for photos, movies, music, s/w distros, and other the digital detritus that one collects.

There’s gotta be something pretty basic that I’ve overlooked. Apple can’t possibly have botched implementation of file sharing in Monterey…

Insights or suggestions will be most gratefully received.
Thanks.

2

Why is this not an acceptable way to do it, if it works?

2 Likes
3

Actually, that’s what I do too. I type CMD-K and add my favorite servers (one file server and two VNC servers) to the list of favorites. Then I can simply double-click the favorite when I want to connect.

I find that much easier than browsing for the servers every time.

3 Likes
4

I agree with paalb and Shamino, I always use Command=K to access servers because - as you’re seeing - I’ve found browsing for servers and trying to connect can be problematic.

It’s also a good way to rule out DNS issues when you can test smb://192.168.1.6 vs smb://example.com

I see the same thing when using the Screen Sharing app. It can be notoriously unreliable when browsing for machines but very reliable when typing an address directly.

To be honest I’ve never really considered it an issue but now you’ve raised it it’s clearly not as robust as it should be.

4 Likes
5

I haven’t needed to work with file sharing in a long time, but what I’d do is connect manually once and then make an alias to the server or the desired folder inside and use that from then on.

3 Likes
6

A couple of reasons:

  • other members of the household are not facile with cmd-K keyboard command and/or entry of arcane (to her) strings like smb://nnn.nnn.nnn.nnn. Over many years of using Macs, the well-known and -learned method of just clicking in the sidebar for a desired folder or server has become second nature. Introducing a new methodology (opening the Connect to Server dialog box and then selecting from its list of Favorites) is a step backwards in UX.
  • my cursed M1-MacBook Air is having ongoing problems with another macOS stalwart: Time Machine. The Monterey logs reveal that TM seems to be having problems finding the miniserver, and maintaining connections to it. I suspect that this underlying defect in Monterey’s file sharing ability might be part of the problem that TM is having.
7

That is good reason in my household too. The problem is that browsing for servers has been unstable for many years. You have been lucky if you have a good experience.

Aliases, as Adam describes, still work with Monterey on both “server” and “client” side. Maybe that is suitable alternative. Also, you can add the shared disk to login items.

1 Like
8

Hmmm… I hadn’t thought of DNS. Is it even in the loop for resolving local IPs? Resolving a host name in your example above (“example.com”) requires a query to a DNS somewhere in cyberspace to obtain the server’s public IP address. But file sharing from one Mac on the LAN to another is entirely local. What’s the mechanism by which you think DNS might be an issue? I may be overlooking something…

I’ve done a little more investigation, and I think the issue might be related to addressing. Using a Bonjour browser utility, I looked at the Bonjour broadcasts on the LAN. The Mac mini is advertising itself as an SMB server with three addresses for SMB over TCP/IP:

  • miniserver.local.
  • 192.168.1.6:445
  • fe80::40e:blah:blah:445

The latter is the self-generated Link-local IPv6 address of the Mac mini.
If I use the Connect to Server method, the first two addresses always succeed. But attempting to connect with smb:// [fe80::40e:blah:blah]:445 fails
→ (“The server may not exist”).
I don’t know if the Connect to Server dialog is IPv6 literate. The failure might due to a limitation in Connect to Server, or might be due to a bug in the IPv6 implementation.

My knowledge of IPv6 is sketchy at best, but I’m now wondering if Monterey might be preferentially attempting to connect to the mini using IPv6 when one clicks on the icon in a Finder window’s sidebar. The use of cmd-K (then entering the IPv4 address) would avoid use of IPv6. That might be the reason for the different result with file sharing (and also screen sharing, as you mentioned). Entirely speculation.

9

Adam,
Doh!! I should have thought of that.
Thanks for (once again) refreshing my aging memory cells. I’ve concluded that my grey matter is like an SSD with insufficient spare sectors - after lots of write cycles, it’s becoming unreliable.

2 Likes
10

It’s done via Bonjour Service Discovery, which in turn is based on mDNS.

The hostname with a “.local” domain suffix is the mDNS name. macOS (and any other computer that supports mDNS) tries to resolve these names by sending DNS requests to a multicast address (will go to all devices on your local subnet and may go elsewhere if you have an mDNS gateway server installed). The device that owns that name will respond with its IP address.

The link-local IPv6 address should work just as well as the IPv4 address, assuming it is on the same subnet. But there could be network issues preventing it.

For example, if one device is on wired Ethernet and the other is on Wi-Fi, your router might be preventing IPv6 traffic from crossing between the two segments. Ditto for the multicast traffic used by Bonjour. If you suspect this might be the case, check your router’s configuration.

I had this problem years ago when I was using Verizon FiOS. Their router wouldn’t propagate multicast traffic from Wi-Fi to Ethernet. So my wired devices could access services on Wi-Fi devices, but not vice versa. I couldn’t reconfigure the router, so I ended up disabling its Wi-Fi and used an external access point (a Linksys router configured for bridge mode) for the Wi-Fi, which didn’t have any such problem.

1 Like
11

I use screen sharing a lot to access other Macs around my home. For years I’ve been using a free menubar utility called “ScreenSharingMenulet” by Stefan Klieme. It’s dated 2010 but still works fine on my MBP M1 and has no trouble accessing Macs on old operating systems. It simply displays a list of all the Macs it can find on your local network and when you select one of them, Screen Sharing prompts you for credentials (if you let Screen Sharing save them, you can just press Return to log into the remote Mac.)

I like it better than aliases because the menu is current – if a remote Mac can’t be accessed for some reason, it won’t show up on the list, which is great for troubleshooting. With an alias, you have to wait for it to try and connect and fail before you realize there’s a network issue.

1 Like
12

I have had server sharing difficulties too. These were most frequently after I replaced a server and also after I renamed a server.

I suggest you look in your keychain, find the entries related to the server and delete them. You can create new ones when you next connect.

1 Like
13

Maybe heresy to some, but I’ve found success using AppleFileShare in my home/office with mixed OS Macs, including two Monterey machines. I simply replaced smb:// with afp:// and my file sharing woes vanished (knock on wood).

I don’t know what features I am not getting by using the older protocol, not officially supported by Apple, but it is much more reliable for me (perhaps because I am connecting to older Macs?)

14

David,
Thanks for the reply.
When the device that owns the mDNS name responds, does it reply with its IPv4 or IPv6 address? (or both if it has them?). If the client, in my case the MacBook Air, got back the IPv4 of the Mac mini, the MBA would then ARP to determine the MAC of the mini. I don’t know enough about IPv6 to know how v6 devices on a LAN communicate, but since the physical layer is still ethernet, I assume they also use MAC addresses.

My router is not in the equation. Like you, I also use separate access points. My WiLAN is a pair of Unifi 802.11ac APs, which sit on the same flat GigE LAN as the MacBook and Mac mini. Broadcast packets between wired and wireless segments don’t have to traverse my router. However, it’s possible that the Unifi APs might be interfering with IPv6 traffic. That’s something I’ll look into. Perhaps it’s time to set up Wireshark and see what’s on the LAN.
Thanks for the lead.

15

Definitely an old/new thing.
From what I can tell (using the Bonjour Discovery scanner), my Monterey MBA does not advertise its file sharing capability over AFP. Neither does my Big Sur Mac mini. (they both advertise only as SMB). They can both use AFP as client devices to connect to older Macs, or other servers that support AFP.

I think you’ll find that your Monterey Mac can use AFP to connect to older Mac models (Mojave or earlier, I think), or NAS devices or other servers that support AFP. But not to each other.

16

Paul,
That’s a good idea - something I hadn’t thought of. Thanks!!!

17

Marc,
+1 re ScreenSharingMenulet. It also works well on my M1-MBAir.

18

It responds with whatever kind of address was requested. Like normal DNS, there is an “A” record containing an IPv4 address and an “AAAA” record containing an IPv6 address.

Like unicast DNS, an application can request all kinds of records, including IPv4 addresses, IPv6 addresses and special “service discovery” records which can be used to learn what network services the device is providing.

19

This may not be relevant to your problem, but I encountered something similar when I added a newish MBPro to my local network of older machines. Browsing the network, Monterey could see the Mojave and Snow Leopard machines, including their external drives, but refused to connect to the Mojave system itself. After much hair-pulling, I found an obscure note to the effect that Monterey can’t handle APFS drives via AFP, and apparently Mojave was advertising itself through AFP. Once I defined the connection as SMB, I could instantly connect via Go/ConnectToServer (Cmd-K).

I haven’t tried connecting Monterey to the Panther machine yet, but Panther connects to Snow Leopard, which is all I need. Panther also connects to the oldest machine in the network, which is Mac OS 8.1, and is the only machine that can do so. Keeping old machines running (though powered down when I don’t need them) is one solution to the problem of essential but non-upgradable software.

2 Likes
20

Carl,
Thanks for the post.

From reading various articles and exploring the various Macs on my LAN, I’ve concluded the following:

  • Monterey and Big Sur systems can connect to older Macs using either SMP or AFP (if the older Macs have those protocols enabled for file sharing). But Monterey and Big Sur no longer support AFP as servers. (ie, other devices can’t connect to them over AFP). I think this explains various (contradictory) articles I’ve seen about whether or not those OSes ‘support’ AFP. Apple did drop AFP support for Monterey and Big Sur on the server side, but not on the client side.
  • I have a 2015 MacBook Air running Mojave: it still offers both AFP and SMB connections to clients. Ditto for an old Mac mini with El Capitan. I don’t have any Catalina systems so don’t know whether they support SMB on server side.
  • I have a really old Mac mini (2,1) from 2007 still in service. It’s in the basement running Lion (10.7) with some HA software and a big hard drive as a file server. As a server, it supports file sharing over both AFP and SMB, but only SMBv1. A few years ago, I acquired some home security cameras that can save video footage to an SMB server. But when I tried to configure them to write to the Mini’s HD, I discovered they require SMBv2. Not compatible with Lion. Ms. Google found an old SMB add-on (SMBup) that endowed Lion with SMB2 capabilities, and the cameras now write to the file server with no problem. The vagaries of SMB1 vs SMB2 might explain various reports that different versions of an OS do (or do not) support SMB.

A useful (and free) tool for spelunking what’s on a LAN is Lily Ballard’s “Discovery” app from TildeSoft. It watches the Bonjour traffic on the network, and will reveal what hosts are advertising what services. what ports they’re using, even what storage volumes are available for sharing.

1 Like