SoftRAID Volume Out-Of-Sync

I think I have (unsuccessfully) mentioned that ejects are issues on the Apple side. SoftRAID is the messenger, telling you what happened on the hardware end.

Thunderbolt is very sensitive to signal continuity. Any microsecond disconnect powers off the drives.

However you are pointing to ONE drive in an enclosure that is ejecting?

That would be a disk drive issue. Either it is powering off at hibernate, or it is not waking up for too long a time. You can attach a support file and I can look to see which drive. It comes back on its own?
One workaround is set the RAID drive time out in settings to 2 minutes.

It unfortunately won't let me with the standard version of your software. So, again, my hardware is crippled and I'm bound to pay subscription fees to use my paid hardware without jeopardising my hard drives.

@steve223 
Then look in the logs and figure out which drive is not showing up. Is it the same one every time?
how many power on hours do these drives (or the missing one) have?

@softraid-support It seems to be always the same drive. The drives are three years old, don't get very hard use because there are no working drives, and are run during daytime. Please provide me the option to change the drive time out, as without it it seems my hardware does not operate, and I should not have to pay for a subscription for base Functionality.

Hi again, just a quick update on my ongoing RAID 5 ejection and rebuild issues with my OWC ThunderBay 4 enclosures (SoftRAID 8.5 on macOS Sequoia 15.5, M1 Mac Studio Ultra). Thanks for your previous advice—I've been trying to troubleshoot further.

I called Apple Support today to discuss the problem. They said they're not aware of any widespread issue with Thunderbolt enclosures and ejections during sleep or startups, but they mentioned that a macOS 15.6 update is coming out soon, which might include some general improvements. However, Apple suggested this is likely a SoftRAID compatibility issue rather than a macOS problem, and they couldn't offer further help on their end.

Every restart now triggers the same issue. One thing Apple suggested was to switch the ThunderBay enclosures off when I shut down the computer and manually switch them on after startup. This made sense to me because I thought the Thunderbolt connection might be finicky during boot-up, when the system is loading a lot of other things. But it turns out to cause exactly the same problem—ejections and automatic rebuilds. As it stands now, I can't restart my Mac without the array being rebuilt, which is really frustrating.

Interestingly, it always seems to be the same hard drive that's flagged as missing or ejected. However, after the rebuild, the hard drive appears to be fine and does not show any issues in Disk Utility either. As mentioned previously, these are high-quality Toshiba drives still under warranty, which are not heavily used (mainly for backups). They don't make any noise and pass every test, so I don't think it's a hard drive issue.

I'd really like to test whether changing the disk timeout (e.g., to 2 minutes, as you suggested) makes a difference, but given that I'm waiting for my NAS setup to arrive, I'd like to ask if you could please provide temporary access to the Pro version for a few months. This would let me test the timeout adjustment and other advanced features to see if it solves the issue. Again, I don't think it's reasonable for me to pay for a Pro version if the lack of features in the standard version is preventing my hardware from working properly. Thank you very much for your consideration.

On a side note, I constantly get a reminder that Nord VPN is installed. We've been through this previously—while I do have Nord VPN installed, I do not have any of their other features (like extensions or additional software) installed. Even though I click "Don't display this warning again" every time, it pops up on every restart. Maybe you could check whether that additional software is actually installed and not flag non-VPN versions in general, which don't seem to have an issue? No matter how often I tick "don't remind me again" (see screenshot), it pops up again on every restart. I also receive an error message that something couldn't load properly (screenshot attached).

I've attached the screenshots for reference. Looking forward to your thoughts!

@steve223 

Apple support people are just reading from a script. Anyone who "blames" the SoftRAID driver does not understand how drivers work in MacOS. So just ignore what they say.

There are many people who have filed bug reports with sleep with Apple hardware/MacOS, not just us. While its possible 15.6 could address part of this, its not likely. Apple kernel changes like this pretty much are limited to fall/spring releases, not "incremental" like 15.6.

While the rebuild issue is a total hassle, there is no data corruption, its clearly an HDD issue. Did you try moving the drive to another slot, to confirm it is drive, not enclosure?
If you confirm it is drive, get it replaced. You should not have to live with a drive that takes too long to power up. its out of specification.
You can time it, from connecting the thunderbay, when the first drive appears in SoftRAID (usually 8 seconds or so), to when the rebuild starts, is the additional spin up time for your drive. Call Toshiba. While they will likely send a refurb, it won't have the issue.

@softraid-support

Thanks for your quick response and the additional insights—it's helpful to understand the limitations of Apple's support and the broader context of bug reports with macOS sleep and Thunderbolt issues. I get that kernel-level changes are more likely in major releases, so I'll keep an eye out for whatever comes in the fall update.

To address your questions: No, I haven't replaced the hard drive yet. As I mentioned, it's a Toshiba drive still under warranty, and it passes all tests after rebuilds with no apparent issues, so I'm hesitant to go through the hassle of a replacement (especially if it's a refurb) unless we're sure it's the problem. On that note, I haven't tried moving it to another slot in the enclosure either. I don't think I can just swap it without corrupting my RAID 5 array, or would it? Could you clarify the safe way to do this for testing—maybe with steps to avoid data loss or array disruption?

That said, I did speak to Apple Level 2 support (not just a basic rep reading from a script), and while I understand what you're saying about drivers and macOS, the fact remains that if this is an Apple-side issue, it makes Thunderbolt RAIDs seem unsuitable for Macs anymore—as sad as that is. I have to raise it again: My Promise Pegasus never had these ejection or rebuild problems, nor do either of my two QNAP T4 RAIDs. It's only the OWC ThunderBay enclosures that are affected, even though they're all connected the same way. So, I'm wondering—if other manufacturers can deliver RAIDs that work reliably without these issues, couldn't you adjust your software to handle it better (e.g., without rebuilds after every restart)? Or perhaps shift to making hardware RAIDs that don't rely on SoftRAID? I really do like your hardware products—they're well-priced, appear solid, and I've been a fan for a while. It's a real pity, but because of these ongoing problems, I'll be switching to NAS devices now. I've upgraded everything to 10 Gigabit, and honestly, I don't think it'll be slower, but it certainly should have fewer issues, especially since it seems Apple can't sort out Thunderbolt reliability. Mind you, I've been using Apple products for over 30 years, and the state Apple is in nowadays is the worst I've ever seen.

In the meantime, could you please give me temporary access to the full SoftRAID version (Pro) so I can change the timeout setting and see if that makes a difference? As I said before, I'm transitioning to NAS anyway, but this would help me test it properly without having to pay for an upgrade when the standard version's limitations might be part of the problem.

Thanks again for your help—appreciate any guidance on the drive swap or timeout access.

@steve223 

SoftRAID does not care what slot, what bus, or what enclosure a drive is in. So you can safely move it around, with no issues.

SoftRAID reports everything, which can be annoying, as it gives users more info than they want, but that is what we are trying to do, keep you informed. hardware RAID does not have SMART analysis (most only support SMART, if at all, by playing around with buttons on the box or their control app)

You can try downloading the trial of DriveDx and see if it reports the startup issue. We do not monitor it, as it is not directly statistically tied to early drive failure. Then you can uninstall it.

Thunderbolt has been getting better, slowly. TB3 is more robust than 2, and 5 more robust than 3 or 4. But sleep is a separate issue, the Mac is trying to meet government mandated energy savings (and internal enthusiasm to be more "green") and the sleep issues are a side effect, especially the issues of powering up drives every 45 minutes when hibernating. You never hear it with flash in fan-less enclosures, but you hear it on other enclosures. I don't think it was thought through and sleep engineering is not exactly a "plum assignment" to attract the best engineers. So its been very slow to get fixes done regarding sleep.

What you can do if this is for a test, is a clean second system install of MacOS. Then use SoftRAID in trial mode, which is 30 days. Make the settings and see if you avoid seeing this issue.

A second install does not affect anything, is safe, etc. Just add a new volume with Disk Utility, start up in recovery mode, under options, "reinstall MacOS" and select the new volume. It shares space, so only takes up about 30GB. Its worth the testing, I think in your case.

Thanks for the message and the additional details on drive swapping, Thunderbolt evolution, and sleep issues—it's interesting to hear the behind-the-scenes context, even if it's frustrating.

That said, I don't get paid to do huge amounts of troubleshooting, and I simply don't have the time for things like installing and reinstalling macOS on new volumes, setting up trial modes, or running extra apps like DriveDx. I've purchased hardware products that advertise reliable RAID performance and plug-and-play compatibility with Macs, and I just expect them to work that way without all this extra effort on my end.

Anyway, I received my QNAP NAS today (the TS-873A), and interestingly, connected via 10GbE Ethernet and still synchronizing, it's already faster than the OWC ThunderBay via Thunderbolt 4—which is not what I expected at all. And given that I'm using Ethernet, I shouldn't have any of these ejection or rebuild issues moving forward.

For reference, my QNAP TS-873A with 5 HDDs in RAID 5 is showing write speeds of 447.8 MB/s and read speeds of 513.7 MB/s—and that's without an NVMe cache installed (which is coming next week), while the unit is still rebuilding, and with only 8GB of RAM (more is on the way too). In comparison, the OWC ThunderBay with RAID 5 gets about 430 MB/s write and 522 MB/s read. While I sure would prefer the plug-and-play simplicity of the OWC units, the amount of grief and time they've cost me so far is actually crazy if I think about it.

In my opinion, you shouldn't sell these products if they don't really work reliably, no matter who is at fault here—whether it's Apple, SoftRAID, or something else. It's been a disappointing experience overall.

@steve223 

You have a fault in your system, which I am trying to help you diagnose. Its not our generic hardware that is the problem, its your specific hardware. There is clearly a hardware issue and you keep expecting SoftRAID (i.e software or a driver) to fix it.
You have not tried a clean install (second system).
You have not tried moving the disk that is missing to a different slot.

I even suggested trying a third party app (DriveDx) to help you get more information on the potentially failing drive

Its hard to assist meaningfully when you expect a magic answer!

You either need a new disk, or a new enclosure. There is no other "fix". Or live with it until the storage system fails on you.

Thanks for your reply, but I feel like we're going in circles here. First of all, you've previously acknowledged that there is an issue with macOS in regards to sleep and drive detection failures, which contributes to these kinds of problems with Thunderbolt enclosures. It's not just my "specific hardware"—there's a broader compatibility or OS-side element that OWC/SoftRAID has recognized, even if you're now framing it solely as a hardware fault in my setup.

Second, it seems you're failing to understand that while you are paid to provide support and troubleshoot for OWC, I am not. I'm a customer who's already spent a ton of time on this, and I'm currently in the process of migrating everything to my new QNAP NAS, so that's where my focus is right now. If the OWC unit turns out to be faulty, it'll just go in the bin because it's older than three years and out of warranty—it's simply not my top priority to invest more hours into troubleshooting it at this point.

I have downloaded DriveDX as you suggested. Interestingly, one of the disks doesn't show up in DriveDX at all intially, yet SoftRAID after a rebuild shows it as fine. As I said before, these issues exist on both OWC enclosures when they go to sleep. So we seem to have two issues here: One is that OWC doesn't deal well with the Mac waking up from sleep (ejections happen even when "put hard drives to sleep" is disabled). And then the second issue is only pertaining to one of the OWC enclosures, where that one hard drive disappears, reappears, and then needs to be rebuilt after every restart. Indeed, that could well be a hard drive issue—I'm currently talking to the vendor (Toshiba) to get a replacement under warranty. But it doesn't solve the underlying problem that you pretty much can't let your computer go to sleep with the OWC enclosures.

Again after more trouble shooting and yet another restart,the same OWC RAIDs came up with a hard drive missing. So I ejected the RAID, switched it off, restarted the RAID. Then the hard drive showed up as missing briefly, then it showed up as there, but the RAID was out of sync. It rebuilt the sync of the RAID, and now it shows up fine. I also attached the four drive reports from DriveDX, which show that all four drives seem to be fine, including the drive which constantly goes missing and then reappears. So it's pretty hard to blame it on the drive then, as DriveDX, DiskUtility and SoftRaid also all mark all drives as fine.

After every restart, SoftRAID warns me of no VPN being installed. And every time I click "don't show that warning again," as I have none of the helpers which supposedly cause the issues installed, yet SoftRAID every time shows up that message again. Not a big deal, but maybe it shows a lack of attention to detail.

In regards to a clean install, this is a fairly new Mac Studio Ultra that already had a clean install when I set it up—not migrated from anywhere, but everything from scratch. Doing another clean install on a second volume and testing that would be hours of work, so that's not something I'd consider as a first (or even second) line of troubleshooting—it's just too disruptive.

To give more details on the behavior: That disk in question was showing perfectly fine. Then on the next restart, it doesn't show up at all, triggering the rebuild. Then on the following restart, it shows up again but needs to be rebuilt (the array turns red), and after that's done, it shows up as fine again. It's intermittent like that, which makes me question if it's purely a drive failure.

Finally, I'm wondering—with such sophisticated software, why couldn't SoftRAID show me easily which drive bay we're talking about? That can't be that hard to implement—showing it as part of the drive information in which bay it's in would certainly make troubleshooting a lot easier for users.

Best,
@steve223

@steve223 

Based on your latest observations, I am 100% sure you have a faulty hard drive. However, you still need to try swapping it with another bay to ensure that it is the drive, not the bay.
This is becoming a more and more serious issue.

When sleep/thunderbolt are an issue, it is ALWAYS 100% of devices in an enclosure ejecting, never just one. So that is a red herring as far as you're issue is concerned.

In. order for SoftRAID to know which drive is "missing", it has to keep a table of drives in every volume. it violates the "keep it simple" coding philosophy that has kept SoftRAID efficient, non bloated and efficient, for a product that is 30 years old. Go look at all the "old" apps you use. They are bloatware. SoftRAID is not.

You can tell which is missing by noting the serial numbers and seeing which is missing. Also using Blink Disk Light to see which drive is not blinking. Then you ID'd the missing drive by elimination.

I am sorry about the VPN bug. You can try 'uninstall" SoftRAID, restart, then checking the do not show again box. See if that helps.

For being alerted about sleep issues, here is a question: 

if you go to the doctor every year and he never does a prostate test, then you go to a different one, and you have a problem, did you only have a problem when the new doctor reported it? Or, was it an undiagnosed issue all along?
SoftRAID is reporting these ejects, because we think it is serious. MacOS ignores this as much as possible. Which would you rather have?

a simple proof would be (we tested this), is take an enclosure/cable/mac combination that ejects during sleep. Convert them to Apple format drives (volumes). the messages magically go away. Is that a good thing that you do not know of this issue?

On another hand, the waking from sleep issue during hibernation happens regardless of driver or even with a raw unformatted disk, about every 45 minutes, drives spin up for several minutes. But, you likely only notice this with multi-drive enclosures. (a single drive enclosure is less likely to be audible.) Does this mean the wake during hibernate only happens in OWC enclosures? 

I am being a bit sarcastic, but we are living in the real world, with real bugs, some which we can deal with, some we cannot.

But the SoftRAID driver motto is effectively, "tell the user about every issue, do not ignore any". That means we are a strong messenger for issues, as for mission critical data, users should know about all issues, whether "minor", infrequent, or what. Let them decide whether to ignore alerts, don't hide/ignore issues from users.

@softraid-support

Thanks for the detailed response and for clarifying your perspective—it's helpful to understand the philosophy behind SoftRAID's design and alerting system, even if we don't agree on everything.

On the drive identification point: I don't think adding a simple way to show which bay a drive is in would make your software "bloatware" at all. Actually, you do not keep to the "Keep It Simple" ethos, because "Keep It Simple" would be if I don't have to take out drives or go through elaborate blinking light watching operations to figure out in which bay the drive is. Noting the serial numbers means I have to physically take each drive out to check, which is a hassle. And the lights don't work reliably if there's any read or write activity going on. Identifying which bay has an issue is basic functionality in my book—my NAS certainly does it, and the Promise RAID does it too. It would make troubleshooting so much easier without violating any "keep it simple" ethos.

Regarding your prostate exam analogy: Fair point, but let's flip it for a comparison—if I go to one doctor who tells me there's an abnormality that needs constant monitoring and alerts, but I still live to a ripe old age of 90 without it ever causing a real problem, then it doesn't help me at all compared to the other doctor who said there's no abnormality and let me go about my life worry-free. I think you know what I mean—as long as the end result is the same (no catastrophic failure), I'd rather not hear about every minor blip and potential issue. Constant alerts can be more stressful than helpful if they're not actionable or critical!

That said, I appreciate the suggestion on the VPN bug workaround—I'll give the uninstall/reinstall a try and see if that sticks the "don't show again" preference.

As for the faulty drive theory, I will pop the drives around tomorrow (swap them to different bays) and we'll see how it goes. If the issue follows the drive, that would confirm it's the HDD; if it stays with the bay, then it's the enclosure. Either way, I'll report back if anything interesting comes up.

@steve223 

And, MacOS does not have the ability to identify a bay/slot in Thunderbolt. That is why we have "disk labels" as a feature. MacOS randomly assigns disk numbers when you connect an enclosure.