SMB File Sharing not working in Ventura

I updated to Ventura 13.2.1 on both my M1 Mac Book Pro and on my Mac Pro tower (Intel). Still having the same problems with File Sharing not working between these two computers. Both computers can access a third Mac, which is an iMac running as a dedicated file server (running an older version of OSX because it is an older iMac). This is beyond frustrating, I had hoped the Ventura update would fix the problem. Back on the phone tomorrow with Apple Support ....

We have tried full server disk access to users on couple of our Macs, and it has not worked for us. We also tried to delete all MS Office application files and re install fresh, and that hasn't helped either. It doesn't appear to be a user privilege issue on the server side, but a Ms office application on the client side in Ventura.

Also, full disk access is not a long term solution, as our users can't be given full access to the entire server's drives. User's access to drives and directories are controlled through login access.

I would be interested to know if both save-new file and on going re-saves of existing files behave for you with all cache removed after the saving action.

If I'm not mistaken, the smbd full disk access is turned on automatically when SMB file sharing is turned on. The way we had implemented SMB on the file-server was through user R/W access to select folders and drives specific to each user. Our file sharing is activated only on the server side and not the client sides. On the client side there is no smbd daemon running.

All clients were Mac OS Ventura (Intel based) and the server was Ventura (M1 based) as well.

Just to clarify, using Batchmod isn't the same thing as simply giving users full access on server settings. There's something that happens to the enclosed items when using Batchmod that solves the permissions issue.

Unfortunately 13.2.1 does not fix anything related to SMB file sharing. Also, nowhere in the patch notes does it say anything about Apple addressing SMB file sharing with this update. I suspect that this will be a high priority for 13.2.2 considering the vast amount of attention this issue is getting online (reddit, apple community, articles, etc). I'm not a computer engineer, but it certainly seems like these guys have gotten to the root of the issue:

https://www.truenas.com/community/threads/smb-permission-issues-on-macos-ventura.104067/

If I'm not mistaken, the smbd full disk access is turned on automatically when SMB file sharing is turned on.

It's not, as noted by many people here. I think it was put into Full Disk Access on my Mac, but it wasn't enabled. When users here noted they could no longer access their Desktop, Documents, and Downloads over SMB, I looked for smbd in Full Disk Access and enabled it to check. I have had to explain to others where to find smbd in order to add it to Full Disk Access. It is completely unnecessary for normal file sharing. It is only under Ventura that the privacy settings prevent seeing folders in the Desktop, Documents, and Downloads folders without user permission. The SMB daemon does not ask for access (at least as far as I could tell).

The way we had implemented SMB on the file-server was through user R/W access to select folders and drives specific to each user. Our file sharing is activated only on the server side and not the client sides. On the client side there is no smbd daemon running.

ll clients were Mac OS Ventura (Intel based) and the server was Ventura (M1 based) as well.

If you use Sharing Only users, you can configure specific permissions for everything within the File Sharing Settings. If you create real users on the Mac, when they log in via File Sharing, they will have whatever permissions they would have if logged in directly. The File Sharing permissions do not override those.

There are times when File Sharing creates ACLs for the folders, and those could possibly override the normal user POSIX permissions.

I can confirm that Apple has changed SOMETHING in 13.2.1 regarding file sharing. I tried 2 virtual machines, one as a server, one as a client.

Fresh installation!

Sometimes it can connect, sometimes the Finder hangs. Sometimes the popup with the list of the shared folders stays forever, sometimes it's being closed and a forever-waiting Finder progress bar comes up. Sometimes it shows the mounted folder on the desktop sometimes, it doesn't. But if it connects, it hangs a few seconds later.

In my opinion, it get's worse with every update. And again: I'm talking about a fresh and clean installation.

Let's hope that Apple doesn't choose to "fix" the issue finally by removing file sharing capabilities in the next major macOS release... :-(

Erratic hangs issue on connection for me as well on 13.2.1, but not with all my share points.

None of the suggested workaround work.

I noticed some logs like "smbd socket_look: rdsz 0 ---> EPIPE". Not sure if related in any way.

I opened the feedback ticket FB11991908.

To end up to this conclusion regarding my own iteration of this SMB issue, I noticed that the last logs emitted by smbd around a failing connection (server side) was

Debug       0x0                  14753  0    smbd: [com.apple.smb:default] darwin_stream_create: opening stream .:AFP_AfpInfo
Debug       0x0                  14753  0    smbd: [com.apple.smb:default] stream_id_create: stream name <AFP_AfpInfo>

And after some Google search on AFP_AfpInfo, it seems to be used to communicate data like extended attributes of files.

I then noticed that the only shared directory which was working for me was a directory without extended attributes. I removed the ones from my other shared directory, and everything worked immediately.

I don't know if it can explain the fact that the problem was resolved for some people when they removed custom volume / directory icons (I think they are stored in the .DS_Store, not sure it passes by the AFP_AfpInfo stream in such case, but possible, and then it would confirm there is an issue in AFP_AfpInfo stream handling ?).

Possible there is actually no relation with AFP_AfpInfo, but in such case, the coincidence was at least productive ;)

It's something I'm doing in a Terminal, yes. You should not remove the directories themselves, we are talking about the actual shared directories, so you would just lose your data in such case.

Just remove their extended attributes with the "xattr -c" command.

@kpmelocoton

Im wondering if BatChmod program will work by checking the box called <Clear xattrs> ......based on your discussion it may.

I thought I had this all solved when of the server administrators created a Word file on her laptop and copied it to the server in our <Shared> files group......everyone else could only read it and not write to it......this I believe is a different problem.

There seems to be more than one problem with File Sharing, and clearing the extended attributes solves the simplest one. This is closely tied to custom icons on the shares as creating a custom icon creates the com.apple.FinderInfo extended attribute.

I don't think it is all extended attributes, but only the FinderInfo extended attribute. I have one other extended attribute on my SMB shares, and it doesn't prevent File Sharing.

I think the FinderInfo attribute can be set for various things not involving custom icons, and that is the only one that would need to be deleted.

I do not know if the extended attributes that could exist on subfolders has any effect.

The following command (after fixing the path to share to match what volumes you are sharing) will remove FinderInfo, only.

sudo xattr -d com.apple.FinderInfo /path/to/share

You can just enter this (make sure you leave a space after FinderInfo), then drag the shared drives to the Terminal window and it will fill in the path.

sudo xattr -d com.apple.FinderInfo 

I have the same problem. Can not connect anymore between MacBook Pro 2020 , MacBook Pro 2022 (M1), MacStudio 2022 (M1) and a MacStudio 2023 (M1). I can see them, but not access them anymore. Also connecting with my apple ID is not possible anymore. all running OS 13.2.1. The problem started with OS 13.2, before that everything worked very well. Tried several workarounds (toglle on/off shared folders, recreated shared folders + I don't have custom folder icons). Nothing worked. Very annoying. Hope for a fix really soon, because now we can't work together anymore on shared videoprojects.

I have tried this suggested fix multiple times, with no luck

What, exactly, did you try? Did you find the extended attribute or custom icon and remove it?

Or, did you not have any of those?

There are some that have problems caused by the FinderInfo extended attribute. There is some other problem. (or problems) that nobody has figured out. It appears you have that problem, along with many others.

Thanks for the response. I might not have done this correctly. I simply Pasted the code you shared in Terminal, followed by dragging the icon for the shared folder/volume into Terminal. I did this for several volumes that I need to share. Sometimes I can access & share the boot drive on the host Mac, and sometimes even open the Desktop on same. But I never can access the various other internal hard drives & external drives on the host Mac. I am pretty Mac literate, but not at the level of this forum. I don't know exactly what the extended attribute or custom icon might be (?).