After upgrading to 13.2, I was unable to connect to my network shares connected on my Mac mini, most of which were on a SoftRAID managed OWC RAID enclosure. It turns out that this appears to be associated with drives that have custom icons, and since all SoftRAID drives have custom icons, this means that all shares have to be to folders on the drive, not the drive itself.
This seems to have gotten around the issue on my setup here.
@rnb2
the issue is that we were asked to make SoftRAID volumes the type "removable" to avoid a Time Machine kernel panic.
So you need to specifically share the volume in sharing (+share), which usually works, and in some cases, yes you need to also share a folder inside the volume.
For me, connecting to my server didn't start working again until I removed the share to the drive itself - after I did that and did "Connect as" in Finder, I was able to browse my shared folders. Unfortunately, even that failed when my backup jobs actually ran, and as of this morning, I'm back to not being able to connect to my shares at all.
After a couple setbacks, things seem to be stable now - I had another custom icon lurking in a shared folder, and eliminating that seems to have (hopefully) taken care of the sharing issues I was having. It doesn't appear that the custom icons for SoftRAID volumes cause issues as long as you share folders rather than the drives themselves.
@rnb2
We are in the process of filing a formal bug report to Apple, in case that has not been done before. At least there are relatively easy workarounds.
It helps that this can be triggered by any custom folder icons, not just SoftRAID volume icons.
I've run into this issue as well, SoftRAID XT 7.0.1 on macOS 13.2 after an upgrade from Monterey. I can share non-SoftRAID drives on my file server but not the SoftRAID drives.
I've tried sharing a folder on one of the SoftRAID drives independent of sharing the whole drive as I had been doing. Also tried with sharing turned on for the whole drive plus a folder, and sharing just the folder with sharing for the whole drive disabled. The folder has the standard OS icon, not custom, and I can't seem to get any sharing working on a SoftRAID drive.
If there are any other suggestions for getting this working that would be helpful. I'm about ready to shift the SoftRAID drives back to standard Apple drives if I can't get this sorted out.
@ tfritz
this is an annoying issue, as with clean installs of 13.2, I cannot reproduce this issue. Sharing works fine. Its strange, as its clear this is a bug that users have been blasting Apple over for the past couple weeks.
How are you sharing your volumes? On the same local network? Are they on 13.2 also? If I can reproduce it, maybe we can find a workaround until Apple fixes this.
All machines are on the same local network. The file server is an M1 Mac Mini running OS 13.2 with the SoftRAID drives in an OWC four-bay Thunderbolt 2 enclosure connected to a Thunderbolt 3 port with an adapter. The machines on the network are an Intel iMac (OS 13.2), a Mac Studio ( OS 13.0), and an old Mac Pro running High Sierra. All of these machines were able to connect to the server over SMB and reach the SoftRAID drive when the server was running OS 12. Upgrading to 13.2 last week started the problem.
Is there anything else I can tell you that might be helpful?
So you went from 12 to 13? did you try using in sharing prefs, the + and adding the volumes specifically?
So I guess picked a very bad time to replace my 2018 i3 Mac mini with a new M2 Mac mini. I've spent two days trying to figure out what the heck was going on. The hack to use folders with in the shared volumes is so far working.
My system is a M2 Mac mini with two Thunderbay 8, two Mercery 4 bay drives. Is there any other info that could help?
Sorry for the delay in replying.
I did upgrade from 12 to 13.2. As part of my attempts to get SMB working again, I removed the two volumes I was sharing in the system settings and added them back in. I also reset the permissions on both volumes. None of this solved the problem.
Thinking that the problem was somehow a conflict with SoftRAID, I formatted a new drive as APFS with Apple’s Disk Utility and copied my data to it from the SoftRAID volumes. I removed the SoftRAID drive from the enclosure and the system preferences sharing and shared the new volumes. I was then able to log in to the server from other machines on the network and read and write files to the volumes, everything seeming normal.
However, after a few hours the shared volumes became unresponsive on the remote machines and I couldn’t interact with them. Other functions of the server continued to behave normally but the SMB sharing deteriorated and after rebooting a remote machine I couldn’t access the drives.
It seems that the problem may not be related to SoftRAID. I’ve lost a lot of time to this issue and need.to get things stabilized so I can get work done on my clients’ projects. I’m going to roll back the OS to 12 as I’ve read others have done and hope that returns things to normal. I’ll report here how that goes.
@tfritz
I have a couple other ideas. If you have BackBlaze, make sure you have upgraded to the latest version.
One report I saw, said create a new folder, share it, copy your data to that folder. I wonder if that helps
This is a weird bug, its likely this will be fixed in 13.3, but it is annoying.
It does not appear to be strictly SoftRAID, see tfriz's experience.
I have an 2014 Mac Mini running macOS Monterey 12.6.2 which is sharing SoftRAID drives at the drive level and not folder level. The 2014 Mac Mini is too old to run macOS Ventura. If I upgrade my other mac computers to macOS Ventura 13.2, will I encounter this bug if I access the shared drives on the Mac Mini? I wasn't sure if this bug only occurs if the mac hosting the shared drives is running macOS Ventura 13.2?
Thanks so much
I do not know enough about the mechanism behind this bug to answer your question accurately. I can only suggest try one computer, and let us know. the other problem is this is not a universal issue, some sharing works, some do not. In our labs, we do not see this with clean installs.

