JorgeB

That suggests the NIC can't get an IP address from the DHCP server.

Disk8 appears to be failing, and since there's already a disabled disk and you only have single parity you can't rebuilt it, you can try copying everything you can from that disk to others or using ddrescue. Disk4 is not showing SMART, you'll need to check connections.

Those are expected since previous check was non correct. Before buying one you could try flashing that one to IT mode, it will use a different (and better for Unraid) driver.

Not that I know of, please try after booting in safe mode, if it still happens create a bug report, don't forget the diagnostics.

The backplane uses 10 standard SATA ports, you can use standard SATA to SATA cables or miniSAS to SATA forward breakout cables if you have an LSI or similar controller.

Invalid slot is a more cleaner way of doing it, just make sure you follow the instructions carefully and ask if there's any doubt. -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed, including new disk14, replacement disk should be same size or larger -Important - After checking the assignments leave the browser on that page, the "Main" page. -Open an SSH session/use the console and type (don't copy/paste directly from the forum, as sometimes it can insert extra characters): mdcmd set invalidslot 14 -Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box (GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the invalid slot command, but they won't be as long as the procedure was correctly done), disk14 will start rebuilding, disk should mount immediately (possibly not in this case since parity won't be 100% valid) but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Disk dropped offline so there's no SMART, check/replace cables and post new diags after powering back on.

Not a good idea to add a cache device when there are fs problems, best bet is to backup anything important on cache and re-format.

Do you mean after posting the diags, if not why is your RAM still overclocked?

If 5 ports are enough get a JMB585 controller, for more ports get one of the recommended LSI HBAs.

Close enough, do you have another source computer you can test the transfer with?

Please post diags to see what's the actual problem with the disk when mounting. You can do that after doing a new config, but should have the same issue mounting the disk.

Wrong used space is an Unraid bug, should be fixed on next release, wrong free space is a btrfs bug, it affects any raid1 pool with an odd number of devices, should be fixed on a future linux kernel/btrfs tools release.

You need to format the device before use, next to array start/stop buttons.

Because it's has bad sectors, this is a hardware problem, either the disk was already bad/failing or in some rare cases bad power can damage disks.

Thinking more about it I think you are saying trust parity with the old disk then replace, in that case yes, it would be similar and no problem replacing it with a larger disk, but since the disk appears to be failing badly just mounting it could result in read errors, though you could start the array in maintenance mode, that should be OK.

Your cache device is failing and needs to be replaced: 197 Current_Pending_Sector -O--C- 100 100 000 - 5 198 Offline_Uncorrectable ----C- 100 100 000 - 5

Yes if array was started in maintenance mode the first time and the spare was the same size as the original, but invalid slot is the more correct way of doing this, and no issues with larger replacement disks.

Do you have a spare? Same size or larger.

If SMART test is OK just do a new config and re-sync parity, if not you can try to rebuild disk14 using the invalid slot command.

Not that part if done in read-only mode, but parity already is already a little out of sync with those disks. Stop array, unassign both disks and start array, or they won't be available for UD, in UD enable read-only button before mounting. Also depends on the result of the SMART test for disk14.

I would guess a standard replace and rebuild should do it, but it's something I never tried.

If that's something you were using in safe mode it might, so try again with that stopped, but Unraid also uses nginx for the webGUI.

Looks like you used a slightly smaller disk to replace disk3: Aug 26 18:00:39 ZOE-X1 kernel: attempt to access beyond end of device Aug 26 18:00:39 ZOE-X1 kernel: md3: rw=4096, want=4000797296, limit=3907029104 Disk needs to be same size or larger.

The filesystem on the actual disks should be OK, and they can me mounted with the read-only option in UD, but since the rest of the array was started without them parity will always be a little out of sync, so there could still be issues rebuilding disk14 using the invalid slot command. I would check if both disks mount OK (with UD in read-only mode) and also run an extended test on disk14, then decide what to do based on the results. P.S. disk14 and a lot of your disks are the infamous ST3000DM001 that tend to fail a lot.