hawihoney

Yes, that did the trick. Thanks a lot. Rebuild is running - fingers crossed. I do have a backup disk (the one that was replaced). After rebuild I will copy it's content over the new one. Just to fix the 6 errors that found their way into the parity during the initial problems.

Thanks for your answer. It's one of my three Supermicro SC846 with BPN-SAS2-EL1 backplane. Systems are running since years that way. Is there a way to tell Unraid to forget that disk7, put it in as a "new" replacement disk again, and start rebuild again? What I don't understand. If this disk is disabled, how does it report SMART values. Is it really disabled or not? That puzzles me. When I did start rebuild for the first time, I had 7 errors within 3 minutes, before I did realize that replacement went wrong this time. So I fear that this did destroy parity.

Sure. I guess it's my 50 th replacement in these servers in 17 years with Unraid.

Something I never had before. I did upgrade a 6 TB to a 18 TB disk7: Stopped array, replaced the old 6 TB disk with a new 18 TB disk, started array. After restart the array told "No or unmountable file system". So I did restart the array again. That's what I do see now: The new disk is in the array but disabled. Is this disk DOA? towervm02-diagnostics-20251029-1707.zip

Looking at my Dashboard I do see my 3 active Unraid Servers with one showing missing text. What's this missing text? Just curious.

Why does umount of a device through Unassigned Devices take that long when the target device crashed? Device is mounted (CIFS/SMB) in Unassigned Devices. I mount with the following UD command through User Scripts: /usr/local/sbin/rc.unassigned mount //192.168.178.101/disk1 Target system crashes. I umount with the following UD command through User Scripts: /usr/local/sbin/rc.unassigned umount //192.168.178.101/disk1 UD issues the following command and uses lazy umount: Unmount cmd: /sbin/umount -t cifs -l '/mnt/remotes/192.168.178.101_disk1' 2>&1 Every single umount takes approx. 5 minutes even with lazy umount applied. What might be the reason and what can I do to fasten that? Thanks in advance.

Natürlich geht das mit User Scripts: #!/bin/bash #arrayStarted=true #foregroundOnly=true #clearLog=true #argumentDescription=Was ist? #argumentDefault=Bla echo argument="$1"Aufruf des User Scripts: Default Argument "Bla" durch den Text "Nix" ersetzt:

Das ist unerheblich. Die Datenplatten haben immer Priorität. Es wird immer, bis auf wenige Ausnahmen (z.B. bei defekten Sektoren oder beim Rebuild von Daten-Platten), von den Datenplatten zu den Paritäts-Platten geschrieben. Die Parity-Platten dienen der Ausfallsicherheit und nicht dem Backup. Moderne Dateisysteme wie XFS nutzen Transaktions-Logs. Sollte mitten in einem Schreibvorgang der Strom ausfallen, dann wird beim nächsten Start auf den betroffenen Datenplatten der alte, in sich abgeschlossene, Zustand wieder hergestellt. Das wird beim Parity-Check bei einer erkannten Differenz auf die Parity-Platten übertragen. Ich würde davon ausgehen, dass alles was auf die Datenplatten geschrieben wurde in Ordnung ist und der Inhalt der Parity-Platten nach dem korrigierenden Parity-Check zu den Datenplatten passen. Das ist das Wichtigste. Tatsächlich sind in der Regel nur die nicht abgeschlossenen Schreibvorgänge weg - und das deckt auch kein Backup ab.

An existing array with 2x parity disks and some XFS disks. Why should I do a New Config on that running array, before adding the NTFS disk that has existing data on it? Now I'm out. I don't get that. Way to complicated for me. Good luck explaining that to new Unraid customers ;-)

I must be really stupid that I need to ask further: I add a NTFS drive to my array that has 2 parity disks and some XFS data disks. I use New Config and let the parity disks to be rebuild. The data on my XFS drives and the NTFS drive are untouched after successful run. That will work? Cool!

Isn't that contradictory? On a new install the array disks become cleared as well - isn't it? If they become cleared, the format and the data is gone. Still confused, sorry. ***EDIT*** Got it. With parity data disks become cleared, wthout parity you can build an array without clearing the data disks. Please add that "array, no array" to the changelog. It's confusing without that - at least for me.

Thanks for your fast answer. There's no requirement to clear disks that become added to a new or existing array? No Unraid signature that becomes patched to Unraid array disks as of today?

"You can create an array or single device pool with existing drives formatted in Ext2/3/4 or NTFS" What does "array" in combination with "existing drives formatted" mean? I could add all kind of formatted drives to an array up until now because they all become formatted before using the array. Can I now create an (additional?) array with already formatted drives without the need to format them? Just curious.

The latest Selkies based version "12.07.25" does no longer work here. I do receive a "Waiting for stream" output and that it was. I read that https is required now. I can't use that here. What do I need to return and stay with the previous "05.07.24" release? Using the following did not work: lscr.io/linuxserver/doublecommander:amd64-05.07.24 Any help is highly appreciated.

jdownloader2 includes ffprobe and ffmpeg: /tmp # ls -l /usr/bin/ff* -rwxr-xr-x 1 root root 301208 Jun 7 2024 /usr/bin/ffmpeg -rwxr-xr-x 1 root root 162872 Jun 7 2024 /usr/bin/ffprobe I use it from within a python script (use your own container name and input value): [...] jdownloader2_container = "JDownloader2" [...] ffprobe = f"docker exec {jdownloader2_container} /usr/bin/ffprobe" [...] command = f'{ffprobe} -v panic -hide_banner -of default=noprint_wrappers=0 -print_format flat -show_format "{input}" | grep creation_time' r = os.popen(command).read() print(r) [...]

Since a year my Unraid combo crashes weekly. The problem is always the same - a Unraid license USB stick is reset and the server is down immediately. I tried different USB Devices, I tried different ports, I tried nearly all workarounds for syslinux.cfg I found in the internet, without success. The failing USB devices are the Unraid license sticks. If they are not accessible the server (the Unraid VM) is dead immediately. After theses crashes the USB sticks don't show any errors, they can be used again immediately: Jul 9 03:18:40 Tower kernel: usb 1-5: reset high-speed USB device number 2 using xhci_hcd Jul 9 03:18:46 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:19:02 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:19:02 Tower kernel: usb 1-5: reset high-speed USB device number 2 using xhci_hcd Jul 9 03:19:07 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:19:23 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:19:23 Tower kernel: usb 1-5: reset high-speed USB device number 2 using xhci_hcd Jul 9 03:19:29 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:19:44 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:19:44 Tower kernel: usb 1-5: reset high-speed USB device number 2 using xhci_hcd Jul 9 03:19:50 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:20:05 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:20:05 Tower kernel: usb 1-5: USB disconnect, device number 2 Jul 9 03:20:05 Tower kernel: usb 1-5: new high-speed USB device number 8 using xhci_hcd Jul 9 03:20:11 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:20:27 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:20:27 Tower kernel: usb 1-5: new high-speed USB device number 9 using xhci_hcd Jul 9 03:20:32 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:20:48 Tower kernel: usb 1-5: device descriptor read/64, error -110 Jul 9 03:20:48 Tower kernel: usb usb1-port5: attempt power cycle Jul 9 03:20:49 Tower kernel: usb 1-5: new high-speed USB device number 10 using xhci_hcd Jul 9 03:20:54 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:21:09 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:21:09 Tower kernel: usb 1-5: new high-speed USB device number 11 using xhci_hcd Jul 9 03:21:15 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:21:30 Tower kernel: usb 1-5: device descriptor read/8, error -110 Jul 9 03:21:30 Tower kernel: usb usb1-port5: unable to enumerate USB device Now I found a new possible solution. This is my last and final idea before I drop my machine completely. So I'm looking for a way to a.) block xhci_hcd completely and use ehci_hcd on the machine as the only USB driver or b.) a PCI card with a USB2 controller: https://bbs.archlinux.org/viewtopic.php?id=186617 Any help is highly appreciated. The diagnostics is old but the hardware has not changed and the server is down currently. I will need several hours to bring the server up again (lots of dead Unassigned Devices SMB mounts that need minutes each to find out that the SMB server does not respond). tower-diagnostics-20250115-1128.zip

In January 2008 1x Lime Technology MD-1500/LL was shipped to Germany with two 4.7 Pro License Sticks. In 2009 1x MD-1510/LL with two additional Pro License Sticks was added. Count in 17 years.

Ist da tatsächlich etwas bekannt? Hab keine USV - ist wohl an mir vorbei gegangen. Kannst Du mir ggfs. den passenden Thread benennen? Das wäre sehr freundlich. Ich kämpfe seit einiger Zeit mit meinen USB Lizenz Sticks. Nach ein paar Wochen (4-8) kommt immer die selbe Nachricht und der Rechner ist tot. Mittlerweile starte ich den Server (einen Server!) alle 4 Wochen neu, um dem Phänomen zuvor zu kommen. Der Stick ist nach dem Crash sofort in jedem anderen Gerät lesbar, keine Fehler. Ich habe schon andere Sticks, andere Ports, USB3, USB2, Verlängerungskabel dazwischen, einfach alles versucht. Ohne Erfolg. Das ist die Meldung. Passt die eventuell zu dem von Dir genannten USV Thread? May 31 01:28:57 Tower kernel: usb 1-3: reset high-speed USB device number 2 using xhci_hcd May 31 01:29:02 Tower kernel: usb 1-3: device descriptor read/64, error -110 May 31 01:29:18 Tower kernel: usb 1-3: device descriptor read/64, error -110

This is what I experience since many, many years on different hardware - fast boot yes/no makes no difference here. E.g. Supermicro X12SCA-F here with two attached NVMe. Reboot: 1x NVMe, Hard boot: 2x NVMe. I live with it. Never reboot. I even cut power for a minute - just to be sure.

It's the parity check after a server crash and reboot. AFAIK, that one is always correctional - for a reason. This one SHOULD correct sync errors always. All drives are spun-up during that correctional check, so reconstruct write for array writes wouldn't hurt IMHO. I get your point with before is corrected, after will be corrected. And I know the technical ideas behind parity checks (data disk is always correct). But during that parity check writes may use wrong values and now consider a crash during that writes ... IMHO that would make things worst. I vote for recosntruct writes during a correctional parity check.

Stupid question: My server crashed last night. After reboot the usual parity check starts. While parity check is running I can write to the array. So far so good 1. What I see is, that the parity check uses all disks at aprox. 35 MB/s. Fine with that during parallel writes. 2. But for the writes to one data disk I see that only the parity disks and the array disk, I'm writing to, are being used. Isn't that dangerous? The writes seem to consider parity disks are ok. But they are checked currently. So shouldn't writes during a parity check use "Reconstruct write"? Read/Write/Modify is IMHO wrong during a running parity check. In the image below you can see what I mean. 34 MB/s is the parity check. 90 MB/s is the write to disk21 (not shown) and the parity disks.

According to the help text for SMB/NFS, you mount the source name it has within UD. So in that case its //UNRAID_BU/BACKUP.

If you click on the help icon while on the Unassigned Devices tab you will get all possible commands. Let UD mount/unmount. It knows exactly how to mount/unmount on Unraid: E.g.: I use these commands from within User Scripts to mount/unmount an external SMB resource: #!/bin/bash #backgroundOnly=true #clearLog=true /usr/local/sbin/rc.unassigned mount //192.168.178.101/disk1 ### /usr/local/sbin/rc.unassigned umount //192.168.178.101/disk1

Just two small corrections/additions. I think you mean two expanders on the backplane, these are for redundancy, correct. These Supermicro backplanes are called *EL2 instead of *EL1. The two ports (I think you mean that with connections) on a previously mentioned SAS3-846EL1 can be used as input or output. You can even use two ports as input ports from one single HBA. These expanders will handle that. We use SAS2-846EL1 with 3 ports each. You can mix the ports as you like. Had them running with two input ports and one output port to another SC846 on Unraid. You can even output with breakout cables. Limitless possibilities. Cascading is no problem with Unraid. The only thing you need to figure out is how to use more than one backplane (48 disks, 72 disks, ...). Theres only one Array possible currently, so you need to use Unassigned Devices, ZFS pools, etc on top of one Array of a fully occupied SC846 case.