SMB File Sharing not working in Ventura

After reading that the latest Ventura release fixed reported file sharing issues i retried with a share on AppleTV Infuse app (media player app). Works fine until you shutdown the Mac and the share is completely forgotten and can’t connect.

The only way to get it working again is to turn off file sharing on the Mac and reboot, turn it back on and setup share again on AppleTV which works perfectly until the next Mac shutdown. Rinse and repeat. So still broken for me.

I had some time to futz with this again, updates to 14.1.1 but could not get File Sharing to work by turning File Sharing off, rebooting the Mac (and router)then turning on File Sharing again.

As per this article, SMB File Sharing is supposed to happen on port 139.

TCP and UDP ports used by Apple software products - Apple Support

With Stealth Mode disabled in Firewall, I'm noticing Port 139 is not even listening.

 Open TCP Port: 88     kerberos

Open TCP Port: 445    microsoft-ds

Open TCP Port: 625    dec_dlm

Open TCP Port: 3689   daap

Open TCP Port: 5000   commplex-main

Open TCP Port: 5900   rfb

Open TCP Port: 7000   afs3-fileserver

Open TCP Port: 49177

Open TCP Port: 49733

Port Scan has completed…

I opened up ports 135-139 on my Router (port forwarding to my Mac) but that did to bake any difference. To me, it looks like there's problem with the port that handles SMB transactions. Im getting Authentication errors when attempting to connect too server from the Files App (on iPad and iPhone) and this would explain that. If it can't connect to authenticate, well, that would explain it as that's the first thing in any session.

I tried nc -zv iMac.local 139 from he command line (stealth mode still disabled on Firewall) and returned this,

nc: connectx to iMac.local port 139 (tcp) failed: Connection refused

nc: connectx to iMac.local port 139 (tcp) failed: Connection refused

nc: connectx to iMac.local port 139 (tcp) failed: Connection refused

nc: connectx to iMac.local port 139 (tcp) failed: Connection refused

So. clearly, there is an issue with the SMB port. Still stumped....

Whatever. The point is, the Guest User can be used to access shares while the other users attempting to authenticate can not.

Access to shares is dependent on the Login type and what access that type of login has.

If a user account exists on the server and is used to login to the server, they should have the same access that they would if they log into the Mac directly.

If it is a sharing only user, then they have the access as set in file sharing.

If you enable guest remote login, that is a sharing only user and should have the access granted to "everyone" in the File Sharing setup.

Please log a bug - the open a tech support case. They will fix nothing because we complain here. We need to generate cases, and FOLLOW UP. Make them fix it.

I’ll try disabling and reboot Mac and router. 🤞

I tried the "turn file sharing off, then reboot, then turn it back on trick and it didn't solve it for me. Other users on the network can access the files but whenever they save any changes, a temp folder is created in this format "filename.xlsx.sb-***" where *** is about 10 random characters. Those temp folder don't disappear automatically. The only accumulate. I spent 90 mins with Apple Support on the phone and it still wasn't resolved. :-(

I seemed to have resolve the file sharing issue... at least for the moment.

I turned off File Sharing and Media Sharing on both iMacs, shut down both, restarted both and turned file and Media Sharing back on. I don't know if that even mattered.

Now, this happened exactly the same on both iMacs... In Media Sharing under the (i) there is the option to turn Home Sharing on. It was on so I turned it off and turned it back on again. This required my AppleID & Password which I entered. This gave me an endless spinning wheel by the ID I had to Option-Command-Escape out of System Settings. I went back and tried again and this time it said Home Sharing has been turned on and the appropriate Family Icon Drive appeared.

This happens to me, but I detected it only happens when Screen Sharing is-was connected, apparently VNC service has conflicts with SMB service. So To allow the data to work, I need to not have been connected with Screen Share. (thats why it works)

but then, If I connected to read files, I cannot connect to VNC server on my MacMini with M1 and Ventura updated.

I have found a work around to share files and it works very well so far......I only have a small staff for file sharing so Im not sure this will work for large numbers of people.

Here is what I did....have dedicated M1 mini for sharing......there are 2 levels of access rights....one level that all files are read and write for admins and 1 for staff....staff cannot read everything but what is assigned to them

1. Set up both Administrator and Standard User Accounts for everyone sharing the files
2. Set up as many folders as you want under Macintosh HD/Users/Shared
3. Drag files and sub folders under #2 above and arrange them based on who you want to see what files (permission rights)....in other words.....what to standard users get to see.....plus this can be broken down my user as well
4. If you have different access rights to your files make up a chart of who is supposed to access to what folder and or files......group your files according to Admins and staff appropriately.....
5. Download BatChmod....this is a batch program that will assign access rights to individual files or a group of files in a folder
6. Run BatChmod to assign access rights.....if you are changing a group of files in a folder, dont forget to check "Apply to Enclosed"......this will assign access rights the with same permissions to every file in that folder
7. Additionally, if only one standard user has different rights than another standard, then each folder and file will have to be changed in either System preferences/General/Sharing/File Sharing or "Command I" for each file and folder....this is a PIA

Anyway, it works great for us....no more fiddling around

Bob

An update for my situation, where nothing works for more than a few seconds (and Firewall settings (not enabled anyway) make no difference.

I use the Infuse app on the Apple TV to access and play from the SMB shared folder on my macMini - and it does not seem affected at all!? It has been going a week now without any disconnects!

But if any client Mac tries to connect via SMB, either Monterey 12.6.3 or Ventura 13.2, then disconnect after seconds. Disable on host, restart, reconnect, then clients connect again but disconnect after seconds. If I manage to get a file transfer working, then it will complete that single file transfer (even if it is a minute in duration) then disconnect immediately afterwards.

Could it be a client issue rather than the host?

Is the disable-reboot-enable merely getting the client to connect, but then it trips up again?

I have had so many issues with SMB sharing for the last three major OS releases but this is the worst, the prevalent one is double clicking on files on the server will intermittently not open the file. Sometime I can drag the file on the host onto its application on the client and that sometimes works, but often not even that will work.

So is the problem with the client not with the host?

I'd like to believe that they're hard at work on a solution right now, but the reality is (and history has shown) that they prioritize security over functionality 9 times out of 10, and this issue will most likely fall back in priority until it becomes a big enough problem for them. I highly encourage everyone on this thread to submit bug reports, otherwise we won't see a fix for a few OS updates. People need to call in and complain, and escalate this issue to the highest possible technical support channel. I know it's a pain in the ***, and the reps will waste your time doing mundane troubleshooting, but this is the only way it will get their attention.

Running with the firewall off not a good idea either.

This is not better than turning off sharing when shutting down - then on when restarting.

The best thing we can do is open a support case and compel Apple to fix this properly.