Alby24

I wanted to add something outside of what I marked as a solution. Basically, the issue was that Unraid decided that my parity disk had problems when it hadn't. Just because one single write failed, it decided that the disk was dead and therefore disabled it. By doing this, the array was put at risk, once again, for no reason at all. Unraid should've been built to protect your data, instead it tried to temper with it like a malware. This is terrifying. Disabling a drive just because one single write failed (that could happen for a loooot of reasons) does not make any sense and I hope you all see that. Run a check on that sector and keep the drive active. If write operations fails frequently, then you can think about disabling the drive. I am growing tired of the lack of documentation, of the lack of official support that this (paid) software has. In fact, this forum was not able to provide any concrete solution and help outside of something very basic and, to be precise, 90% of my post was just ignored. I really cannot recommend Unraid anymore, unless you want to risk losing your data without any failure and want to troubleshot it with a UI that gives out useless messages only.

Two days later, this is what I've done: I've changed the cable of Disk 4 and never encountered any other error I've rebuilt Parity disk onto itself (lol) and never encountered any other error In short, Disk 4 was unmountable because of the cable, and the parity disk was disabled because Unraid said so.

What to do now then? How do I re-enable the parity drive?

Thanks for your answer. That's good to know, it should be stated in the UI somewhere. Given that the SMART report of the parity drive seems ok, is there are a possibility that there was a write failure due to the fact that Disk 4 was unmountable?

Hi there, I'm having issues with my Unraid server. Yesterday, Disk 4 reported an UDMA CRC error count equal to 1. The array was working fine. Today, when I booted the system up, the UDMA CRC error count of Disk 4 was increased to 9 and the Web UI was saying that the drive was unmountable. Most importantly, the parity disk was automatically disabled. After a reboot, Disk 4 was successfully mounted and present in the array, however the parity disk was still disabled. I'm aware of the fact that UDMA CRC error count is related to connection errors, therefore I am planning on checking the cable of Disk 4. What concerns me is that I have no clue why the parity disk, which seems healthy, was randomly disabled. It also says that the array is unprotected. What happened to the parity disk? How do I re-enable it? I'm attaching the diagnostic. P.S. I find unbelievable that there is no explanation on the Web UI on why the system decided to disable a working drive. unraid-nas-diagnostics-20230311-2025.zip

Of course not sir. I posted a bug report here but I haven't got even a single sign of life from the dev team in 8 months.

Indeed, and that is weird, since the standard "/sbin/init 0" was being reached. Plus, the system doesnt shut down with the button anymore, that implies that I have modified the correct file. We're missing something for sure, but I have no idea what

I tried as you said and I believe nothing is being logged at all. I don't really know what to say...

Man if you aren't sure, I really don't know what to do, I know very little about this syntax. Do you mean writing something like this? case "$2" in power) logger "before run" && /usr/bin/docker pull alpine:latest && logger "after run" ;; Plus, where can I find the log? Thanks again.

Yes you are correct, now I can use the command. Anyway it doesn't seem like it is being executed when I press the power button. Does acpi logs anything? Here is my entire acpi_handler.sh script: #!/bin/sh # Default acpi script that takes an entry for all actions IFS=${IFS}/ set $@ case "$1" in button) case "$2" in power) /usr/bin/docker pull alpine:latest ;; *) logger "ACPI action $2 is not defined" ;; esac ;; *) # logger "ACPI group $1 / action $2 is not defined" ;; esac

But when I try to run a command like: /var/lib/docker run alpine:latest This is shown: bash: /var/lib/docker: Is a directory And nothing is executed

Thanks for your repy. I see what you mean, I found out that docker is located at: EDIT: this is the right path /usr/bin/docker But I dont know the exact path to the executable. Isn't there a simple command that I can replace "/sbin/int 0" with, in order to see if this approach can work?

So...Nobody? I started messing up with /etc/acpi/acpi_handler.sh and I have replaced "/sbin/init 0" with "docker run ... " The system does not turn off anymore when I press the power button, but the docker command isn't being executed either. I do not know how this works and how to debug it, so any help will be appricated.

Do any of you know if this method still works? I know it's been a while, but I'm trying to replicate it and I cannot get my script to run. The server doesn't shutdown anymore tho, so I might be in the right direction.

Hi there, I am trying to run a custom command whenever the power button of the server is pressed. In particular, I'm looking for a docker run command. I found at this page that one way to do that is sysctl -w kernel.poweroff_cmd="/sbin/powerdown" So I replaced "/sbin/powerdown" with "docker run ..." But it is not working and the system is shutting down normally. The page also says that: Guess mine doesn't. Is there any other way to do this?

Yes I totally understand that. I will create a bug report and keep my fingers crossed. Thanks for the help

I do not plan to do that, but it will inevitably happen sporadically, since both the mover and the shutdown are scheduled.

Hello again, Parity check completed successfully (finding 0 errors), but the mover is still ignoring those files and so they are "stuck" on the cache drive. Today I will make another attempt by shutting down the system via the GUI button. What now? Can we officially call it a bug?

So basically unRaid uses COW in the case of useCache:yes and the source file cannot be corrupted, am I correct? I will still wait for this parity check to end, to see if unRaid can solve the issue automatically. I believe more tests need to be done, does the same behaviour occur when the shutdown is sent using the GUI or with the "powerdown" command in a terminal? (I read somewhere that "powerdown" is a cleaner way to stop the system) Thanks for your help guys

Alright, maybe I have understood what is happening. UnRaid this time noticed that something was off, this notification was shown: Automatic unRaid Non-Correcting Parity Check will be started Unclean shutdown detected I believe this happened every other time but I just ignore it because I didn't realize the mover was running. Probably unRaid will now wait for the parity check to end, and it will realize that the file was moved only partially and eventually invoke the mover again. Still, I need the parity check to be complete to verify this, so...See you tomorrow

I managed to reproduce the problem by pressing the power button manually, steps: Transfer a large file (mine was 271 GB) to a share that uses the cache pool Invoke the mover, or wait for its schedule, doesn't make any difference Press the power button, the system shuts down Turn on the system again The file that was being transferred is stuck on the cache drive and the mover will ignore it from now on A copy of the file is present on the array too (perhaps damaged, even if showing the correct size, as there is no way 271 GB were copied in a few minutes) So yes, it sounds like a bug in the shutdown/mover code. Could someone else try to reproduce it?

This is the code that simulates the pressing of the button (it pilotes a relay) gpio mode 0 out sleep 0.500 gpio write 0 0 sleep 0.250 gpio write 0 1 As you can see, the signal is up for less than a second. In fact, I never got problems about unclean shutdowns, it is just this mover "thing".

It is being captured because the system does turn off. Anyway, I haven't tried to reproduce it with the real power button yet, but tomorrow I definitely will.

Yes a short press is what I am simulating already, but that seems to generate the issue. How is the mover supposed to behave if system shuts down while running? Could someone else try to reproduce this?