Waves00

I'm getting the same error and keep having crashes as described in this thread.

Would it be ok to delete the system folder from disk1? I have set the system folder to have the cache ssd as the primary storage. I disabled docker and vm manager then invoked mover. The system folder moved the cache. However I still see a system folder on disk 1 with a docker folder and image in it. The modified times are the same on both folders. Disk1 is the disk that the diagnostics log reports never spins down because it's busy all the time. I'm wondering if this duplicated system folder is related to that issue. Should I delete it off disk1 even though the date modified is the same as the cache drive system folder?

New problem: I tried to turn on unraid for the 1st time today and it repeatedly goes to the bios screen. Never actually boots the usb drive despite me clicking it in bios and setting it as the 1st boot item. This is a brand new samsung 256gb flash drive (I know it's excessively large but it was the only brand new usb stick I had). I flash this usb stick yesterday using a backup of the original usb stick. Fixed the boot problem: The EFI folder renamed itself "EFI-" for some reason. I deleted the dash and it started again. So back to the original problem of not being able to shutdown cleanly.

I'm pretty sure I have this same issue on 6.12.4. I do not have any ssh sessions open when it happens. Disabling docker in settings reliably fixes the issue. Is there some kind of fix for 6.12.4 other than having to manually unmount docker.img? Having to manually unmount docker is inconvenient. Disk1 always refuses to unmount. tower-diagnostics-20230930-1519.zip

Update: I tapped the power button and those picture above show it started running the shutdown script however it's been 15 minutes now and nothing has happened. The shutdown delay is 7 minutes (420 seconds as mention in the OP). It should have shutdown by now. I had to power it off by holding the power button because 25 minutes after tapping it, nothing was happening. Prior to that I tried plugging a keyboard. The screen updated to show it recognized a keyboard was plugged in but I wasn't able to type anything. Pressing keys didn't result in any letters appearing on the screen.

I left it running overnight and now it's not accessible at all. I tried ssh and the gui also doesn't work. The browser says it can't find the ip address or hostname depending on which I try. So I'm going to have to unclean shut it down using the power button. I don't have any backups running. The only thing running is that jellyfin docker container. I plugged a monitor in and tapped the power button. This is what appeared. It was initially a black screen until I touched the power button. The ip address has changed compared to what it was yesterday. It still doesn't respond to the hostname and that is shown as unreachable in a browser. Using the new ip from the pictures 192.168.0.29 gets a time out error.

I recently installed docker so I could run Jellyfin. I also added an intel arc gpu for transcoding and an ssd for cache. It's been running fine and the GPU works. However I quickly found that if I press shutdown or reboot in the gui while the docker is running I get an unclean shutdown. After reading the unclean shutdown pinned post: I increased the docker time out to 90 seconds and the unraid shutdown delay to 420 seconds but I'm still getting unclean shutdowns. It's getting annoying because as expected it keeps running parity checks after every unclean shutdown. I replaced the usb drive trying to see if that would help but the issue persists. I've also tried manually stopping the docker jellyfin container using the stop button in the gui on the docker container page. I press stop there, wait until the container says it is stopped then I go press the server reboot or shutdown buttons. I still get an unclean shutdown. Unclean shutdowns used to never occur. Up until now, I've never used docker either. I have attached my diagnostics zip. Is there anything that indicates what could be refusing to stop in the allotted 420 sec shutdown delay period? tower-diagnostics-20230930-1519.zip

Running sync with apply parity fixes corrected the ~9400 errors it detected the first time. I then ran sync again but with fixing parity disabled. It detected 0 errors so it looks like it is fully functional again. I did see a folder with a random name when I was looking through files on the network share. I'm guessing that is the folder which I was copying onto the server when it abruptly powered off. It has a name which I didn't use. I'll delete it and continue transferring items like I was doing before the motherboard/processor started failing.

I see, didn't know it was real time parity. I'll stop the current check and change it to a correcting parity check. I did have multiple unclean shutdowns. It would run for random amounts of time before shutting off abruptly. Sometimes hours sometimes less than an hour. If it happens again, the only remaining part are the memory sticks (or I suppose a cable but that seems unlikely). It had been going for a little over a day before I thought it was safe to try transferring more files onto it. I had run a few checks between abrupt shutdowns and they came back as 0 errors but I wasn't moving files during any of those shutdowns. I'll see how the parity repair goes and what the non-repair check shows after. Thanks!

I was transferring files from a usb drive to the unraid storage when the server shutoff unexpectedly. It was on a UPS. I believe I had a bad processor or bad motherboard. I couldn't narrow it down and decided to replace both. I had been troubleshooting this unexpected power off issue for awhile and thought I had it fixed with a new power supply. But I was wrong and this time it powered off during a transfer. I got a new motherboard and processor. It's running well now. I wanted to make sure the drives were ok since it got interrupted mid-download moving files from the usb drive to the server. The usb drive was plugged into a usb port on the server. I'm seeing a lot of sync errors though. I set it to check for errors but not correct anything yet because I wasn't sure how to handle this situation. I'm new to Unraid. Could these sync errors be present because some of the files that were successfully transferred had not been added to the parity information yet? Or maybe they are only a result of the dirty abrupt shutdown and the interrupted files copying. I had been moving a lot of files onto the server that day and hadn't done a parity update that day. I'm wondering if new files that have not been added to the parity info, appear as sync errors. I know in ZFS that can happen but Unraid is Btfrs. With ZFS I know if you add files to the drives then do a parity check, the check can report errors because the drives no longer match the parity. You have to update the parity to include the new files so the parity check doesn't think the new files are mistakes. What do I do now that there are errors? Run the sync again but this time allow it to apply fixes? Thanks tower-diagnostics-20201105-2026.zip