Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I received a message from Apple yesterday:
”As a result of your feedback, there are changes in the latest update, build 22E5236f, that have resolved this issue.”
I’m on vacation and away from my Mac for the next 2 weeks 😲 so I won’t be able to test.
Hopeful! Time to update my test machine to 13.3 beta 3. Strangely enough nothing about this in its release notes.
 
Hopeful! Time to update my test machine to 13.3 beta 3. Strangely enough nothing about this in its release notes.

That's pretty common... only a few outstanding bugs are mentioned in each release, but I bet dozens of minor ones are usually fixed.
 
I have just experienced this smb file sharing issue with a Windows 7 PC. Ventura doesn't recognize the Windows machine unless I go directly to it via entering the ip address. Then, having mounted it, files won't upload or download from it. Yet no problem with Ventura to a NAS or another Mac running Mohave.

Pretty outrageous that Apple would cripple a core function of the OS and let it go unfixed for so long. Speaks volumes about their priorities. Strongly considering returning the M2 pro mini as just days to go on the 14-day return window. Hard to justify keeping a machine on a hope of a fix. Back to the MacPro until a fix is verified.
 
I have just experienced this smb file sharing issue with a Windows 7 PC. Ventura doesn't recognize the Windows machine unless I go directly to it via entering the ip address. Then, having mounted it, files won't upload or download from it. Yet no problem with Ventura to a NAS or another Mac running Mohave.

The ip address issue is nmb rather than smb - the name resolution part of the protocol. And working with Windows 7 shares won't be impacted by the extended attributes issue that this thread seems to have settled on as the cause.

Since Windows 7 is so old, I wonder if it's just Apple eliminating support for older protocols - or being less tolerant of subtle variations of protocol implementations.
 
The ip address issue is nmb rather than smb - the name resolution part of the protocol. And working with Windows 7 shares won't be impacted by the extended attributes issue that this thread seems to have settled on as the cause.

Since Windows 7 is so old, I wonder if it's just Apple eliminating support for older protocols - or being less tolerant of subtle variations of protocol implementations.
Really? I thought SMB was backwards compatible with older versions.
 
Last edited:
Really? I thought SMB was backwards compatible with older versions.
Have you tried configuring protocol selection with the nsmb.conf file? If you force your Mac to use smb v1, you might have luck with windows 7.
 
Ventura doesn't recognize the Windows machine unless I go directly to it via entering the ip address.

I've been puzzling over why you would have a problem with name resolution. This has nothing to do with the problems you have when you use IP address.

I assume you are using something like Command-K from finder to type the Windows 7 machine name. So, "smb://machineName" doesn't work, but "smb://10.1.2.3" does. I also assume you're not appending ".local" to the machine name.

Is there any chance you set up your new machine on a different LAN segment from your Windows machine?

MacOS, unless I configure it otherwise in the nsmb.conf file, uses NetBIOS to do name resolution to find my Windows 11 machine. That should work fine when looking for a Windows 7 machine.

But, NetBIOS is broadcast based and, unless you're doing something fancy, is restricted to your local LAN segment. So if you have another network, reachable by IP address, but not on the same broadcast segment, then you would get the behavior you are experiencing. That could easily happen to me since I have multiple LAN segments in my house.

By the way, I can look up my Windows 11 machine using the name XYZ.local. That won't use NetBIOS; it uses mDNS instead. That would not work against Windows 7 unless you have some software (e.g. Bonjour) installed. I briefly thought your new Mac was trying to use mDNS to find your Windows 7 machine, but I see no evidence of that kind of behavior using Wireshark on my brand new Mac, unless I put ".local" at the end of the name. Apparently Microsoft is phasing out NetBIOS in favor if mDNS and I wondered if maybe Apple had jumped on that bandwagon too early. But that would have been ridiculous, even by Apple's standards of carelessness.
 
  • Like
Reactions: osplo
13.3 beta 3 appears to have fixed this issue! Also, no new issues so far.

Two questions:
Did you have to install it on the client hosting the share, the client connecting to the hosted share, or both?
Are the client(s) Apple Silicon hardware?

As much detail as you can provide would be helpful to others before tinkering with beta releases.

Thanks
 
Two questions:
Did you have to install it on the client hosting the share, the client connecting to the hosted share, or both?
Are the client(s) Apple Silicon hardware?

As much detail as you can provide would be helpful to others before tinkering with beta releases.

Thanks
FWIW, I installed the latest 13.3 Beta 3 on: MBP 2020 13in, MBP 2018 15in, Mac Mini 2018, MBP 2019 16in, and iMac 2020 27iin...all Intel. Only observable/discernable change so far is that local SMB file sharing now works between all, without kludging up Finder. Can't otherwise tell the difference so far from macOS 13.2.1.

YMMV....but I'm happy to have file sharing back, without any side-effects so far...

Finny
 
  • Like
Reactions: osplo
I've been puzzling over why you would have a problem with name resolution. This has nothing to do with the problems you have when you use IP address.

I assume you are using something like Command-K from finder to type the Windows 7 machine name. So, "smb://machineName" doesn't work, but "smb://10.1.2.3" does. I also assume you're not appending ".local" to the machine name.

Is there any chance you set up your new machine on a different LAN segment from your Windows machine?

MacOS, unless I configure it otherwise in the nsmb.conf file, uses NetBIOS to do name resolution to find my Windows 11 machine. That should work fine when looking for a Windows 7 machine.

But, NetBIOS is broadcast based and, unless you're doing something fancy, is restricted to your local LAN segment. So if you have another network, reachable by IP address, but not on the same broadcast segment, then you would get the behavior you are experiencing. That could easily happen to me since I have multiple LAN segments in my house.

By the way, I can look up my Windows 11 machine using the name XYZ.local. That won't use NetBIOS; it uses mDNS instead. That would not work against Windows 7 unless you have some software (e.g. Bonjour) installed. I briefly thought your new Mac was trying to use mDNS to find your Windows 7 machine, but I see no evidence of that kind of behavior using Wireshark on my brand new Mac, unless I put ".local" at the end of the name. Apparently Microsoft is phasing out NetBIOS in favor if mDNS and I wondered if maybe Apple had jumped on that bandwagon too early. But that would have been ridiculous, even by Apple's standards of carelessness.
The only problem I am having now is the Windows 7 machine name doesn't appear in Finder. I see now that even though I have typed the ip address in the go-->connect to server menu Ventura has translated it to the machine name; so presumably if I had typed the machine name it would have found it.

On the smb performance issue between the M2 and Win7 machine, seems to work almost normally now. If I move files using Carbon copy cloner via erthernet speeds are as expected. However, if I drag and drop files from Win7 to M2 there is a small but noticable delay in starting the operation, then it goes quickly. Moving files via wifi between my M2 Air and the Win7 machine is still very problematical as there is a significant delay (1 minute+) in starting a copy operation but it eventually proceeds normally. So don't know what is going on there as I have a very good wifi signal (5Ghz).

Hoping that next update will fix it.
 
Yes, that is my experience. 13.2.1 breaks SMB/Finder file sharing, 13.3 BETA 3, has fixed it for me.
It was broken for me in 13.2 as well. But see, this proves that Apple DOES listen to us. I remember last year when Monterey 12.3(.1) had the bug preventing FireWire video capture from working, but 12.4 fixed it after many people posted about it online.
 
Yes, that is my experience. 13.2.1 breaks SMB/Finder file sharing, 13.3 BETA 3, has fixed it for me.
Does it still work?

It used to work here at the office until I updated my Mac Studio to Ventura. File sharing was broken. It stopped working between iMac 2016 and Mac Studio. I replaced the iMac for a Mac Mini m2 pro and Studio Display. And we thought we'd go back to work..

:mad: and then..you guessed it. Still broken. File sharing is not working. Finder freezes. Other apps crash.

Very very frustrating.
 
Mine is still working fine on 13.3. Beta 3. I think it's been almost a week now.
okay, great! So no more trouble with finder and loading files. Here I have the problem that he suddenly no longer sees the files and if you go to another folder you see them and then you don't see them again. then things freezes.
 
okay, great! So no more trouble with finder and loading files. Here I have the problem that he suddenly no longer sees the files and if you go to another folder you see them and then you don't see them again. then things freezes.
Just to make sure: You are indicating that you are still seeing File sharing & Finder issues after upgrading both client side and server side to Ventura macOS 3.3 BETA 3 (or 4) ? That is not my observation here across an iMac 2020 27in, MacMini 2018, MBP 2018, MBP 2019, MBP 2020 (all Intel). But all have been updated to Ventura 13.3 Beta 4.

I'm very confident that 13.2.1 introduced the issue, and if you stay on that, File-Sharing/Finder is broken. It requires to update to at least 13.3 Beta 3 (or later) for the fix.

(Just to note, I have NOT observed ANY other issues with Ventura 13.3 Beta 4 so far. In fact, to be honest, I appears to run better than Ventura 13.2 GA release....making 13.2 "feel" like the "beta"....lol)
 
Just to make sure: You are indicating that you are still seeing File sharing & Finder issues after upgrading both client side and server side to Ventura macOS 3.3 BETA 3 (or 4) ? That is not my observation here across an iMac 2020 27in, MacMini 2018, MBP 2018, MBP 2019, MBP 2020 (all Intel). But all have been updated to Ventura 13.3 Beta 4.

I'm very confident that 13.2.1 introduced the issue, and if you stay on that, File-Sharing/Finder is broken. It requires to update to at least 13.3 Beta 3 (or later) for the fix.

(Just to note, I have NOT observed ANY other issues with Ventura 13.3 Beta 4 so far. In fact, to be honest, I appears to run better than Ventura 13.2 GA release....making 13.2 "feel" like the "beta"....lol)
No, I don't work on Betas. I'm done with all macs on 13.2.1. So a definitive update to 13.3 is very much desired!

Sounds good! When would the final version come out?
 
No, I don't work on Betas. I'm done with all macs on 13.2.1. So a definitive update to 13.3 is very much desired!

Sounds good! When would the final version come out?
Well, it looks like you are in luck. My iMac (on 13.3 Beta 4) just got notice that 13.3 is available to update. Since all my Ventura Macs are on the Beta 4, I assume this is 13.3 GA release day.
 
  • Like
Reactions: Citroentaart
Well, it looks like you are in luck. My iMac (on 13.3 Beta 4) just got notice that 13.3 is available to update. Since all my Ventura Macs are on the Beta 4, I assume this is 13.3 GA release day.
Replying to myself. It seems today's notice from SW update is RC build 13.3. (Release Candidate) But, this means official GA release should be coming very, very soon...maybe even next week.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.