I've been battling this strange issue since I swapped motherboards. Within a day to week timespan, UnRaid will go offline without warning, but the PC will be perfectly fine. I've done tinkering in the BIOs, turning off Intel C-State, keeping my RAM below 3200 mhz, running a memtest on them (they passed), and booting it in safe mode (it didn't crash, but it was less than a week and I needed my plugins). I even suspected it was my router provided by my ISP and bought an aftermarket router to see if that was the problem. But nope! UnRaid crashed again last night.

I finally managed to have it crash while having the syslog write to the flash drive, it's attached to this post along with the diagnostics. Can anyone find the root of the issue? I'm really hoping I can get some peace of mind and solve this strange issue once and for all.

It's been crashing before I switched to the router last night, and I suspect the cause might be having to switch the internal IP address. But if there's more issues at hand, I'm more than willing to adjust my settings! 😀

helios-diagnostics-20230225-0802.zip syslog.txt

Are you using any docker apps with dedicated IP addresses (or set to network type br0 with a dynamic address)

 

If so, you will attain higher stability by switching the network type from macvlan in Settings - Docker (with the service disabled) to be ipvlan.

 

Also (either caused by the crashes or bad memory) 

Feb 24 22:11:51 Helios kernel: BTRFS error (device nvme1n1p1): block=87024451584 write time tree block corruption detected
Feb 24 22:11:51 Helios kernel: BTRFS: error (device nvme1n1p1) in btrfs_commit_transaction:2418: errno=-5 IO failure (Error while writing out transaction)
Feb 24 22:11:51 Helios kernel: BTRFS info (device nvme1n1p1: state E): forced readonly

I'll let @JorgeB advise on the btrfs recovery, but personally I'm not a fan of using BTRFS on single device pools.  You will always obtain better stability on the pools / filesystems by using XFS unless you require the features of btrfs (of which they are minimal on a single device)

2 minutes ago, Squid said:

Are you using any docker apps with dedicated IP addresses (or set to network type br0 with a dynamic address)

 

If so, you will attain higher stability by switching the network type from macvlan in Settings - Docker (with the service disabled) to be ipvlan.

 

Also (either caused by the crashes or bad memory) 

Feb 24 22:11:51 Helios kernel: BTRFS error (device nvme1n1p1): block=87024451584 write time tree block corruption detected
Feb 24 22:11:51 Helios kernel: BTRFS: error (device nvme1n1p1) in btrfs_commit_transaction:2418: errno=-5 IO failure (Error while writing out transaction)
Feb 24 22:11:51 Helios kernel: BTRFS info (device nvme1n1p1: state E): forced readonly

I'll let @JorgeB advise on the btrfs recovery, but personally I'm not a fan of using BTRFS on single device pools.  You will always obtain better stability on the pools / filesystems by using XFS unless you require the features of btrfs (of which they are minimal on a single device)

I did, Nginx Proxy Manager, I disabled it however when I couldn't figure out how to make it play nice with my router. The crashes were happening well before I installed that container however. I will try switching it to ipvlan, then.

I did try switching the file type for that particular drive to xfs, but it wouldn't mount after I rebooted the server. It's not super important, just my downloads cache for my downloader containers, so I don't mind formatting if necessary. Are there any tutorials on switching the filesystem gracefully?

4 minutes ago, GPEcho said:

but it wouldn't mount after I rebooted the server.

Requires you to format

13 minutes ago, GPEcho said:

Are there any tutorials on switching the filesystem gracefully?

There is this in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Thank you everyone. While it might be too soon to say if this is what's causing UnRaid to crash, changing the docker settings to ipvlan was the only thing that I hadn't thought to do, so I'm going to cautiously say that Squid's suggestion will be my current solution unless it crashes again in a week.

15 hours ago, Squid said:

write time tree block corruption detected

This indicates data corruption was detected before writing the data back, and it's usually the result of bad RAM.

12 hours ago, JorgeB said:

This indicates data corruption was detected before writing the data back, and it's usually the result of bad RAM.

Dang, looks like I’m not out the woods, then. Does that mean I should run an extended memtest?

Yes