JorgeB

I replied above.

Then please post that.

Was taking a second look since the first one was on the phone and it's not so easy to look at the log, and I did miss this line: Jun 30 17:43:58 Kaokulk kernel: BTRFS error (device nvme0n1p1): incorrect extent count for 19382927360; counted 1535, expected 1532 Fs is not going read-only, so this might not be the problem, but it is a problem, first time I remember seeing this error, so not sure how serious it is, you should make sure backups are up to date and attempt to repair the filesystem, or backup and re-format the pool, there's also this which I saw before: Jun 30 17:43:51 Kaokulk kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 Jun 30 17:43:51 Kaokulk kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme1n1p1 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0 Some data corruption was found at some time earlier, it might be from a while ago, still this is usually a sign of bad RAM or other hardware issue, if you don't re-format the pool you should reset the stats ad keep monitoring.

Correct. Before this was done by the GUI, but IIRC it was kind of a hack, and it didn't always work correctly, so it has to be done manually for now.

Try a different NIC if available, ideally an Intel one.

Resume from sleep it's not officially supported, in part because it's difficult to confirm all hardware works correctly with it, if you'd like to keep using it I suggest connecting that disk to a different controller if available or using a different model disk.

Did you notice if the 2 errors are on the same sectors? They are very close together, if you didn't correct parity and post new diags when it finds more sync errors.

That confirms it's a network problem, usually, NIC, switch, cables, etc.

Docker image is corrupt, delete and re-create.

It should mount after running xfs_repair.

Yes, but it's not 20.00.07.00

Start by running a single stream iperf test in both directions to see if it's network related.

Crashing while idle is a known Ryzen issue, see here.

You should also enable the syslog server and post that after a crash.

With 6.10 Unraid makes you disable spindown before being able to run a SMART test to avoid this exact issue.

It will shutdown based on the first hit of the 3 parameters set, in this case time to initiate shutdown, set that for 2 or 3 minutes, like mentioned you should avoid long time on battery, also at least here when the power goes out for more than a couple of minutes it will usually be a while.

It's not a pool problem.

No, but if you have a spare device available cloning would be my first option, no need to buy another program, just note that if cloning to a larger device it won't mount with Unraid, but you can use UD.

Sorry, typo, I meant a little half way past.

Flash devices come with some spare cells to replace ones that turn bad, for that device once the spare space gets below 10% you'd get a SMART warning, it's now at 0% and I assume the reason why the device is read-only. Also note that according to this the device was just a little half way past predicted life, but this is just an indication, I have one currently at 187% and still going strong.

It would be easy if the filesystem was still mounting, since it's not and it can't be fixed there are basically two options: use a file recovery util like UFS explorer or clone it to another device then run xfs_repair.

The device is in read-only mode, that's why xfs_repair is failing to write the corrections, you'll need to replace it and restore data from backups if available.

Try again, xfs_repair should always finish, with more or less data loss, do you remember if the device had some free space or was close to fully used?

And use -L if it ask for it.

Run it again without -n or nothing will be done.