SMB File Sharing not working in Ventura

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

Just had a call with a Sr. Rep (not engineer), and they pulled another diagnostic report from my machine. This time with the firewall inactive. Apparently the engineers are advising the senior reps that there is an issue with the system firewall which is impacting SMB file sharing on all 13.2 machines.

Here are some steps I've produced to get SMB File Share to work:

• Turn off file sharing and clear all shared folders from the server
• Disable system firewall on Host computer
• Restart the host computer
• Download Batchmod and run Batchmod on the shared folders using the below settings:

1. 1. Drag folder into Batchmod "File" bar
   2. Switch Owner: Root
   3. Switch Group: Admin
   4. Make sure "R" "W" and "X" are checked for every single box (owner, group and everyone)
   5. Check boxes "Change Ownership and Priveleges", "Unlock", and "Clear ACL's"
   6. And check the folder at the bottom "Apply to Enclosed"
   7. DO NOT check "Clear Xattrs"
   8. Click apply and enter your password

• Now that the permissions are reset on the folders on your host computer, turn on the file sharing, and add the desired shared folders one by one. Don't mess with the permissions once you've gotten to this point

I've been able to test that this works for the past couple hours, and i've been running SMB File Sharing off my MBP with no issues. The only folder I seem to be having issues with is an alias of a Onedrive shared folder, and I suspect this has to do with a permissions block. But all of my other folders work.

Can anyone else please replicate these steps and tell me if it fixes the issue for them???

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.

It would be difficult without time machine because you need to erase everything on the target disk.

You could do one time machine backup for this migration only. I did it and everything was fine.

Sometimes, when you desperately need file sharing to work, the quickest way is to downgrade. I gave up after hours of time wasted with timeouts, reboots, disable/enable file sharing, chasing custom attributes and what not...

My steps performed to downgrade:

1. perform a time machine backup - use an external usb disk with spare space
2. boot into the already created macos monterey installation USB stick
3. quit installation and open disk utility - erase the existing disk (the one with Ventura on it)
4. you will be restarted after the erase process (stupid new thing) so you need to boot again to the USB stick mentioned at point 2
5. install monterey on the disk erased at point 3
6. during the migration assistant process, connect your backup disk (with time machine backup files) and choose "from a mac, time machine backup or startup disk" and select as source the disk
7. done!

Thank you!! Just turning file sharing off and rebooting didn't work for me, but following your added instructions (removing all shared folders from the list, then making sure they were all unchecked in "Get Info" before rebooting) did the trick for me. Also, I don't know if the order matters, but after rebooting I:

• enabled file sharing
• shared the folders by checking "shared folder" in the Finder "Get Info" boxes for all the folders I needed to share

I was afraid my shiny new M2 mini server was going to be a very expensive brick, but this approach seems to have done the trick for me!

Hi folks,

like all of you, I had issues with SMB shares on Ventura. I was stuck on 13.1 because the "reboot trick" did it for me in this particular version. Everybody said that 13.3 (and now 13.3.1) solves the issues and I can confirm that. Because of other problems (Wallpaper was reset to default after every reboot, external drives took 1-2 minutes to mount) I decided not to update, but to do a fresh installation of 13.3.1.

All. Issues. Solved.

Regarding SMB:

• Shares with custom icons are working as expected: SMB shares can be mounted on other Macs and can be accessed on iPhone with VLC and with GoodReader
• Saving files on SMB shares from another Mac still create those folders with the .sb2 suffix, but they disappear within a second

Well, I'm on iOS 16.6.1 and Ventura 13.5.2 and rebooting didn't work for me - as well as disabling File Sharing, SMB option/restarting/re-enabling, disabling firewall. Nothing for it. I simply can not connect using the smb:// address as I have for the last 10 years. Gettin an interesting message.. but it's totally erroneous.

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!

I file share between an M1 Mac and Intel MacBook Pro without issue. I can file share with both to/from a Catalina mini without issue.

There are some privacy controls in Ventura which require adding smbd to Full Disk Access if you want to share Desktop, Documents, or Downloads.

Please describe the problems you are having.

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.

UPDATE: Once I turned my iMac off, and back on, File Sharing started not working again. That means that I have to turn off File Sharing before turning the computer off, and turn File Sharing on after turning the computer on for File Sharing to work.

This solved the problem for me too. Just to be clear, I tried rebooting, toggling it off and on again, rebooting again. I even tried waiting a bit in between toggling it off and on again. I still couldn't connect. The only thing that got it working was turning it off, restarting while File Sharing was off, then turning it back on afterward.

YES ! I have been struggling with this ever since the Ventura update. I have a Macbook (M1) that backups on a drive attached to a Macmini (M1) that acts as a networked Time Machine disk. This set up stopped working after updating both Macs to Ventura. Could not figure out what was wrong. Your solution works permanently. That’s a tough one: thousands if not milions of folks will struggle with this bug.