JorgeB

Type mv /boot/config/pools/cache.cfg /boot/config/pools/cache.bak Then reboot

FWIW, I can copy all the sample files from my Windows desktop to an Unraid share root@Tower7:~# ls -l /mnt/user/Temp/test total 154496 -rwxrw-rw- 1 user users 28673056 May 17 21:56 1\ -\ fail\ (ORIGINAL\ FILE).zip* -rwxrw-rw- 1 user users 28673056 May 24 10:24 1\ -\ fail\ (ZIP\ repacked\ -\ Store\ method).zip* -rwxrw-rw- 1 user users 28364023 May 24 10:26 1\ -\ pass\ (ZIP\ repacked\ -\ Deflate\ method).zip* -rwxrw-rw- 1 user users 28381062 May 17 20:48 1\ -\ pass\ (ZIP\ repacked\ to\ 7Z).7z* -rwxrw-rw- 1 user users 13269448 Mar 15 2024 2\ -\ fail\ (ORIGINAL\ FILE).zip* -rwxrw-rw- 1 user users 13269448 May 24 10:30 2\ -\ fail\ (ZIP\ repacked\ -\ Store).zip* -rwxrw-rw- 1 user users 13046221 May 24 10:29 2\ -\ pass\ (ZIP\ repacked\ -\ Deflate).zip*

If it happens with multiple flash drives, it suggests a hardware issue, since this is not normal behavior. To rule out a config problem, you can boot with a different flash drive using a stock install, no key needed, and then see if a stock install has the same issue, if yes, it can only be hardware.

I think you will just need to try and get those files in a different format

65536 bytes = 64 KiB, this is a standard SMB2/SMB3 write chunk size, not a limit being hit. Try adding this to SMB Extras: veto oplock files = /*.zip/*.MSI/*.msi/*.ZIP/

That suggests to me an antivirus or similar is interfering with the files on the source

Since the scrub is aborting, the filesystem has some issues. I recommend backing it up, reformatting, restoring the data, then monitoring the pool for any new errors.

You can use the Limine boot with 7.3 if booting from a flash drive, if you use an internal boot pool, you can use the stock Unraid bootloader (since it uses a different one with internal boot)

You can turn it off once the server receives the reboot comamnd. If the flash drive keeps needing reflashing, there may be an issue with it; I would recommend trying a different one. Alternatively, with 7.3.0, you can boot from an HDD/SSD.

That SSD would be better assigned as a single pool, since SSDs cannot be trimmed when assigned to the array.

UTP version works with 7.3.0 using the stock driver, SFP+ version requires a newer kernel/driver

Best bet is to look for the support thread for that container:

Disk2 looks OK.

See if you get the syslog after it hangs cp /var/log/syslog /boot/syslog.txt Then attach here, or enable the syslog server and post that.

Try this, open a terminal window and type or copy/paste unraid-api stop unraid-api restart Try again to register from the dropdown

You should also scrub the pool to confirm there are no uncorrectable errors.

I don't see a way to import the pool with the new drive. The old one shows online but may be out of date. You try to go back a few TXGs to see if can be imported (with the old drive connected). zpool import -FX zraid If that still fails, I'm afraid you may need to destroy the pool and recover from a backup.

It may be worth a try, but before that, post the output from zpool import -d /dev/disk/by-id/

It's an issue with the plugin; sometimes it doesn't install everything correctly.

Open a terminal window and type: unraid-api plugins install unraid-api-plugin-connect Then refresh the GUI; that should get the icon there.

Possibly, try zpool import -F pool_name if that fails, post the output from zdb -l /dev/sda1

If it's only python that keeps segfaulting, it could be an issue with a specific container or plugin. Try booting in safe mode, leave Docker disabled, and retest, if OK, start enabling the container one by one, or a few at a time.

For which device did you run labeclear? I wish you had asked for help earlier. There are now two invalid disks for a raidz1 pool, so the pool cannot be imported.

Enable the syslog server and post that fater the next crash.

The device is still dropping, if the kernel parameters don't help, best bet is to try using a different brand/model device or a different board.