JorgeB

Looks like this issue, though not so easy to say without the full log: See if this applies to you, if yes, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Ok, thanks, looks like your server is affected by the possible corruption issue, as long as you leave vt-d disable for now there shouldn't be any more issues, and hopefully a fix will come soon.

Thanks, so cache was mounting before updating, correct? And the diags are from the first boot with v6.10.2 or did you do any previous boots with this release?

Click on the first device of the pool then set the minimum free space you want.

This means btrfs detected corruption before writing the data to the disk, it usually indicates RAM or other kernel memory corruption.

This is the repeating line: Jun 8 02:56:31 Tower kernel: w83795 0-002f: Failed to read from register 0x02f, err -6 Can you try booting in safe mode? Or since it looks sensor related try uninstalling the system temp plugin.

Errors you're having suggest a possible RAM issue, start by running memtest, after that there are some recovery options here.

Note that since the extended SMART test failed you still have a disk problem, you can try another full disk write, it might remap the sectors, it won't on a read.

Yes, that will work.

I believe not, I assume you're using the UD plugin? If yes best to ask in the existing plugin support thread.

What's what the log suggests, some kind of power/connection problem, also note that in my experience Samsung SSDs are very picky with SATA cable quality, so still worth trying with different cables if you have some, recent locking cables that come with current motherboards usually work very well.

Looks like a power/cable problem, start by checking/replacing cables.

That doesn't look like a configuration issue, most likely cable, NIC, transceiver, switch, etc

Jun 9 11:21:41 Tower kernel: ixgbe 0000:01:00.0 eth1: NIC Link is Down Jun 9 11:21:44 Tower kernel: ixgbe 0000:01:00.0 eth1: NIC Link is Down Jun 9 11:21:45 Tower kernel: ixgbe 0000:01:00.0 eth1: NIC Link is Down Link is constantly going up and down.

Can't really help with NFS as I never used it, as for the SMB issue, did you confirm permissions were OK for these?

That doesn't mean it was formatted, you need to manually format every disk after it's added to the array, but that's not the case here, the disk was formatted before, though based on the transid it was barelly used: Jun 9 00:40:52 BIGASSNAS kernel: BTRFS: device fsid 0ce0630a-bf7e-4ce4-84f1-f598405bcb82 devid 1 transid 7 /dev/sdb1 scanned by udevd (1282) Note 'transid 7', this is a very new and unused filesystem, compare for example with your other ones: Jun 9 00:40:52 BIGASSNAS kernel: BTRFS: device fsid d9e9f710-02c9-41cb-bd9b-cfc93345fbc1 devid 1 transid 98843 /dev/sdc1 scanned by udevd (1289) Jun 9 00:40:52 BIGASSNAS kernel: BTRFS: device fsid 33232feb-7c0b-4e3c-bbef-a0925aae03c4 devid 1 transid 1334443 /dev/sdg1 scanned by udevd (1289) Jun 9 00:40:52 BIGASSNAS kernel: BTRFS: device fsid 41637979-6e3a-4dfc-a801-edcd1a8032b7 devid 1 transid 113884 /dev/sde1 scanned by udevd (1289) Jun 9 00:40:52 BIGASSNAS kernel: BTRFS: device fsid 812a0302-1349-4d0e-9703-5291c65db4d8 devid 1 transid 19303823 /dev/sdd1 scanned by udevd (1289) So if you just re-format pretty sure there wouldn't be much there, maybe nothing, but if you want to try and recover or confirm first there are some recovery options here.

This can also help with some common Ryzen related issues: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

This is normal with btrfs, not everything shows usage correctly, you can go by the GUI, or use: btrfs fi usage -T /mnt/cache

That's a kernel crash, don't see any clues for what caused it though, could be hardware related.

A couple of questions if you don't' mind, did you upgrade from v6.9.2 (or older) directly to v6.10.2? And was your cache unmountable before doing that?

What if you swap ports between those different pools, it would confirm the problem is with the ports or not.

Enable the syslog server and post that after a crash, it might catch something.

The colors in the dashboard have a different meaning, which can be confusing I guess, there it means those shares are set to cache only, if you click on "Shares" you'll see the green ball or orange triangle before each share name indicating if the shares are on redundant storage or not, though for pools it only checks the pool is multi device, not if it's actually redundant, so if for example the pool is raid0 it will show protected when in fact it's not.

You should have a remote console option that shows the same it would on a monitor, note that the output might be blank after a few minutes, you need to press any key in the remote keyboard, you should then see the normal login: Just login to Unraid and type the command there.

So far no.