timekiller

I am unable to run the mover. I'm trying to move data off a dying disk and when I clock the "Move" button the page just reloads and the button is not grayed out. I have noticed when the system boots I get an error saying "/usr/local/bin/mover not found". Logging in I can see /usr/local/sbin/mover. I'm not sure why the system is looking int he wrong place. I can manually move the binary, but I want to know the "right" way to fix this. quick update, I just took a closer look at /usr/local/sbin: root@Storage:~# ls -lh /usr/local/sbin/move* lrwxrwxrwx 1 root root 19 Mar 17 09:33 /usr/local/sbin/move -> /usr/local/bin/move -rwxr-xr-x 1 root root 161 Mar 17 09:33 /usr/local/sbin/mover* -rwxr-xr-x 1 root root 4.6K Mar 17 09:33 /usr/local/sbin/mover.old* since /usr/local/bin/move doesn't exist, /usr/local/sbin/move is a broken symlink Edit (again): This is on Unraid 7.0.0, which has been through many updates

In full panic mode right now. Both of my parity drives are disabled. In the SMART report I can see Smartctl open device: /dev/sds failed: No such device in dmesg I see [2118735.635675] mpt2sas_cm1: log_info(0x31110d01): originator(PL), code(0x11), sub_code(0x0d01) [2118735.644150] sd 13:0:7:0: [sds] tag#4096 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s [2118735.644164] sd 13:0:7:0: [sds] tag#4096 Sense Key : 0x2 [current] [2118735.644171] sd 13:0:7:0: [sds] tag#4096 ASC=0x4 ASCQ=0x0 [2118735.644178] sd 13:0:7:0: [sds] tag#4096 CDB: opcode=0x88 88 00 00 00 00 04 dd 3d 00 f8 00 00 04 00 00 00 [2118735.644184] I/O error, dev sds, sector 20891631864 op 0x0:(READ) flags 0x0 phys_seg 128 prio class 0 [2118735.644195] md: disk0 read error, sector=20891631800 [2118735.644204] md: disk0 read error, sector=20891631808 [2118735.644209] md: disk0 read error, sector=20891631816 [2118735.644213] md: disk0 read error, sector=20891631824 [2118735.644218] md: disk0 read error, sector=20891631832 I can't spin up the drive (expected). Server has been running fine until today. I want to power it down and check the cabling, see if the drives come back on reboot, but before that is there anything else I should do? (diagnostic report attached) storage-diagnostics-20250313-1059.zip

I previously bought a license, but stopped using it for a while. Now I have built a new server but don't have the usb drive I used, and can't find a way to re-use my license. Can someone help, or will I be forced to buy a new license?

That worked, thank you!

Bump for visibility

I have a Home Assistant VM that I am trying to pass a USB controller to. I have to pass the whole controller because I have a Coral AI accelerator which changes device ids when it's initiated, so I can't pass just the device. I have the controller bound in System Tools: When I view the VFIO-PCI Log it says it was successfully bound: When I try to attach it to the VM and start I get the error Execution error internal error: qemu unexpectedly closed the monitor: 2023-04-10T18:08:06.139081Z qemu-system-x86_64: -device vfio-pci,host=0000:09:00.3,id=hostdev0,bus=pci.4,addr=0x0: vfio 0000:09:00.3: failed to setup container for group 19: Failed to set iommu for container: Operation not permitted Diagnostics file attached. Thanks in advance. storage-diagnostics-20230410-1359.zip

Posting an update in case it's helpful to others. I believe I have this solved. I realized that the drive issues I was having were all on drives in this drive cage I bought to try and squeeze an extra drive into the server. I removed the cage, rearranging drives to get everything mounted securely and started yet another parity rebuild. This one took about 37 hours and completed successfully last night. The array has been online and stable since then. Hopefully That was the source of all my issues and I can move on. Thank you everyone who gave advice, even if I didn't necessarily take all of it.

of the 24 drives, there is a grand total of 2 splitters (not daisy chained, and not on the same line). Again, I don't believe this is causing the issue.

a couple, just due to the runs I have. Not as many as you might be thinking. It's a 1,000 watt PSU so there are plenty of ports for peripherals. I really on't think the PSU or the way I have the power wired is the issue.

Yup. My mistake. The data drive was marked unmountable, not disabled. The 2 parity drives were still online and the data on the unmountable drive was missing fromt he array. That was 3 weeks ago and I've been dealing with so many issues since then I forgot the specific error for the drive. This doesn't answer my current problem though. New drives, new cables, new controller cards, and I still can't get a successful parity rebuild.

Evenly split. PSU is more than capable of handling the load.

I understand how it's supposed to work. Both parity drives were online. The disabled drive was no emulated. Don't know what else to tell you on that. Doesn't really matter since this was like 3 weeks ago and not relevant to my current issues.

...with the power supply?

No. The drive was "disabled" and all of it's contents were removed from the array. Not emulated.

New. EVGA SuperNOVA 1000 G+, 80 Plus Gold. Bought it in May