JorgeB

Flash drive dropped offline: Aug 29 10:20:12 Abazuu kernel: usb 2-5: USB disconnect, device number 2 Aug 29 10:20:12 Abazuu kernel: xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. Aug 29 10:20:12 Abazuu kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 29 10:20:12 Abazuu kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 07 9f b9 00 00 1f 00 Aug 29 10:20:12 Abazuu kernel: blk_update_request: I/O error, dev sda, sector 499641 op 0x0:(READ) flags 0x80700 phys_seg 31 prio class 0 Aug 29 10:20:12 Abazuu kernel: blk_update_request: I/O error, dev sda, sector 499642 op 0x0:(READ) flags 0x80000 phys_seg 30 prio class 0 Aug 29 10:20:12 Abazuu kernel: blk_update_request: I/O error, dev sda, sector 499641 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Try a different USB port, ideally USB 2.0.

If you're starting over that's all you need.

On the main GUI page click on each disk and change fs from auto to XFS, start array, disks should now mount.

You have a plus license with 13 devices connected, it won't allow you to start the array unless you upgrade to Pro, note that if the array is started with 12 or less devices it will allow you to connect more and it will work until the next time you need to start the array again.

Enable syslog mirror to flash then post that after a crash.

It's a known issue with some upgrades, you need to re-enable user shares: Settings -> Global share settings

First need to fix this: Aug 25 21:21:13 Tower kernel: md: disk2 read error, sector=54793824 Aug 25 21:21:13 Tower kernel: md: disk2 read error, sector=54793832 Aug 25 21:21:13 Tower kernel: md: disk2 read error, sector=54793840 Aug 25 21:21:13 Tower kernel: md: disk2 read error, sector=54793848 Disk appears to be failing, extended SMART test will confirm.

One full disk write (not read) is usually enough to get rid of pending sectors, but they could or not comeback again soon.

If you just need the license from the current flash you only need the key file from the config folder, they redo the flash with v6 and restore the key.

Please post the diagnostics to check if a driver is being loaded: Tools -> Diagnostics (if booting in GUI mode) or just type "diagnostics" in the console.

Looks like under certain circumstances, e.g., if a new share is created, and then minimum free space is set, it doesn't take until next array start, and this happens with Krusader or MC, so you might want to try that also.

Please try doing the same thing with Midnight Commander (mc on the console), that will confirm if there's an issue with Krusader or some other thing. I did repeat the test I did yesterday with v6.10, since before I did it with 6.9.2, and the first time I did it with Krusader it did go well beyond the minimum free space set, curiously a 2nd try after rebooting worked as expected, so there might be something there.

See if the flash boots on another computer to confirm where the problem is.

That's a known limitation with pools, see here for better pool monitoring.

Posting them might help see what the problem is.

Best bet it to replace it with an LSI HBA based on the SAS 2008/2308/3008 chip.

This is usually a flash drive problem, try recreating it or using a different one.

Cache disk dropped offline: Aug 27 22:40:20 Tower kernel: ata9: COMRESET failed (errno=-16) Aug 27 22:40:20 Tower kernel: ata9: reset failed, giving up Aug 27 22:40:20 Tower kernel: ata9.00: disabled Check/replace cables but also check SMART once it comes back online.

Try a different flash drive if available.

Then it should go the the pool, if cache for share2 is set to "only"

It will if it's being moved from a different share and you are using user shares (/mnt/user/share) as source and dest, never move from user shares to disk shares or vice versa, fine to use disk shares only.

You can't do that after a disk is disabled, parity will no longer be valid, you need to rebuild the disk (or do a new config and re-sync (or correct) parity).

There's only one pool for any new written data, if you access the share you'll still see and access the data form any pool (and/or array disk) that contains that share.

Sorry but don't believe that could happen, if the settings were as they are now.

Disk1 has 135GB free according to your screenshot