JorgeB

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

There's nothing logged about the crash, one thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Flash drive problems, try a USB 2.0 port instead.

Because it's safer that way, metadata uses very little space comparatively and you'll have redundancy there, but if you really want you can force metadata to raid0 also using the CLI.

Most likely.

There shouldn't be anything that would cause this just by using Unraid, same or different controller with Ubuntu?

No without the diags, after trying to assign a SAS device please.

It still can be, if you do large transfers it can take about 3 times longer than a non SMR drive. That's males much less of a difference.

That's OK, as long as there's no warning on the right side that "all data on this device will be deleted at array start" you can just start the array, if it doesn't mount run another filesystem check but without -n.

Config looks fine to me, how are you copying to the share?

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

Strong possibility.

Those are SMR, they work but will be slower for large writes.

You can easily recreate the docker image: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564309

No, it will take effect for any new written data.

Cache device dropped offline: Jun 12 07:00:22 BokunoNAS kernel: ata3: hard resetting link Jun 12 07:00:57 BokunoNAS kernel: ata3: softreset failed (1st FIS failed) Jun 12 07:00:57 BokunoNAS kernel: ata3: limiting SATA link speed to 3.0 Gbps Jun 12 07:00:57 BokunoNAS kernel: ata3: hard resetting link Jun 12 07:01:02 BokunoNAS kernel: ata3: softreset failed (1st FIS failed) Jun 12 07:01:02 BokunoNAS kernel: ata3: reset failed, giving up Jun 12 07:01:02 BokunoNAS kernel: ata3.00: disabled If this is with a new cable try a different port, make sure you also replace/swap the power cable, if that fails try a new device, if available.

VMs are stored in libvirt.img, that's a file you should regularly backup but it's not on the flash drive.

Please post the diagnostics: Tools -> Diagnostics

Not currently, multiple arrays have been mentioned as a future upgrade, but no ETA for now.

That's not so strange since TV\ Shows was a different share, and it would use the default allocation method, high-water, though it's strange that the TV\ Shows share was not appearing on the diags.

It's not, if you start another parity check now does it run at the normal speed?

Weird, rsync command looks good to me, check that TV Shows share is still set to fill up and continue transfer, but check if another TV\ Show is created, you can try escaping the space, like so /mnt/user/TV\ Shows/

What do you mean permutations? You just needed to start the array without any pool devices assigned, then re-assign both, that should have done it.

Took another look a the last diags to see if the emulated disk was mounting and there are more disk errors, now disk4: Jun 10 17:07:44 Warptower kernel: sd 11:0:2:0: [sdd] tag#801 ASC=0x4 ASCQ=0x0 Jun 10 17:07:44 Warptower kernel: sd 11:0:2:0: [sdd] tag#801 CDB: opcode=0x28 28 00 ae ad 2b 40 00 03 38 00 Jun 10 17:07:44 Warptower kernel: blk_update_request: I/O error, dev sdd, sector 2930584384 op 0x0:(READ) flags 0x0 phys_seg 103 prio class 0 Jun 10 17:07:44 Warptower kernel: md: disk4 read error, sector=2930584320 Jun 10 17:07:44 Warptower kernel: md: disk4 read error, sector=2930584328 Jun 10 17:07:44 Warptower kernel: md: disk4 read error, sector=2930584336 Jun 10 17:07:44 Warptower kernel: md: disk4 read error, sector=2930584344 Looks more like a power/connection problem.

After the folders are renamed there will be new shares, movies and music, they will have the default settings, so you need to check the settings, likely split level, allocation and mostly minimum free space.