SMB File Sharing not working in Ventura

I had and still have the same problem. Turning off file sharing and rebooting might work one time, but then I have to do it again. The person at Apple I spoke to did not have any other solution. Apple need to fix this.

It has been many weeks since a senior advisor told me my case was escalated to engineering. I have never heard from anyone at Apple since. Whatever this is it will not be fixed quickly. I went out and bought a Synology NAS and put it on my network and use that as my bulk storage location for all the devices in my home and it works perfectly. Either build or buy a NAS - if Apple could figure this out quickly they already would have. Synology and QNAP are the big names in off the shelf NAS products, or you can build your own if you want to go that route with TrueNas, UnRaid, or a bunch of other open source NAS products.

This is the conclusion I reached as well that I could not wait any longer for Apple to figure this out. Initially I built NAS devices as test cases using some older computers using TrueNas and UnRaid - they worked perfectly - so I purchased a Synology box to have a more modern platform than my test case NASes, also the off the shelf NAS devices use less electricity than the big old servers I used for test cases.

I dunno how Apple managed to break network file sharing but they should be ashamed of themselves, this is kindergarten level stuff that any operating system has to be able to do. How Ventura ever got out of testing with this flaw is shameful.

I wholeheartedly agree with you. Some people would say that all we had to do is revert back to the previous OS. In some cases it is not that easy. I'm now happy again as I can access my NAS and USB drives.

We have switched the file servers to Linux Ubuntu. We examined TrueNas, but we’re far more comfortable with the Linux platform. We even used a couple of our Intel based Mac Minis to install Linux. For us it has been accumulative issues, such as abandonment of email and LDAP servers. Then inability to reconfigure Mac Mini hardware in the 2018 onward gave us pause, but we were still loyal then this issue put us and our content at risk.

It has been rather difficult decision after 17 years to make a major back office reform. Our front office will still remain mostly MacBook and MacBookPro.

Hope this is not interpreted as Apple bashing, we needed a realistic and immediate business solution.

We have switched the file servers to Linux Ubuntu. We examined TrueNas, but we’re far more comfortable with the Linux platform. We even used a couple of our Intel based Mac Minis to install Linux.

As it is merely a server, it doesn't really matter what hardware you use.

I don't know if it is possible to install Samba (which you are likely using on Linux) on macOS and force it to use that instead of Apple's implementation, but it is likely more difficult than just setting up a Linux server. If you don't need to use the server as a Mac, then there is no reason to do so.

Yes, we have setup a SAMBA server controlling a QNAP multi-drive system with some mirroring built in. The SAMBA server setup was rather easy. We set up user folders and drive access controls and passwords duplicating what we had on the Mac OS.

The Samba server could also be set up to function as a Domain Controller (DC) as well as OpenLDAP backend.

In terms of the hardware, you are absolutely right, we could have used any other hardware, but we had some Mac Mini 2012 (i5) and 2014 (i7) that were available. Impressive speed running Ubuntu on them.

We are also retiring our old Apple email server, replacing with a brand name running on Ubuntu.

Sad to say the back-end will be transitioned completely to Linux.

I would love to downgrade back to Monterey since there seems to be no fix for this issue any time soon. Apple Support told me I needed a Time Machine backup to downgrade. I don't use Time Machine for backups, but rather Chronosync, which I love. Is there any way to downgrade back to Monterey without a Time Machine backup? Thanks.

All -

Before you give up and go back to Monterey (a disruptive process) - Letting you know I have been engaged with support and feeding logs, videos and reports to Engineering on several occasions. When we have gotten to this step in the past it usually means they are tracking down the problem and working the issue.

So you might want to sit tight before wasting a lot of time reinstalling.

No guarantees tho - it's up to them.

Just a thought for Apple to consider: Perhaps Apple's update supply chain got hacked like the Colonial Pipeline attack almost two years ago. If so, the Ventura 13.2.1 we're all having trouble with might be subtly different from the one that Apple has in Cupertino. I don't want to sound like a conspiracy theorist, but the Colonial Pipeline attack was real, and it would certainly cause Apple fits trying to track down the problems users are having if such a thing had happened.

I personally am disabling file sharing until this issue gets resolved.

Disabling the File Sharing is not an option for me as I need to share files across our network of Macs. Right now I am using a small portable hard drive to physically move digital image files (large) from one Mac to another. How frustrating!

I tried all the supposed "fixes" from deleting VolumeIcon files to turning off file sharing then rebooting and turning on file sharing and rebooting.

I finally went back to Monterey 12.6.3 and file sharing worked again but then other features stopped working like Apple Photos, Apple Music and Apple TV.

So then I updated from Monterey 12.6.3 back to Ventura and files sharing went wonky again.

I will say that it appears to be the "server" side that broke, because I kept my "client" Macs on Ventura throughout the process. They worked and saw all shared files when the server was running Monterey and then did not work when the server was running Ventura.

I actually think that the problem started with the update from 13.1.x to 13.2.1 but have no proof of this.

I did this as well and got going again.

FYI. I also dinked around and created a Parallels 18 macOS Ventura Virtual Machine and moved the files that were giving me the problems into that virtual machine. I was able to turn on file sharing in that virtual machine and voila I could see all the files from my clients with no problems, no spinning beachballs and no client hangs.

I am currently of the opinion that the problem is related to the number of files in the shares. The directory/folder that was giving me problems has 20000+ directory or file entries. For some reason, sharing with Monterey had no problem, and also sharing with a clean macOS Ventura (in the Virtual Machine) seems to work.

One other thing I did was break the large file hierarchy into smaller folders and shared those separately, and that seemed to help the issues.

With all the problems that most of you are experiencing it seems that I should consider myself lucky as I have found work arounds while I impatiently wait for the the next update which hopefully will fix this thing.

I am using an Intel 2018 MacBook Pro as a file server on which multiple drives are mounted and a 2022 M1 MacBook Air to access the file server. Everything worked fine until Ventura.

Both are running the latest version of Ventura and have found the following to be true.

Screen Sharing works in both ways, MBPro > MBA and MBA > MBPro.

I can only file share from the MBPro > MBA so to transfer files I just connect MBA > MBPro via Screen Sharing and I can transfer files either direction.

The only thing I can't do is backup my MBA to the SparseBundle I have mounted on the MBPro. So I am temporarily backing up to a local drive until a solution is found.

So my problem is File Sharing M1 > Intel so I cannot backup over the network.

I am no genius but one of the issues seems related to what processors you are using.

The restarting suggestion did not help. Many other comments are good and relevant, but obviously, they do not solve my issue of accessing files on my Ventura 13.2.1 mac-mini from other macs (which have a variety of OS software).