JorgeB

It should, you can also try to backup and reformat that flash drive first.

Enquanto o disco de 6TB não chegar pelo menos a meio será para onde irão todos os dados, independentemente da opção de alocação escolhida, se não é isso que está a acontecer adiciona um print screen de main e os diagnósticos: Tools -> Diagnostics

Please post the diags: Tools -> Diagnostics

If the problem follows the drive the drive itself is likely the issue.

You can.

Unfortunately no, since docker interactions with the filesystem aren't/can't be logged.

If it wasn't the mover it's likely some docker you're using, especially dockers that handle files, extract, rename, move, etc.

Same issue as this one, rebooting will fix it, not quite clear what the underlying cause is, possibly a fuser bug caused by mover/docker trying to access files that were already deleted/moved.

FYI looks like a problem with the Marvell controller, it dropped all disks there connected, not so unusual and one of the reasons we don't recommend Marvell controllers with Unraid.

You can just google it, one of the first results: How to Use Midnight Commander, a Visual File Manager

It's a problem with the onboard SATA controller, quite common on AMD boards, there are reports that running the latest beta helps due to newer kernel, disabling IOMMU should also help if not needed. Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00000 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00180 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00280 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00300 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00400 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00480 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00580 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00680 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00700 flags=0x0020] Sep 6 16:48:22 Ewing kernel: ahci 0000:46:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff00800 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00880 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00980 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00a00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00b00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00c00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00d00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00e00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00f00 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff00f80 flags=0x0020] Sep 6 16:48:22 Ewing kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=46:00.0 domain=0x0000 address=0x000007fffff01000 flags=0x0020]

Most free won't affect writes to cache, those will be the same independent of the allocation method used, it will only make a difference when writing to the array directly or when running the mover.

Please post the diagnostics: Tools -> Diagnostics

Check/replace cables on the parity disk, but likely unrelated to your other issue.

Yes cache is corrupt and needs to be re-formatted, some recovery options here if needed, but that's not the only issue, shfs also crashed later, that's what's causing those "transport endpoint" errors: Sep 6 16:00:01 Tower kernel: shfs[3059]: segfault at 0 ip 0000000000403bd6 sp 000014fcc136b930 error 4 in shfs[403000+c000] Sep 6 16:00:01 Tower kernel: Code: 89 7d f8 48 89 75 f0 eb 1d 48 8b 55 f0 48 8d 42 01 48 89 45 f0 48 8b 45 f8 48 8d 48 01 48 89 4d f8 0f b6 12 88 10 48 8b 45 f0 <0f> b6 00 84 c0 74 0b 48 8b 45 f0 0f b6 00 3c 2f 75 cd 48 8b 45 f8 Sep 6 16:00:01 Tower move: move: create_parent: /mnt/disk2 error: Software caused connection abort Sep 6 16:00:01 Tower move: move_object: /mnt/disk2/system: Transport endpoint is not connected Sep 6 16:00:01 Tower move: system: Transport endpoint is not connected You'll need to reboot to fix that.

Nothing being logged suggests a hardware problem, but try booting in safe mode and leave all dockers/VMs disable, if it still crashes like that it's most likely hardware related, if not start turning all the services on one at a time.

Please don't crosspost, and this is the wrong forum for this question, anyone wanting to reply do it here:

Please don't double post:

Everything looks fine from what I can see, are you having some issue?

Please post the diagnostics: Tools -> Diagnostics (boot using GUI mode if LAN is working)

Post the diags before rebooting, it might show the problem.

No. Correct. Would think so, but if the emulated disk is unmountable run a filesystem check, some corruption is possible due to starting the array when you did it to identify parity, if that doesn't work best bet is running a partition repair utility like testdisk on those disks, then if it can be fixed mount the disks with UD and copy the data to the array.

Just need to add for the way you normally boot, usually the 1st option unless you boot with GUI mode. No.

Delete/rename network.cfg and network-rules.cfg on the flash drive (both on the config folder) and reboot, that will revert LAN settings to default, then just reconfig.

You can, one at at time if, and it's a big if, data is still valid on those drives, just partition info is missing, still nothing to lose to try, at least up to the emulated disk, again just rebuild on top if the emulated disk mounts and contents look correct. Not with single parity, you'd be doing a procedure similar to this, though for a different reason: