If I reset one mac, none of my other macs can ever reconnect unless I reset them to. A way to fix?

[iemcj]

I have a few mac computers/laptops all on the same wifi network and I'm commonly accessing the files on different machines. Under locations on the left hand side I just click on "imac" and poof I'm able to browse it as if it were my own local files.

But if I ever need to reset that other imac, none of my other 5 machines can go back to that imac. It'll still show up as "imac" under the locations tab, it'll show the directories, but if I click on anything it'll close the finder window and say "The operation cannot be completed because the original item for "imac" can't be found."

I can try to once again go to that imac and click "disconnect" and nothing happens. The folders stay visible, it just changes the button to say "connect as" and if I click on it, nothing ever happens.

This has been bugging me for years and I just assumed it was because I was on older hardware/software but it's still just as problematic even with my machines on catalina and using my brand spankin new macbook pro. Surely there's a way to fix this? Isn't it supposed to just work without having to reset every single machine in the office just because one of them did?

 

[xnsys]

I'm getting exactly the same with a NAS and other Windows servers - it appears to be a bug that was existent in an older macOS that has resurfaced - there isn't much you can do apart from use the hostname and connect that way from the finders "connect to server..." option and put in "afp://x.x.x.x" or "smb://x.x.x.x" where x.x.x.x being the IP address of the machine you're connecting to - or wait hoping that apple will fix it in upcoming releases.

Interestingly, a log-out and back in on the machine that cannot connect sometimes (9 times out of 10), fixes this.

I'm starting to sound like a broken record, but I cannot believe just how may bugs that were squashed have resurfaced in 10.15 - bugs which have been there since the first beta, and ones that I've raised previously...

 

[iemcj]

I'm getting exactly the same with a NAS and other Windows servers - it appears to be a bug that was existent in an older macOS that has resurfaced - there isn't much you can do apart from use the hostname and connect that way from the finders "connect to server..." option and put in "afp://x.x.x.x" or "smb://x.x.x.x" where x.x.x.x being the IP address of the machine you're connecting to - or wait hoping that apple will fix it in upcoming releases.

Interestingly, a log-out and back in on the machine that cannot connect sometimes (9 times out of 10), fixes this.

I'm starting to sound like a broken record, but I cannot believe just how may bugs that were squashed have resurfaced in 10.15 - bugs which have been there since the first beta, and ones that I've raised previously...

Ok whew so I'm glad it's not just me, I was worried maybe it was my router being evil but it's literally an apple router so I would certainly hope it wouldn't be the issue. I'll try that going forward thanks!

 

[xnsys]

It seems to be the way that the finder is holding onto the mDNS record - as it will still allow connection using smb://nas._smb._tcp.local for example.

 

[hvfsl]

It could actually be the router causing this. I have seen many routers which allow you to have 2 SSIDs with the same name (one on the 2.4Ghz frequency and one on 5Ghz) cause this issue. Basically some of the computers will be connecting to the 5Ghz SSID and others will be connecting to the 2.4Ghz SSID, but because of limitations with the router, devices on 1 SSID can't connect to devices on the other SSID.

A quick fix is to disable one of the SSIDs or give the 5Ghz SSID another name, so you can make sure all your devices that need to see each other are on the same SSID. Otherwise you will need to get a more advanced access point that doesn't have this limitation.

 

[xnsys]

I don't see how it can be the routers as with the same router, and same configuration this problem doesn't exist for me in 10.14.x

 

[hvfsl]

I don't see how it can be the routers as with the same router, and same configuration this problem doesn't exist for me in 10.14.x

It looks like your issue is a bit different to the OP's as I am assuming you are connecting to devices which are wired in. (Although if you are using a wifi extenders in your house, that could be causing the issue too). But for anyone having an issue like this, it is worth disabling the 5Ghz SSID (or changing the name) just to rule that out.

 

[BrianBaughn]

Do your devices have static local IPs via DHCP reservations on the router?

 

[xnsys]

My machine will connect to both, I've seen it on 2.4 and 5GHz radios - both of which have the same SSID - the point is that if it was working with 10.14 and 10.13 fine, what's changed in 10.15 to stop it working when the router hasn't been changed - and it's still running the same firmware...

I appreciate where you're coming from - but this is like changing the road surface because your car has just had a different style wheels installed...

10.15.x definitely has different WiFi drivers as there is the introduction for WPA3 connectivity, which Apple seems to have implemented quite well, just a shame that the Cisco Mobility Express firmware isn't as good as I did have a play with it.

It's not a networking / WiFi issue and definitely a macOS / Finder issue as when you log-out or relaunch finder it will connect again, WiFi will still be connected at this point, as will a Ethernet connection.

Do your devices have static local IPs via DHCP reservations on the router?

It's not so important if static or DHCP - it's more to do with how the finder is caching the 224.0.0.251 multicast address.

 

[iemcj]

It could actually be the router causing this. I have seen many routers which allow you to have 2 SSIDs with the same name (one on the 2.4Ghz frequency and one on 5Ghz) cause this issue. Basically some of the computers will be connecting to the 5Ghz SSID and others will be connecting to the 2.4Ghz SSID, but because of limitations with the router, devices on 1 SSID can't connect to devices on the other SSID.

A quick fix is to disable one of the SSIDs or give the 5Ghz SSID another name, so you can make sure all your devices that need to see each other are on the same SSID. Otherwise you will need to get a more advanced access point that doesn't have this limitation.

For me this isn't the issue as I only have the 2.4 enabled (It makes more sense for me as I'm in a rural area with little interference and 2.4ghz has better range and penetration than 5 does). So it's not like it's getting confused on which network to join.

Do your devices have static local IPs via DHCP reservations on the router?

I have no idea lol. I just do the normal entering of my network password like I do with every single other wifi network I've ever been connected to.

 

[gilby101]

I think this discussion about wifi, etc. is a red herring for @iemcj's issue. I can get the same thing with Ethernet only Macs. It is an issue at the SMB level in the network stack, not at the physical level.

The issue comes and goes and at times I have both remote host and remote host.local in the Finder sidebar and only one works.

I am now using a bit of AppleScript to mount remote shares. Then I can be sure that the remote shares appear under the local computer location in the Finder sidebar.

Oddly, remote connections have become more stable (working correctly) in the last week.

To see what connections are being made I use the mount (just the one word) command in Terminal.

 

[xnsys]

I think this discussion about wifi, etc. is a red herring for @iemcj's issue. I can get the same thing with Ethernet only Macs. It is an issue at the SMB level in the network stack, not at the physical level.

The issue comes and goes and at times I have both remote host and remote host.local in the Finder sidebar and only one works.

I am now using a bit of AppleScript to mount remote shares. Then I can be sure that the remote shares appear under the local computer location in the Finder sidebar.

Oddly, remote connections have become more stable (working correctly) in the last week.

To see what connections are being made I use the mount (just the one word) command in Terminal.

I too doubt very much that it's a WiFi or Networking issue - my gut feeling is that it's something to do with the implementation of SaMBa. I've not tried with Apple File Sharing as that is now effectively depreciated and not secure.

check out the command "smbutil" - "smbutil statshares -a" for example gives some useful information

After 3 hours of uptime, and working solidly on this machine with no wifi dropouts, and NO sleep cycles I get the following...




So doesn't appear to be related to sleep for connecting to the servers, which is one issue - the other issue is when you wake from sleep and have a share mounted and Finder cannot find it, then it crashes.


Just looking through the system logs - this is looking so much like the 10.10 issue...

default    22:35:13.493932+0000    NetAuthSysAgent    Process 375 is not sandboxed and is allowed to mount a shared volume (0).
default    22:35:13.493967+0000    NetAuthSysAgent    quarantine check returned 1
default    22:35:13.494021+0000    NetAuthSysAgent    Proxy Mount Share: request D8D004B8-9B2C-439A-8828-5BD654F21CF4 from sharingd (375)
default    22:35:13.494092+0000    NetAuthSysAgent    Mount share = Temp
error    22:35:13.494152+0000    sharingd    SDNetworkResolver: handleMountCallBack returned -50
default    22:35:13.494493+0000    Finder    Connection to sharingd became invalid

Time to crash it and issue "sudo killall sharingd" - worked with 10.10 so let's see what happens....

----------EDIT----------

Okay - this is the exact same issue as was present in 10.10.x - issuing the command "sudo killall sharingd" and the finder springs back to life and I can connect to my NAS - so the issue is with sharingd.

sharingd is run by the logged-in user which explains why logging out and back in again would also work.

 

[gilby101]

Okay - this is the exact same issue as was present in 10.10.x - issuing the command "sudo killall sharingd" and the finder springs back to life and I can connect to my NAS - so the issue is with sharingd.

Thanks, I will do that next time. And I really must follow it through the logs - nasty as that is now.

 

[xnsys]

I've updated my bug-report with apple to report my findings - let's just hope that they can fix this soon as it is most annoying.

 

[nocturne1]

I've updated my bug-report with apple to report my findings - let's just hope that they can fix this soon as it is most annoying.

Reviving an old thread, since the bug still seems to exist. Any update from Apple on this?

 

[xnsys]

What do you think? That would mean admitting that there is a bug in their precious system

 

[nocturne1]

What do you think? That would mean admitting that there is a bug in their precious system

LOL. Well, they may have closed as duplicate

 

[rlf613]

Relaunch finder will fix this. No need to reboot.

 

[xnsys]

Doesn't fix it - finder just crashes more and freezes the whole system

 

[rlf613]

You did this? I'm really unsure how relaunching finder would cause it to freeze and crash more..

 

[xnsys]

Because the problem here is another service / daemon that the Finder calls upon, that crashes badly and relaunching the finder means it cannot access the "sharingd" (for example), and will not start-up.

 

[TonoT1]

Okay - this is the exact same issue as was present in 10.10.x - issuing the command "sudo killall sharingd" and the finder springs back to life and I can connect to my NAS - so the issue is with sharingd.

sharingd is run by the logged-in user which explains why logging out and back in again would also work.

You are 100% correct, this indeed fixes this BUG....
Thanks for sharing!

 

[shish1]

issuing the command "sudo killall sharingd" and the finder springs back to life and I can connect to my NAS - so the issue is with sharingd.

This finally fixed the issue for me on my M1 laptop connecting to another M1 Mac. Thank you!