SMB File Sharing not working in Ventura

Barney-15E wrote:

The guest login has nothing to do with the Guest account. It is just an anonymous login. That login would have access as determined by everyone.

I beg to disagree. I have the Guest User (user name) enabled with "Allow guest users to connect to shared folders" enabled.

Using the FILES APP on my iPhone, I use "Connect to Server" using iMac.local. For the "Connect As" prompt, I'm selecting "GUEST" instead of "Registered User" (which prompts for Username and Password - GUEST does not) and it connects and displays shares as expected.

If I disable the Guest User access in Settings>Users & Passwords>Guest User and log out, no Guest User is available in the login screen. Furthermore, the iPhone FILES APP will no longer connect to the previously created server connection.

The Guest User on the Mac is definitely the same GUEST used in the iOS FILES APP when using the Connect to Server utility. The EVERYONE group has read-only permission as default but I updated Sharing & Permissions on my user folders to read/write so I have full to my files.

As I previously mentioned, this will due until Apple fixes the Authentication Error issue. I spoke with countless Sr. Analysts on this problem and was finally told Apple is aware of the issue but have no solution for it yet. This was before 14.1 and 14.1.1 so it might be time for another callback on that case!

Update:

1. We just updated the the Ventura (file server) with Version 13.2.1 (22D68) and it seems most access restrictions are resolved (for us).
2. We also updated the users / client machines with Version 13.2.1 (22D68). The users have access to files (mostly office files) on the file server without any access control issues.
3. Client machines log into the server using (smb://192.168.xx.xx)
4. The Microsoft Office Apps (Word and Excel) on client / users updated Ventura 13.2.1 continue creating the ".sb" cache directories / folders that are not removed by the Apps when re-saving the same file on the server. This is an improvement, as these ".sb" files are not created for new documents anymore.
5. The users are now able to delete these directories on their own remotely without admin assistance.
6. The users machine behaves the same way accessing and saving Office documents on the back end Linux file-server. This indicates the issue related to the Microsoft Apps leaving cache directories on the file-servers originates from the client machines updated with Ventura.

There seems to have been some improvement on SMB access to the server, however the issue of Office App permissions using the SMB from the client machines running new version of Ventura still remains.

P.S. our platform includes both M1 and Intel based (2020) Macs.

After I installed macOS Ventura my File Sharing stopped working. I wasn't able to connect from my Windows computer to my Mac anymore.

I had to turn off File Sharing, reboot my computer, and then turn on File Sharing again. It started to work after I did that.

The turning off File Sharing, reboot my computer, and then turn on File Sharing again, did the trick! Thank you. Ever since I upgraded to Ventura, I started having problems with File Sharing, but this simple steps solved my problem.

I am having sharing issue to in osx Ventura. I try every possible thing, but only thing works is the turning off the firewall.

It seem like it blocking smbd, netbios, launchd, 445 port and many other services. I have turn off the firewall deleted "com.apple.alf.plist" at "/library/preferences/", restart the osx, turn on the firewall and restart the osx. It works after that but than restarting 3rd time it goes back to problem. So I turn it off completely as no solution found internet and waiting for next update. Hopefully apple will solve the issue.

Try turning off the firewall and restarting the computer. Also you can reset the firewall with below steps but you will loose the firewall settings. So if you try reseting the firewall, the save your firewall option setting by writing down the paper the path of software and setting button option.

Reseting firewall

-----------------

Delete "/library/preferences/com.apple.alf.plist" and reboot.

This is a recap of how I seem to have resolved my file sharing issue. Maybe it will be useful to others.

1. Under: General > File Sharing and Media Sharing, I switched both OFF on both iMacs, shut down both machines, restarted both, and turned File Sharing and Media Sharing back on.

2. What follows happened exactly the same on both iMacs: 


Under: Media Sharing > under the (i) icon 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 Apple ID & 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 read that Home Sharing has been turned on and the appropriate Family Icon Drive appeared.

3. Under: General > Sharing > Media Sharing > Home Sharing & Share Media with Guests. 


Log on to both computers with the same Administrator ID and Password

4. Under: (Your Name) > Family Sharing, select Users who can have access.

Make sure all have Read & Write Permissions.

5. Under: Privacy & Security > Full Disk Access > SMBD is on.

6. Under: Desktop Menu > Go > Connect To Server, I've saved the functioning path to the other device. Example: smb://(other-mac-name)._smb._tcp.local

I have Energy Saver > Wake up for Network Access Off so, I think that's why the other computer has to be awake to access... but I haven't tested that.

Good luck.

Hi tresinnoctem,

I tried a few things in virtual machines to recreate the bug: It's impossible. When you install Ventura from scratch, file sharing works perfectly. Also when start with 12.1 or 13.0 and then upgrade to 13.2: In all cases file sharing continues to work. So in principle, it works. Therefore, it must be a configuration error why it's not working for us. I still assume the firewall to be turned off so that we can focus on the file sharing issue itself. My Mac mini was an 10.14 Mojave installation and made all updates until 13.1.

Please have a look at this file: /Library/Preferences/com.apple.AppleFileServer.plist

(You can open and edit it with Xcode e.g.)

On my Mac mini it's full of parameters of all kind.

But on a clean Ventura 13.2 installation, its almost empty. Only one parameter is present (kerberosPrincipal).

Try to remove all the other parameters from that file and reboot.

Does it work?

Kind regards from Germany

Has anyone tried this?

From:

https://mjtsai.com/blog/2022/12/30/fixing-smb-file-sharing-in-ventura/

“When migrating from an earlier macOS to Big Sur & newer, this key in:

/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist, gets migrated:

<key>LocalKerberosRealm</key>

<string>LKDC:SHA1.xxxxxxxx</string>

Apparently Net Auth gets "confused" by the Kerberos Realm and hangs.

Delete:

com.apple.smb.server.plist (you'll need to authenticate), then restart, com.apple.smb.server.plist gets created & properly populated without a Kerberos Realm.

After doing that the Synology no longer spontaneously dismounts or fails to mount, plus File Sharing on the fixed Macs works.”

I can attempt this later today and report back. Soon as I get another window of time to do free beta testing for a buggy OS !!

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 ;)

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 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.

Thank you, this worked for me as well. I had tried everything in your post *except* removing the previously shared folders from the list in Settings as part of the process. I went to the list of shared folders in "File Sharing" (click the little info circle to open a dialogue that shows the list.) I removed all folders from the list, turned off file sharing, unchecked "shared folder" in all Finder Get Info boxes, and rebooted. After the reboot, the folders are shared normally. Time Machine backups now work normally. Sharing has survived multiple reboots over two days to be sure, so I am happy. 

abromber