Arturia

That's a really good point about Molex carrying higher current without voltage sag — that actually makes a lot of sense given my original problem was 5-way Molex→SATA adapters on aging connectors. Quick context first: since I carefully reseated everything 3 days ago it's been completely stable, and before that it actually ran fine for about a month too. So part of me wonders whether I even need to change anything, or whether a connection was just slightly loose/aging and reseating fixed it. Would you still recommend rewiring it properly anyway (or at least replacing the cable), rather than risking another dropout down the line? I'm fine going either full SATA or full Molex — neither bothers me, even if custom cables end up being more expensive. I'd just like to do it once, properly. If you were going the Molex route only, how would you wire my setup for 32 drives? My situation: - Seasonic Prime PX-850, 6 peripheral ports - 32 drives max (30 now + 2 free controller ports) - Layout: 12 drives in a vertical Fractal column, 6 in Phanteks brackets below, 12 at the front A few things I'd love your input on: 1. How many Molex→SATA splitters per Molex cable, and how many drives per splitter, would you consider safe? (I'm guessing 4-way max per splitter, but how many splitters per cable / per port?) 2. How would you spread 32 drives across the 6 ports to keep each cable within a safe current budget? 3. Most importantly — what specific cables/splitters would you actually buy? I want to avoid the cheap Molex→SATA adapters that have fire risks (that's basically what burned me). Any brands or specific products you trust for quality Molex cables and 4-way Molex→SATA splitters? Really appreciate the help — I'd rather invest in the right parts once than keep chasing dropouts.

Thanks, good to know the plan is sound. Out of curiosity — if you wanted to avoid custom cables entirely, how would you personally wire 30 drives on my Seasonic Prime PX-850 (6 peripheral ports)? Would you just use standard Seasonic SATA cables and accept some cable slack/looping where drive spacing is tight, add a 2-way splitter here and there, or something else? I'm trying to weigh the custom route (clean but pricier and longer lead time) against a simpler standard-cable approach. Curious what you'd do in practice.

Following up with my actual layout to get your opinion. I've attached a diagram of the rear of my case (Fractal Meshify 2 XL). My setup: 12 drives in a vertical column (Fractal native HDD cages), connectors all facing the same way, ~30mm spacing between drives 6 drives below in 3x Phanteks PH-HDDKT_03 brackets (2 stacked per bracket), same connector orientation as the column above 12 more drives at the front Seasonic Prime PX-850, 6 peripheral ports ModDIY recommended max 5x SATA per cable, and you mentioned a single 2-way splitter per cable is OK but best avoided. ModDIY can also do custom cables with selectable routing direction (bottom-up) and custom connector spacing: [https://www.moddiy.com/products/1634/Premium-Custom-Multiple-SATA-Molex-Power-PSU-Modular-Cable.html] My plan: 6 custom native cables (one per port), bottom-up routing, ~5 connectors each, tight spacing for the dense column. No splitters if possible. Does this look sound to you for 30 drives? Any concern with the tight 30mm connector spacing on a single long cable feeding the 12-drive column, or would you split that across two ports/cables instead? layout_arriere_meshify2xl_final.svg

Thanks again for the warning about modular pinouts — I've done my homework. I confirmed on Seasonic's official cable compatibility chart that my Prime 850 Platinum (Legacy PRIME Series, Platinum-Gold column) uses SATA cable references xB03 / xB21 / xB55 / xB56 / xB65 / xB80 / xB81 / xB82 / xB101 / xB118 / xB119 / xB133 / xB134 / xB146 / xB149. The chart also notes that while these models originally shipped with inline-capacitor cables, cables without them are also compatible. My documented native SATA cables are only 3 (two 810mm + one 860mm, 4 connectors each = 12 SATA total). The rest of my 30 drives were on Molex→SATA adapters, which I'm eliminating. I found CableMod's EU configurator (configurable per exact PSU model, covers customs/import). My plan: Add native 6pin→4×SATA cables on the free peripheral ports Use a StarTech PYO4SATA splitter only on the last connector of a cable where drive spacing requires it Target: ~7 drives per port max (3-4 native + splitter), keeping each port around 70W My layout: 12 drives front, 18 drives rear (12 in the Fractal cage column + 6 in Phanteks brackets). Two questions: For someone running 30 drives, would you go fully native (more cables, fewer splitters) or is a native-cable + StarTech SATA splitter mix perfectly safe at these loads? Any reason to prefer genuine Seasonic replacement cables over CableMod custom cables, as long as the pinout matches the Prime series?

Following up on the power supply discussion — I'm planning to replace all my Molex→SATA adapters with proper native cabling. My setup: Seasonic Prime 850 Platinum with 6 peripheral ports. I have 12 drives at the front and 18 at the rear (30 total), and I'm planning ahead for up to 42 drives. My plan is to use 6 native 6-pin→4×SATA cables (one per PSU port), with a StarTech PYO4SATA splitter on the last connector of each cable, giving 7 drives per port × 6 ports = 42 drives total. Two questions: Would you recommend any specific 6-pin→4×SATA cables compatible with the Seasonic Prime Platinum available on Amazon.fr? I want quality 18 AWG cables, not cheap generic ones. Is the StarTech PYO4SATA a good choice for this use case, or would you recommend a different splitter? The goal is zero Molex adapters, everything on native SATA power.

Reseated all Molex connectors and the array came back stable. Confirmed I have a Molex to 5x SATA splitter (XMSJSIY IDE to SATA 4 Pin Male Power Cable with 5x 15 Pin Female). I have two of these on separate Molex connectors from the PSU — one powering 3 disks, the other powering 5 disks. Array seems stable after reseating but I understand this setup is not ideal. (https://seasonic.com/prime-px/ 850W)

After doing a new config, disk12 (ZJV08KYH) also started showing read/write errors on sdv. Both disks are now causing issues simultaneously on the same cable. I've shut down and disconnected both disks to stabilize the array. At this point I'm not sure if it's the HBA port, the new cable, or both drives failing. What would you recommend as next steps? Update: reseated both power and data cables on disk12 and disk13. Array is back online with all 30 disks, both disks mounted cleanly (XFS journal recovery ran on both as expected after the unclean shutdowns). No dropouts since. Both disks share the same power splitter — could that have contributed to the issue alongside the SAS cable ? Assuming things remain stable, would you recommend running a correcting parity check at this point?

Jun 2 21:00:51 Sphinx emhttpd: online: ST10000VN0004-2GS11L_ZJV08NXS (sdae) 512 19532873728 => MBR read error when i try to New Config, and after 3 try sdae is reconnected

Replaced the cable as suggested but disk13 (ZJV08NXS) is still dropping immediately on boot with the same loop. Disk12 (ZJV08KYH) imports cleanly on the same cable/port. The drive eventually stabilizes after several reconnect cycles but drops again during use — it dropped twice within 10 minutes during my last test (at 20:30 and 20:35). Disk13 doesn't reliably appear in the md import on first attempt (import_slot: 13 empty) and requires multiple reconnect cycles before being accepted. I have two other available SATA ports I could test the drive on, but I don't have a spare cable at the moment to try. Would you recommend replacing the drive and rebuilding from parity, or is there another way to confirm it's the drive before ordering a replacement? Logs attached. sphinx-syslog-20260602-1859.zip

Cable replaced as suggested and started a parity check, but disk13 dropped again during the check with the same SAS port remove pattern: mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x300062b202991677) mpt3sas_cm0: removing handle(0x002f), sas_addr(0x300062b202991677) mpt3sas_cm0: enclosure logical id(0x500062b202991660), slot(13) sd 0:0:23:0: [sdx] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK Paused the parity check for now. Disk12 appears stable. I'm thinking about physically reseating disk13 in its slot — would that be worth trying, or should I move it to a different PHY port on the HBA to isolate whether it's the drive or the port?

Reseated all cables (both disk side and HBA side), ran xfs_repair on disk12 and disk13 — no corruption detected on either. Had to do another New Config since they were still showing as disabled from the previous failed boot. Both disks are back online. Replacement SAS cable is arriving tomorrow. Given that reseating seemed to stabilize things, would you recommend swapping the cable anyway as a precaution, or would you wait to see if the issue recurs first? Also worth noting: both disks share a power splitter, which I also reseated while I had the case open.

Tried New Config as suggested but both disks dropped again immediately during array start — same SAS dropout loop (device cycling through multiple SCSI handles). Key logs: sd 31:0:21:0: [sdac] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK sd 31:0:23:0: [sdae] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK XFS (md13p1): Corruption warning: Metadata has LSN (1:361399) ahead of current LSN (1:360796). XFS (md13p1): Failed to read root inode 0x80, error 117Also getting XFS corruption on disk13 (LSN mismatch). Replacement SAS cable is on order but won't arrive until tomorrow. In the meantime I'm going to reseat the existing cable and try booting into maintenance mode to run xfs_repair on both disks before starting the array. Does that sound like the right approach, or should I wait for the new cable before touching anything?

Thanks Jorge! I've already ordered a replacement SAS cable (SFF-8643 to 4x SATA, 1m), should arrive in a few days. In the meantime, to get disk 12 and 13 back online, should I proceed with a New Config + Keep All like last time, or something else ?

Update — June 1st, same issue recurring Disk 12 and 13 disabled again tonight with no changes made to the system since the last fix. Syslog shows clear physical SAS link dropouts this time: mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x300062b202991677) [phy23 / disk13] mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x300062b202991675) [phy21 / disk12]Both disks show Power-on or device reset occurred immediately after removal. Disk 12 (phy21) attempted 3 reconnections in a loop before being disabled. log_info(0x31110d00) reported on each event. Both affected PHYs (21 and 23) are on the same LSI 9305-24i HBA. The NAS has not been moved or physically touched since the last incident. Given that the dropouts are clearly at the SAS/PHY layer, what would you recommend as next steps? Should I replace the SAS breakout cable serving these ports, suspect the HBA itself, or could the disks be the cause despite clean SMART data? New diagnostics attached. sphinx-diagnostics-20260601-0641.zip

Thank you for the clarification! I'll run another parity check in a few days to confirm everything is clean. Regarding the disk dropout — I'll check the SAS cables on the HBA ports for disk 12 and 13. Good to know about grabbing diags before rebooting if it happens again. Thanks again for all your support, this community is great!

Hi Jorge, Parity check completed with 528,049 sync errors corrected. Is that number concerning or still within acceptable range given the situation we had with disk 12 and 13? A few follow-up questions: Should I run another parity check now to confirm everything is clean, or is one pass sufficient? Would you recommend periodically running XFS filesystem checks on the array disks via maintenance mode? If so, how often? Regarding your comment "Disk ID should never change on array start, unless the disks are dropping and reconnecting" — do you have any insight into what actually happened in my case? The disks were on an LSI SAS3224 HBA and their device names shifted on array start (not on reboot). Could this indicate a hardware issue with the HBA or cabling, or is it more likely related to the 3 storage controllers I have (LSI HBA + ASMedia ASM1064 + AMD B550 onboard)? Thanks again for all your help throughout this!

This Option ?

Hi Jorge, Current parity check status: Position: 3081 GB (15.4%) Speed: 106.6 MB/s Sync errors corrected: 412 Estimated finish: ~1 day 20 hours No read or write errors so far One concern: I have a planned power outage coming up. Is it safe to pause the parity check, shut down properly, and resume after power is restored? Will Unraid pick up where it left off or restart from the beginning? Thanks again!

Hi Jorge, Update: backup is done and I followed the steps as planned. New Config - Keep All - Apply ✓ Verified all assignments ✓ Checked "parity is already valid" ✓ Started array ✓ Parity check running Results so far: Disk 12 and 13 are back online, no longer DISK_DSBL ✓ Data on both disks looks correct (tv/ folder structure intact) ✓ 74 sync errors corrected so far, estimated finish in ~2 days 9 hours at ~97 MB/s Assuming this is expected behavior, I'll let the parity check complete. Please let me know if the error count looks concerning or if there's anything else to watch out for. Thanks again for your help, really appreciated!

Thanks Jorge. Following your advice, we'll do the New Config + resync parity approach. Before proceeding, I'm currently doing a precautionary backup of both disk 12 and disk 13 to external drives (rsync in progress, ~10-12h remaining). This is because the emulated content (P/Q/R/ at root) doesn't match the physical content (tv/P/Q/R/), so I want a safety net before any config changes. Once the backup is complete I'll proceed with: New Config - Keep All - Apply Verify all assignments Check "parity is already valid" Start array + run parity check Will post new diags if any issues arise. Thank you.

Thank you. Before proceeding with the rebuild, I want to flag a discrepancy I noticed: When I mount the physical disks directly (array stopped): /dev/sdac1 shows tv/P/ tv/Q/ tv/R/ (correct structure) /dev/sdae1 shows tv/P/ tv/Q/ tv/R/ (correct structure) When I start the array and check the emulated content: /mnt/disk12 shows P/ Q/ R/ directly at root (missing the tv/ parent folder) /mnt/disk13 shows P/ Q/ R/ directly at root (missing the tv/ parent folder) The emulated content does not match the physical content. I ran xfs_repair on disk 13 which had reinitializing root directory and inodes moved to lost+found. I am currently backing up both physical disks before proceeding. Should I still rebuild, or is there a way to sync parity from the physical disks instead?

No, array was stopped before adding the drives. The problem was enumeration shifting when starting the array: after adding the 2 new drives, every time I started the array, disk 12 and 13 shifted from sdac/sdae to sdag/sdaf. This happened consistently on array start, not on reboot. I tried recabling 3 times with different SATA ports. Eventually the enumeration stabilized with the current cabling and sdac/sdae are now stable and pointing to the correct disks by serial number. But disk 12 and 13 remain DISK_DSBL despite diskState=4.

Started array in normal mode, new diagnostics attached. Additional info: while in maintenance mode, I ran filesystem check and fix on both disk 12 and 13 via the WebGUI. Both disks now show "filesystem OK" after the fix. sphinx-diagnostics-20260411-0004.zip

Thanks for the reply. The disks were working fine before tonight — they got disabled after I added 2 new drives which caused a SATA enumeration issue (devices shifted from sdac/sdae to other letters). sphinx-diagnostics-20260410-2342.zip

Hardware: Motherboard: Gigabyte B550 AORUS ELITE AX CPU: AMD Ryzen 3600 HBA: LSI SAS3224 (Broadcom 9305-24i) — 24 ports SAS/SATA Additional SATA controller: ASMedia ASM1064 (Moonqkuses PCIe card) — 4 ports Onboard SATA: AMD B550 chipset — 4 ports Boot: USB flash drive Unraid version: 7.2.4 Array: 30 disks total, dual parity Disk layout: Parity 1 & 2: 2x 20TB Seagate Disk 1-26: mix of 10TB and 18-20TB drives on LSI HBA and ASMedia card Disk 27-28: 2x 20TB WD (newly added) Disk 12: ST10000VN0004-2GS11L * (sdac) — 10TB on LSI HBA phy21 Disk 13: ST10000VN0004-2GS11L * (sdae) — 10TB on LSI HBA phy23 What happened: I had a working 28-disk array. I added 2 new WD 20TB drives (disk 27 and 28). I stopped the array, physically connected the 2 new drives, and rebooted. After reboot, disk 12 and 13 appeared with red X (disabled). I checked cables, rebooted again, but the problem persisted. What I tried: Verified SMART on both disks: PASSED, no errors, 0 reallocated sectors Confirmed XFS data is intact: mount -t xfs -o ro /dev/sdac1 /mnt/tmp shows data correctly Checked dmesg — disks are detected correctly by kernel on sdac/sdae Tried New Config with Preserve All assignments — did not fix the issue Key finding in dmesg: Healthy disks import like this: md: import disk1: (sdu) ST18000NM000J-2TV103_* size: 17578328012Disk 12 and 13 import with a trailing 0 flag: md: import disk12: (sdac) ST10000VN0004-2GS11L_* size: 9766436812 0 md: import disk13: (sdae) ST10000VN0004-2GS11L_* size: 9766436812 0This trailing 0 causes them to be marked DISK_DSBL immediately. Current state: rdevStatus.12=DISK_DSBL rdevStatus.13=DISK_DSBL sbSyncErrs=0 — parity is valid sbSyncExit=0 XFS data readable directly on physical devices Question: What does the trailing 0 flag mean in the md import line, and how can I clear it to allow these disks to rejoin the array without rebuilding from parity? sphinx-diagnostics-20260410-2159.zip