JorgeB

Aug 6 19:13:44 UNRAID emhttpd: error: malloc_share_locations, 8948: Operation not supported (95): getxattr: /mnt/user/system

There's something creating /mnt/user/system before the array is started, this is not supported, and it's what is causing the problem, fix the script or whatever is creating that, and it should resolve the issue.

Try rebooting the server.

After resolving the RAM issue, you should scrub the pool to see if any errors are found, and then reset the stats, if there are uncorrectable errors, any listed files should be deleted/restored from a backup; probably also a good idea to recreate the docker image. There can also have other corrupted data in the array, but XFS can't detect that, so not much you can do unless there are preexisting checksums for all the files.

I don't see why it's failing; try reimporting the existing pools and then add the device once more.

on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 1 slots
assign the old pool device, leave the filesystem set to auto
start the array to import the pool

Then stop and try adding it again; if it still fails, post new diags

The root cause is memory exhaustion, with qBittorrent consuming about 6.5 GB of RAM, also seeing other signs of memory pressure on the server, so you may need to limit the RAM for some containers or increase the server RAM.

P.S in case you missed it, there are read errors on disk6, and they are logged as a disk problem.

Once a disk gets disabled, it needs to be rebuilt, SMART looks fine, and the emulated disk is mounting; assuming contents look correct, you can rebuild on top: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Recommend reposting in the plugin support thread, also include the diagnostics: https://forums.unraid.net/topic/136889-plugin-tailscale/?do=getNewComment

It will check the whole pool.

With different-sized devices btrfs can now use raid0, but not sure that was supported with the kernel in 7.2, so best to use single, with the array running type

btrfs balance start -dconvert=single,soft -mconvert=raid1,soft /mnt/home

Any there are any issues during the balance and it aborts, post new diags.

This is very bad news and a known issue, avoid splitting any Molex connector into more than 2, and never split a SATA connector into more than two; SATA plug doesn't have enough amps for more.

They have an existing partition that is too small; wipe them before with wipefs -a /dev/sdX, then restart the array and reformat. And since the disks were not cleared, best to run a correcting parity check after.

Reported ATA issues are with parity and parity2. Check/replace cables for both disks, could also be a shared power splitter if one is in use.

It should be fine to go directly to 7.3.1, read the release notes for 7.3.0 and 7.3.1, and always goof to create a flash drive backup just in case.

Drive as UDMA CRC errors; this is typically a bad SATA cable. Click the thumbs down to acknowledge the current value, if new errors come up, replace the cable.

You just do a normal license transfer; you can do it yourself if under the limit, or contact support if above it.

You won't, unlike a flash drive; TPM is not permanently blacklisted; it can be used in the future with a new license, or you could even transfer it back.

Jul 27 12:46:05 Tower webgui: /boot/config/plugins/dynamix/dynamix.cfg corrupted or missing

See if this file exists; if not, change a setting so that it gets created, e.g., a general disk utilization warning or temps; if it exists, delete it and recreate it.

Looks good for now; replacing the cables is a good idea to rule that out, if you notice any issues with Docker, recreate the Docker image.

The pool is currently only using one device; the other is missing.

First reimport the pool using only the good device (sdc)

on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 1 slots
assign the good pool device, leave the filesystem set to auto
start the array to import the pool

The pool should be imported degraded, since it's using single profile, you will need to use th CLI to correct it, with the array running type:

btrfs dev remove missing /mnt/cache

Now reimport the pool once more with the single device, it should now be imported without being degraded.

If yes, you can now add one device and then the other one.

-Tools -> New Config -> Preserve current assignments: All -> Apply

Then unassign one of the parity drives, if that's what you want; should leave parity1 in use.

Start the array to begin parity sync, and you can then also format disk7 at any time.

The OOM event was apparently caused by a Docker container that had a hard memory limit of 768 MB, and it reached it exactly, it wasn't a system-wide out-of-memory event.

Looks like this one: docker/b7215cfc67841485fb9a58cbb88ebde431e9206868bcc0364923718121f566c8

You are supposed to use a URL, not a local path, but see the release thread, there are some workarounds posted there

You can reimport the pool:

on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 6 slots
assign the 6 maan pool devices, leave the filesystem set to auto
start the array to import the pool

Make sure this has been taken care of: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

If that does' help, enable the syslog server and set the persistent syslog to be saved to a share, then post that after the next crash.

A full recovery seems unlikely to me, since, besides the missing device, the pool has write errors with one other device, and the pool was not fully redundant, possibly because of that:

Jul 2 11:07:25 Tower kernel: BTRFS info (device nvme0n1p1): bdev <missing disk> errs: wr 1873035, rd 89663673, flush 0, corrupt 1, gen 0
Jul 2 11:07:25 Tower kernel: BTRFS info (device nvme0n1p1): bdev /dev/sdb1 errs: wr 58, rd 0, flush 0, corrupt 120, gen 0
Jul 2 11:07:25 Tower kernel: BTRFS warning (device nvme0n1p1): chunk 1104150528 missing 1 devices, max tolerance is 0 for writable mount
Jul 2 11:07:25 Tower kernel: BTRFS warning (device nvme0n1p1): writable mount is not allowed due to too many missing devices

You can try these recovery options here to see if you can save some of the data, but likely the pool will need to be reformatted in the end

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

It's not logged as a disk problem, looks more like power/connection issue, Check/replace cables, also any power splitters in use?

The boot pool is using both devices, but the data partition is only using one of them, if you are OK with formatting the data partition, it should be possible to start the array after clicking the 1st pool device and then "erase pool" (any data on the data partition would be lost), if there's data there, you would need to mount that filesystem manually, copy its data, then reformat.

If you need to mount the filesystem manually, this should work.

mkdir /x
mount -t btrfs /dev/nvme0n1p4 /x

You can then access the data under /x